area %d = anim %x

Bon, franchement, je me demande depuis quand ce problème attend que je m'y attelle... que ce soit mon blog, twitter ou mon calepin, impossible de trouver une date correspondant à "oui, la plate-forme se reclappe, mais quand je me mets plus sur sa gauche, je passe à travers.

J'imagine que ça fait partie des choses qui m'ont motivé, fin du mois dernier, à faire en sorte qu'Inspector Widget marche à nouveau dans la démo "3 rooms". Et la visualisation des zones de collision m'avait porté à croire que j'avais mal défini les zones de collision dans l'éditeur, sur NDS.

At some point, I noticed that InspectorWidget wasn't working anymore in Dreams.nds ... not quit ideal when you're trying to add bits of gameplay to your years-long-under-development demo. Especially not when you barely manage to get more than 1 hour of gamedev at once. And after I managed to get it back, I suddenly remembered that seeing Bilou falling through the flipping platform was nothing new and that it was linked to the platform having bad hitbox.

Parce que oui, ayant la flemme de définir les zones à la main, cette 'crocforme' est (avec la branche-qui-rebondit), un des premiers objets du jeu à importer une zone de collision passive directement avec area 0 = anim ${FLAGS}, plutôt que d'en fixer explicitement les coordonnées comme j'ai fait avec Apple Assault et School Rush.

Sauf que sur DS, les hitbox sont parfaites. Rien à redire. Je re-transfère le fichier (le lendemain), des fois que j'aurais oublié que j'avais déjà corrigé le soucis. Je recompile (le surlendemain), je teste. Pas d'amélioration. On est samedi, je sors l'artillerie lourde: une nouvelle instruction `break` pour le langage de script histoire de pouvoir mettre un breakpoint dans ddd et commencer à inspecter le comportement du parseur de script pile là où ça coince: dans la boucle qui lit les commandes 'Define' de l'animation où on fixe les coordonnées de la zone solide et des hitboxes pour l'animation.

At first, I thought I had just messed the hitbox within AnimEditor for DS. But a few checks and WiFi transfers later, it turned out that no: the data (as far as the editor was concerned) was ok, but the game still would use the bad hitbox. Checking that on the parser would be darker than night -- or so I thought. This is how the parser now supports an additional "break" instruction that is a noop where you can set a gdb breakpoint while parsing things. These are not meant to be committed, of course, but it definitely helped.

A few 'next instruction' later, it turns out that my engine is using tool-absolute coordinates for the hitbox instead of object-relative coordinates. That is, when you edit an animation in AnimEDS, you don't only store how to use it in-game, but also what you need to edit it again in the editor, and that includes where to put each component on-screen in the editor. The character's center and the edition widget center may match, but they don't have to.

Le code qui gère ça n'est pas tout neuf: il a permis d'améliorer les hitboxes pour attraper les objets dans SchoolRush il y a près de 10 ans. Mais j'ai commis l'erreur de copier-coller le code plutôt que de faire une fonction "importArea" qui serait utilisée des deux côtés: pour les zones actives et les zones passives.
ça n'aura donc pas été trop compliqué de faire en sorte que les deux utilisent le même bloc de code (le bon) et d'avoir une plate-forme qui fait *enfin* ce qu'on attend d'elle :-P

J'espère que je passerai un peu plus vite de la découverte du problème à la recherche de sa solution, la fois prochaine ^^"

If I want to fix that, I need to track not only hitbox#n ORIGIN coordinates, but also those of the 'solid' box -- the one used to decide whether the object cando() something. then when one 'ORIGIN' instruction shows up for the area we're interested in, we create relative coordinates. Hopefunny enough, it turns out I already have code that does precisely that, because I have both active and passive hitboxes and I failed to avoid repeating myself when writing the original parsing code ... and later failed to fix both copies when I realised things were not going as they should have.

Time to fix things.

