20 ans de Nintendo DS

Il y a 20 ans, j'ai reçu plus qu'un nouveau gadget. Une nintendo DS .. avec aucun jeux, en fait. On nous avait annoncé un nouveau Super Mario, un nouveau Zelda et un nouveau Yoshi Island. Bien plus intéressant que les projet rub et zoo keeper qui avaient accompagné la sortie.

20 years ago, I got a new something that was hugely more than a gadget. A nintendo DS. Just that. Not even a game to run on it, but I was then ready for the freshly announced New Super Mario Bros, the new Zelda and a shiny-new-pixelart Yoshi Island.

I started a small bsky thread to commemorate and got significantly more feedback than ever!

Comme j'avais envie de revenir un peu sur tout ça, j'ai fait un petit récapitulatif de la première année de développement et blogging sur bsky ... et d'une façon assez surprenante, ça a explosé les réactions.

Et ils n'ont pas encore vu cette ligne du temps tortueuse qui reprend les milestones, les releases et les interventions et commentaires de "guest stars" 

Et un Bangbash qui marche ! ...

Enfin ... "marcher", c'est beaucoup dire. Mais il bouge, il fait demi-tour en bout de plate-forme le tout dans son environnement naturel. Par contre, la quasi-totalité des animations de transition (atterrir, arriver au sommet de la courbe de saut, etc) ne fonctionnent pas (pour des raisons dont le niveau de compréhension est encore variable), mais bon sang, on l'attendait depuis tellement longtemps que je ne vais pas faire la fine bouche avec un "ouais, mais non, je vais attendre qu'il soit fini avant de poster quelque-chose", hein ;)

Finally! Finally I've got a working bangbash in a Bilou Level! it's not yet fully functional, but there it is, hoping ahead and back. I still needs care for the transition animations but at least it unlocks some levels designed almost 18 years ago. Think about it: bangbash has been waiting to get alive for almost as long as the pendat did!

