just another breakpoint in the wall

Since last week, I've been tweaking the state machine of my meka-tester trying to make it better mimmic the behaviour of Bilou when it gets into the walls. I finally get the kind of error I wanted, but it makes little sense.

. . .  Well, I initially wanted to tell you about how it suddenly hops into the wall, 4 pixels further than it was without ever seeing the 'building up' delayed move explain anything of that. but I feel so tired. s/4f.f, S/ffe6.0 ... I'd have to dig up my notebook (page 14) to decode what that means. I just can't. my eyes don't want to look at the screen anymore. See you later.

Pendant près de deux semaines, j'ai fait des essais et des ajustements pour avoir un meka-apple qui reproduise les bugs et-vlan-me-n'là-dans-l'mur que je rencontre systématiquement dès que j'essaie de jouer dans le nouveau niveau de mon fiston. J'ai fini par y parvenir, mais on ne peut pas dire que ça m'aide à comprendre ce qui se passe. Une téléportation de 4 pixels d'un coup, alors que tout semblait aller bien jusque là...

Un peu de repos, un peu d'astuce, et j'ai des pistes pour améliorer la situation. Mais alors que je refais un essai dans "Dreams.nds", je me rends compte que le problème est toujours là. Et il est très facile à reproduire manette en main sur ce niveau, en plus. Est-ce que j'ai tenté de faire du unit-testing trop tôt ?

<later> over the week, I managed to identify some issues and possibly fix some, but it is still possible (and actually easy) to trigger. 

It makes me feel like I tried to unit-test the issue too early. Maybe what I actually need is a way to get a bunch of data out of the emulator, and monitor them when I'm done reproducing the issue.

Let's see what we would need ...

Je change d'approche, du coup : il existe dans l'organisation de mes jeux une classe indépendante du Game Engine, mais qui a accès aux objets du Game Script et qui peut exécuter une méthode à chaque frame, le HUD. Si je fais tourner mon niveau dans un émulateur avec débuggeur, et si je rajoute un break pointau cas où Bilou serait arrivé dans un mur, je devrais pouvoir creuser le problème.

• [done] access game object position and variables.
• [done] record them, e.g. in the GameObjectState structure defined in unit-tests
  
• [done] check whether game object got into a wall (cando(0,0, PLAYER_THRU)
• [done] switch to 'investigation' mode when we're in a wall
• track state changes and controllers reports (through a custom inspector)
  

edit:A class deriving from iHud met all the criterion above. If I'm okay with using ddd to inspect the content of the last GameObjectState array, I can start investigating ...

Sauf que ça n'a pas été si simple. Même en ré-important le code des tests qui enregistre les mouvements des dernières seconde de jeu, l'information restait trop sommaire pour pouvoir retracer pas à pas ce qui ne "marchait" pas au cœur de la fonction do-slopes.

Mais Murad-dib m'a sauvé la mise  (oui, depuis qu'on est allé voir Dune avec les collègues, je me suis replongé dans le bouquin.) Et si comme lui je balayais de la main toutes les règles et les conventions (du c++, ici, pas du C.H.O.M.)... si je prenais avant chaque appel à bilan.PlaY Une copie de la mémoire contenant l'objet 'Bilou' ... je pourrais en cas de mur réappeler 'play' sur la copie ! le moteur de jeu est ainsi fait qu'il n'y verrait que du feu, et je pourrais faire mon débugging pas à pas en étant sûr que je suis dans un cas où le bug va se manifester

It wasn't quite sufficient, unfortunately. Hopefully, I was reading Dune again, and going through the moment when Muad'Dib decides to break all the rules so he could get victory, I realised that I could go for Muad'dibugging too: create an empty GameObject in addition to the real one for Bilou, and memcpy a snapshot of the current state before every 'play()' call. If we turn out to end up in a wall, I could just call 'play()' on the copied state to reproduce step-by-step what the first one had encountered.

Of course, that goes against all established rules about how to deal with C++ instances, and make the 'NOCOPY(GameObject);' macro look like a fool. But it worked.

And at last, on 2021-10-13, 22:**, I think I nailed that stuck-in-the-wall bug that had been since my kid drew his pyramid level.
 

DJLN.cmd