After graphically resolving dependencies between my huge list of todo items, I attacked with usability issues in RunMe. I trashed a couple of evening on long-lasting bugs (although pathetically trivial >_<) in InspectorWidget and adjusted further the areas reporting so that I can follow which one is active when. That way -- and with another fix on AnimEDS -- I can check that flashing hitboxes needed to improve GRAB animations work fine.

There is also a curious asymmetry in the "GRAB" states. Just having left-facing GRAB react "on dpad" prevents the animation to run to completion. Indeed, the button will appear to be released (triggering a "dpad" event) a few frames after it was pressed (as a result of the mechanic allowing for precise jumps). Better seems to be Good's archenemy.

I've got an on-going experiment that allow beaming only "tiles" or "animations" or "sprites" (...) of a .spr file, in an attempt to work around limited reliability of WiFi transfers for increasingly large files from the DS... It's not very convincing so far.

Oh, and compared to June, Inspector widget has improved. I can expand/shrink behaviour controllers, set breakpoints on their events, and touching left/right "monster area" change the "suspect" in the GOBs list (only selecting those that are active, iirc).

Les p'tits trucs du monde 16 bits ...

Je trouve assez instructifs les commentaires de Tool-Assisted Speedrun de Coeur de Vandale, RealMyop et leurs invités. Dans sa présentation, le jeune Got4n nous explique par exemple que dans son portage GBA, le moteur du premier Rayman ne teste pas toutes les collisions à chaque frame. Les collisions entre Rayman et les ennemis ne seront évaluées qu'une frame sur 4 alors que les zones plus larges (sortie de niveaux et autres déclencheurs) se relaient et sont évalués une fois toutes les 7 frames. Une ruse élégante pour continuer à faire tourner un jeu conçu pour PC à 90MHz sur un processeur ARM 33MHz (le hardware graphique du GBA permet de sauver pas mal de temps, mais tout de même ...)

About one year ago, a colleague pointed me towards a video where two French guys comment a tool-assisted speedrun completing Super Mario World in a couple of minutes. It is not quite "abusing game rules" where you'd play Megaman as if you were Neo in the Matrix. No. It's looking much more a hacker exploit where you force the program to jump to some place where you can distort content of the code memory. There is no limit to what you can achieve once you reach such a point. You can immediately launch "you won" credits, you can replace any monster's behaviour with some machine code of yours ... you can even play Snake rather than Super Mario.

Since then, I keep an eye on speedruns and tool-assisted speedruns as a way to pleasantly discover the little tricks inside major games. Things like "given maximum speed is 8px/frame, you only need to test for collision with block-size spikes once every 4 frames (Rayman GBA). Or that all the dungeons of Zelda: LTTP are located in the same map and that you can move from one to another provided that you can drill hole between them.

Dans les autres découvertes sympas, saviez-vous que tous les donjons de Zelda: Link to the Past partageaient la même map, et qu'il est donc possible de passer d'un donjon à l'autre en s'y prenant comme il faut ? Eh oui. Quand on doit faire la première grande aventure sur une cartouche 8Mbit, tous les coups sont permis ;)

A la base d'un Tool-Assisted Speedrun, il y a un émulateur dont on utilise à fonctions d'inspection de la mémoire pour trouver où sont conservées les vitesses, les zones de collisions et tous ces petits détails croustillants qui permettent de définir la trajectoire idéale. On s'autorise aussi à envoyer à la console n'importe quels signaux d'entrée, même quand ils ne sont pas humainement possible avec une manette normale et des (gros?) doigts, comme relacher le bouton et le réenfoncer en 1/30 de seconde précisément avant de faire faire Gauche+Droite au D-Pad dans le 60ème de seconde suivant.

Allez, la prochaine fois, je vous explique comment on manipule les boss.

Couper les cheveux en quatre ?

