Tilegame et mouvements : model or not model ?
Par -Alexandre LEGOUT aka LAlex- le mardi, décembre 2 2003, 17:59 - Projets - Lien permanent
Je continue à avancer sur mon moteur de tilegame, et je viens de rajouter les déplacements "en douceur". Ca consiste tout simplement à ne pas téléporter un élément d'une case à une autre, mais de le déplacer progressivement.
C'est en implémentant cette fonctionnalité que je me suis rendu compte d'une erreur que je pense avoir fait lors de ma précédente version : le modèle n'a pas à gérer le déplacement, mais uniquement le position actuelle de l'objet, et ses prochaines positions.
En fait, précédemment, le modèle s'occupait de faire passer les éléments d'une étape à une autre au moyen d'un setInterval. Aprés réflexion, je pense que c'est la vue qui doit demander au modèle la prochaine position de l'objet et l'afficher. Et encore plus quand le déplacement est progressif : en effet, un objet en position (1.2, 3.5) ne veut absolument rien dire pour le modèle. Cela à un sens uniquement pour la vue. ![]()
Du coup, c'est la vue qui stoque une liste des objets en mouvement. Maintenant, le setInterval s'est déplacé sur la vue. Le modèle dit "Tel élément doit aller à tel position". La vue déplace cet élément, et une fois que l'objet est à destination, la vue dit au controleur "Je suis arrivé". Le controleur demande alors au modèle d'informer la vue de la prochaine position de cet objet, etc... 8| Je sais pas si c'est exactement comme ca que dois fonctionner le MVC, alors si des experts de ce modèle de programmation passent dans le coin, manifestez vous ! ![]()
J'ai également un peu modifié la gestion du chemin. Auparavant je parcourais un tableau de positions en incrémentant l'index de la position courante. Maintenant, je fais un shift du tableau, et je récupère la position à l'index 0 à chaque fois ... C'est bien suffisant, et en cas de changement de direction, c'est plus logique ... ![]()
Commentaires
Hmmm... Si j'étais à ta place, j'agirai de la sorte :
Je garderai les déplacements au niveau du modéle (car le modéle doit forcément connaître la position d'un objet à un instant t et surtout s'occuper de gérer lui-même les déplacements de celui-ci, du moins ça me semble mieux encapsulé de la sorte), les données doivent absolument par contre rester sous forme de matrice (ex : [3,3]), car il s'agit que du modéle, qui se doit de rester le + abstrait possible.
Le view est à l'écoute du modéle, dés qu'il reçoit un broadcast de changement de position (avec la durée en ms pour passer d'une case à une autre de la matrice par exemple) il s'occupe de l'interpréter. Je veux dire par la que si c'est un view 2D que tu implémentes, il ne fera forcément pas les même démarches (calculs en pixels) que si c'est un view 3D Iso : D'où l'intérêt du MVC.
Pour conclure et résumer, je chosirai le modéle pour jouer le séquenceur et temporisateur des modifications de ses propriétés (le view ne devant pas être concerné à mon humble avis par cet aspect des choses) et le view pour retranscrire une interprétation des données du modéle qui soit propice à l'application choisie.
Voici ma modeste contribution et vision du probléme
petepx >> Je crois que j'ai mal expliqué alors ! °:|
Je pense que j'ai fait comme tu me l'expliques : quand le view recoit un évenement de changement de position, il effectue le déplacement "visuel". A ce moment la, le modèle contient comme coordonnées celle de l'arrivée : il sait donc où se situe l'élément. Une fois arrivé à la destination de ce déplacement "visuel", il le dit au controlleur, qui le dit au modèle. Le modèle change alors à nouveau la position de l'objet, puis envoie un évenement au visuel, etc...
En fait, je pense que la confusion vient du fait que je parle du fait que "c'est la vue qui stoque une liste des objets en mouvement" ... C'est pour ne boucler que sur les éléments en mouvement dans un seul setInterval
petepx >> Je reviens sur ce que tu as dit. En fait, je ne suis pas tout à fait sûr de bien comprendre ce que tu as dis : le modèle devrait être au courant de la position d'un objet lorsqu'il est entre deux cases ? :o
Et pour lui passer la durée du déplacement par exemple, ca oblige à faire un setInterval par élement ca non ? :o
A mon humble avis, le modéle doit être au courant si un objet est en cours de transition entre deux cases et où il en est, il doit aussi gérer les temps de transit d'une case à l'autre.
Le view doit être seulement la pour faire écho de ces modifications aen temps réel avec son kaleidoscopage des données (ex: longueur/largeur d'un tile, offsets ... ).
Pas obligatoirement, rien ne t'empêche d'avoir un séquenceur principal qui tourne très vite, et réajuste toutes les valeurs en fonction des vitesses décrites (low level events), quand un des éléments est arrivé à sa case de destination, le séquenceur récupére dans la queue (high level events) son mouvement suivant (s'il existe), sinon il continue d'interpoler.
Tu peux si tu préféres sinon instancier un Tween ou déclarer un setInterval par objet, mais c'est moins élégant je pense.
Voilà pour mes modestes idées.
J'espére que je suis clair
Super, merci pour ton avis éclairé !
Je vais essayer de "digérer" ca et le comparer à ma manière de voir les choses pour une amélioration de mon système actuel ... ^^
y a un bug quand tu fait onRealseOutSide, la nouvelle position n'est pas prise en compte et le contour rouge reste
Y a que toi qui pense a faire des trucs comme ca .. :?
salut
ben moi je trouve ça instructif ce bug
tu as donc deux états pour chaque clip (out/over) ? Moi je pensais par souci d'optimisation, de gain de poids avoir un clip unique (un carré rouge) et le déplacer en fonction des coordonées de la souris et du type de case qui se trouve en-dessous 

Après il est clair que cette solution peut poser des problèmes à partir du moment où on gère les "hauteurs"
ciao
c'était peut-être pas très clair mais en fait c'était une question :lol:
j'me demandais lequel est le mieux :
- deux états (minimum) par clip : over & out
- ou alors un clip "carré" que l'on déplace en gérant les coordonnées de la souris
pour ma part je prendrais la deuxième solution, mais après si je veux gérer les hauteurs c'est vrai que ça peut poser quelques problèmes. D'un autre côté, deux états par clips (surtout si on utilise du .png pour les gfx) ça va faire lourd aussi...
z'en pensez quoi ?
ciao

wuastc
C'est pour l'instant une question que je ne me suis absolument pas posée !!!
La solution d'un seul carré ma parait pas mal ... 
En cas de gestion des hauteurs, peut-être faire un carré par couche à ce moment la ? Seulement, ca empêche de faire un effet par "type" de case (quand on passe au dessus d'un objet ou d'un héros par exemple ) ... :roll:
le gros problème est pour moi de savoir sur quel niveau veut aller l'utilisateur.
En effet si deux niveaux se superposent (par exemple si j'ai une map qui représente un paysage avec un cours d'eau et un pont qui l'enjambe) comment faire savoir au moteur si l'utilisateur veut aller sur le pont ou bien s'il veut aller au bord de la rivière ?
Il faudrait da
oups clavier de ****
[...]
Il faudrait donc gérer le déplacement de l'avatar par étapes :
- si la case est "mono-choix" (elle ne peut correspondre qu'à un seul niveau) alors on y va
- si elle est "multi-choix" on va sur la case du niveau en cours. Pour aller sur une case d'un autre niveau il faudrait donc passer par une case "mono-choix" de ce-dit niveau.
Cela pose des problèmes assez évidents au niveau du gameplay mais je vois mal comment faire autrement...
Vous avez une autre solution ?
ciao
Attention, utilisation fourbe de ton moteur : )
Si je clique un peu aprtout, vite, il y a effectivement un bug sur le OnReleaseOutside comme l'a dit Ali O Kan. Mais surtout au bout d'un moment, le moteur plante et le carré bleu ne bouge plus du tout.
De même, autres faits étranges.
Si tu lui indiques un aller/retour entre deux points, il ne prend pas le même chemin. (notamment haut/droite à bas/gauche et vice versa) Est-ce normal?
Et il s'arrète parfois pile/poile entre deux cases. Et là, c'est plantage définitif. (j'ai du recharger la page pour pouvoir poster!!)
J'espère que ces constats te seront utiles.
Stéphane,
si je peut me permettre une petite critique negative en tant qu'amateur lorsqu'on relache le bouton de la souris hors de la case le carré rouge reste et le carré bleu ne se deplace voila c'est tout a+
Fil des commentaires de ce billet