Faire des niveaux sur papier, ce n'est définitivement pas une activité à proposer à mon fiston. Au mieux, je peux lui proposer de me dicter un niveau que je ferais moi sur papier.

Par contre, prendre la Nintendo DS de papa et ajouter des blocs ici et là, ça ça lui plaît bien. Mais pas de chance, la branche "newmap/newmeta" n'est pas encore stabilisée au point qu'on puisse tenter de jouer au niveau ainsi construit.

Assez surprenemment, mon nouvel écran de patching m'indique que l'erreur se trouve sur la première ligne de pyram.spr, CMAP n'étant pas une commande valide pour les scripts. Enfin, ça c'est sur émulateur après avoir récupéré les fichiers présents sur DS avec le wifi remis en service.

En fait, ce serait la commande spr.more "pyram.spr" qui n'a pas été comprise par l'éditeur de niveau. Du coup, au moment de sauver, il en fait un input "pyram.spr" Si j'en crois les numéros de version, le bug a déjà été patché, c'est juste que la DS n'avait pas pu profiter de la nouvelle version. C'est J.L.N qui va être content...

• invoking autoexec.cmd with the [run] button does not seem to allow PatchWindow to be invoked.

MechaSkull's ninja

J'ai à peine atteint le boss des catacombes dans The Messenger que la nouvelle tombe: Cyber Shadow, le jeu de ninja de MekaSkull sort la semaine prochaine demain aujourd'hui. Un jeu dont j'ai suivi le développement avec plaisir et assidûité ces dernières années. C'était d'ailleurs un de mes plaisirs sur twitter pendant les années creuses de mon blog: découvrir un nouveau screenshot animé de MekaSkull, et imaginer la raison d'être de ce qu'on voit ou des variantes pour un retour-plus-tard-dans-le-jeu.

Traps activated by powersources. There may be more ways to use them?#indiedev #8bit #pixelart
pic.twitter.com/GVH6sr4gby

— Aarne Hunziker (@MekaSkull) September 27, 2016

