Grab me, shoot me.

Tout ça est parti d'une relecture des "notes de développement" que je prenais il y a maintenant 10 ans (eh oui) en préparant mon "Ultimate Game Maker". Si les approches que je voulais suivre sont complètement obsolètes, en revanche, j'avais bien creusé les "scénarios pièges" qui définissent généralement la limite entre un moteur de jeu "spécifique" et un moteur générique. En l'occurence, ici "Bilou attrape un ennemi assomé et s'en sert comme arme sur d'autres ennemis".

Coding in a hospital is definitely not an easy job, but there was at least one thing i managed to do during that "free" time when sleep didn't want to come : re-reading those design notes on the "Ultimate Game Maker" I wrote down 10 years ago, organising them, pin-pointing good and bad ideas. Despite virtually all the technical details now fall in the "BadIdeas" category, there were a collection of "gameplay scenarios" that i can reuse to ensure my current game engine is generic enough. The specific "use case" I further studied was the ability to grab an ennemy and use it as a weapon against other ennemies.

Du point de vue "mécanique", je joue sur la possibilité de définir des propriétés aux zones de collisions. Un appleman normal possède juste la propriété "stomp" qui permet à Bilou de l'étourdir en sautant dessus, une fois étourdi, il possède aussi "pick". Au moment où le joueur enfonce le bouton "poing", on ajoute une zone de collision à Bilou qui teste la présence de "picks". En réaction à ce genre de collision, l'état de Bilou aussi bien que celui de l'appleman sont modifiés. Le même genre de mécanisme avec une propriété "shot" est utilisée pour provoquer le passage de l'appelman de l'état "transporté" à l'état de projectile. Tout va bien.

First, I need to translate the scenario into states-collisions-properties elements of my current engine model. With the recently introduced per-collision-area properties, it goes quite well. The appleman doesn't receive f_pick collisions unless it is in the 'stunned' state, and Bilou doesn't test for f_pick collisions unless the player triggers a punch. Similarly, the 'carried' appleman can receive f_shot collisions that turn it into a weapon agaisnt other ennemies. This was tricky in the UGM model because the class of a Gob (bonus, character, ennemy, shot, object ...) stricly defined what collisions could occur. The new model is much more tolerant and it's only your mind that decide the appleman is now a ennemy and then a weapon. Of course, the controller used in "carried" state aligns position and speed of the appleman to those of Bilou.

Sauf que ... comment au juste vais-je "ramasser" l'appleman ? Je veux dire, le mouvement des mains de Bilou et celui de l'appleman doivent être synchronisés pour que ça marche. C'est le genre de problème qui n'apparaît pas dans Blues Brothers avec une seule étape d'animation et un seul objet à ramasser (la caisse), mais je veux profiter de l'absence de bras & jambes de Bilou pour améliorer les animations, même si j'ai 15 ans de retard sur Rayman pour l'implémentation ^^"

The tricky questions surprisingly came from rendering the actions. How do I define the intermediate frames of Bilou grabbing and shooting the appleman ? It wasn't much of an issue in 8-bit (chip'n'dale) or 16-bit (Blues Brothers) paltformers, because you had at most one frame and one object to carry (the crates). But I'd like to take advantage of the 'limbless' nature of Bilou to improve animation (despite I'm 15 years late compared to Rayman :P)

Plusieurs lignes de conduites sont apparues par rapport à cette réflexion:

• les sprites d'un Gob composé doivent permettre de définir l'emplacement des zones de collisions, ainsi f_pick est toujours associé à la main droite de Bilou (tout au long de son déplacement) et f_shot à son pied droit.
• l'ancrage d'un Gob (appleman) à un autre (Bilou) doit aussi pouvoir être défini par rapport à un sprite précis. Ainsi, quand Bilou abaisse sa main pour shooter dans l'appleman, l'appleman suit le mouvement
• deux "commandes" permettront de définir des animations plus fluides : "goto" et "auto", qui permettent à un sprite d'utiliser une paire des variables du Gob comme vitesse pour atteindre un point de référence donné.
  

It resulted that in such 'composite GOBs', the individual sprites (hands, feets, body) should be allowed to govern the position of (some) test areas, and serve as anchor points to other 'carried' GOBs. Moreover, we'll love to have "automated" animation statements such as "go to (x,y) using GOB variables v4 and v5 as horizontal and vertical speeds", rather than giving explicit position for every sprite at every frame.

I could have alternatively opted for multi-gobs (that is, Bilou *shoots* a hand that come back at him), but that would have terribly complicated further interactions.

ps: i gave the official google "readmore" feature a second try on this post and i'll drop it: the RSS still provide the full post, making "read more" not that useful. Plus it will doom my backup strategy. Only "ranting" posts will have "read more" stuff.
pps : yeah, that means i'll really have to work on that "modular animation" add-on for SEDS.