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 ^_^