Prenons les barrières électriques intermittentes et les "chausse-trappes" à coup de sol qui s'électrifie par moment, par exemple: en introduisant des 'générateurs d'impulsions' (les ronds rouges), MekaSkull permet à la fois de mieux visualiser les timings complexes (façon guitar hero ?), mais aussi nous permet potentiellement de chercher par quel détour on pourrait aller les désactiver et rendre le passage moins hardcore. (s'il ne l'a pas fait dans Cyber Shadow, j'ai bien l'intention de faire ça dans la pyramide de Bilou, d'ailleurs).

Testing room for new enemies. They can now defend themselves with aimed shots... to some extent.#indiedev #8bit #pixelart pic.twitter.com/C9HpIezzH0

— Aarne Hunziker (@MekaSkull) October 10, 2016

Vous aurez probablement compris si vous avez cliqué sur quelques liens pour aller voir les vidéo de gameplay que MekaSkull avait postées qu'on est -- au niveau de l'intrigue -- à la croisée des chemins entre un Ninja Gaiden et un Matrix. Et je dois dire que ça me convient bien.

Il ne manque pas de vidéos sur Internet où les développeurs -- quelle que soit leur expérience -- cherchent à résoudre le problème des 'ennemis stupides' dans un jeu "moi contre le monde". Même la Développeuse du Dimanche y passe [citation requise]. Pourtant, dans ce genre-là, c'est presqu'indispensable d'avoir des ennemis un peu stupides. Pas forcément au point de se jeter d'eux-même dans les trous à la goomba, mais vu leur sur-nombre sur nous, c'est ça où nous rendre tellement blindé d'armure qu'on se demande comment on arrive encore à bouger.

That one enemy didn't seem too tough....#indiedev #8bit #pixelart pic.twitter.com/8QpK23pLAv

— Aarne Hunziker (@MekaSkull) January 23, 2017

Pour moi, le setup 'cyberpunk' avec des robots comme adversaires offre une excellente justification: ce ne sont que des machines. Une tenue de camouflage peut en effet faire en sorte qu'elles soient 'myopes' comme des taupes. L'absence d'instinct de survie peut expliquer qu'elle continuent à faire leur ronde bien qu'on vienne d'éliminer trois de leurs clones, etc. Et on peut matérialiser la borne qui leur envoi un message de 'fin de recherche' si elles n'ont pas trouvé leur proie au bout de 20 secondes (et donc détruire cette borne si on veut).

On peut même justifier leur montée en aggressivité au fur et à mesure qu'on progresse dans le jeu par des mises à jour un peu rushées du genre "dévier l'alimentation vers la coque en cas de choc inexpliqué" (traduction: l'ennemi qu'on utilisait jusque là comme plate-forme va pouvoir maintenant s'électrifier après 1 seconde quand on lui tombe dessus, mais en revanche, ça vide ses batteries pour nous tirer des boulettes dessus).

Some skills can be used in unorthodox ways to avoid traps and travel faster. #indiedev #8bit #pixelart pic.twitter.com/0nwnhaBQRN

— Aarne Hunziker (@MekaSkull) October 3, 2016

Enfin, voilà. Avec le soucis du détail qui a été mis dans ce jeu, j'espère très sincèrement qu'il retiendra l'attention des sélectionneurs de l'Ultime Décathlon!

DS Day Off

 Il me restait quelques jours de congé à prendre. Et la Wallonie avait prolongé les congés de Toussaint de 7 jours ... du coup de mercredi à dimanche, j'ai pu prendre à peu près 2 heures par jour pour faire un peu de développement DS. L'objectif: pouvoir faire une démo des "blocs interactifs de taille variable". La stratégie: remplacer les fichiers de la "démo git père Noël" par les fichiers de Crazy Brix.

J'ai fini par y arriver, mais avec 3 jours de bidouille pour parvenir à utiliser des fichiers pré-existants, on ne peut pas dire que dsgametools soit prêt pour une game jam.

Mon éditeur de sprite ne m'a pas aidé à manipuler ce 'brix.spr', importé par WiFi, si bien que j'ai finalement ajouté un widget pour pouvoir ouvrir n'importe quel fichier (et pas juste les quatre "projets en cours").

Je devrai rajouter une p'tite couche de ce côté-là: une tentative pour sauvegarder les modifications, et vlan, c'est le répertoire tout entier qui s'est retrouvé renommé 'movibak'. Et aussi bien runMe que mon éditeur de niveau se sont retrouvés incapables de poursuivre le travail parce qu'ils n'avaient plus leur répertoire temporaire.

Le code de base du moteur de jeu m'a mis les bâtons dans les roues, lui aussi. Pour pouvoir changer la couleur des briques, j'ai utilisé les changements de palettes. Si, vous savez: ce mécanisme qui permettait à Super Mario Bros 1 de gratter quelques blocs mémoire en recolorant les nuages pour en faire des buissons. Ouais. Bin la DS sait faire ça aussi mais avec 16 variantes de couleurs pour 256 couleurs. Quelque part cet été, j'avais ajouté la possibilité de repeindre les morceaux du niveau (pas juste les éléments de décor, comme dans School Rush, mais aussi les éléments principaux). Mais j'avais oublié que le moteur de jeu, lui, n'était toujours pas prêt pour cette rajoute ^^". Et desmume n'est pas aussi sexy de ce point de vue-là que les émulateurs des devkits SNES ou NES: je ne me suis rendu compte de rien jusqu'à ce que je fasse un dump des registres graphiques dans DDD...

Voilà. Ajoutez un premier jour bien cahotique où le code importé du repository git ne voulait pas compiler, ou ne trouvait plus ses fichiers intégrés, ou "oubliait" de reprendre les couleurs des personnages parce que, dans sa branche, il n'y a même pas encore de support multi-palette pour les sprites (mais si, enfin. Ces p'tits blocs mobiles qui se déplacent librement sur l'écran, en plus des grilles qui servent pour les décors)... Vous comprendrez pourquoi ce genre de chose ne s'était pas mis en place depuis un bon moment.

Twitter Trapped [t.a.g.]

At some point in the future, twitter will no longer exist. That will be a shame, because after dev-fr.org will have closed, that will be the spot where I'll keep contact with homebrew community and get in touch with many indie devs and gamedevs of the 90's. I'll be gone by then but some of my posts will still be heavily referencing contents hosted solely on twitter and until I managed to convert the archives I downloaded into something that can be hosted online, I'll rely on services like archive.org or nitter to avoid luring you into what had turned into the darkest place of the web.