J'hésitais à introduire le contrôle des boîtes de collisions dans mon éditeur d'animations. J'hésitais encore plus à ce qu'on puisse activer ou désactiver certaines de ces boîtes au fil de l'animation. Tout ça me semblait plutôt relever de la machine d'états et des gardiens de transitions. Et puis Shantae m'a fait changer d'avis.

So far, I have been able to keep hitboxes on a per-state basis. Anything more subtle was resolved either by spawning new GOBs (like the punch attack in Apple Assault) or splitting the animation (inkjet). I was growing the conviction that it wouldn't be enough for new grab-in-the-air mechanic, Shantae's move pushed the definitive argument: *any* punch or kick-like move has build-up and recover phases, and the hitbox shouldn't be active by then. Splitting the animation in such cases ? That would quickly turn into a nightmare!

At this point, not adding edition of hit boxes in the animation editor would strongly reduce my chance to have form-fit-function ...

Lors de l'animation d'un coup, on peut distinguer trois phase: la préparation, l'action et le retour. Idéalement, seule l'action correspond à une hitbox offensive. Selon la longueur de la préparation et du retour, enfreindre cette règle (qui dérive du "form fits function"), c'est produire des effets incohérents et du coup rendre beaucoup plus complexe l'apprentissage du système par le joueur. Je n'ai pas eu le problème dans Apple Assault parce que les coups de poing étaient en réalité des sprites indépendants. J'ai contourné le problème avec inkjet en tronçonnant l'animation en deux parties et en faisant en sorte que Bilou ne puisse réagir qu'au moment précis de la transition entre les deux tronçons. Mais soyons clairs: faire la même chose avec tous les mouvements "power-up" prévus serait un véritable cauchemar.

Shrink and Grow!

It's somewhat time to allow my game "objects" to take the "drink me" bottle and to change size as the game goes. Well, they can already do so. Well, they can already change size, but it usually result in characters stuck in walls, since the coordinates doesn't change.

Jusque là, si M. Miyamoto était revenu me voir après sa pause-déjeuné au Palais du Champignon Chinois, j'aurais bien tiré la tête en l'entendant dire "Mario géant, on ne va pas le faire géant dès le départ: il aura une taille comme dans Mario Bros. et il deviendra géant seulement après avoir attrapé un champignon. C'est bien connu: ça pousse vite, les champignons". Si mon éditeur d'animations me permet effectivement de changer la taille de la zone occupée, le fait que la position du personnage (de son coin supérieur gauche, pour être précis) reste identique l'envoie plus souvent qu'à son tour se faire emmurer.

So despite I'm feeling as dizzy as an egg, I managed to update the game engine so that you can now indicate which edge of your character should stay in place when coming from a state where the major hitbox (the one which is used to test collisions against the world) has a different size. At last, that allows Bilou to adjust his position as the inkjet shrinks while preparing a "blow".

Mais cette fois, j'ai enfin intégré une amélioration du moteur de jeu trop souvent retardée: premettre d'indiquer sur quel bord/coin de sa zone le personnage doit s'aligner. Ça me permettra prochainement d'ajouter de sympathiques animations pour l'aterrisage de Bilou (comme Lazycow l'avait suggéré). Plus directement, ça me permet enfin de décaler légèrement Bilou vers le bas quand un encrier se prépare à le propulser en l'air ^_^

Merry christmas.

The art of Blading

For g88 release, carrying bladors was functionally correct, but still a bit cheap, as the carried blador could move through walls, ceilings and such. It would be an acceptable simplification of physic rules in-game if that did not meant you could "throw" it while it overlap solid structures, which would let it "stuck" there as soon as regular physics takes over to let it be thrown away. I want the game to feel professional, and demonstrate that a simple scripting approach does not imply half-baked behaviours. It's thus time to prove it.

