GameObject : public Animator

Bin voilà. Hier soir j'ai fait le point sur tout ce qui tourne autour de ma classe GameObject qui assure la gestion des monstres et compagnie. C'est déjà un peu le méli-mélo, et je dois rajouter là-dessus des objets multi-sprites (pensez à une chenille, et vous êtes dans le bon) et surtout les contrôleurs, capables d'influencer le comportement des monstres en assurant ce que les petits scripts et les machines d'état ne sauraient pas proposer.

Je m'explique.

Prenez un sprite comme le petit ver. Il a principalement deux états (avancer vers la gauche ou avancer vers la droite). Chacun de ces états est lié à une animation (qui entre-autres le fait bouger) et définit les conditions sur les testpoints nécessaires pour rester dans cet état (pas de mur devant lui, et du sol en-dessous). Lorsqu'un des testpoints n'est plus bon, on cherche une transition à appliquer pour passer dans un nouvel état (en l'occurence, il y a une seule transition, vers l'autre état).

En gros, c'est super-simple.

I shoot a picture of my attempt to summarize the OO design of my GameObject class (later on called "GOB" through code and blog) and everything sitting around. Let's see that with a simple example such as the WoodWorm, that simply move forward and backward on platform. The worm has mainly two states depending on its direction. Each state has an associated animation and defines conditions expressed on testpoints that must be met so that we can remain in that state. Namely, when moving to the right, the worm must have some ground behind him and no wall in front of him. When testpoints are no longer valids, we look for a transition that will lead us towards a new (valid) state.

L'appleman, lui, est un peu plus sophistiqué: il se balade également au sol (avec les 2 même états), mais lorsqu'il arrive au bout d'une branche, il peut décider de sauter au sol pour attaquer Bilou si

1. Bilou est en-dessous de lui
2. Bilou n'est pas trop loin.

Le contrôleur, dans le cas de l'appleman, est passif: il se contente de lui rapporter sa position relative par rapport à sa "cible" (Bilou) et c'est via les prédicats des transitions (que je n'ai pas encore implémentés :P ) que la décision de faire demi-tour ou sauter se prendra.

More sophisticated GOBs, such as the Appleman, have a behaviour that does not depend only from test points. When reaching the edge of a cliff/platform, the Appleman will either turn back if Bilou is not in its attack range or jump off if Bilou sits below him in attack range. I intend to build that by means of controllers: C++ objects attached to a state that affect either directly (altering speed) or indirectly (indicating the presence of Bilou) the behaviour of GOBs. Even reading the Dpad and moving the hero accordingly can be achieved by a controller.
This should give us flexibility while reducing the amount of CPU power thrown at interpreting scripts.

Si on prend maintenant notre copain AppleBat, il dépend aussi de la position de Bilou pour son déplacement, mais il accélère et suit Bilou. Pour faire ça proprement, je vais laisser à son contrôleur le soin d'ajuster sa vitesse automatiquement pour se dirriger vers la cible. Tout ce que le script aura alors à prendre en compte, c'est le choix de l'image utilisée (pour que l'applebat continue à regarder vers Bilou quand il le dépasse).

Le reste, à mon avis, c'est du détail de bricolage de colle, donc je vous laisse le soin de déchiffrer mes gribouillis en cliquant sur les images si ça vous intéresse.

En d'autres temps, d'autres lieu, tout ça aurait pu faire une bonne autre lettre à Gédéon ;)

edit: partly obsoleted by this post and that post.