Bon, par contre, il faudra vraiment que je fasse une révision de Inspector Widget, pour 1) montrer les testpoints dans la zone radar, 2) faire en sorte que le *hot spot* soit toujours dans le radar (et pas le centre du personnage, parce que pour bangbash et pendat, ça ne sert strictement à rien.

I'm a bit ashamed at how long it took me to understand why I couldn't make it turn back as intended. It should really have been as easy as pressing START and checking InspectorWidget. Especially since I still have to add collisions, Bilou detection and bashing animations. If I want Bangbash to have a dedicated move when Bilou is on the top of a pencil, I should better polish my tools ^^".

Là, j'ai dû faire mon débugging en combinant ddd et gimp ... en allant gratter dans les fonctions internes de libgeds. On va dire que côté dever-friendly, il y a mieux ^^". Aucun risque de faire de l'ombre à gbstudio dans ces conditions...

edit: avec un peu plus de travail sur les animations, la position des images par rapport à la "boîte-position" du personnage, ça donne enfin (4 janvier) ce que voulais que ça donne. Bon, évidemment, ça ne satisfait pas J.L.N qui demande "il attaque déjà ? " et "on peut lui envoyer des taille-crayons ?" ... pas encore, mon p'tit loup ... pas encore ...

tapis roulant!

Nous y voilà enfin! Après l'eau-qui-pousse, je peux vous présenter le sol-qui-pousse. Le point délicat, vous vous en doutez, ça aura été de mélanger ça avec des sols pentus. Ce à quoi je ne m'attendais pas franchement, par contre, c'est que être poussé pendant qu'on est immobile sur le sol se révèle plus compliqué à gérer qu'être poussé pendant qu'on avance.

The natural step after water-that-push-Bilou was ground-that-push-Bilou. It started quite nicely and it is finally working, but to reach that nice behaviour, there has been significant ups and downs, and especially to get it working on sloped ground. But hey, sloped conveyor ground was my trick to have one-way halls without getting too mechanical.

C'est que pendant qu'on avance, on appelle régulièrement la fonction do_slopes, voyez-vous. Et même si le sol annonce "je te pousse de deux pixels sur la gauche" alors qu'on est sur une pente, on finira bien 2 pixel à gauche et 1 pixel plus bas si nécessaire. Mais rien de ce genre dans l'état "immobile sur le sol". Et notre fonction do_slopes est prévue pour aller directement corriger la vitesse et les déplacement retardés du personnage, or l'idée du "sol qui pousse", c'est justement de manipuler la position dans un premier temps et de laisser le code qui traite la vitesse tranquille. Sans ça, sur un tapis roulant trop rapide, vous verrez Bilou se retourner pour marcher tout seul vers la gauche plutôt que de le voir s'échiner à avancer vers la droite tout en reculant malgré tout vers la gauche. Pas terrible.

Dans Rayman, j'avais pu voir qu'on avait deux types de pentes: des normales et des glissantes. Chaque angle et chaque offset est dédoublé avec un second type pour gérer les deux types de physiques. J'avoue que je souhaite plus de souplesse pour Bilou. Pas tant que j'ambitionne de faire un jeu plus complexe que Michel Ancel, mais surtout parce que je n'ai pas l'occasion de planifier l'ensemble du jeu. Je suis incapable actuellement de garantir qu'il n'y aura jamais plus de 2 types de sol dans un niveau ni 2 types de pentes. Le projet était donc d'utiliser des emplacements séparés pour encoder la pente et les propriétés du sol. Et quand je me suis mis à coder, c'était encore plus simple que prévu: quelque soit la position de Bilou sur une pente, il est toujours à l'intérieur du tile "pentu". Et donc pour trouver le tile avec le type du sol, il suffit toujours de regarder 8 pixels plus bas. Enfin ... presque toujours.

And that was the final test for my "neat idea" to "simplify" the level editor: use separate tiles to indicate the slope (if any) and the ground properties. Ground properties are always on the 'plain' part of the ground and the slope types sit on top of it. A new getGroundType function can probe through that slope layer to find the actual ground and return its numerical type. Then, each controller use that to index to retrieve relevant parameters, such as push vector, friction, or whatever needed. It mostly worked except on one spot: the precise location where Bilou's hotspot has just been shifted out of the lowest 'sloped' tile of a slopes stripe. It is now mid-air, with one 'slope' tile below it and the ground properties one more below. Then Bilou stops because it is no longer pushed but doesn't fall either. And if I try to hack that around, I end up with Bilou moved horizontally instead of following the slope because there's no slope to follow.

Comme toujours avec les pentes, les problèmes commencent quand le sol n'est plus dans le prolongement horizontal de celui utilisé une frame plus tôt. On se retrouve dans ce cas-là soit avec Bilou qui s'arrête au milieu de la pente, soit continuant à se faire pousser, mais à l'horizontale. 

Yet, when you walked on the sloped ground rather than letting yourself pushed by flowing sands, you wouldn't get any issues. The trick is that walking state already has a call to the do_slope function that keeps Bilou in contact with sloped ground despites of motion. The extra shift happened prior that call, so it would still re-align when Bilou's own velocity is applied. But there was no such call in "idle, standing" state so far. And the do_slopes function wasn't meant to affect anything but character's speed, while it should now sometimes affect temporary variables used to immediately apply a coordinates update.

And just in case that seemed too easy, a typo in the first coding sprint made me change accumulated step instead of actual speed, ruining the whole thing with Bilou digging into the ground. Then a bug introduced in the level editor broke some part of the level without me realizing it and I started suspecting wrong properties for the ground here or there.

But there we are. It's working, even though it cost me hopping back in time with Mercurial and re-doing the sprint one dash at a time, checking, committing, re-importing maps and the like. And about one week later, I finally shot a decent .gif of the behaviour so I could post it and write this stuff. It's been planned for so long. It has been through so many preliminary work and so that I'm gonna call it a milestone.

Bref, inspector widget, ddd, j'ai pu sortir toute la panoplie. Presque (pas les unit-tests, cette fois). Mais l'éditeur de niveau m'aura bien cassé le rythme.

(wow. Le soir est tombé, j'ai encore une machine à faire tourner et je n'aurai pas fait plus de homebrew de cet aprèm' libre que de vous raconter tout ça :-P)

3 Rooms - Release Early

 

There we are. The first demo featuring the first 3 environments of Bilou's Dreamland cycling to one another, changing music and graphics. It's super work-in-progresss, and there are so many things to be fixed that I won't try list them now. But you know what they say: "release early, release often", and a fellow gamedever asked me earlier this week about being allowed to test and so on. So if you think he's right, enjoy this St-Nicolas gift.

Download: Dreams.nds updated Dreams.nds for new year

Voici donc (enfin ?) quelque-chose de téléchargeable avec les environnements que j'ai l'intention de faire évoluer pour y amener toutes les nouveautés de gameplay de Bilou's Dreamland. Alors, soyez avertis quand-même: c'est vraiment une version 0.0.0.1 là. Pas même une ébauche, tout juste un canevas. Y'a des retouches à faire par-tout. Y'en a tellement que je n'aurais même pas le temps d'en dresser la liste avant d'aller me coucher. Mais qui sait, ça vous amusera peut-être.

3 rooms milestone.

My next first milestone for Bilou Dreamland will be to create a .nds where you can use doors to visit the 3 available environments. Ideally, each of the "room" (need not to be single-screen, but should stay simple) would feature the key gameplay mechanics I want to work on / repair before I go for more complete level designs. Sandboxes, in a sense.

On dirait bien que mes éditeurs sont maintenant prêts pour le travail sur Bilou's Dreamland. Support des nouveaux types de collisions et de pentes, support du choix de palette sur les deux plans. Et les spritesheets/tilesheets ont été nettoyées et prêtes à l'emploi aussi.

Il me faut donc un prochain objectif, et ce sera les trois portes salles. Une pour chaque environnement, pas trop grande, mais assez pour qu'on puisse y placer les différents éléments de gameplay critiques pour le jeu comme les cascades, l'eau qui change de niveau, le sable qui glisse, les portes, les plate-forme crocos, les branches qui plient, etc.

(Eh, CJ, ça fait penser à tes niveaux-téléporteurs du jeu d'origine, ça, non?)

School Zone: aftermaths

Five year ago, I released a single-level "anniversary" game featuring Bilou in a school zone settings. A bit later, in early November, I had the opportunity to have it play-tested by my nephews, who were 7 to 13 years old by then. From there difficulties to approach the game, I added one "preliminary" level that is now level 1 in school Rush.

Voici 5 ans, je vous faisais un jeu-anniversaire avec Bilou dans la zone de l'école. Quelques semaines plus tard, en septembre, mes p'tits n'veux me faisaient me rendre compte qu'il me fallait quelque-chose d'autre comme niveau pour introduire les mécaniques du jeu. Ce niveau non-tutoriel est depuis devenu le premier niveau de School Rush.

Download SchoolRush - JLN build.

So yeah, the 5 levels I'm releasing today for Bilou's 25th  anniversary took me long time to make. And it doesn't even feature the level that started it all. Because meanwhile, I grew interest in speedruns, and I wanted the game to focus on going as fast as we could and save the books. Things with a focus on wandering, discovering, solving or exploring will happen in another small game.

I'm proud I could get feedback from several professionals with the 2016 release. I hope the game is better now. May there be many of you finding it, may you have a fun time playing it. This is my gift to whoever makes free software, free music, or free videos. Thank you all for making coding possible/enjoyable. 

The engine code is LGPL, the tools 'used to make it (animations and level editors) are GPL, the art and level design remain my copyrights, but they are free to play, and free to share unmodified as part as this School Rush release.

Aujourd'hui, le développement de School Rush prend fin. Ce fut long, parfois fastidieux, mais je voulais l'amener jusqu'au bout. Comme dans tout jeu, il y a des choses qui ont été abandonnées en cours de route. Soit qu'elles ne convenaient pas, soit qu'elles m'écartaient du but premier du jeu... soit qu'elles promettaient de devenir un gouffre de développement rendant irréaliste toute sortie tant que je serais en solo sur le développement. Que ce jeu soit mon cadeau à tous ceux qui ont écrit du code free software que j'utilise tous les jours, les musiques que j'écoute en codant, les vidéos sympa qui m'ont donné envie de continuer. Merci à tous pour votre travail.

I'll just update November post with the link to December contents, if you don't mind. How-to-play etc. is there. If you're looking for a changes list, it's been posted already ;)

Featured on PDRoms.de

History tracked on playeradvance, tigsource, homebrewlegends

1-ups... At last.

Finally, something good does happen when you collect letters in School Rush. Nothing fancy, and not even anything original, I'm afraid: you just get an extra life. Yet, considering the difficulty of the -final level, this might be welcome.

It required some new tools, though. Lives, hit points and collectibles are managed through counters in the game engine. counters can normally get their value defined only when you parse the level script. Then, you would only increment or decrement the counter as game events occur. Then, you can define one or more actions that happen when the counter reaches zero.

Enfin! Ça vaut enfin la peine de faire la collecte des lettres dans "School Rush". Rien que du très conventionnel, j'en ai peur (on prend une vie supplémentaire), mais bon, vu la difficulté du dernier niveau, quelques vies supplémentaires ne seront sans doute pas de refus. Mais cela ne s'est pas fait sans de nouveaux outils.

When hit points counter gets to zero, for instance, a jingle and a death animation are played. We can even force a domino effect that decreases the "lives" counter then. But that mostly works because I load level" action also allow an expression to be defined, and because you're then allowed to reset the hit points value when reloading the level.

To provide 1-ups, I had to introduce a new elementary action dubbed "setcounters" that offers that freedom out of the level-loading machinery.


Les vies, les points de vie, les objets à récolter, tout cela est géré à travers des compteurs dans mon moteur de jeu. Normalement, on ne sait definir la valeur d'un compteur qu'au chargement du niveau. Durant le niveau, en revanche, on ne sait qu'augmenter ou diminuer la valeur petit à petit.

Le gros intérêt de ces compteurs, c'est qu'on peut forcer l'exécution d'une action lorsqu'ils arrivent à zéro. Comme redémarrer le niveau, changer la musique ou, faire apparaître un nouvel objet. Mais idéalement, ici, il faut surtout augmenter un autre compteur (les vies) et reprogrammer pe compteur arrivé à échéance (le nombre de lettres avant la prochaine vie). Bref, ce sera le rôle de l'action "setcounters", fraîchement ajoutée à la panoplie du parfait programmeur de GobScript.

Augmentons la Gravité ?

J'ai eu l'honneur (et un peu la chance, il faut l'avouer) d'avoir un retour de Romain Claude -- dévelopeur principal de Splashers sur mon School Rush. Un feedback assez technique et qui ne sera pas facile à prendre en compte, parce qu'on s'attaque ici au coeur du gameplay.

Mon principal retour pour le moment concerne la prise en main, que je trouve assez raide. De plus, le fait que le jeu soit assez mou rend le tout assez hardcore, même en facile ... Côté contrôles vous devriez avoir un air control progressif (de moins souple à beaucoup plus souple), et ceci marié à une gravité plus forte rendra la prise en main plus réactive et agréable. Par contre pour retrouver la même hauteur de saut il faudra augmenter la valeur de l'impulsion.

I'm honoured and proud that Romain, main designer of the platformer "Splasher" took the time to try and give detailed and technical comment on my own "School Rush". In the upcoming weeks, I'll likely be busy understanding the implications of his proposals and doing attempts to adjust the gameplay of SchoolRush accordingly.

The first suggestion is to increase the gravity to get more a reactive experience -- which echoes a comment from Kirby Kid in a previous iteration. That's not something to be taken lightly, though. Many things in the game depends on the gravity. Changing it by a ration g'/g means that you have to modify the jump impulse v1 so that the maximum height of the jump -- v1²/2g -- remains constant. But even so, the amount of time you stay in the air is reduced due to the increased gravity, meaning that the distance you can clear with a jump is shortened.

Mais changer la gravité, c'est changer beaucoup de chose. En plus d'ajuster la puissance de l'impulsion, je dois aussi ajuster la vitesse de déplacement de Bilou puisque le temps qu'il passe en l'air, lui a été réduit. Sans celà, il faudrait revoir tous les obstacles du jeu.

En fait, une fois tous les paramètres dépendants de la gravité réajustés, on a le même jeu mais avec le temps accéléré. Ce n'est pas déplaisant, mais ça va demander aux joueurs d'être plus alerte, parce que du coup, je vais devoir aussi augmenter la vitesse de l'encre sans ça elle est complètement à la traine. Peut-être devrai-je aussi accélérer les pendats...

By increasing the walking and the jumping speed of Bilou with the appropriate factor, I can keep the levels unchanged and enjoy a more engaging gameplay. I'll have to speed up the rise of the ink: at the moment, the game has turned too easy and I might also have to speed up pendats, so that Bilou don't outrun them too easily, which will shrink the response time allowed to the player (to 86% of the current value for g'/g=4/3) ... but it still leaves 500ms+ to react, so that should work.

J'essaierai celà dit d'éviter "l'effet Meat Boy" si je le peux, à savoir d'avoir le contrôle en l'air tellement élevé que l'on finit par "glisser" dans l'air et se déplacer plus vite horizontalement que verticalement. Mais en ajustant la vitesse horizontale maximale, il devrait y avoir moyen d'éviter ça.

Directly linked to the change of gravity, Romain suggests progressive air control. The current code controlling Bilou has some momentum while mid-air with an acceleration that is 1/2 of the one you have on the ground.

In his interview about Splasher, Romain says:

Air control is a touchy subject: you need sufficient control so that player can compensate for an imperfect impulse (imperfect timing or speed) while still having an interesting skill floor, but not give too strong air control, else the player will [go wild at uncontrolled speed] at the slightest move of the joystick.

To balance things in Splashers, Romain used delays, so that the air control just after the impulse is not as strong as it is some frames later.

This happens in Super Meat Boy too, with a character that initially struggles to work against its original impulse, but that gets increasing amplitude as you maintain the joystick pushed into one direction. To be honest, Super Meat Boy isn't one of my reference in terms of gameplay. I would even consider it as a counter-example of convincing physics

Dans le "School Rush" actuel, j'ai un système qui encourage le joueur à prendre le temps de courir avant de sauter: une fois en l'air, on peut ralentir et faire demi-tour (Bilou reste tout de même un explorateur de l'espace, ça offre quelques mouvements inaccessibles aux simples humains), mais on ne pourra jamais atteindre à nouveau la vitesse maximale avant d'avoir touché le sol pour courir à nouveau.

Ma première tentative pour m'approcher du "contrôle de plus en plus souple" (que je traduis par "augmentation linéaire de l'accélération horizontale avec le temps passé en l'air") consistait simplement à autoriser une vitesse horizontale plus grande en phase descendante par rapport à la phase ascendante. Mais ça, ça n'a pas été un succès.

Its all sketched in the book!

early bugs to be caught.

Don't you dare thinking I'm using the BmxExcuse to pause School Rush development near completion once again. Here's the proof: a few more lines of code (with plenty of hard-coded magic values to bridge with the game logic and assets, I confess) and I get those illustrations on the bottom book updating as Bilou gets and loses power-ups. Even better: as she picks up bladors, the player is hinted that she could throw them at pendats, which is the way to get power-ups. 

Now all I have to do is to switch to that bookmark-health-bar because the raising black rectangle ridiculously obscures now-crucial gameplay feedback.

N'allez pas vous imaginer que j'utilise une autre excuse-de-BMX pour ne pas fignoler School Rush! J'attendais juste un moment un peu plus calme où je ne serais pas occupé à faire des trous dans les murs. C'est tout. Et nous y voilà justement, avec un sympathique changement d'illustrations pour guider le joueur dans son aventure et le renseigner rapidement sur les mouvements possibles.

Costumes, folks.

Je vais appeler "costume" un ensemble alternatif d'animations pour un personnage qui ne change pas fondamentalement le comportement du personnage. Ce sera le cas par exemple de Mario quand il grandit. Bien sûr, mario-grand est capable de faire des choses que petit-mario ne sait pas faire, mais les animations modifiées vont bien au-delà des nouveaux mouvements. Devenir Mario-tanooki, c'est enfiler un costume. Devenir Mario-feu ou Mario-Marteaux aussi. Devenir Mario-Grenouille (SMB3) change fondamentalement l'ensemble des mouvements du personnage, la physique des déplacements et ne peut clairement pas être assimilé à un costume comme défini plus haut.

Some heroes use costumes. When they have some specific powers, their apparence is changed. Their set of moves doesn't fundamentally change -- it's a costume, not a mutation, but they gained an important additional move that may change strategic choices at some points. Yes, exactly like the fact that Mario is currently able to shoot fireballs, just in case the last platforming section made you forget about it. Grabbing the tanooki suit is a costume. Same for the Hammer Bros. suit. The Frog suit in SMB3, however, is more like a mutation. Many basic moves of Mario like running and jumping are no longer available when you're a frog, and replaced by another set of moves. This is truly a distinct part of Super Mario's state machine, while the Fire Flower merely grant you to access one conditional state (throwing fireballs). I need to find something similar for Bilou's BigPunch power-up.

La question qui se pose pour le développement de Bilou est de choisir le bon moyen de réaliser ce changement d'apparence. Vu la complexité de la machine d'état, plus franchement question de doubler l'entièreté des états pour tenir compte de la disponibilité ou non d'un power-up.

Dans certains cas, un simple changement de contenu de RAM grahique suffit. C'est plus ou moins le cas de SMB3: en utilisant son "mapper" pour remplacer la page de ROM présente, les dessins de Mario petit disparaissent et ceux de Mario grand prennent leur place. A part modifier le visage de Bilou, cette technique ne me permet pas vraiment de changer d'animation parce que moi, je fais de l'animation modulaire: la mémoire vidéo ne contient donc pas d'étapes d'animations mais uniquement des fragments d'image génériques.

I've seen some costume as simple as a palette swap. Megaman uses it quite efficiently. I don't feel to use it for Bilou: its colors are deeply linked to his identity, as far as I'm concerned. I've seen other costumes implemented as a video memory update: some new pictures are loaded and used, while the rest of the code -- including the one that decide which portion of the video memory to use at what time -- remains unchanged. Super Mario Bros 3 obviously works that way, at least for Big / Racoon / Tanooki / Hammer Mario. Same moves at the same place within the different pages. A simple re-mapping of the video ROM and the costumes are swapped.

As much as I like that behaviour, it's useless for me. Bilou's hands and feet cannot be easily replaced because they're shared with bladors and pendats. Only the head could be updated. It wouldn't make the animations -- especially the idle animation -- fundamentally different because I'm doing modular animation: the video memory doesn't contain frames but merely fragments.

A more practical alternative would be to reuse Sonic's shields idea, because those shields are animated and rendered independently from Sonic himself. I don't quite know how I could convey the idea "you have punch power" with such a shield around Bilou, though.

La version plus facile, héritée de la NES et de ses palettes séparées, c'est de changer le jeu de couleurs du personnage (demandez donc à Mega-Man, il en sait quelque-chose). Une approche que je mets de côté pour Bilou: ses couleurs font bien trop partie de son identité.

Autre alternative possible, on se la joue Sonic et son espèce de bouclier transparent. Ici, le sprite de base et toutes ses animations restent inchangées: il suffit de faire suivre Sonic par un sprite supplémentaire suffisamment creux pour qu'on voie encore le personnage par-dessous. Jouable pour Bilou aussi, j'imagine.

Je choisis un système moins rétro mais mieux adapté à mon moteur de jeu: j'introduis des sections conditionnelles dans les animations elles-même. L'idée est d'éviter de devoir modifier les infos liés à l'état -- il continue à ne connaître qu'une seule animation -- mais de profiter du fait que j'ai déjà des instructions type RISC pour les animations (déplacer tel OAM, changer l'image utilisée par tel autre, etc.). Du coup, il est assez facile d'ajouter une "instruction d'animation" qui est en réalité un saut conditionnel dans la séquence, sur base d'un des compteurs de bonus ou d'une des variables internes du personnage. Reste à construire la séquence correctement. Ça, ce sera le rôle du lecteur de scripts. Les animations elles -- et leur éditeur --
restent totalement inchangés. On se contente au moment du parsing de construire quelque-chose de plus complexe comme "if [compteur%] animA else animB".  C'est encore insuffisant pour émuler SMB3 (au niveau script, je veux dire), mais ça devrait faire l'affaire pour Bilou.

So there's one option left if I want to swap animations without modifying the states (and e.g. start having multiple animations per state): the animations themselves. They are build as a sequence of a RISC-styled instructions, each instruction changing one specific parameter of the rendering. My idea is to have one additional instruction that behave as a conditional branch, and allow merging of two animations (or more) in a single one.

It's not quite perfect: it requires the two animations to use the same pages with the same structure because at the moment, only one of the structure will be kept for the merged - conditional - animation. The script-parser that performs the binding is still a bit crude too. Likely too much problem-specific while those instructions could do much more. But it will do the trick for Bilou: School Rush and that's my current interest.

Enfin ... le ROM mapping de SMB3 est peut-être un peu plus compliqué que ça. On voit sur la vidéo de Bisqwit qu'une seule "page" de 256x16 pixels est utilisée à la fois pour Mario, or il y en a 4 différentes par "costume" de Mario. Selon l'action en cours (marcher: +0, courir et tenir une carapace +2, voler +3), la page choisie est différente.

And while we're at it, the costume management for SMB3 could be a bit more sophisticated than I originally thought. Only 1 row is accessible to the NES' GPU at any time, and one "costume" offers at least 3 such rows (dubbed 'pages' on bisqwit's original picture) plus one that is used for star-powered sommersaults. I also spot a "page" that is useful only when Mario is carrying a koopa, or turning back. But excepted for little Mario and Frog Mario, all the rest replicate the same layout for common movements.

Emunit-testing

I am stuck with bugs in the two approaches I planned to use to allow shop-for-bonus in-between levels. Kind of bugs that are difficult to track with regular debugging, and that may even crash the emulator or the debugger itself.

So it's time for me to start doing more professional testing on my code base, dropping rendering and things alike so that I have more control on memor allocation and objects lifecycle. For that I need that access to NDS registers can still be performed although it will be a regular x86 program running under linux. I thought I could use a custom linker map to force the declaration of a regular area where the registers are expected, which you use with -T linker-script-file. But being sure that all of C++ sections will remain in place might be harder than creating a custom layout for an operating system kernel.

Hopefully, the memory map is somewhat compatible with the default locations for a 32-bit linux process. A few mmap calls and I can have valid read/write memory mapped at the place where NDS registers are expected. That should be all I need.

I will need to track what memory area are still alive after the end of a level, to know whether some could still reference dead objects and lead to memory corruption. I'll need too, to know who allocated such block so that I can understand their nature and purpose. I remember of Tim Robinson explaining how he embedded a call trace leading to *alloc. I'll try and do the same. It's not quite completely working at the moment.

See you, bloggers.

With dev-scene.com dropped, dev-fr crashed, google reader turned off and the DS celebrating its 10 years, my RSS feeds list has shrunk to the point it is no longer worth checking. I wished to thanks their author for the nice ideas shared between 2005 and 2012 (mostly).

J'ai beaucoup aimé les années blog, que je situeraient de 2005 à 2010. J'ai beaucoup aimé l'ambiance bon enfant de dev-fr jusqu'à ce que l'engouement pour les iPhones ne le dépeuple et qu'un Androïd ne lui donne le coup de grâce. Je suivais les développement des uns et des autres via Google Reader grâce à la magie des RSS. Je laissais des commentaires et j'en recevais quelques-uns en retour. Tout celà est loin maintenant. Les blogs sont au mieux alimentés d'un "je ne suis pas mort" annuel. Au pire, leur adresse a été vampirisée par un quelconque annonceur sans scrupule. Petit message de sympathie à mes correspondants de l'époque.

0xtob is the author of NTXM library and nitrotracker for Nintendo DS. I owe him a lot -- including a patch featuring my upgrades to his player. His work has now moved to code.google.com. His blog is gone, his homepage is still there.

Je commence par 0xtob, à qui je dois la base du son dans mes homebrew. Je lui dois d'ailleurs toujours un rétro-portage de mon code pour les effets (vibrato, etc) dans sa nouvelle architecture... Le blog est mort. La page d'accueil lui a survécu. Le code aussi. J'aurais dû regarder de plus près à son moteur physique, peut-être ?


Squidi had the Grand project of describing 300 game mechanics. One a day, iirc. He went quite far away, around 160 mechanics, and even started implementing examples in HTML5. I think the archive.org is the only way to consult content he wrote.

Il n'y avait pas que des homebrew dans mes flux RSS, mais aussi les nouvelles idées très chouette de règles de jeu. Il s'était fixé l'objectif de 300 règles, il est arrivé au résultat très honorable de 160. Bien mieux que le catalogue des Jeux Vidéos Obsolètes.

Sverx doesn't post much anymore, but he's still into homebrewing. Mostly moved to SEGA mastersystem tools/libraries and posting code on github.

Les petits jeux de Sverx étaient bien agréables. Ses conseils de baroudeur des consoles Nintendo Précieux. Il est maintenant passé à une bibliothèque pour la Master System de SEGA. Github semble être suffisant par rapport à un blog puisqu'il n'y met plus qu'un bonjour par an.

J'adorais les mini-jeux de Mia. Lui a continué à blogger de temps en temps, et son blog est toujours actif. Comme de nombreux homebrewers' Mia est passé au jeux Androïd, mais malheureusement avec de "simples" jeux de cartes. Peut-être celà représente-t'il un vieux challenge à vaincre pour lui ?

Last but not least, I'd like to greet Mia and thank him for his inspiring little games on Nintendo DS. He switched to Androïd, like many other french homebrewers. It's a bit of a pity that he decided to make only plain card games. I know he used to rip nintendo graphics because he had no own characters for his games. Maybe that's still missing for him ? Maybe he doesn't know about Open Game Art ?

And then, there are those who haven't gave up. I'm impressed at how Smealum (previously releasing Aperture Science for DS and the first DS minecraft clone) makes progress towards a full understanding of the 3DS, and it looks like there is now a growing community of 3DS software homebrewers, reaching the state where a clone-of-moonshell is being crafted. So far, what I want to do fits the NDS alone, I haven't found any way to push homebrew to my own DS (I'm often lacking the game to exploit) nor did I started investigating what others have done / found on that newer hardware,  but maybe that would be the best way to quit that feeling of being a lomesone cowboy lost in the deserts of NDS homebrew...

Oh ... et pendant ce temps-là, Zalo nous sort quelques tutoriels 3DS et une reprise de Jumping Jack sur son blog ^_^

Air Grab

On s'approche, on s'accroche ... Les travaux sur les zones de collisions contrôlées depuis l'éditeur d'animations portent enfin leur fruits. Il y a maintenant un état dédié dans le comportement de Bilou pour "je pirouette en l'air pour attraper quelque-chose".

At last, the track for controlling hitbox activation through animation is paying off. I have been able to give Bilou a dedicated state where he's checking three directions for something to pick or ride on. I intend to use that both to ease swinging on spongebops and allowing high-paced dumblador grabbing. In the "anniversary level", using spongebop to move along was planned as the hard path. The way that the skilled player would prefer because it leads to faster results as opposed to wandering on the ground. They still had that role when I added "*deline's level" as preliminary experience to the "true level" of the school zone, but the levels are definitely more fun to play when you mastered spongebop riding (left alone the 'sponge jump'). So I want to make more players try to use them.

• Dedicated "grab-mid-air" animation and gameplay state makes it obvious to the player that something happen, and how it spans in space-time.
• The animation itself is fun. J.l.n, my 2-year-old boy goes laughing when he realize he can press A/B buttons to make Bilou roll mid-air in a flash. And fun is important in a video game: that's our primary reward.
• Moving from demanding hitbox (purple one on picture below) to welcoming hitbox (light-blue one) will make it more open to learning.
• You'll still have to learn how your speed evolves with the swing if you want to reach high places or gain stupendous momentum. The potential for power-play is not lost.

Au-delà de la performance technique, l'idée est d'agrandir la marge de manoeuvre des joueurs qui veulent s'accrocher à une éponge. J'ai tenté de reporter sur l'image ci-contre la marge de manoeuvre avant (en mauve) et après (en bleu clair). En rendant le fait d'attraper l'éponge moins élitiste, j'espère -- selon les conseils de KirbyKid -- les rendre aussi plus amusantes.

Une chose, par contre, n'a pas changé: Bilou est toujours centré au-dessus de l'éponge quand il s'y accroche. Du coup, agripper une éponge alors qu'on arrive à côté d'elle produisait un décalage brusque de Bilou. Je tente donc un élément inédit dans le gameplay: une transition pendant laquelle Bilou, roulé en boule pirouette pour revenir par-dessus l'éponge mais dans une forme de pilotage automatique. Il est déjà lié à l'éponge et se dirige automatiquement vers elle, même si elle fait demi-tour et s'y accroche dès qu'il entre en contact avec elle.

I had one concern, though, about the immediate coordinates update that makes Bilou appear centered on top of the spongebop immediately after you hit its side with your hand. Piet and Pierrick, both co-author of the very first Bilou game, suggested that I should "cheat a bit with physics so that the game gets easier for the player", but I'm not confident with such approaches. Yet, it wouldn't be fun to get merely a bounce if you hit the spongebop from the side when trying to grab, so I give a try something new in Bilou's behaviour: temporary automatic control. When you'd expect Bilou to grab and climb the spongebop, he'll actually do it by a rolling bounce in the air where he'll mag(net)ically align to Spongebop position and start riding when reaching the proper position. Accelerations faster than what you could reach manually are tolerated in this state, and all you have to do is hold the (B) button down and hope for hitting no ceiling.

I'll submit that to the S-testing team tomorrow. That may be the biggest improvement since the release of "School Rush" game. Stay tuned.

2D + 3D = ^_^

After some clean-up and tweaks, I got the 2D+3D setup properly initialised in my test level. Nothing useful rendered so far: just a NeHe tutorial triangle that rotates as you press the DPAD in various direction without interfering with the 2D game. I still have to re-arrange memory banks before I can get textures, though. And I'll have to move around the owl-school background which was currently mapped on the "BG0" layer, the only one capable of 3D.

Quelques règlages ici et là, et j'y suis: un premier polygone (non-texturé) affiché en symbiose avec le moteur de jeu 2D. Tout ça fonctionne évidemment mieux quand on essaie pas d'activer la 3D à 3 emplacements différents dans le code. Je vais devoir à nouveau ré-organiser quel-layer-est-utilisé-pour-quelle-fonction ... ça devient un brin lassant, je vais faire une couche d'abstraction, ce coup-ci.

That starts sounding like I should introduce an abstraction layer so that the following things manipulate a "logical background" rather than physical registers directly:

• setting up map/tile VRAM addresses in GameScript
• scrolling registres in InfiniMap
• setting priority in runme

There was activity about the controling log display this summer ... It should allow me to flip between BG and log quite transparently.

edit: huzzah! it works!

edit: game engine fix is done. Runme adaptation will have to follow (and will likely be a bit more tricky). Real bugger will be the "fade sequence" which used BG1 (now used as "farground") to hide the screen content while re-loading the level ... I'll have to use another technique like window registers.

School level delivered!

Enfin nous y voilà. 3 ans après 'Apple Assault', un nouveau jeu Bilou est sorti. Enfin, "jeu" est excessif: c'est une démo jouable comme vous auriez pu en trouver avec votre magazine PC-Fun préféré dans le milieu des années nonantes. Avec un seul niveau, il n'y a par exemple aucun moyen de reprendre de la vie ni de regagner des vies. J'ai pourtant d'excellents souvenirs de la démo de Prehistorik 2 avec son compteur de pourcentage d'exploration. Nous nous étions donc mis en chasse des dernières plate-formes invisibles et bonus cachés jusqu'à parvenir à un 100%. C'est ce genre d'ambiance que j'ai tenté de reproduire dans le niveau-anniversaire mis en ligne hier.

Looking back at the former releases and the completed todo lists initially left me with some bitter taste: since March, it looks like nothing significant has been achieved and that almost all the features were present in the "usability test demos". Reality is somewhat different. Even the month spent exploring SMW and incentives for "alternate path" was the key to level re-design. There *was* some significant progress on the reliability of my SEDS/LEDS/AnimEDS tools. when monsters are randomly altered after every save, when you have some animation that may disappear under some circumnstances, when the map may be erased by a misplaced click, the odds that you manage to craft a level featuring 20 monsters are weak. Shaping up to 54 unique animations is only possible with some convenient numbering scheme.

Hopefully, those 6 monthes made the tools reliable and the additional month made the level appear. Let's celebrate ^_^.

Et dire que depuis Mars dernier, il me semblait de n'être nulle part, puisque presque toutes les modifications apportées au moteur de jeu dataient de 2012. Et pourtant, du changement il y en a eu: tout ce "rush" sur le niveau-anniversaire n'aurait jamais été possible avec des outils aussi peu fiables que ceux dont je disposaient en début d'année, succeptibles de perdre ou d'écraser le travail accompli à la moindre fausse manoeuvre.

I was concerned about the lack of variety in my tileset. One book here, one binder there ... wooden structure, metallic items, spiky pencils. At the end of the level, I started feeling repeating myself. If a level 2 was required, I'd need more variety, shadows, and such similar things. That's especially blatant in those confined areas where the scrolling background is not visible. Hopefully, I'm not near 80% of tile space as I initially thought. I merely used 50% of the space, because many object got dismissed as "drafts" as I progressed (greyed/translucent areas).

Le niveau dans lequel on se promène tente de respecter le plus fidèlement possible le design d'origine (1994) créé par mon frère, mais remplace régulièrement les "clés" et les "interrupteurs" abstraits par des interactions entre personnages. Par contre, au niveau graphismes, je dois admettre que sur la fin du niveau, je tournais un peu en rond. Pour continuer à construire la School Zone, il me faudra d'autres objets. Et là, soulagement de dernière minute; je ne suis en fait qu'à ~50% de l'espace disponible. Du côté des sprites je devrais pouvoir compter sur le doublement de l'espace disponible (j'utilise 64K sur 128), mais il faudra "expliquer" ça à l'éditeur de niveau.

I will have to do similar cleanup in the "sprites" memory or upgrade to full 128K of sprites (the hardware allows it, LEDS won't like it :P) if I want to have the full set of animations of pendats with pixel art (initially, 3D was planned) or if I want to have spinning sponges once on the ground.

Quite amusingly, many aspects of the monsters behaviour where "hacked" during the release-rush through creative use of the current game engine and level editor -- such as undermining some platforms so that monsters see them as holes while Bilou can indeed walk them -- where I'd have in normal hobby development extended the game engine with dedicated features to support the desired behaviour (such as a monsters-wall that Bilou can move through).

Si je suis parvenu à boucler ce "niveau jouable" en 2 mois alors que je travaille sur la school zone depuis Septembre 2011, c'est entre-autres que je suis passé sur une autre approche: chaque fois que c'était possible, j'ai rusé (par exemple en trouant le sol sous les pieds des Pendats pour leur faire faire demi-tour à l'emplacement souhaité) plutôt que de chercher à étendre le moteur de jeu (p.ex. avec un mur invisible pour les monstres). à retenir.

Et maintenant ? Quand tous les confettis de l'anniversaire auront été balayés? Bien sûr il y aura un peu d'emballage nécessaire pour permettre à mes p'tits n'veux de faire leur propres niveaux: manuel d'utilisation, blocs supplémentaires pour les vies et les soins, par exemple. Sur une autre branche, proposer une réalisation de "Deep ink pit" malgré tout pourrait s'avérer sympa, encore que le concept du jeu n'était pas aussi riche que celui d'Apple Assault. Enfin, il serait temps de s'attaquer à la 3D, histoire de permettre aux crayons de poursuivre Bilou et d'introduire le fameux Bang Bash qui, en février 2006, introduisait le jeu vidéo Bilou dans la blogosphère...

Oh ... et il me faudra un écran "sound test" pour comprendre les effets curieux qui se produisent sur les musiques ces temps-ci.

throwing bladors

I can be glad I'm done with the "bottom things" of my summer todo list. Now the winter is starting, and what is left is what is more linked to the game logic and the revised collision engine which is waiting to prove its superior capabilities with some dumblador stunning and throwing.
De temps en temps, ça fait du bien de retourner à une "liste de choses à faire" pour s'assurer que le projet avance effectivment. Bon, des "todo lists", vous devez tout doucement commencer à en avoir une indigestion, mais je parle ici de quelque-chose qui s'approche plus d'un "planning" que des micros-tâches à effectuer sur un temps de midi. Mon dernier planning datait de mi-juin ... voyons où on en est... tous les éléments "du bas" ont été satisfaits, à grand renfort de mises à jour de SEDS et AnimEDS. Je vais donc pouvoir cet hiver attaquer sérieusement les nouveaux types d'interactions entre personnages: assomer, attraper, balancer.

On dirait que les mois à venir vont être durs, chez les Dumbladors.

At those "milestones", I can close many former todo lists, by collecting in a new one the items that remains pending but that weren't really linked to the then-going activities. And yes, this is truly a milestone, since I now have fully operational CompoundGobs, including the definition of palettes for individual limbs (altering the palette while playing the animation will be for a next milestone :P)

• [done] looping move should only be generated for looping animations
• [done] initial Mx,y statement should be ignored by the game engine (actually, everything that delays the rendering of the first frame of the animation should be skipped). That will partly solve the "landing bug".
• [todo] most of blador's debugging could have been avoided if we had the state-initialisation expression feature implemented.
• [done] not detaching an attached GOB when "throwing" it may have weird effects, but I would have liked the display list to be re-ordered so that such side-effects wouldn't have systematically occured.

First multi-palette LEDS screenshot

Si le post précédent vous a laissé avec des yeux grands comme des soucoupes, voici une petite image qui résume ce que donne le "multi-palette" hardware une fois ajouté à mon éditeur de niveau. Eh oui: les livres peuvent enfin avoir des couleurs différentes. Bon, on est encore loin du compte, parce que pour l'instant, ce sont les propriétés des objets (solide, pentu, ...) qui modifient les couleurs, alors qu'au final, il me faudra un outil de sélection de couleur à part. En plus, seul l'arrière plan (juste derrière Bilou) pourra voir ses couleurs modifiées, l'avant plan utilisant obligatoirement les couleurs de la palette "de référence".

the multi-palette .spr file I crafted on my DS phat has been beamed and (thanks to Sverx's precious hints), I've got LEDS now working in extended palette mode, so that it can natively use the same tiles data for at least two different tints of books. I still have much to fix, but it's a nice first step.

pullmask working!

That's quite an achievement for the z-order branch: I got the 'pull mask' technique working properly in the game engine. No more than 14 hours ago, I still had Bilou disappearing (with only one hand remaining) when I made him do a roll-jump. I also altered the engine so that a transition animation *always completes* before another animation is launched. Switching to mid-roll-jump transition to jump/fall transition just kills the whole purpose of transanims (offer some more smoothness). The "new Bilou" track is thus completed and ready for a new release.

Après le décor, c'est Bilou qui - in extremis - est prêt pour la Grrande Riliize de Septembre. Il n'y a pas 14 heures, faire faire un saut-boule à Bilou le faisait disparaître presque complètement... c'est maintenant résolu. Les "transanims" sont donc prêtes à l'emploi et il me restera au plus à faire une copie-miroir du saut-boule (pour qu'on puisse aussi en faire vers la gauche ;) Mes nouveaux outils sprsplit, dumpanim et sprmerge ont été bien utiles dans la bagarre, si vous voulez savoir.

Reste donc juste à peaufiner la map pour faire un premier schooldemo.nds... et là aussi j'ai une bonne nouvelle: je viens de retrouver sous un fauteuil le chargeur de la DS "phat" de ma fée (la DSlite étant en réparation depuis sa Grande Chute du mois de juin et la DSi pas encore homebrew-ready, mais j'y travaille :)

Il me restera donc tous les aspects "collisions étendues" pour l'après-vacances.

transanims get rolling!

Voilà. Après une soirée de debugging intense (entrecoupée de chasse aux bananes dans Donkey Kong Returns :P), j'ai réussi à faire "tourner" les animations de transition. C'est encore trop rudimentaire pour vous en montrer une démonstration (j'ai une seule transanim que j'applique à tort et à travers juste pour vérifier que ça fonctionne), mais c'est fait.

Got transanims working ! The effect is not yet convincing because I haven't created all the due animations, but at least it demonstrates that parsing was correct and that triggering of the anims work. Huzzah! Now adding the dynamic priority thing to CompoundGob.cxx

Dumblador turns back

Here it comes. Some final tweaks on dumblador's "walk to the right" animation last night and I now have a CompoundGob that turns back when it encounters a wall (how sweet ^_^) Dumblador avance et fait demi-tour. L'occasion de revenir sur le fonctionnement des personnages dans mon moteur de jeu. Accrochez-vous un peu: le 'gobscript' est conçu plus comme un modèle de bytecode en ASCII que comme un véritable langage de programmation, mais comme dumblador est tout simple, ça reste lisible (j'espère ^^") Please bear some GobScript since it's still a pretty simple and straightforward monster:

anim1 = spr:0 anim2 = spr:3 statL0 :anim1 { using walker selfmove test 0 (2,4)-(8,14) 0001 area 0 (0,0)-(8,4) 000A }

on commence par importer des animations depuis le jeu de sprites (il suffit de connaître leur numéro, ici n°0 pour avancer vers la gauche et n°3 pour avancer vers la droite) et on leur donne des identifiants locaux (anim1 et anim2, respectivement). Le comportement de dumblador va maintenant être construit comme une combinaison d'états réutilisant ces animations: L0 pour avancer vers la gauche et R1 pour avancer vers la droite.

statR1 :anim2 { using walker selfmove test 0 (2,4)-(8,14) 0001 area 0 (0,0)-(8,4) 000A } statL0->statR1 on fail (100 :0) statR1->statL0 on fail (100 ~ :0) statL0->statR1 on hit0 (100 :0) statR1->statL0 on hit0 (100 ~ :0) end

The only thing you have to remember about your spritesheet is now the position in the animation slots where your things are. That's slots #0 (walk left) and #3 (walk right) for me. You give them animation identifiers for your monster (1 and 2, resp.) From that, you can define states walk left and walk right. Each state defines an animation being played and a behaviour. The combination of using walker and selfmove means that DumBlador will move forward at constant speed, according to what's defined in the animation, but not faster than the value defined in its internal variable v0 (x speed)

Vous pouvez penser à un "état" comme à une action que fait un personnage: s'il est dans l'état "avancer", il fait son animation "un pas en avant" et utilise un morceau de code C++ un (contrôleur) identifié via using walker qui reprend les tests "y-a-t'il du sol? dois-je suivre une pente?, etc.". Le mot-clé "selfmove" indique que c'est l'animation qui définit de combien de pixel on avance à la fois pour une meilleur synchronisation. On reste donc par exemple dans l'état "vers la gauche" tant que tout va bien. Le contrôleur génère un "fail" lorsque le personnage arrive dans un mur. À ce moment-là il va falloir choisir un nouvel état. Les commandes du types statdepuis -> statvers on fail [condition] (action) permettent de construire les transitions qui seront testées dans ce cas-là. Ici, l'action consiste simplement à écrire une valeur constante (100 ou -100) comme nouvelle vitesse horizontale (variable n° 0). "walker" is what's called a controller for the GOB. It can also report events and indicate when it failed to perform the desired movement. The two on fail statements indicate transitions from "walk left" to "walk right" and back when it's no longer possible to move forward. That could be due to a wall or the end of a platform. With this simple script, dumblador "has no way to figure out". Another part of the current behaviour is that dumblador turns back when Bilou jumps on his "head". This is achieved by the two on hit statements. It's still necessary to provide the (relative) coordinates of the hitboxes manually. Here the "hit" statement corresponds to a passive area in the state definition, which is seen in dark cyan in the Inspector widget. "000A" is the bit mask that corresponds to Bilou's stomping action or AppleAssault's attacks. I could have used "0002" to make DumBlador impervious to punch attacks and reacts only to stomps. Enfin, pour compléter le comportement décrit par chaque état, les instructions test|area n° (coin1)-(coin2) avecqui donnent les zones de collisions (rectangulaires) qui vont permettrent d'interagir avec les autres personnages. La partie un peu "magique" se situe dans le nombre hexa avecqui. Pour chaque "type" de collision, il faudra choisir un des 16 bits disponibles et faire en sorte qu'au moins deux zones de collisions (p.ex. le corps de blador et celui de Bilou) utilisent le même bit (0001) mais dans un test pour l'un et dans un area pour l'autre, pour refléter l'asymétrie frappeur-frappé du moteur de collisions. Finally, the curious (100 ~ :0) are GobExpressions. It's a minimalist encoding of "set var[0] to -100". It works as those RPN calculators, where you type "2 40 +" to compute "40 + 2". Only simple parts are used here: push the constant 100, negate it (I don't have negative constants so far ^^") and assign it to variable 0 (mnemonic: Pascal uses := for assignments). Reusing a constant here is required as the walker controller is allowed to alter the speed in the final steps towards the wall. Would you like to give it a try yourself ?