Tilegame : interactions à la souris et déplacement
Par -Alexandre LEGOUT aka LAlex- le 1 décembre 2003, 14:48 - Projets - Lien permanent
Mon petit moteur de tilegame continue à avancer comme il peut, toujours en MVC "fait-maison" ... 
J'en arrive maintenant à une iteraction à la souris, et au déplacement d'un élément suivant un chemin (accessoirement trouvé avec mon pathfinder A*) ...
Tout d'abord, je me rend compte que mon pathfinder "mis en situation" semble bien fonctionner. Même si c'est vrai que l'espace de recherche est plutôt réduit dans cet exemple, vous remarquerez qu'il n'y a pas de temps de latence (notable) entre le clic sur une case et le départ du l'objet. Et ca, j'en suis assez content ! 
J'ai passé un petit moment à réfléchir sur la manière de faire suivre un chemin à un objet, et également à avoir la possibilité de faire se déplacer plusieurs objets en même temps, en ayant des performances correctes. J'en suis arrivé à créer des propriétés _path et _pathPos pour chaque élément. La première contient un tableau renvoyé par le pathfinder, dont chaque élément est un objet ayant les propriétés x et y. Là deuxième est l'indice de la position actuelle.
Les éléments possèdent également une méthode next ... Qui déplace l'objet a la position suivante, et renvoie un booleen qui spécifie s'il reste encore du chemin à faire. S'il est faux, on est au bout du chemin. J'utilise également un système équivalent à la gestion des évenements par Flash. C'est un tableau contenant tous les objets en mouvement. Si un objet arrive au bout de son chemin, il est retiré du tableau. Pour faire bouger un objet, il suffit de lui attribuer un chemin, et de l'ajouter au tableau.
Ainsi, le modèle contient les méthode addMoving, removeMoving, et moveForward, cette dernière faisant avancer tous les objets en mouvement d'une étape. C'est également moveForward qui est appelé dans un intervalle (setInterval) pour simuler le mouvement.
Un aspect pratique est de créer une méthode findPath à laquelle on passe un élément, et des coordonnées d'arrivée. Cela permet de choisir une autre destination pendant le déplacement de celui-ci. Il suffit alors juste de changer le chemin à parcourir pour l'objet, et il continue de se déplacer sur son nouveau chemin. 
Commentaires
Salut LAlex
Est-ce que ton moteur actuel gère la vitesse de déplacement des éléments? Un monstre en forme de limace par exemple..
Et puis je me pose une 'tite question pour ma part du côté de mes recherches à moi. Comment gérer efficacement le passage d'une case à l'autre? Je vois que toi, comme moi, tu fais se "téléporter" le personnage directement à la case suivante. C'est la méthode la plus simple, mais côté rendu, ça laisse un peu à désirer le trouve... Seulement, si on ajoute un déplacement "doux", et que le joueur change de trajectoire en étant au milieu d'une case, il faut gérer le replacement, et c'est plutôt lourd... En plus, coté coordonnées, comment gérer ça ? Position (2.12;4.27)? C'est pas super non plus...
J'avais pensé affiner la grille de calcul par rapport à la grille réelle, mais ça boost le temps de calcul du pathfinder.. Une idée? :p
Je n'y suis pas encore au déplacement inter-cases, mais c'ets vrai que ca va venir, le déplacement est trop brusque comme ca. Mais j'avais pensé à un système évenementiel. L'élément emets un évenement quand il arrive sur sa case de destination, il dis "Je suis arrivé", et le modèle lui donne sa prochaine destination (prochaine case voisine à atteindre).
Pour le changement de direction, je pense qu'il suffit juste de faire le pathfinding à partir de la case de destination que le perso doit atteindre : ainsi, tu remplaces la fin du chemin actuel par le chemin vers la nouvelle destination, qui celui-ci part de la case que le perso s'apprête à atteindre. On verrais pas de changement "brutal" comme ca ...
A+
J'utilise des queues aussi pour les déplacements d'objets dans mon moteur iso. Pour les changements de destination je fais exactement comme te le suggére LAlex, je vide la queue de l'objet en question pour la remplacer par la nouvelle.
Yesssss! Mon système est pas trop mauvais alors !
C'est pas con, ça, d'en faire un évènement -_- J'ai un peu de mal avec les évènements moi... On va dire que je suis dépassé par les évènements. (Wow, je suis vraiment super drôle :D)
Merci bien ^^
Moi aussi dans les quelques expériences que j'ai eu avec ce genre de truc, j'ai utilisé une queue. Mais pour assurer une vitesse constante en multiplayer, j'envoie des "parties" de la queue seulement...
C'est peut-être pas la meilleure méthode, mais c'est ce que j'avais trouvé de mieux à l'époque. Par-exemple pour un chat avec avatar utilisant FCS (pas tile-based), le client envoie à tous les autres ses 5 prochaines positions. À la réception des 5, les persos avancent en utilisant ces 5 positions. Mais lorsque le client (celui qui a envoyé son déplacement) recoit sa propre queue de 5, il déplace de un et renvoit aussi encore les 5 prochaines à tout le monde. À la réception par chacun, le déplacement et ré-évalué en fonction de la position actuelle et des 5 nouvelles reçues.
J'ai utilisé cette technique pour contrer de trop grandes différences de vitesses des personnages, la vitesse variait beaucoup trop selon la vitesse de connection des usagers (on a des usagers sur modem 56k...).
Cette technique permettait d'avoir un client qui fait le "métronome" et aussi de gèrer les changements de directions. Et en envoyant pas toute la queue, la vitesse est constante...
Je crois pas que ce soit le truc optimal, je n'ai que joué brièvement avec le pathfinding et le multiplayer, c'est pas vraiment ma spécialité... Mais c'est un bon petit truc qui a fonctionné assez bien...
stef >> J'adore ta technique : c'est super futé !
Je suis tombé par hasard sur cette source en faisant des recherches sur les pathfinder sur le net ..
Et je me permet de te dire que ta source est la plus efficace de toutes celles qu'il m'aient été données de voir en Flash !
Elle mériterait un meilleur environnement graphique afin d'avoir un rendu digne du code !
J'aurais bien une solution pour éviter les sacades dans les changements de direction :
laisser le personnage/monstre arriver à la case et ensuite changer de direction.
Certe, ça fait perdre un peu de temps, mais ça a l'avantage d'être simple et pas trop prise de tête.
Moi qui sius en train de bosser sur un moteur 3Diso, j'avoue que ça me botterais bien de pouvoir faire qqch à partir de cette source .. mais comme je ne code pas encore en AS2 (oui, je suis graphiste à la base) cette source m'est complètement inaccessible !
ou alors je me met à MX2004, mais là, je vais en Ch....
Fil des commentaires de ce billet