Mekappleman

Le rythme 'confinement' me laisse paradoxalement moins de temps pour bilouter que mon rythme habituel. Malgré l'absence des activités de fin de journée des enfants, malgré l'absence de trajets en voiture. Entre les repas qui sont rallongés (intervention parentale oblige), les ballades de santé qui se transforment en promène-le-gamin, les mises au lit plus tardives et les débuts de soirées amputés d'un jt pour se tenir un minimum informé ...

Bref, dans tout ça, j'ai quand-même fait tourner un pseudo-dumblador sur le terrain simulé pour tester les pentes du nouveau moteur de jeu. Et je me suis retrouvé bloqué. Dans certains conditions, le code de gestion des pentes le fait entrer dans le sol plutôt que de le faire monter sur la pente. En cause, le mécanisme qui permet de 'mettre en attente' un déplacement le temps que l'animation soit prête pour un déplacement (qui peut être de plusieurs pixels d'un coup).

Some claim they can start new hobbies while they are covid-confined. I had a hobby already before, but not having to drive the car to the office and back doesn't really give me free time. Just more time tending the kids. But well, I still managed to find some time to have mecha-blador walking in virtual level and try new slopes for the revised game engine. Then I got stuck...

From times to times, slopes-handling code would makes mecha-blador enter the ground rather than climb up the slope. The cause turned out to be the trick allowing to delay a move until the animation could follow it (which may require we move several pixels at once). The tricky part is that dumblador animation mixes move-to and delay instructions. Trying to validate fixes in such conditions doesn't feel appealing, so I instead picked back the Appleman, who's walking animation is using only MOVETOs.

Là où ça se complique, c'est que le DumbBlador mélange ce genre de déplacement et des pauses. Difficile de s'assurer que les correctifs fonctionneront pour tous dans ces conditions. J'ai donc ressorti un personnage à l'animation 'plus simple', inspiré de l'Appleman.

J'ai aussi revu le mécanisme qui capture l'évolution des personnages, me basant sur l'idée que si ça ne t'aide pas à trouver les erreurs, ce n'est pas un unit test. Jusque là, testme BasicSlopesTests pouvait juste me dire que ça n'allait pas, et à quelles coordonnées le meka s'était arrêté. Le reste, c'était à faire dans le débuggeur.

Now, if I want it to be unit-tests like, it has to be useful to identify what goes wrong. So far, testme would just tell me at what coordinates the meka-sprite ended up. Everything else was to be done in the debugger. A new GameObjectState class can now collect information about how coordinates evolve and and what 'debug signals' controllers sent to InspectorWidget. Granted, $/ffff0001 is crude, but I can tell it is sent by doSlopes, which failed with (-1, 1) motion. It could actually be post-processed by a PERL script.

C'est un début, mais c'est clairement perfectible. J'ai donc un nouvel objet GameObjectState destiné à capturer tout ce qu'il faut savoir du meka pour les besoins des tests (à la discrétion du programme de test) et un ensemble de ces objets en guise d'historique (plutôt que 2 tableaux de coordonnées et un de vitesses). J'ai pu aussi intercepter les rapports destinés au ChiefInspector (relai vers l'InspectorWidget) et les capturer dans les GameObjectState correspondant. C'est un peu  
laborieux à décoder, mais ça devrait réduire tout de même le travail de mise au point. Par exemple ce '$/ffff0001' est émis par doslopes qui échoue un déplacement (-1, 1) et 'S/0' que GobWalkerController reprend la main avec des vitesses nulles dans les deux directions.