Un taille-crayon qui passe à travers tout pour qu'on puisse le lancer n'importe où, ce n'est pas très réaliste, mais c'est acceptable dans un jeu vidéo. Un taille-crayon qui reste bloqué dans un mur quand on le lance, ça, ça fait tache. Surtout quand le joueur aurait théoriquement dû pouvoir le ramasser et l'emporter plus loin. Premier pas pour corriger ça, interdire à mon taille-crayon de passer à travers les murs (ce qui demandait un réglage spécifique du contrôleur freemove). Résultat: Blador suit maintenant Bilou "de son mieux", ce qui amène parfois des résultats curieux comme un saut quantique à travers un mur contre lequel il est resté scotché pendant 15 secondes lorsque Bilou émerge enfin d'un passage secret.

The first step is to make blador using freemove(1) instead of using freemove(0) when carried. Freemove is the controller that allows free movement typical from airborne ennemies such as the berrybat. The only thing it does before validating the desired movement is checking that you cando(m) where m describe some properties of the environment - like being something you can MOVETHRU. 0 is considered as a special case where you can always do what you want -- perfect for ghosts or sparkles that will fall of the screen. So now, blador can't get into walls, but curious things occur when Bilou gets into narrow passages where Blador cannot follow: Blador just sits where it is, and if at some point Bilou reaches a new position where Blador could fit above its head, Blador gets quantumagically teleported to that new location (yes, again).

Pour corriger ça, il faut que Bilou puisse être informé de la situation du Dumblador qu'il transporte. En '97 j'avais donc pensé augmenter mon "ulitmate game maker" d'un système de messagerie entre les personnages. En fait, ici, on va faire beaucoup plus simple: tout comme l'encrier possède une zone-test (hitbox) qui repousse Bilou lorsque celui-ci l'approche, le Dumblador transporté va disposer de murs invisibles qui empècheront Bilou de s'en éloigner de trop tant qu'il le transporte. Eh oui: c'est aussi simple que ça.

Enfin, presque. Il y a quand-même une subtilité dans le cas du saut. Si je me contente de forcer Bilou à faire du sur-place au milieu d'un saut juste parce qu'un taille crayon a la tête dans le plafond, ça fout en l'air la crédibilité de la physique du jeu pour donner un effet Badman/RSD Game-Maker carrément pathétique. Il faudra donc que je traite cette collision aussi du côté de Bilou en forçant une remise à zéro de la vitesse, exactement comme le contrôleur "gravity" l'aurait fait si on s'était vraiment retrouvé directement dans un mur.

I like how Bilou/Blador distance is stretched or squished when colliding the environment, but I need more control over it. And that's just a perfect fit for the "repel" action introduced with solid inkjets. To avoid having Bilou going too far away from the carried Blador in a narrow tunnel, I just need some repelling-areas acting as virtual walls at appropriate distance from its position.
The same approach allows Blador to take some room between Bilou and the ceiling, but here I need some additional action. "Repelling" simply adjusts coordinates and does not affect speed. The result was that Bilou would keep floating along the ceiling as if he virtually kept jumping. Even weirder: he might have resumed moving up as soon as he'd have moved away from what was blocking Blador (just as in Badman II, actually).
To avoid this, Bilou needs to react on the collision and clear vertical speed. Additional tests are needed to ensure the blocking object (active GOB) is indeed over Bilou's head and that he's still moving upwards. The center-to-center distance (dy) is available through GobScript wf variable read and is positive when the active object is above the passive object (and yes, the sign of dx and dy is related to passive/active roles as the distance is defined only once, and then reused in both passive and active objects transitions).

Il me reste donc "simplement" à corriger l'ordre d'affichage de Bilou et du dumblador (tant qu'à faire, prenons-le en mode "hotte de père Noël" plutôt que "Sac de courses devant le nez") et à m'assurer que les mains de Bilou apparaissent sur le taille-crayon pendant qu'on transporte le crayon.

It leaves me with one last aspect to fix: having Bilou's hand properly shown as grabbing the blador while it is carried, knowing that hands will have to be aligned with blador rather than with Bilou if we want to keep stretch/squish.