LAlex devblog v6 - Tilegame et mouvements : model or not model ? - Commentaires

Tilegame et mouvements : model or not model ? - Sylion

Sylion — Wed, 17 May 2006 14:54:10 +0000

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+

Tilegame et mouvements : model or not model ? - enchanteur

enchanteur — Mon, 09 Feb 2004 07:46:10 +0000

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,

Tilegame et mouvements : model or not model ? - SetBlue

SetBlue — Tue, 06 Jan 2004 22:42:47 +0000

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.

Tilegame et mouvements : model or not model ? - wuastc

wuastc — Tue, 09 Dec 2003 17:34:19 +0000

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

Tilegame et mouvements : model or not model ? - wuastc

wuastc — Tue, 09 Dec 2003 17:21:33 +0000

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

Tilegame et mouvements : model or not model ? - LAlex

LAlex — Tue, 09 Dec 2003 17:05:04 +0000

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:

Tilegame et mouvements : model or not model ? - wuastc

wuastc — Tue, 09 Dec 2003 16:48:37 +0000

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

Tilegame et mouvements : model or not model ? - wuastc

wuastc — Fri, 05 Dec 2003 19:16:07 +0000

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

Tilegame et mouvements : model or not model ? - LAlex

LAlex — Thu, 04 Dec 2003 16:18:24 +0000

y a un bug quand tu fait onRealseOutSide, la nouvelle position n'est pas prise en compte et le contour rouge resteY a que toi qui pense a faire des trucs comme ca .. :?

Tilegame et mouvements : model or not model ? - Ali_o_kan

Ali_o_kan — Thu, 04 Dec 2003 16:06:20 +0000

y a un bug quand tu fait onRealseOutSide, la nouvelle position n'est pas prise en compte et le contour rouge reste

Tilegame et mouvements : model or not model ? - LAlex

LAlex — Wed, 03 Dec 2003 22:39:48 +0000

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 ... ^^

Tilegame et mouvements : model or not model ? - petepx

petepx — Wed, 03 Dec 2003 19:20:52 +0000

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 ... ).

Et pour lui passer la durée du déplacement par exemple, ca oblige à faire un setInterval par élement ca non ? 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

Tilegame et mouvements : model or not model ? - LAlex

LAlex — Wed, 03 Dec 2003 09:25:10 +0000

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

Tilegame et mouvements : model or not model ? - LAlex

LAlex — Tue, 02 Dec 2003 20:39:45 +0000

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

Tilegame et mouvements : model or not model ? - petepx

petepx — Tue, 02 Dec 2003 19:58:18 +0000

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