Pix'n'Gem: La naissance de space invaders

Prenez un Japonais qui maîtrise suffisamment les chips TTL pour avoir réalisé "Speed Race" (mais si! ce jeu d'arcade qui a servi de base au jouet où le volant déplaçait une petite voiture sur une route avançant toujours plus vite ... et à Donkey.bas, au passage :P), qui vit dans une époque où les clones de Pong saturent les machines d'arcade et qui rêve de jeux où les graphismes nous feraient plus voyager que des rectangles et des carrés...

Maintenant, faites-lui se prendre une grande claque en lui présentant le tout nouveau breakout d'Atari. C'est toujours des rectangles et des carrés, mais c'est aussi un jeu complètement neuf! En plus, il vient d'obtenir un processeur 8080 (l'ancêtre du Z80), ce qui va lui permettre d'envisager quelque-chose de beaucoup plus sophistiqué que ces petites voitures (qui étaient déjà franchement pas mal :)

Il ne le sait pas encore, mais il est sur le point d'entamer le développement de Space Invaders, et ce n'est pas un hasard si Pix'n'Love y consacre un article de 10 pages dans son premier mook! L'histoire de Tomohiro Nishikado mérite amplement de figurer dans les référence d'un cours de game design (n'est-ce pas, Mlle L. ;). Partant de Breakout, il modifie le concept, prototype après prototype jusqu'à finalement arriver avec l'idée d'aliens tombant du ciel. On est en plein dans la philosophie de "l'habillage de dernière minute".

• d'abord, des briques, un tireur et des tirs qui montent à la verticale plutôt qu'une balle qui pongue
• les "briques" (en fait des cibles) pourraient bouger: ça donnerait plus de challenge
• il faudrait limiter le temps, comme dans les jeux de tir mécaniques 
• OMG ! en fait ils pourraient faire ce que les cow-boys en alu des salles d'arcades n'ont jamais pu faire: ils pourraient nous tirer dessus si on ne tire pas les premiers! (eh oui, à l'époque, c'était une idée novatrice, voire audacieuse)
• et on aurait pas besoin de limite de temps si les cibles-qui-tirent avancent vers nous. 
• S'ensuit enfin la recherche du bon habillage ... et c'est finalement la folie Star Wars qui donne l'idée

Le dossier ne se limite pas à interviewer sur le développement, cela dit. On a aussi des détails intéressants sur les playtests avec les clients potentiels, le lancement, etc. Mais surtout (pour moi) une note qui retient mon attention: le devkit 8080 coûtant trop cher, l'équipe doit se fabriquer le sien, ce qui lui prend 6 mois hors des 10 consacrés à la réalisation du jeu. Ahurissant du point de vue d'un programmeur de machines tournant à 66MHz, mais le gars a l'habitude de réaliser des circuits, pas juste des programmes. Et son écran n'aura besoin que de 480kHz pour tracer les 256x224 pixels du jeu... ce qui devrait rendre possible le prototypage sur breadboard avant la mise en production d'un PCB.

Bref, la suite du Pix'n Love  #1 devra attendre parce que me voilà parti à fouiller les schémas de la borne pour essayer de reconnaître la partie "générateur d'image" après avoir découvert qu'il utilisait une VRAM en mode "gros bitmap" en creusant dans le code désassemblé (?) qui tourne sur le CPU. Un bitmap, ça veut dire que 8 pixels contigüs sont rassemblés sur un même accès mémoire ... c'est souvent désagréable à gérer surtout quand on a un défilement horizontal: nos données devront être décalées et appliquées sur deux zones mémoire. Mais dans le cas de space invaders, l'écran est placé à la verticale (assez fréquent dans les machines d'arcade), si bien que nos aliens -- qui font justement 8 pixels de haut -- n'ont jamais besoin de décalages. Et pour les tirs, le 8080 est secondé par un registre à décalage manipulé avec les instructions IN et OUT comme s'il était un coprocesseur.

edit: on a aussi un sympathique article de quelques pages sur Toki dans ce numéro (mais qui fait plus figure de test/présentation dans un magazine style PCFun) et un dossier sur la création de Metroïd mais qui reste plus en retrait: quelques trivias sympa, une remise dans le contexte historique, mais c'est tout.

Enfin !

Il fait partie de mon top 20 des jeux vidéos, et ça fait pas loin de 20 ans que j'essaie d'y jouer, des mois que je résiste à la tentation de prendre un abonnement sur ma Nintendo Switch pour y jouer. Le linker GBA s'est avéré décevant, j'en arrivait à envisager de demander à quelqu'un de remplacer une ROM sur une cartouche lambda étant donné à quel point il était introuvable en magasin.

Mais ça y est: j'ai enfin une cartouche de Kirby & the Amazing Mirror(s) pour GBA! (à laquelle je jouerai sur NDS lite, ne vous déplaise ... les gâchettes de Lime fonctionnent encore assez pour appeler à la rescousse:). Je n'irais pas jusqu'à appeler ça une occasion en or, mais je vais pouvoir me replonger dans quelque chose d'inspirant au niveau game design et ça me fera du bien ^_^
 

Signets et attach

J'ai pour la SchoolZone l'intention d'introduire des signets/marque-pages qui pendouillent... on pourrait s'y accrocher (indispensable), grimper, descendre (sympa) et ils réagiraient comme des cordes plutôt que comme des barres.

J'ai appris dernièrement qu'il fallait que je prototype ce genre de choses dans l'environnement des "three rooms" sous peine d'être démoralisé par le côté "nu et inintéressant" d'un niveau à peine commencé. Et coup de bol, il y a un coin de la salle "école" qui conviendrait bien : le haut. On pourrait atteindre les signets en utilisant la gomme et s'en servir pour rejoindre l'éponge, un peu compliquée à utiliser pour l'instant.

Hanging to a rope-like bookmark, using it to swing around and hop to the next ... that's clearly something I'd like to bring into the school zone and I may have just found the right way to introduce it first in the "three rooms" demo. Yes, I could use one of the levels in which they are featured, but recent development on the green zone shown that a rushed large level doesn't motivate me as much as a small polished screen can. They would be there, in the top corner and providing an alternate way to reach the swinging Spongebop.

Avant de permettre de s'y accrocher et de se balancer, je voulais voir comment m'y prendre pour une interaction plus simple: juste laisser Bilou bousculer le signet et qu'il ondule un peu en reprenant sa place. J'ai le comportement "circular" qui pourrait être pas mal pour ça.

Before I'll let Bilou grab them and swing, I'll have to start with something easier, like just having Bilou disturb them and make them swing stronger when passing nearby. It should be a mere matter of attaching segments to one another with the "circular" controller... except that once Bilou pushes the bottom part of the "rope", segments now need to lookup two objects instead of just one. And that's a bit more tricky to handle for my engine that only allow one object pointer per object.  

Sauf que on tombe dans le cas de figure compliqué où les mouvements d'un segment dépendent à la fois de la position du segment au-dessus et en-dessous de lui, ce qui pose trois questions:

• Est-ce qu'il faut que j'ajoute une zone "solide" à Bilou ?
• Quels flags (pour les collisions) sont disponibles pour ajuster les comportements (j'ai oublié ^^") ?
• de quelles infos est-ce que je dispose après une collision entre deux segments ? Est-ce suffisant ? 

J'avais pensé relire le tag "attach" pour me rafraîchir la mémoire, et j'ai eu la désagréable surprise de le trouver confus, avec quelque malheureuses infos pratiques perdues au milieu du "gamedev story". Il est devenu mon "tag de la semaine", mais j'ai dû reconnaître que ça ne suffisait pas. Je me suis retrouvé à essayer de l'extraire avec les outils "blogpress" et lui appliquer une feuille de style avant de l'utiliser pour tester les "pages web codeberg".

So, that was the idea back on 11/11 when I sat down with my notebook and collected the questions that needed answers before I could get to the coding stage. I thought unrolling the "attach" tag of the thread would give me answers, but it turned out the useful information was somehow lost into trivias, screenshots and other progress reports. And the code documentation wasn't much better, so I ended up restoring a setup for blogpress and tutogit at the same time, uploading them all on codeberg and see whether I could apply simple.css etc.

ça m'a donné le déclic pour reprendre le travail sur le repository "tutogit", en plan depuis 7 ans, vu que maintenant le nouveau système de gestion des propriétés du niveau est arrivé à maturité. Je pense que ce serait là le bon emplacement pour des pages thématiques présentant chaque élément du moteur de jeu ... qui puisse au final s'intégrer à la documentation doxygen. Voilà déjà celle pour attach.

simple.css

That's the stylesheet colleagues use when they make some internal website. This is what my HiFi remote control over HTTP is lacking... https://simplecss.org/

Although, I may like it better with a few CSS transitions, especially for the navigation header:

header > nav a,
header > nav a:visited {
  margin: 0 0.5rem 1rem 0.5rem;
  border: 1px solid var(--border);
  border-radius: var(--standard-border-radius);
  color: var(--text);
  display: inline-block;
  padding: 0.1rem 1rem;
  text-decoration: none;
  transition-duration: 0.2s; // added
  
}

header > nav a.current,
header > nav a[aria-current="page"],
header > nav a[aria-current="true"] {
  border-color: var(--accent);
  color: var(--accent);
  cursor: pointer;
}

header > nav a:hover { // forked out of block above
  border-color: var(--accent);
  color: var(--accent);
  cursor: pointer;
  transform: scale(1.1); // added
  transition-duration: 0s; // added
}

It acts on <a> tags that sit withing the <nav> in <header> section, making them more ... playful and engaging ? It's been sitting here for a while, but now that I'm toying a bit with codeberg pages, It's time to publish my original (Nov '24) notes as well ^^"

The basis of  simple.css is to create a grid at page level, and to indicate on which cells of the grid each item should fit. Lines are created automatically by titles, paragraphs and things alike, while columns are templated once for all.

The core layout of the document is defined by grid-template-columns: 1fr min(45rem, 90%) 1fr;, which is where the 3 columns come from.

• column 2 is 720px (45*16) if that fits, 90% of the page width otherwise.
• columns 1 and 3 are as large as allowed, the fr unit being "how much space is left". Apparently, balancing available space between the two is automatic although you could have used .5fr 45rem 1.5fr to get one margin bigger than the other.

45em is more or less the size you need for a 60-75 characters amount in English (the target of most LaTeX documents). There will be another rule stating grid-column: 2; within body > *, meaning that anything within any tag within <body> goes into column 2. That's why my blogger-to-simple script ends up with some text weirdly on column 3 when it isn't in any tag, but just sitting directly within <body>

Survivre à Octobre

Bon, c'est sans doute excessif comme formulation, donc pardon pour le drama. Mais le mois d'octobre n'a pas été de tout repos. Entre les travaux sur la maison qui sont sur le point de démarrer (mais qui s'accompagnent de mauvaises surprises), les efforts pour la désencombrer et les déboires accompagnant les remplacements de PC au bureau, j'ai rarement eu assez de tonus pour envisager du gamedev en fin de journée ... encore moins pendant les week-ends. 

Ce qui aura le plus fait progresser "dreamland", ç'aura été les efforts sur les "pentes glissantes" qui interviennent ça et là dans les niveaux dessinés par mon frangin pour la "green zone" il y a tant d'années. Ah, et je vous rassure tout de suite: elle n'auront pas cette dégaine d'ovni digitalisé : ça c'est juste un montage pour essayer de me rendre compte des couleurs à utiliser, des ombrages qui marchent ou non, etc. 

Non, le graphisme actuellement utilisé pour la démo est beaucoup plus sommaire que ça, pas franchement mieux intégré.

Le comportement de base est codé, mais il reste insatisfaisant, en particulier parce qu'il permet de sauter à pleine vitesse vers l'avant même si l'eau nous faisait presque reculer. Le mécanisme de "tapis roulant" ne suffit pas ici. 

J'avais aussi envisagé au début du mois de commencer à dessiner quelques sprites pour le personnage de "Napin", ou au moins d'étudier les oreilles des Tiny Toons, mais ça non plus, ça n'a pas réellement eu lieu. 

Out of Memory

There's something going disturbingly wrong with my debian setup ... I thought it was mainly an issue with firefox, where the whole system froze and became completely unresponsive when youtube's scripts push the browser out of memory bounds. But it just happened as I tried to convert a too complex picture into a stack of svg path with inkscape while still having gimp opened with the bitmap edits and consuming about 3G of RAM to host them.

Usually, I can then access a text terminal and launch the top tool to kill the process that went crazy, but with that debian 12, it seems like it couldn't even keep that in memory ... too often, I end up having no other option but forcing the system to shut down, losing whatever state I had on the machine.

A message on stack exchange describes quite accurately what is possibly going wrong: the system has been assigning so much memory to data that it started stealing pages of executable code from processes ... and unfortunately, those processes call these pages back, forcing the swapper to find something else to kill, again and again. the "Out Of Memory" behaviour of the system does not kick in, or not before things have been running wild for over 10 or 20 minutes.

I've found some blog page presenting "Early OOM", an alternative that would kill memory-hoggers process in advance. Got it installed ... Got to check whether it helps ... Still have to write a wrapper to firefox launcher that would ulimit its consumption of virtual memory (did check it is effective).

(Maybe having a look at https://fedoraproject.org/wiki/Changes/EnableSystemdOomd could be useful, although it is for fedora installs) 

Spotting systemd_oomd running on my ubuntu (virtual) machine ...  

A better snake (?)

Looloopaa made a funny edit of a pokemon to make it look like it had a hand instead of its head... and that reminded me of my yet-to-be-drawn sand-snake for the pyramid. It was looking good (else it wouldn't be featured on the banner), but I'm struggling to be consistent with its design, especially when it's attacking and not just being intimidating. I picked up my boox and tried to sketch what a hand-snake would look like

Un petit post qui aurait dû paraître en Juin ... j'étais tombé sur une réédition d'un pokemon qui remplaçait sa tête par une main ... comme j'ai un peu du mal à dessiner la tête du serpent-de-sable pendant son attaque, j'ai essayé de la remplacer par une main, elle aussi.

(for reference, the original GBC interpretation of Slapras). And regarding whether that would be drawing inspiration too far, the artist said:

Hah, I'm not the first person to replace a head with a hand and I won't be the last. If it sounds fun I say you should go for it! -- looloopaa

There would be another benefit from having a s-hand-snake: in a world where the most common limb is a floating blob, it helps understanding where people crafting those giant stone smasher drew inspiration from.

Je ne suis que moyennement convaincu par le résultat, mais ça aurait assurément l'avantage d'ancrer dans le monde de Bilou les poings-écrabouilleurs de la pyramide.   

Le mois dernier

Il faut bien le reconnaître, le mois de Septembre a été pas mal secoué... le remplacement de la machine à pain n'étant que le début des rappels à l'ordre du monde réel ... et j'avais un bouquin intéressant sous la main pour les soirées parce que m'attaquer à du code, j'avais rarement l'énergie de m'y mettre. Et quand je m'y mettais, c'était sur un side project que je retarde depuis trop longtemps: un remplaçant de Tomboy basé sur les bibliothèques d'Enlightenment... L'occasion d'ailleurs de me frotter un peu plus à Codeberg, l'alternative à github.

Mais il y aura quand-même eu quelques Bilouteries ... Dont des petits fantômes plutôt sympas inspiré d'un motif sur un des vêtements de ma fée... Enfin quelque chose qui fasse suffisamment fantôme sans faire trop Boo. C'est la castle zone qui va être contente :P

Bon, en plus de ça, je suis aussi tombé sur des moddeuses de (3)DS qui présentent leur collection .... et j'avoue, n'ayant toujours pas trouvé le public de School Rush, les voir inclure Ori ou Kirby dans leur coup de coeur, ça donnait envie de tenter d'établir le contact et de poursuivre l'exploration.

J'ai un peu discuté avec mon frangin des incohérences des niveaux historiques et de la manière de s'y attaquer, mais j'avoue que ça m'a plombé plus que motivé même si on est d'accord. Je crois que l'approche "make it exist first" ne me convient pas pour l'instant. J'ai besoin d'environnements qui permettent d'avancer proprement sur les nouveautés, pas d'un gigantesque chantier de trucs qui ne marchent pas. La prochaine étape, ça devra donc être de remplacer le setup "ramassage de pomme" par un setup "cascade/glissade" dans la première des "three rooms"

Et puisqu'on est dans le tour des trucs en vrac sur lesquels j'ai passé du temps, j'ai essayé un design pour un futur T-Shirt "if it's not broken, open it and see how it works" qui aurait été basé sur le bloc-question de Super Mario World, ce qui m'a emmené faire de l'analyse d'assembleur SNES. Mais ça n'a pas donné si bien que ça de sorte que j'ai aussi imprimé des schémas de circuits amiga pour une approche plus copper-and-blitter.

Réparer Lime ?

"Ah, oui. Les gâchettes, c'est un peu plus cher à réparer parce qu'il faut souder" déclarait le mois dernier un vendeur de NDS moddées. J'ai été un peu surpris, j'avoue, et me voilà à passer en revue une vidéo Réparer les gâchettes sans un sou. Alors ? Est-ce une piste pour remettre Lime en selle ?

Sans un sou peut-être, sans souder sans doute, mais pas sans sueur froide. Une fois la coque ouverte et la partie mécanique des boutons extraites, il s'agit d'aller nettoyer la corrosion installée à l'intérieur du micro-switch 0_o.

The Fix fait ça avec une lame de rasoir pour écarter la protection métallique qui maintient le micro-switch en un seul morceau et l'incliner vers l'avant pour libérer les composants internes.

Au fond du switch, une zone métallique qui fait récepteur et qu'il faudra grattouiller avec une aiguille pour faire partir la corrosion. Par-dessus ce récepteur, une coupelle métallique qu'on sort par magnétisme pour lui faire subir un traitement similaire. Mais attention à ne pas la déformer ! Et enfin, par-dessus tout ça, il y a le petit bouton en caoutchouc qui presse la coupelle sur le récepteur pour faire contact.

Une fois les métaux restaurer, il faudra tout refermer délicatement. Autant dire que ce n'est pas gagné d'avance. Mon frangin m'avait bien proposé une "Silver" en manque de batterie, mais je viens de tester avec une batterie de secours que j'ai ressortie d'un tiroir et ... bin rien. La Silver, ça semble être son bouton power qui est en rade ^^". Mais ça, c'est encore un autre niveau. 

 

Une pente qui tombe à l'eau

I had tiles that push you along a slope. They've been shown in the sands mostly, but more importantly, they've been tested in a setup where there's plain ground at the bottom of the slope.

Here, I'd like to use water falling down a slope as a way to implement a one-way region somewhere in a cavern of the green zone. But it didn't quite worked as intended. What makes Bilou slide down in such a setup is that a test-point queries the tile number under his feet and use that to look up a physics values array. But once you get down the hill, the hotspot gets in the air, and nothing finishes to push you out. 

Il y a sous l'arbre creux une sorte de pente rendue glissante par une cascade sous-terraine. Mon frère l'avait utilisée pour créer une sorte de sens interdit entre deux morceaux du niveau. Alors j'ai déjà des pentes, donc ça aurait dû être une simple formalité, mais comme vous l'aurez sûrement deviné par le titre, ça n'a pas été sans mal Premier couac: en voulant rendre ce "tapis roulant" plus rapide que les chutes de sable, je suis sorti des limites d'un tableau, ce qui a eu pour effet d'appliquer l'effet geyser à l'ensemble du niveau ^^".

Plus contrariant, une fois arrivé en bas de la pente ... rien. On ne tombe pas dans l'eau, on reste juste là, sur le rebord. Parce que c'est le pixel sous le *milieu* de Bilou (le "hotspot") qui détermine si on se trouve sur un tapis roulant mais qu'il faut qu'il n'y ait plus rien sous lui sur toute sa largeur pour qu'il commence à tomber. Je dois donc rajouter un autre type de tile qui pousse comme un tapis roulant tout en étant pas du sol.

So I added another tile that behaves like air and keeps pushing you as if you were on sliding ground and put them at the bottom of the slope, but even that wasn't enough to get it working. It would take you as far away from the slope as you want, but then, once your hotspot is in plain air, you'll stop, happily idling in the middle of nowhere.

The part I was still missing was the F_START_FALLING property to my new tile type, something introduced so that we could land in slopes properly by having slope tiles letting you keep falling into them (until the hot spot reaches the ground) but not start falling through them when you're walking.

Il restait un dernier soucis. Un couac lié à un changement plus récent et qui fait qu'après avoir bien emmené Bilou au milieu de nulle-part, il ne tombe toujours pas. tout ça parce que j'ai donné au nouveau tile possède bien la propriété F_FALLTHRU, utilisée pendant que Bilou tombe, mais pas F_START_FALLING utilisée pendant que Bilou est au sol pour voir s'il pourrait tomber ^^"

With that new bit set, we finally have it: Bilou keeps sliding until there's no solid ground, and there  it cando(START_FALLING) and ends up in the water :P

There's one odd thing going on with the way the water slide is made as a conveyer, though. Conveyers just move you and don't affect your speed, and that's on purpose. But that means that as you're running full-speed against the water flow (if you manage to) and decide to jump, you suddenly move in the air at top speed while you were almost idle on the ground.

Maybe I should mimmic Sonic's water slide and make a dedicated "woah! I'm sliding down!!" state for Bilou as well.

But even then, when Bilou is walking against a conveyer, it is natural that he's walking faster than he's moving ... against water, we all know there's a force slowing us down, so it'd make sense to see his animation slowed down and pixel-fitting its motion against the water ... which would mean acting on his speed rather than shifting his position ... Meditate on this I will. 

Petit à petit, le niveau se construit...

Bon, j'ai passé un peu de temps dans mes éditeurs sur DS ces derniers jours pour habiller un peu plus le premier niveau et je viens de construire une map avec le 2eme (après un moment de frayeur de "est-ce que je ne viens pas d'écraser mon gac.map en essayant de créer gpc.map ?_?"), tout ça pendant que je faisais la mise au point des portes du côté PC.

• un arbre tout à gauche pour marquer le bord du niveau
• (pour une raison inconnue, sortir de la map par la gauche conduit à un plantage de runme ... à investiguer)
• une petite pente avant le premier arbre pour rendre le niveau moins plat, valider le graphisme des pentes et faire de la place pour des plate-formes avec les petits vers dessus (côté notuto)
• il faut encore une palette alternative pour la terre dure et des images de bord pour la terre d'arrière-plan
  

I've spent some times on PC to get doors working, but also some time on the NintendoDS itself, putting more tiles around the edges of crude level I had last week. I even tried to start importing the second green zone historical map, but a blue screen in LEDS put that to an end. (possibly linked to bad handling of color palette selection in "paint" mode). It highlighted I'm lacking some darker tones for some parts of the color palette (mostly dirt) and some edge tiles for the "far away dirt"

So here's a couple of screenshots that were part of the last "Screenshot Saturday". One of them illustrating an attempt to implement the "sliding stream from waterfall" which doesn't quite work the way it should: it's too easy to force your way by quickly jumping away again and again. plus, it doesn't kick out into the water once you're at the bottom of the slope. To be investigated

• première tentative pour la cascade-glissante
• quelque-chose empèche le système actuel de nous jeter hors d'une pente avec les tiles "tapis-roulant" ... à creuser.
• correction des hitbox de Bilou qui nage pour qu'il arrête de se manger les murs à tout bout de champ
• habillage de la "cachette sous l'arbre" ... je la trouve un peu petite dans son état actuel ...

Par contre, avant la prochaine release, il faudra vraiment que je prenne le temps de dessiner une deuxième moitié au décor de fond qui convienne pour "au plus profond des cavernes sous la forêt" ...

ROX'64

This is a piece of history. A screenshot from ROX64, a small lunar lander for C64 (without rotation) where you'd have to shoot at meteors once you've landed before the moon you've landed on starts getting moonquake due to excessive amount of shocks from meteors.

Ce petit screenshot n'a l'air de rien mais il a pour moi la saveur du Chaînon Manquant... cette part d'histoire qu'il faut que je vous raconte: c'est le jeu qui m'a fait passer d'un projet de quizz géographique en texte pur à un projet mêmant PETSCII, sprites et même quelques effets son au SID. Oh, ne vous emballez pas: le jeu que vous voyez là est un titre tout à fait officiel dont je n'ai pas touché un seul byte, mais il était écrit en BASIC, et j'ai donc pu l'imprimer, l'analyser et -- au final -- le bidouiller pour remplacer le module lunaire par un Caliméro.

One interesting aspect of the game was that it was 100% BASIC, meaning you could get and print the listing, study it ... and in my case, modify it so you'd play as Calimero throwing apples to avoid getting squashed. It wasn't much, and I bet nobody would have played it more than I did while proof-testing the thing, but it was the first time I was going beyond a quizz game and actually made something with all chips of the C64. If you think about it, replace the starry sky by some massive mountain, make the asteroid look red and you've got a boss-sort encounter that would have actually fit the theme of the (yet to come Calimero) game's first zone.

Oh and the (original) game was by Jeff Minter, by the way .. the one person who wrote "Revenge of the Mutant Camels"
 

Make it exist first,

You can make it good later. It's an ongoing meme in the gamedev community, and it's perfectly capturing what I intend to do with the "Green Zone" levels.  The map is very crude, most of the areas use repetitive patterns of the same block, it feels dull to "play" and I don't even have graphics for the key or the closed door ... but at least, I can check whether we can reach branches, cliffs, leap over holes and the like.

Il y a un meme qui est occupé à faire le tour des groupes "gamedev": un trait qui reboucle plus ou moins sur lui-même entourant un pâté de couleur accompagné de la légende "commence par faire en sorte que ça existe". En vis-à-vis, l'image d'un cercle aussi propre sur lui que s'il sortait d'inkscape ... avec la légende "tu pourras l'améliorer plus tard". Et c'est vrai que c'est assez pertinent: combien de projets ont tourné à rien parce que leur dévelopeur à cherché à atteindre l'inaccessible étoile trop tôt ? En plus ça colle assez bien avec le planning que je me suis fixé pour l'été: faire une version minimaliste de chacun des niveaux qui hantent le cahier-bleu-du-redesign pour voir si Bilou sait atteindre les différents objectifs ou si je dois envisager des mécanisme "d'aide à la conduite" du genre de ceux utilisés dans MainFrames. Et tant mieux si le niveau me sert aussi de bac à sable pour valider le fonctionnement des portes.

Files are being swapped back and forth between the computers and the DS, as I bring together the fixed bouncing branches, geysers and updated applemen. Unfortunately, the level editor is currently unable to show us invisible gobs (workaround: done), and with doors and branches, I start to have a higher number of them ... It also has restrictions on how to link items that I'll like to get rid of later on.

There's something though, that I don't really like about the current state. It's crude. There's no beauty in the way it looks. There's not much fun in the way it plays. Monsters feel placed randomly on uninteresting surfaces. The forever-in-progress "level two" -- with its geyser and huge trees -- makes me feel prouder than this.

Je transfère donc un script dans un sens, un spriteset dans l'autre, je passe du temps dans l'éditeur de niveau pour que ce "Green Zone 1: L'Arbre Creux prenne forme... Forme, mais pas vie. J'avoue que c'est un peu décevant cette austérité, cette absence d'objectif et de gameplay... et je me suis surpris à apprécier de retomber sur le niveau-en-chantier ou la salle de test qui me paraissent tellement plus accueillants bien que totalement inachevés.

Jackpot!

Trouvaille tandis que j'accompagnais ma fée dans le magasin-dont-on-ne-sait -pas-prononcer-le-nom ... Bonne reliure, motif à points imprimés pas trop forts, couverture robuste ... un prix assez proche de ce que je trouvais chez Toga au début. Papier 100gr/m² qui ne laisse pas trop voir mes marqueurs habituels à travers la feuille ... je valide. Même si la tranche dorée me donne un peu l'impression de l'avoir chipé à quelqu'un d'autre ^^"

Pour comparaison, j'ai mis aussi le bujo GDMLUP téléchargé de Chine, 1€ plus cher (sans compter les frais de livraison et le CO2 ^^"), avec un papier 140gr/m² (un peu trop raide à mon goût, mais intraitable contre la transparence) mais malheureusement un motif imprimé avec une encre trop sombre et qui gène la lecture ... mais que j'utilise pour l'instant comme cahier/journal/agenda parce que ... bah, j'avais encore rien trouvé de mieux :P

Enfin des portes

 Si, si ... ce blog parle toujours de développement de jeu DS. C'est juste que les portes, c'est pas mal comme morceau et que les retours de camps, c'est pas mal chronophage. Mais voilà! J'ai eu un truc qui commençait à marcher hier!

Post by @PypeBros@mastodon.social

View on Mastodon

ici je vous ai mis la version rigolote. Quelques heures plus tard, j'avais fini par trouver les bons réglages pour que Bilou s'arrête à la porte de destination une fois sa vitesse suffisamment réduite.

Here's the first somehow-working attempt to move Bilou from one door to another. There are plenty of things still quite crude, and we don't even get the illusion that Bilou enters the door. It's based on another patch that allowed entering the end-of-level doors and on a new opcode that simplifies things by letting Bilou directly target the door's destination rather than aligning on the coordinates of the source door as it moved to the target as I initially planned.

If you can't see the clip from mastodon above, it shows Bilou flipping in front of a door (no enter animation yet ^^"), then zipping to the next door (no hiding yet) and then oscillating around the target door endlessly (wrongly assigned the speed division to a "found" event when I should have used "hit" instead ^^" -- that is now fixed). You'd have missed that it happens in the caves under the Hollow Tree, meaning that yes, I started remaking historical levels into LEDS so that I could test them.

All that also uses (and validates) a fresh implementation of revised collisions mechanism so that we can have collisions for "is there a door", "I'm done entering the door", "I've reached the target door", "I've left the target door", etc. despite the fact that generic flags are already crowded since SchoolRush. 

Les plus observateurs d'entre-vous auront reconnu un fragment de la Green Zone, plus précisément la fin du niveau de l'arbre creux, mais parcouru à l'envers. Donc oui, j'ai enfin commencé à reconstruire les niveaux historiques dans LEDS pour pouvoir les intégrer à Dreamland... ce qui a bien plu à J.L.N, d'ailleurs, qui en a profité pour réenfiler sa veste de chasseur de glitches.

La porte elle-même est finalement beaucoup plus simple que ce que j'avais envisagé grâce à un nouvel opcode: ATATTACH qui permet à Bilou de s'attacher directement à la destination de la porte (à laquelle la porte elle-même est attachée).  

using around

I know it sounds like a detail, but trust me: if your game is lacking a "navigate around the corner of a block", it will significantly impede the gameplay. In some kind of games, it may even *ruin* the gameplay

I did not have it in Bilou RPG, and that meant you would be stopped as soon as your character slightly enters a solid tile. Sure, you can reduce the annoyance by making the box of your character smaller than its appearance on-screen.

You can also keep moving along one axis if the other is impossible. That's what's happening in the 'tutogit' demo, but you can spot times where the character suddenly stops and must be pushed again in another direction. It doesn't feel like how a professional game would behave.  

Super Mario World repousse Mario d'1 pixel par frame si le joueur est un peu trop proche d'un bloc lors d'un saut, autorisant jusqu'à 4 pixels de "débordement" avant de faire rebondir Mario plutôt que de le rediriger. ça n'a l'air de rien, mais c'est le genre de petit détail de gameplay qui fait qu'on peut se permettre des niveau un peu plus chauds sans réserver pour autant le jeu à une élite de speedrunners surentrainés. C'est ce qui faisait en '90 la différence entre Super Mario Bros et Great Giana Sisters.

C'est le genre de subtilité que je n'ai pas pu me permettre avec mes jeux BASIC et qui faisait pester les testeurs potentiels parce que le saut s'interrompait net alors qu'il passait presque. Le genre de subtilité avec lesquelles RSD Game-Maker ne s'embêtait pas et qui explique que Badman puisse filer le long d'un plafond défiant la balistique.

Le problème existe toujours avec GEDS, que ce soit en stoppand net le père Noël de la démo git ou en vous freinant pour rien pendant une ascension périllieuse dans le niveau secret de School Rush. Et donc, depuis aussi loin que j'ai un cahier-agenda, j'ai une page avec une petite note sur ce qui pourrait permettre de se coder ça pour le prochain jeu Bilou. Une page généralement couverte d'interrogations et assez pauvre en idées...

So as you can guess, I'm trying to find a solution to make that work with Bilou in my next game, but to be honest, there haven't been many ideas on the many pages dedicated to the topic in my notebooks. Then two things happened more or less on the same month. I've watched Wye's video showing the interaction points for Super Mario World and I got the idea of having a dedicated state for navigating around a block in my game engine. Which came first, I couldn't really tell any more. Unfortunately.

See, the idea so far was to have an around controller that would be part of the chain of micro-behaviours when Bilou's jumping. But what if we keep that chain unchanged, let the FAIL condition happen, and then check the testpoint and decide whether we could try moving around the blocking ceiling or not.

Mais ça va peut-être enfin changer si je prends le problème par un autre bout: plutôt que de faire un contrôleur qui anticipe la collision et déplace le joueur pour éviter que le contrôleur gravity ne signale un échec, je pourrais utiliser un contrôleur capable de nous diriger pour nous remettre dans l'axe après que la collision ait été détectée.

Une fois qu'il est à nouveau possible de monter, le contrôleur around nous en informerait par un évènement et on en profiterait pour restaurer la vitesse de Bilou au moment où il avait cogné le bloc.

We wouldn't try moving around if a testpoint located above Bilou is in a wall. That's the equivalent of Mario's head interaction point.

• The new controller would tell us whether to align left or right by acting instead of the dpad controller.
• It could report a failure if we're too far away for alignment or if we still cannot keep jumping after alignment happens -- that never happens to Mario because he's a bit narrower than one (16-pixels) block, but tiles in Bilou's world are 8x8.
• It wouldn't have to compensate for vertical speed or gravity because you'd use it in a state where gravity does not apply.
• It would fire an event once alignment conditions are met 

Granted, the behaviour will not be frame-perfect that of Super Mario, but it could be satisfying nevertheless, so it's worth giving it a try, imho.

Chose amusante: le point de "repousse" se trouve au niveau du nez de Mario. Notez que même une fois réaligné, le sprite déborde toujours par-devant le bloc. Et le point qui teste si sa tête a rencontré un bloc est pile entre ses deux yeux.

Bien sûr, avec l'approche que je propose, on aura pas le même comportement à la frame près: Bilou marquera un temps d'arrêt le temps qu'on le repousse. Il faudra tester ce que ça donne pour voir si c'est gênant ou non. Au pire, on ajustera un peu avec l'animation ...

So why reinventing the wheel, you wonder ? why insisting on using cando() while interaction points make things simpler ? well ... because the wheel of Super Mario World is far from being flawless. The gameplay it leads to may be an ideal to reach, but the quality of implementation belongs to the past.

Mario in Godot

Refaire Super Mario World dans le game-maker "Godot" ... j'ai envie de dire à la fois "tout ça" et "rien que ça". Pourtant, l'idée de Wye n'est ni de proposer un Mario World Studio ni son Mario World 3. L'idée, c'est de comprendre le fonctionnement du jeu d'origine en le reconstruisant dans un nouvel outil tout en apprenant l'outil lui-même. Et ça, ça me parle. C'est le genre de bouquin que je dévorerais mais ici, ce sont des vidéos youtube.

"In Super Mario World, Mario was considered fully underwater if both his head and body interaction points are touching water tiles. [...]

That's the kind of things you can learn by watching Wye's series on re-making Super Mario World in Godot, and learn how to use Godot in the process

I've been following the videos roughly since episode 1 or 2, but as Wye now address the water physics, I cannot just remain a silent watcher. I've spent too much time working on water physics myself, and I need to compare the approaches. Of course, Mario isn't using the "cando"  function. Instead, interaction with the world are guided by "interaction points" which remember the type of tile they're on. So for instance, 

"When Mario body is in the water but not his head, that means he is near the surface."

Du point de vue des collisions avec le niveau, Mario n'est pas une boîte. Il est ... une sorte de constellation de points qui ont chacun leur préférence sur le type de terrain 8 en tout, mais dont certains ne seront évalués que dans certaines conditions. Pour déterminer s'il faut nager ou non, ce sont par exemple ce sont les tests du milieu et de la tête qui entrent en ligne de compte. Et pour déterminer si on peut sauter hors de l'eau ? Bin il faut que le corps de Mario soit dans l'eau mais sa tête hors de l'eau. On évite en fait les complications du type "la surface est à la fois de l'air et de l'eau" dans lesquelles je me suis embarqué.

And only when Mario is near the surface is it possible to jump out of water ... and only if pressing UP in addition to pressing the JUMP button ...

The concept of interaction points comes from the disassembly of SMW itself and was discussed in an earlier video. They replace hitboxes when it comes to interacting with the world and there are 8 of them for Mario. But as usual with 16-bit games, not all points are tested on every frame. What is interesting is that rather than testing e.g. "left side" when moving left, the game tests "left side" only if the left side is "smaller" than the right side, as a way to detect "new" things, assuming that what covers most of Mario's box has been tested in the past. "When Mario is on the right side of a tile, the two points on the left are ignored" is possibly a better way to describe what happens, indeed ^^".

I'd be curious to find out to what extent that keeps working where your level grid isn't exactly one hero wide ...

edit: while you need to *press* the jump button to make Mario jump when he hits the ground from a fall, you just need to be *holding the button down* when reaching the water surface to trigger "jump out of water".  (from the "extra bits")

blogpress 0.3

Combinez les scripts de traitement "blogpress" (blogger-vers-epub) et le service d'impression utilisé par Rodrigo Copetti et vous aurez le "side-project" qui me distrait actuellement... Alimenté en plus par une page de recherche sur l'utilisation de XPath pour "travailler plus proprement" ... Sauf que XPath, pour traiter une requête sur le blog, il met 8 secondes. Mes expressions régulières, 1/8ème de seconde.

Ça fait un peu suite à des travaux de septembre dernier pour essayer de voir ce que les "takeout" de photos google ont vraiment dans le ventre, et l'idée serait de "rassembler tout ce qui peut parler de Qui est Bilou, plutôt en Français à destination de la génération suivante.

I have PERL scripts to process the XML data exported from this blog and fetch pictures to get something that could be printed or converted into epub. So far, it had a drawback: if you got an updated version of the xml (i.e. a later backup), all implied filenames for the pictures would change and almost everything would have to be re-downloaded. A shame in a context where some pictures may get lost.

So I opened them again and started replacing "line number" by "uuid generated by blogger", which gives them stable filenames. A curious idea, when you know I was almost stunned by fatigue. I guess I was just too tired to resist the idea of working on a printable book around the idea of "who is Bilou?" that could be printed like the work of Rodrigo Copetti.

Things haven't been all fine, though. One annoyance was those "new" (vs. 2019) 72x72 pixels thumbs that broke some assumptions I made about multiple URLs pointing to the same file in the same post... Then I've tried to use symlinks to refer to contents previously downloaded, but accidentally forgot to tell the "get-pictures" script that it should skip symlinks when they're around, so it tried to overwrite those pictures I already had and I had to plug my backup HDD and enter data recovery mode ... (I mentioned I was tired, right ?)

Plus tôt dans le mois, j'avais passé en revue tous les posts avec le tag "Bilou", donc, pour en retenir à peu près la moitié. 16 Mo de fichier XML, 106 posts retenus (plus les drafts ^^ ) ... des soucis avec les miniatures 72x72 qui essaient de se faire passer pour les images "grand format" ... des soucis avec les fichiers 1600-h qui font semblant d'être des images mais sont en réalité des pages HTML présentant l'image ... des soucis avec les fichiers tirés de screenshots dans firefox qui à force de conversions / -> %2f finissent par produire des noms de fichiers trop long ... les joyeusetés du scripting quoi. Mais au final, j'ai pu avoir un fichier HTML d'à peu près 1Mo référençant la majorité des images voulues convertible en 115 pages de pdf mal fichu (entendez, avec tout de même des images tronquées ou coupées sur deux pages ^^") qui m'a donné envie de voir malgré l'heure avancée "ce que ça donnerait avec la sélection définitive"

Je me prépare donc à télécharger blog-05-07-2025.xml mais à la place ... me voilà débarqué dans le portail "takeout" de google ...  

By late Saturday, I had collected everything again and was ready to apply the scripts on the latest .xml file, the one where I'd have processed all posts with #bilou and assigned some of them to #firstDemo (because they really weren't quite about Bilou himself, but about trees, applemen, scripting ... or something totally unrelated but featuring a small illustration from the 2001 comics). Only to realize that Google has now decided that Blogger export should be managed by the Google Takeout portal. That means waiting for several hours (up to 2 days, but hopefully not in my case), checking boxes and finally receiving a link to a 2GB archive containing .... (drumroll) ... the whole set of pictures uploaded to the blog.

Il me faut donc patienter plusieurs heures pour avoir le nouveau .xml qui est entre-temps devenu un .atom, a laissé tomber certaines informations, regroupé d'autres autrement et est maintenant accompagné ... de l'ensemble (?) des images du blog. Je m'autorise un point d'interrogation, parce que si j'ai finalement pu produire le bilou.html.pdf que je voulais, j'ai quand-même conservé le listing URL->fichiers construit avec blog-28-06-2025.xml et pas avec le nouveau feed.atom ...

Tout ça pour passer le témoin aux p'tits jeunes ? Bah, quand j'ai montré pour la 2eme fois à J.L.N les feuilles qui étaient malgré tout sorties de l'imprimante, il n'y a pour ainsi dire pas regardé et m'a demandé si j'avais fait des progrès avec les cascades, le bug de Bilou-ballerine et tout ça  ^^"

edit: j'ai finalement un petit script thumbify.pl qui rassemble toutes les images 72x72 un peu mieux qu'un oneliner bash et y ajoute les liens vers les posts du blog. ça nous fait 26MiB d'html+png (probablement inutilisable vu le nombre de requêtes HTTP qui seraient nécessaires -- comptez 30' sur le wifi local) ou 11 pages A4 (pas beaucoup plus utiles vu qu'on ne sait pas y faire de recherche ou cliquer sur les liens ^^"). A découvrir sur neocities...

edit++: capturer l'attention de J.L.N avec la page: check ^_^

Dangerous, not evil

If you could read the very early design documents of Bilou's Adventure, you'd note a mad scientist (somehow mix of Dr. Eggman and Dr. Gero). All the bosses are experiment he conducted and likely all the baddies are after you because of him. He was actually imported from sketches of "Calimero". He didn't last long.

Au début du design de Bilou, en '93, le joueur était face à un savant fou (importé de Caliméro), une sorte de mélange entre le Dr. Gero de Dragonball et le Dr. Robotnik de Sonic qu'il lui faudrait affronter dans le combat final, et tous les monstres qu'on allait affronter étaient de son fait ou dans son camp. 

Later on, when working on the "ultimate game maker" idea, I tried to introduce an invading species like the Kremlins in DKC or the Koopas in SMB, that would justify the quest, but that didn't last long either (actually, I couldn't come with anything interesting enough to give it a variant for every zone Bilou travels).

Plus tard, en '98, en parallèle aux recherches techniques sur l'Ultimate Game Maker, j'ai essayé d'ajouter une espèce invasive -- l'équivalent des Koopas ou des Kremlins des jeux Nintendo -- mais rien ne marchait vraiment. Entre autre à cause de l'aspect hétéroclyte du monde de Bilou qui n'a pas grand chose en commun avec le Royaume Champignon. Puis alors que la BD de Bilou prenait petit à petit corps, pas mal de personnages qui étaient au début des monstres se sont retrouvés à jouer un rôle nettement moins "noir ou blanc". Le champignon fou se met a avoir un idéal dans la vie (parvenir à voler) et des mouvements d'humeur.

On retrouve quelque-chose du même tonneau avec la gomme qui charge le crayon (qui l'a réveillé en sursaut), mais qui discute tranquillement devant un gogo susceptible de lui construire un pont. Avec les esquisses de la rencontre avec Bangbash, c'est devenu un mécanisme narratif assumé: il y a des personnages dangereux, au même titre qu'un taureau ou un sanglier sont (plus ou moins) dangereux, mais il n'y a pas de méchants (ou très peu: ce seront les pendats de School Rush, par exemple). Et voici une petite gribouille de 2009 qui reprend cette idée pour la première fois à plat.

Then came the comic, and with the comic, many of the baddies stopped being "evil". The bopping mushroom (now known as Funky Funghi) may occasionally become excessively angry, but he also asks Bilou how he manages to fly and whether he could teach him to fly as well. The RectoVerso eraser is aggressive against the crayon who woke him up, but can just stay there and chat when it seems that he could trick Bilou and Bouli. 

And the picture you have above puts it into words for the first time: they are *dangerous* (like a bull), not evil. Very few of them attack you just because you're a non-them, but you should rather not mess with them either because you could quite easily got hurt. With a few exceptions (like the pendats), what you're facing is *not* an army.

Le truc s'invite même rétrospectivement dans School Rush avec un "évidemment que les gommes sont énervées: l'encre monte", soutenu par un graphisme de gomme qui dort une fois qu'on a rebouché la fuite, ou l'idée pour Dreamland que les applemen soient passifs tant qu'on a pas ramassé de mini-pomme. On justifie l'aggressivité des applemen de Apple Assault par le fait que le vaisseau de Bilou et Bouli vient de s'écraser dans la forêt, saccageant leur habitat naturel (désolé, les compotes ^^")

Tomba/ponkadunk pixelstudy

"Tomba!" by Ponkadunk, published in 2019 on pixeljoint and dug by PixelProspector. A pixel art mockup of what could have been the PSX game "Tomba" if developers had not opted for polygonal textured levels instead. It's been teasing me to pixel-study it for years now, so let's give it a try. About everything in this scene is a mastery: the characters, the pick-ups, the ground ... but if you don't mind, this time I'll focus on the background and maybe the rocky ground as these are the parts in my green zone that could use some more work.

I always interpreted the background as "leaves in jungle", but if you actually go beyond the fact that it's all green, you quickly note that these are bunch of leaves here and there over a rocks background. By playing with the palette, I could spot that the greens for the rocks and the greens for the leaves are actually two distinct ramps, only sharing their darkest parts.

The rocks ramp goes from h120s66v30 to h118s79v15, with hue shifts towards h107 on the 2nd lightest shade and h123 on the second darkest. The leaves ramp goes from h93s84v33 to h103s76v20. (oh, I used a "hsv hue" layer in Gimp to tint the "rocks ramp" towards yellow so we can distinguish it better from the "leaves" ramp.

Note in the middle of the snippet that we have blade-like shapes with the rocks ramp, so likely darker leaves more than odd-shaped rocks. A reminder to not let the initial purpose of colours dictate you how you use colours when doing pixel art... not until you really have to ;)

The common darkest shade at h123s71v11 unifies the things together in a single shadow. While some elements are fully detailed over that background, other blend in and only reveal their contour with some of the darkest shades of the ramp.

The tiling of the pattern is huge -- some 164 pixels wide, which does not correspond to any hardware-friendly size, and this is no issue for a mockup.

Compared to Eagle Island or Sonic Mania background, this one has the advantage that it could fit fairly well the colour count and the memory of the "farground" in my engine.
 

Les portes ... prochain vrai objectif

C'est ce qu'on pouvait lire en mars sur une de mes pages d'agenda et en avril sur mastodon. Et c'est toujours d'actualité, bien que j'envisage de faire d'abord un essai des éléments de base de leur implémentation sur un le bonus qui rend des points de vie ... Si vous avez un peu essayé la dernière démo, vous avez sans doute été surpris par un brusque changement de niveau dès que vous vous approchez un peu trop d'un truc en forme d'ouverture. C'est clairement quelque-chose que je voudrais améliorer.

La bonne nouvelle, c'est qu'en fait, j'ai déjà la moitié du travail: enregistrer la position actuelle dans des variables. Et voici la deuxième partie: se diriger vers les coordonnées enregistrées.

Bilou's Adventure maps have doors... you know, the kind that are located at some point on the map and will near-instant put you somewhere else on the map. So I'd like "Bilou Dreamland" to have doors as well... That will require a bit more effort in the GEDS environment that can't simply do ROOM=12 : xbilou=100 : ybilou=100. So i've got this nice tree stump sketch in my agenda since at least March'25, and I've been twisting my mind around the issue of how to make it work with state machines and collisions and linked game objects.

Now, my Basic games typically struggled to extend beyond one level. At best, I'd chain-load the next level which would happen to look a lot like the previous one (or not) by sharing lot of code thanks to copy-pasta... And entering a door would typically freeze everything as the game had entered a dedicated micro-script that ignored everything but entering the door. 

L'idée générale, c'est donc d'avoir deux "personnages" pour une porte, l'un représentant le point d'entrée et l'autre le point de sortie. Le mécanisme d'attache qui permet à Spongebop de rester pendue à son clou peut aussi servir pour lier les portes. Bilou, lui, se liera à la porte "entrée", et la suit de la même façon que dumblador suit Bilou quand il le transporte.

The overall idea is to have two game objects involved in a door-to-door transit: one being the incoming door, and the other being the target location. There will be a one-way link between them in the level script. As part of the 'entering' trigger, Bilou would attach to the input door, which is itself attached to a target GOB. Using that to transport Bilou to the destination should work quite nicely: it's been years that tracking the attached object works nicely. The question is "how do I send back the door once Bilou has left?"

I cannot just "track an object left at the original position", because so far, the engine only track *one* object at a time. But I could record the position before leaving, and -- with the help of a new controller -- track that position. In fact, I already have such "record position" behaviour as part of the "grid" controller used by bouncy branch and furblock.

Coding directly such a multi-step mechanics didn't sound a wise move to me, but I had an animation for the health power-up that made it circle around ... and a notebook entry suggesting to do that with lines of code rather than lines of pixels. I'll save the introduction of an invisible permanent object to circle around if I inject "reccoords" and "track(recorded)" in that health pick-up ... which has just been completed today. 

Voilà donc un premier pas franchi: ce petit point bleu volant a enregistré sa position d'origine comme l'aurait fait une porte et est en train de se servir du nouveau contrôleur pour s'orienter et graviter autour. 

Bon, et se faire transporter ne sera pas tout: je voudrais aussi qu'on ait l'impression que Bilou *rentre* dans la porte avant le transport. Quelque-chose de plus convaincant que le simple décalage vers le noir de la version BASIC où appuyer sur "haut" un peu trop à gauche ou à droite nous enverrait à travers le chambranle, la main devenue noire de Bilou ressemblant à un trou de trop dans le mur :P  

And I must admit I injected significant time in thinking how Bilou would *enter* the door. I know it isn't required to see him walk into the door like Bubsy did, and likely the spin at the start isn't strictly required either, but I intend to use it as the excuse to align Bilou with the door such that I can later fade him to black without having a Bilou-shaped hole dug into the wall (QBilou.bas did that ^^) nor require pixel-precise location to activate the door (Super Princess Peach did that >_<)

edit: If I give the engine one extra opcode to "attach to the object that object is attached to", then all those extra steps about the "door" acting as a flying carpet that takes you to a given destination and then goes back to its anchor location becomes useless...