Sunday, February 06, 2011

platforms (at last ?)

1. The platform must be passive
This is due to the fact the platform could be carrying several objects and must remain "unaware" of this.

2. Having a "reference GOB" is fundamental
Not only walking on a platform involves Bilou (or other "character" GOBs) to have controllers that look at the behaviour of other GOBs. It also happens with any other kind of vehicles, with homing shots that have per-instance (as opposed to class-wide) target, or to carrying of objects/monsters. Moreover, it is linked to a collision area of the GOB rather than to the GOB itself.

Bion. Refaisons d'abord le point sur les faits:
  1. les plate-formes doivent être passives;
  2. un GOB peut toujours avoir un GOB de référence
  3. le script ne doit être nécessaire que pour les changements d'état.
  4. l'état propre aux contrôleurs est partagé par tous les personnages qui utilisent ce contrôleur.

3. Collisions are only needed when we start/stop being transported.
We simply need to exit the "falling" state when a platform is hit and to leave the "walking/idle" state when the platform stops being solid. To "keep walking" on an established platform, no "event" is required, and no "scriptable action" must take place.

4. It is preferable not to mess with controllers chain
Although it was my initial idea to have collision with platforms to prepend a "walk-on-platform" micro-controller on Bilou, it only make things harder to work with. For a start, controllers are essentially class-wide resources (as the whole state machine), meaning that it would be hard to have e.g. applemen properly walking on platforms this way. Second, it requires that we identify the location in the controllers chain where the new controller should be added, which we currently have no support for. Finally, it would be impossible to insert controller-specific event for "on-platforms" micro-controller, because it is unknown at the "script compilation" time.

Pour pouvoir implémenter proprement les plate-formes mobiles, il faut d'abord:
  • que les plate-formes se soient toutes déplacées avant que l'on ne commence les calculs de mouvement des personnages succeptibles de marcher dessus.
  • que les flags de collisions permettent d'indiquer "conserver ma référence après la collision" et "accepter une référence suite à la collision"
Si tout ce passe bien, une fois ces éléments en place, il sera non seulement possible de créer des plate-formes mais aussi tout autre type de "déplacement aligné" simplement par ajustement du script (quelles collisions, à quel moment, par rapport à quelle zone, avec quel effet sur les contrôleurs, etc.)

The only modifications required on the engine should thus be 1) that GOBs acting as mobile platforms are "animated" prior to GOBs that walk on them (to avoid zool-lags) and 2) allow collision flags to indicate whether a reference to the passive object should be kept and whether the active object is willing to change its current reference.

It is still unclear, however, to what extent platforms require their own collision cast (that is, beyond HERO and EVIL).

1 comment:

PypeBros said... >-- gare aux zones de collisions définies trop arbitrairement (cf. les grosses boules à pics) et qui peuvent donner l'illusion au joueur d'un jeu "injuste" et où il est "impossible de passer sans se faire blesser"