Leilani slopes

The tweet popped while I was doing mental checks on my revised tiled engine, and especially how it would handle more slopes than the previous one: Ishi(soft) finally decided to introduce slopes in Leilani's Island. And while I was looking for convenient ways to encode more than one array of tile_height[type][offset], I was surprised that his approach wasn't not requiring any such array.

Bon, le tweet est tombé comme un pavé dans la mare pendant que je réfléchissais aux problèmes que le mélange des pentes et des blocs à la physique modifiée risquait de poser: on peut aussi faire des pentes sans avoir pour autant besoin de modifier son moteur de jeu pour y mettre des fonctions du genre "doslopes". C'est ce que nous propose Ishi dans sa prose décrivant le moteur de jeu de Leilani's Island. Et que faire d'autre si on ne veut pas simplement faire un clone de Mario 1? Eh bien par exemple générer à la volée des "ascenseurs" sur lesquels les personnages vont se déplacer et dont la vitesse verticale donne l'illusion qu'on suit bel et bien la pente.

(C) Ishi

Instead, the world-collision engine would detect sloped ground and generate sort of "lift" objects that are tied to a specific X location, but adjust their Y location to the X position of the character that triggered them. It allowed enough flexibility to make me think twice before dismissing the approach. One of the benefit of the approach is that the code running the is-there-ground check still happily believes the character have solid ground all around them:

This fixes the problem with enemies turning around on slopes. When they do their collision check, they find solid ground in front of them - because as far as they're concerned, they're on a flat surface.

There was one major restriction, though: Ishi decided to go for a single type of slope (22.5°) where X-to-Y offsets function can easily be computed by shifts and additions. But I personally want more. More angles and some curved ground as well. We could still have that in Ishi's engine, but it would require picking a tile_height[offset] array according to the slope type and pass it to the "lift" object.

C'est séduisant, c'est sûr. Mais ce n'est pas allé sans mal pour autant, et à la lecture de tous les "corner cases" qu'il a dû prendre en compte, je ne suis pas certain d'avoir envie de jeter mon implémentation actuelle pour suivre son exemple. Entre autres, une des choses qui permet à Ishi d'éviter de devoir utiliser plusieurs types de pentes, c'est qu'il s'est limité à un seul angle (22.5°) pour lequel on peut facilement déduire la position verticale de l'ascenseur à partir de la position horizontale du personnage à l'intérieur du bloc. Mais moi je veux plus de variété. Il faudrait donc du coup plusieurs comportement d'ascenseurs et un code qui produit le bon à partir du type de pente que l'on a rencontré.

And the approach apparently has its own corner cases that need to be addressed, sometimes with special edge-of-slope types. The approach I'm using so far has its own corner cases, which were mostly resolved by using jump-through tiles (which are also walk-through) next to sloped tiles to avoid introducing artificial walls within the slope. That's precisely what needed more thinking when introducing "physics modifiers" tiles.

Well, anyway, don't miss the full post on Ishi's tigsource thread. It's very detailed and informative.

PS: it feels a bit odd to write a post about someone else's work here, but I've kept re-visiting the browser tab with the forum with the hope that I wouldn't forget it if there's anything important to find there ... for one week or so.

 Edit: apparently, there's one thing I understood terribly wrong: there is no 'lift object' generated. Just a collision rectangle returned by a function. A different rectangle every frame, but its lifetime is restricted to the duration of Character::think().

Sauf que ... en réalité il n'y a pas "d'objet-ascenseur" dans l'implémentation. Chaque fois qu'on demande au 'monde' s'il y a collision avec le sol, il nous renvoie un rectangle adapté à notre position. Ce n'est pas un objet-plate-forme qui aurait une durée de vie dynamique, juste une valeur de retour qui nous sert de contexte pour les prochains tests le temps d'un cycle de calcul des mouvements du personnage.

Ori and the difficulty curve

If you played Ori and the Blind Forest, I bet you've immediately recognized this place. If you haven't welcome to "how a simple puzzle can be as hard as beating a boss". It's not that the riddle is hard to figure out: there's a corner you'd like to reach locked with a door that you can only open by relaying some shot from the opposite corner of the room. You have the ability to redirect the shot, and there are corner-shaped things you've encountered before that redirect the shot as well.

Eh bien, elle m'aura donné du fil à retordre, cette salle de Ori and the Blind Forest! Pas tant que l'énigme soit difficile, mais l'exécution doit être impeccable. Si passer du premier au deuxième point de "rendez-vous" n'est pas trop tendu vu la vitesse (lente) du projectile qu'on relaie, le deuxième est déjà plus délicat: les sauts sont plus longs et s'attacher aux "lanternes" demande d'abord un double saut. Bref, il aura fallu que je maîtrise la nouvelle compétence du 'BASH' pour y parvenir. D'abord en prenant conscience que je n'étais pas obligé de me trouver au-dessus du projectile pour l'envoyer vers le haut. Je peux me positionner tout simplement au sol, là où il est possible de bien voir le moment où je dois dévier le projectile.

Et si vous n'avais jamais joué aussi loin à Ori, sachez que le "bash" est le signature move de votre personnage. La mécanique de jeu originale consistant à geler le temps à proximité d'un ennemi ou d'un projectile pendant que vous choisissez la direction à donner à ce projectile. Pour faire bonne figure, votre personnage sera propulsé dans la direction inverse. 

No, what makes it tricky is that it requires precise (perfect?) execution with proper timing despite that nothing in the level layout provides you grids or guides to time or aim things. And you've got to be quick because every time you move from one spot to another, you're racing against the same shot, all over the room. In other words, you enter the room with knowledge of how the BASH mechanics work, and you only leave the room when you have mastered the mechanics.

Through my quest to mastery, I discovered that (1) I wasn't required to be mid-air over the shot to throw it up, and (2) that I wasn't forced to use the analog stick to redirect the shot.. Standing still and pressing the BASH button with the right timing does the job. And the 'dpad' of the left joycon provides higher precision under stressful conditions (like re-doing it for the 20th time), when all you need to do is directing something vertically or horizontally. For the rest of the game, having an analog stick is precious, but puts too much stress on the dexterity of the player.

Le deuxième truc, ça a été de me mettre à utiliser le "d-pad" de la switch plutôt que le stick directionnel pour diriger le projectile avec assez de précision même quand le stress est là. Parce qu'évidemment, si les "monstres" présents sur cette scène ne sont pas bien méchants, il finissent toujours par "repopper". On aura donc qu'un temps limité pour boucler la séquence si -- comme moi -- on ne se sent pas assez balèse pour passer d'une traite malgré la présence de limaces à pics.

I was expecting some relief after such a boss-time but actually no! It's even getting worse: I got trapped in an escape event that requires full mastery of almost all the mechanics we've been taught so far. And I failed. A lot. Like 30 to 40 times, split along a whole week. I started believing that the BASH mechanics lacked proper tutorials and that I'd have preferred to face a "GAME OVER" and start the game afresh to find secrets that might bring me there better prepared.

Rush to Flatworld

It took me some time to get all the special block types working again with the new collision engine for GEDS. Partly because there were places in the scripts that referred to some block identifiers which I had to squeeze from 8-bit to 6-bit. I managed to make it a lossless squeeze, but some bits had special meaning. 

Like all the blocks identified 1xxx or 3xxx triggering actions even when collided by a monster while 0xxx and 2xxx would require a HERO cast. Or like the second character of the id xXxx indicating whether the block would act as sky (x0xx), water, block (x2xx) or floor when not interacting.

Avec le recul, ça me fait un peu penser à un donjon Zelda où on viendrait de trouver l'objet-clé. J'ai un nouveau mécanisme pour gérer les types de blocs sur DS, conquis après une lutte opiniâtre contre les vilains bugs (pensez aux wall masters) et les émulateurs récalcitrants (grosses statues à déplacer vers une dalle-interrupteur au hasard dans la pièce).

Et du coup, je dois retrouver les différents endroits où je peux à présent reprendre le développement. Editeur de niveau amélioré ? Programme de conversion vers un nouveau format de map ? Plus de types de pentes ? chacune de ces "petites clés" supplémentaires seront nécessaires au final pour pouvoir faire une version jouable de la maquette "desert zone" que j'ai en tête, et un bon nombre est aussi utile pour débloquer une conversion correcte de la "green zone". Mais là, je suis dans la salle avec trois portes et je dois choisir la bonne.

But well, it finally works fine for level 1 of school rush, and adapting other levels should now become easy as I patched the "rules.gam" shared file instead of patching directly the level commands.

And while working on it, I also mapped the whole set of "tile properties" that were in use in School Rush. That will help for introducing the new tile types. In addition to the 'special' blocks, some will have direct flags for the 'cando' operations and some will have indirect flags (i.e. you have to lookup a table to know their properties). The idea is to reduce the comparison stress for the 'normal', 'empty' tiles. We may keep the 'monster cage' tiles, but they would be seldom tiles compared to plain 'air' tiles and allow an extra table lookup.

Well, that last part is not yet done. And to be honest, I feel so tired that I'll need to go back to my little "remember you had no blog" notebook to see what has unlocked with the newest achievement and which target should be my next goal. I can't even dare to do that on screen :-/

FlatWorld.artmap

Bon, bin j'ai finalement réussi à trouver les erreurs que j'avais glissées dans mon code et à les corriger. Je peux donc reprendre une des "maps" de School Rush et la convertir à la volée pour qu'elle tourne avec la nouvelle classe "monde" et ses données de collisions séparées des blocs de VRAM du fichier .map. Par contre, ce faisant, j'ai cassé la possibilité d'animer le contenu de l'écran en réaction à une collision avec un bloc spécial.

Je dois reconnaître que j'y vais à tous petits pas, là. Entre autres à cause de la faible quantité de temps libre qu'il reste après les transports et les opérations de maintenance domestiques ... et encore, je suis loin du compte.

Bref, on va commencer par ré-établir un lien entre la "méta-map" et les map-à-images puis il faudra ajuster les changeblock() et autres clearblock() pour que tout passe. Mais caser ça avant St-Nicolas ? Je dirais qu'on est à un niveau d'improbabilité de 3.14 ou pis.

visual ...

• objdump equivalent in VS world is DUMPBIN. mingw objdump (elf) will not work on msvc objects (coff), and djgpp's coff tool won't work either (MS-DOS executables no longer running on 64-bit systems).
• /GL is your archenemy if you planned any guru meditation on .obj files. It will kill about everything the file may have as meta-information, including symbol tables. How one can still link such files has not yet been researched. dumbpin will shout File Type: ANONYMOUS OBJECT at you if that flag was present when compiling.
• If you ever see 'Rtl*' in some windows code, stop thinking about RealTech(Tek?) network cards. This is just Run Time Library, doing weirdo wrappers around standard functions such as memcpy for whatever reasons. Have a look in wdm.h or google the function name to find where it is defined.
• it may be sensitive to MIDL_PASS, _MEMCPY_INLINE_ and _CRTBLD
• There is no /Ldirectory_path in (my setup of?) link.exe, but it is sensitive to the %LIB% environment variable.
• The amount of information /VERBOSE produces on link.exe explains why we don't see anything in the map file unless things went ok
• There's no stuff & command to send stuff in the background but we can use start stuff to have the same effect
  
• Speaking of linking, DUMPBIN /imports exe_or_dll is what you'll use instead of /usr/bin/nm and DUMPBIN /dependents when trying to figure out what DLL is preventing your stuff to run. Note that DLL-loading function will return the same error code whether the requested module or any of its dependencies has an issue, and that will be a 'no such file' for you, sir.
• It looks like sysinternals is now an official MS resource for system monitoring. It's just ... Dudes, did you really had to sell its documentation ?
• I won't ever maintain a .sln file in parallel with the SConscript that built the binary I want to debug because I know devenv /debugexe TakeOverTheWorld.exe
• don't even try to use a Debug binary over a machine where there is no visual studio installed. It will miss its MSVCP140d.dll no matter how many attemps vcredist.x64.exe does at populating c:\windows\system32 with release dlls.
• don't forget to disable VS Code tracking & telemetry options if you dare to use that.
• I wish so much I had heard of c:\windows\system32\where.exe, the equivalent of /usr/bin/whereis ...
• There's no killall, but if you have powershell running, there's taskkill /IM buggy.exe /F
• If you want to know which #defines are still present after pre-processing your code, add /d1PP to your /P or /E switch
• If your compiler still pretends that some symbols are undeclared while pre-processing output clearly shows they are there: that sounds like stdafx.h is messing things up. When doing a 'regular' compilation, the compiler ignores whatever #include statements you have and instead blindly use pre-compiled headers that are built only using stdafx.h !
  

And I still have to check the details of pdb files, dump files and remote debugging... edit: hopefully, one can invoke dumpbin from MSYS shell too. I'll just have a disasm bash function to wrap that around from now on:

disasm() {
   /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio\ 14.0/VC/bin/amd64/dumpbin.exe -disasm $* ; 
   }

FlatWorld : public iWorld

Bon, je laisse un instant les commentaires sur Ori et Link's Awakening de côté, les pixels studies et compagnie. Les enfants commencent à me demander s'ils peuvent essayer les niveaux dans la forêt de Bilou, et j'ai une idée un peu plus claire du moteur de jeu que je voudrais avoir pour pouvoir le réaliser.

La première étape va être de faire en sorte que les propriétés du niveau soient conservées dans un tableau séparé, plus dans l'emplacement réservé aux couleurs d'une des deux couches de graphismes (une des plus vieilles fausses-bonnes-idées du projet).

Il faudra adapter l'éditeur de niveaux, mais ce sera pour la deuxième étape. Avant ça, j'utiliserai un "extracteur automatique" pour les "vieilles" maps (comme celle de School Rush et Apple Assault).

Je vais essayer d'avoir un bon design de classe dès le départ ce coup-ci, avec un type pour les données du moteur physique, l'implémentation qui reste un détail et iWorld qui est le seul élément connu du reste du code.

It was about to be a post on how I'm refactoring the Map/World/Camera classes to support my new tile types plans. And then I wanted to quick-check what I had so far with School Rush and problems kicked-in. I couldn't get the debugger handling it properly on my old laptop, and when I tried a rebuild on my fairy's laptop with "latest" devkitPro, I just got a blue screen reminding me that I should have dropped EFS years ago as it is no longer supported by the devkit team. All the previous tricks I could remind of didn't help.

J'ai voulu réessayer de faire tourner ça dans SchoolRush pour voir, mais je n'arrive qu'à avoir un écran bleu quand je compile avec le "dernier" devkitpro. Un conflit avec EFS, semble-t-il ... ou bien j'ai fini par oublier comment je devais invoquer le programme, mais

• ni --load-type=1 ne semble marcher
• ni un build plus ancien
• ni --cflash-path=SchoolTest (et recherche dans les fichiers)

Un premier problème que je parviens à identifier, c'est lseek(..., SEEK_END) qui renvoie -1. Pas bon, vu que le code d'efs va chercher à comparer la taille trouvée avec celle pré-enregistrée. Et si ça foire avec lseek, c'est apparemment parce que open("fat:/SchoolTest.nds") échoue avec un beau ENOENT ... pourtant ce nom provenait d'argv[0]. Bref, c'est de nouveau la saison des guru meditations...

Par contre, le commit précédent marchait sans problèmes sur 'grizzly', mon vieux laptop de 2007 qui utilise toujours un ancien devkitpro. Et mon nouveau code passe sans problème la découverte du système de fichiers embarqué quand il est compilé sur grizzly. Au point que j'en viens à me demander si j'ai jamais fait un build de SchoolRush sur le nouveau système... Fort peu probable, en fait vu que le système de highscores dépend du stylet (décembre 2018) alors que je n'ai corrigé le bug d'intégration du stylet avec le nouveau devkitpro que 6 mois plus tard.

Using the old desmume-cli on newest devkitpro and investigating with their libfatdir sample program, I'm tempted to say that --cflash-path=SchoolTest should have worked (it will work some hours laters for whatever reason -- typically meaning 'make clean' left some stuff dirty), and that the --gbaslot-rom thing is the one that is truly broken with the new devkitpro setup.

And I guess I was too tired to realise I was trying to remote-debug SchoolTest.nds using the LevelEditor.elf image ... So I'd better go to bed sooner tonight.

Je sens que je vais archiver le setup devkitpro de grizzly sur mon nuc-à-tout-faire, moi.
mais, en utilisant grizzly-desmume-cli --cflash-path=directory/to directory/to/SchoolTest.nds, je peux faire tourner le code (c'est l'implémentation pour "cartouche GBA" qui ne marche plus, apparemment).
et en débuggant ce code-là, il apparaît que le destructeur d'InfiniMap se voit appelé lors du premier getflags()... c'est supposé être un iWorld, mais il a une vtable de Vblcallback ...

Et si desmume sur grizzly ne se laissait pas débugger avec ddd c'est parce que ... J'avais chargé l'éditeur de niveau dans ddd pendant que l'émulateur tournait le moteur de jeu et SchoolRush. Eh oui. Je vous en prie, balancez votre vanne préférée sur la quarantaine dans les commentaires.

symbol tables in GS3

J'ai bêtement égaré le carnet Atoma dans lequel je rassemblais les idées pour la révision de mon langage "Game EDitors Scripting" version 3 ...

C'est le genre de choses que j'y avais documentées. Souffrez que je ressorte quelques "brouillons" avec un minimum d'explications, du coup. (enfin, souffrez pas trop quand-même).

Heureusement, j'avais déjà un peu bloggé sur certaines de ces idées, notamment le choix des types de propriété pour les blocs et l'idée fondamentale de séparer l'encodage du type de sol et l'encodage de la pente, quitte à regarder un tile plus bas quand on veut savoir si le sol est glissant, collant, etc.  

Chasm

Regardez-moi ça. Je n'ai pas encore acheté ce jeu parce que je suis encore dans Ori and the Blind Forest ... mais Chasm est devenu un véritable fleuron du Pixel Art de ce millénaire, dessiné par Dan Fessler (aka Indigo Arts). J'ai découvert son développement il y a bien longtemps sur pixelation... On y reviendra.

The ground tile fits on a 16x16 grid with one slight twist: rather than having all 16x16 blocks, we have 18-pixels wide blocks next to 14-pixels blocks. Pairs of blocks work on a 32x32 pattern quite well. 

This is not mine. This is pixel study from a screenshot Dan Fessler published for the then-in-progress game 'Chasm' for which I've been tracking gamedev since it was announced on pixelation. 2022 bonus: the progress steps for that mockup are now available too..

Pyramid zone : un peu de design

 Hey! Je retombe sur quelques croquis de design pour le niveau du désert ... Avec notamment de vieux écrabouilleurs, mais aussi des voleurs-de-trésors qui sont en compétition avec Bilou pour retrouver "certains artefacts". Leur progression correspondait à une forme de timer assez visuel.

Just stumbling upon old scans for pyramid zone level design in the "still draft" folders while I was digging for lost (?) GEDS3 thoughts. Featuring early, non-convincing "smashers" design, and the idea that there would be ninja-bags progressing towards the same artifacts/treasures as we do, acting as a visual time limit to reach something.

Un autre "vieux" design : je cherchais une plate-forme qui se déploie ou se rétracte selon les actions de Bilou, un peu dans le style de ce qu'on trouve dans Shantae. Avec des raté et certains un peu plus chouettes. There was also some attempts to find a visually-pleasing item that would act as triggerred / time-limited platforms as we see in Shantae (and many other games).

And of course, some early appearance of the furry mimmic-block thing that isn't really a destructible block and isn't really a monster either, with some ancient runes that pre-date the electroglyphs.

  Et bien sûr, les blocs-poilus, qui peuvent nous bloquer mais pas indéfiniment. On y voit aussi quelques anciennes runes (juste un alphabet secret) plus anciennes que les électroglyphes.

Sandworms

Allons-y pour un dernier post "monster design" dans la pyramide. ça fait un moment que j'ai envie de pouvoir caser quelque-chose dans le genre du "wormouth" de Commander Keen 4, apparamment tout petit, mais qui peut attaquer en un éclair si Bilou est trop près au moment où lui est prêt.

Unless you were friend with my bro' in the 90s or someone really cool, it's unlikely you've come across the Wormouth of the Shadowlands. Yet, I'd like to share the experience of this monster with the players of Bilou : Infinite Pyramid. It is small on screen, but yet giving you the thrill when you spot it. It it readable, but yet can be easily missed if you don't pay attention. It is treacherous, make you feel cool once you figured how to go past it, or even defeat it.

Ce sera le rôle du "Sand worm" (oui, comme dans Dune) mais que je prendrai ici au sens littéral: le ver fait de sable. Du coup, il vampirise mes tentatives précédentes de dessiner des personnages en forme de serpents (encore qu'ils pourraient servir de NPC, du coup).

A random tweet featuring a sort of zombie knight remembered me of that Ulysse 31 episode with swamp-things and I thought I could have a snake made of sand instead of trying to make the snake look exotic enough to be part of Bilou's world. It would be a sandworm, literally. It would look like the upper layer of sand was continuously cascading down its body.

Il faut que je le travaille encore un peu, bien sûr, mais je le crois plein de potentiel. De quoi remplacer efficacement les "pièges aléatoires" de Pharao's Curse.

edit: oh ? il y a un ennemi un peu de ce genre dans Heart Forth Alicia ... ça pourrait être une référence pour les couleurs et l'animation également.

Pyramid smashers

Croyez-moi si vous voulez, mais même les blocs-écrabouilleurs m'ont mené la vie dure jusqu'ici. C'est bien plus confortable de s'appuyer sur les concepts des autres membres de l'équipe "PPP" que de partir de zéro ... mais bon. Il n'y a jamais eu de design PPP pour la pyramide donc on s'y met.

Dès 2017, je tente une représentation des blocs-écrabouilleurs comme étant des gros blocs en forme de poings. L'idée n'est probablement pas mauvaise, mais je peine à trouver la bonne formule, et dès que j'essaie d'en faire un rendu en pixels, ça ne donne absolument rien.

Not that easy to design proper hero-smashers for the pyramid area. I had the idea to make them look like giant punches, carved into rocks. I had some attempts dating back from 2017, but it turned flat when I tried to render them as pixels with the current colors. I resumed working on it when I thought it could use some of Fury of the Furries metallic shades to make it standing out. But I still couldn't make those snail-shaped blocks look like actual fists.

Je prends mentalement note d'introduire des éléments métalliques dedans et d'y introduire la palette des bleus sombres bien Amiga de Fury of the Furries

#0f104f - #1a206a - #4a3f9a - #9a90ca pour les bleus,
#2f201f - #705035 - #af8a5f - #efcf90 pour le bois.

Là. Avec quelque-chose de ce genre-là, ça devrait donner mieux. Reste à trouver le bon design. Je me laisse un peu emporter et j'imagine quelque chose avec des gantelets tout en acier chromé... ou noir et or. Je trouve quelques bonnes références, je gribouille ...

It then pushed me to study some iron fists / steel gauntlets and things alike -- reference are hard to find back with all those "marvel"ous heroes. I found a few design that were so-so, and one that was really standing out. But when I drew Bilou just next to it, it didn't felt right. It was like I overdid it.

Sauf que de nouveau le résultat cesse de plaire dès que je dessine Bilou à côté: ça donne trop l'impression de sortir d'un autre monde. Je tente des crânes écrabouilleurs à la place, mais ça donne trop l'impression de sortir d'un niveau des aventures du petit barbare de Kid Paddle.

Finalement, les poings stylisés ressortent sous un nouvel angle (en haut de l'image de droite), suffisament simplifiés pour ne pas faire tache au milieu du jeu de Bilou et suffisamment menaçants vu leur taille. A mon avis assez intéressant vu qu'on y voit bien tous les doigts, et tant pis si normalement on ne voit jamais sous cet angle-là que les poings de nos partenaires, jamais ceux de nos adversaires...

And finally, switching the view of the plain, cubical fist worked quite fine: sufficiently detailed so that we immediately identify it as "a fist" (imho) but not too far away from the rest of the things I draw. Granted, you'd never see a menacing fist under that angle, but who'd care ?

Undead cell

Une pyramide sans momie, ce serait comme une soupe sans sel, pas vrai ? J'ai envie de pouvoir ajouter un p'tit grain de sel dans "infinite pyramid" mais sans pour autant aller dans la direction "qui pue qui tue", ni faire des Bilou-zombie. J'en avais gribouillé en forme de cigarette et de cigare (du pharaon) qui aurait pu partir en fumée ...

Mais à part ça, je ne trouvais pas de manière claire de l'utiliser dans le jeu à part "il ne faut pas la toucher, sinon c'est la mort instantanée.

The only in-game pyramid I can think of that features no mummy is that of Commander Keen. I won't say I "loved" the way they behave in Lost Vikings, but it was certainly an interesting game design element. But I struggled to find something that looked mummy-like, didn't imply Bilou turning into a kind of zombie and had something interesting to offer in terms of gameplay.

That was, until I came up with the idea of turning that pharaoh-cigar-like into an un-dead battery cell. Beware of un-dead cells, kids: they could strike you with remaining electricity without notice.

Puis en la re-dessinant, je lui ai trouvé un rôle de pile. Et une pile, ça colle assez bien avec les électroglyphes et le reste du monde mystérieux que je concocte pour cette pyramide. En plus, ça amène pas mal de possibilités au niveau du gameplay.

• Bilou ne se fait pas transformer en zombie par la pile-momie, il se fait électrocuter involontairement et la momie partage ses bandelettes pour le soigner. 
• Les sarcophages sont en réalité des compartiments à pile. On peut activer certains mécanismes en piégeant une momie dans le sarcophage et en désactiver d'autres en faisant sortir la momie.
• La momie pourrait ne pas être complètement invulnérable, mais l'action que Bilou devra faire pour la mettre hors-combat nécessitera soit un objet-clé, soit un power-up plus rare (l'équivalent d'une plume dans Mario World).

So Bilou doesn't turn into a zombie when getting too close, but into a heap of ash, and the mummy-cell will share some of its bandage to help him recover. It could turn other things into ashes as well, which could be used as a way to "distract" it. It could be trapped into sarcophagus (actually a battery compartment) or freed from one, which would have the side effect of enabling or disabling some part of the level's artifacts. There's room for fun game mechanics here.

edit: these dudes seems to be the rightful holder of the hookshot power-up, don't they

Rayman sur Super NES vs. Fantasia sur Mega Drive.

Vous vous souvenez peut-être du bashing du Fantasia d'Infogrames par le joueur du grenier. Moi oui. C'est devenu une de mes contre-références. Comment un tel jeu a-t-il pu recevoir le "seal of quality" malgré son horrible gameplay?

Le contrôle de Mickey est absolument insupportable. C'est L.O.U.R.D. [...] On aurait fait un jeu avec [un président de France gras] qu'il aurait été plus agile!

Quand vous vous tournez, Mickey a une espèce d'inertie hyper-chiante. [...] C'est pareil pour les sauts. [...] Ils ont niqué le gameplay, mais l'important c'est que la souris magicienne qui parle, là, elle saute de manière réaliste. [...] Ce temps de latence absolument dégueulasse **ruine**le**jeu**: le moindre saut devient incalculable. [si vous ratez votre coup en voulant sauter sur un ennemi], vous ne pouvez pas réessayer parce que votre personnage est obligé de prendre de l'élan et donc il reste figé une demi-seconde pour sauter.

Maybe you don't speak French at all, in which case it might help you to know that the guy in the yellow shirt above is known as "le Joueur du Grenier" -- which more or less translates as "the gamer in the attic", who does retro game coverage with a "angry VG nerd" inspiration and a French touch. When he bash a game such as Infogrames' Fantasia on the Mega Drive, he insists so much on things such as "don't put huge things in the foreground", that I cannot ignore them. Some features of Bilou: School Rush have been dismissed because I believe Grenier would bash them if he ever played the game.

J'ai trouvé quelques éléments de réponse dans la dernière vidéo de Splashwave qui couvre la série "* of Illusion" et Fantasia. Sega avait réussi à obtenir le droit d'adapter les personnages Disney sur leur console et s'étaient retrouvé après un Castle of Illusions qui avait besoin d'une suite et un Disney qui voulait un jeu-promo sur Fantasia pour accompagner à Noël sa ré-édition.

Another major flaw he points in Fantasia is the stiffness of the character moves and the lack of consistence in the game rules -- such has having a huge flapping book as a bonus and a small circle in the water being actually ground to stand on. To the point where I started wondering how such a bad game could have ever received the "seal of quality" required to be published on a 16-bit machine.

L'enquête splashwave révèle aussi que le développement de Fantasia s'est énormément concentré sur les graphismes, ce qui ne devrait pas surprendre vu l'importance que la firme attache à la fidélité de représentation de sa mascotte. Les designers détachés par Disney auprès des équipes de jeu ne sont sans doute pas des joueurs à cette époque. Il est probable qu'ils n'auront jamais pris la manette en main pour regarder les prototypes, mais ils seront intraîtables sur des oreilles trop grandes ou des pieds trop petits.

Then came the amazing video in the "Splash Wave" series on the making of Castle/World of illusion and Fantasia games. Both had the same Disney supervision and were part of a licensing deal directly managed by Sega. In all of them, Disney representatives were super-strict on look and behaviour of their characters, to the point where "lives" are dubbed "tries" because Mickey cannot die nor kill. And you should better not have their ears a bit too large or feets a tad too ocre.

Splashwave's investigation reports how the Infogrames team spent almost all of their time polishing graphics and kept the gameplay development at the end of the planning. It strongly shows for the CES demo, where most visuals are complete, but the goals are unclear and the controls are a nightmare. How could that have happened ? Who could lead game development at professional scale and do such a thing ? 

Au moment de présenter une démo du salon CES, tout le monde est impressionné par les graphismes, mais il y a encore énormément de travail à faire sur le gameplay: Infogrames avait prévu de s'y attaquer sur la fin du développement. Après la lecture des habitudes de travail de Miyamoto ("faites d'abord un test avec un carré/cube. ça doit être fun à jouer rien qu'avec un cube") et les vidéos des travaux préparatoires de Ori and the Blind Forest, j'en arrivais à me demander "mais quel chef de projet peut laisser le travail avancer autant sans jamais travailler sur le gameplay ?"

Quelques heures plus tard, je retombe par hasard sur une vidéo du prototype de Rayman sur SuperNES et j'ai la réponse: quelqu'un qui est avant tout un graphiste.

L'important pour lui ce ne sont pas les mécanismes de jeu. Ce n'est même pas l'histoire qu'il veut raconter. C'est l'environnement dans lequel le jeu va jouer. Le monde magique qu'il veut sortir de sa tête. Si on le laisse faire, tout son temps va être consacré à dessiner, s'assurer qu'il peut faire tenir ses dessins dans la mémoire de la machine, essayer des effets de transparence, etc. Le déplacement du personnage sera simplifié au point d'être essentiellement un testeur d'animations.

Watching a video of the Rayman-on-SNES prototype suddenly revealed a possible answer to the question above. Because we are almost exactly there with this wannabe-title too. The visuals are stunning, even if totally unrelated of the dreams world of Rayman. They are not just nicely executed: we have all the slope effects and the animated backgrounds, and the variety. Everything. Rayman is walking along and jumping, but there is nothing we can really do but move forward. Nothing to bounce of. Nothing to punch out. Not even a ting to grab. I could easily see man-month effort in this demo, but yet there is not an ounce of gameplay.

Knowing that Michel Ancel is initially more a design-and-draw guy, I could say "that is the type of person who could spend so much time on the look before starting to work on the feel". That demo exactly show that. There is not a bouncing ball doing all amazing things in his head. There is not either a grand story to be told. But there is an amazing world of wonders that waits for being explored. Awe, not fun. And so, when ennemies are eventually introduced in such a demo, the purpose is more to check how their animation renders than trying to start interacting with them.

Soyons clair: sur SuperNES pour quelque-chose de plus ambitieux que Mario World au niveau graphique, c'est déjà costaud. Le prototype de Michel Ancel est allé plus loin: il y a des tests de collisions et compagnie. Mais il n'y a rien à faire dans le jeu. Aucun ennemi. Le personnage est lourd à manoeuvrer et on ne sait même pas lancer son poing (juste accumuler de l'énergie pour le lancer plus loin). Pourtant l'environnement est déjà super-détaillé et très varié.

Mais en réécrivant la partie Anglaise de ce post je me rends compte d'un défaut dans mon raisonnement: il ne tient que si le prototype que l'on voit ici est la seule chose qui ait été produite jusque là. Or il est fort possible que des essais d'interaction avec les ennemis aient eu lieu sur une autre machine (sans doute un Atari ST ou un Amiga, à l'époque). Ce n'est pas le genre de code qui demande un expert sur une console 16-bit, alors que vérifier qu'on a assez de couches de graphisme pour faire ce qu'on veut, c'est beaucoup plus difficile à simuler.

Et il est aussi possible que ç'ait été une habitude dans le milieu du jeu vidéo Français: pour convaincre un éditeur potentiel, il aura fallu montrer des graphismes aboutis, peu importe le gameplay ou le nombre d'ennemis différents qu'on affronte. Hors de question en revanche que le personnage ne soit toujours qu'un cube qui se déforme un peu.

I might be wrong of course. First because the Rayman-on-SNES prototype might have been a companion for a gameplay-on-Amiga prototype that nobody ever thought to preserve. Second, because it might not be something linked to the mind of the designer, but rather to the habits of the video game business in France by that time. Maybe you'd be sure to see your budget cut if you dare to show a prototype with placeholder cubes and rectangles, and you're likely to get the project accepted by a potential editor if you have stunning visuals.

Oh, et pour les trivia, selon Splashwave, ce n'est pas parce que le jeu Fantasia était trop pourri que Sega l'a retiré des magasins, mais parce que les gars de chez Disney avaient oublié qu'ils avaient promis à Walt qu'ils ne feraient pas de produits dérivés de son bébé chéri.

Scorpion or not scorpion

I'm still on my quest to find creatures to fill the gameplay of the "infinite pyramid", looking for things that will remind the player of Earth Egypt / deserts while keeping the exotism of Bilou-like characters. And my fresh quest on "why some Ori monsters didn't work on me" pushed me to find the real best candidate so that my own fiction keeps an homogeneous world. It's kinda tricky, and it is possibly the first time I'll have a full area with monsters of my own from the first stroke to the last pixel in the game.

J'essaie de trouver des personnages pour peupler cette fameuse pyramide. J'ai déjà quelques possibilités pour des figurants, mais rien de suffisamment interactif pour motiver sérieusement la scribouille de petits scénario comme j'ai pu le faire avec le Bilou's Book au début des années 2000.

J'avais une idée de "rampant", dont le design était inspiré de Toki Tori 2 et des torches de Link's Awakening (le vieux).

I already had a fun crawling crab sketch. I got it by blending the look of some Link's Awakening torch with the gameplay of Toki Tori 2. It introduced the idea that "monsters are the treasure, and the treasure is the monsters" that would fit nicely with the design of the School Zone and the green zone, but I'm afraid those little crawling legs will make it too slow to be truly interesting. Plus it only fits the theme if it is impossible to stomp on. I had the idea to try something with a glowing, gem-like back, inspired from some HoB crawling sentries. There came the blades (instead of pinches), and legs might be made of that metal helping gems to fit rings. But the outcome isn't working as I expected.

J'ai aussi essayé quelque-chose qui restait dans le thème "les monstres, c'est le trésor, le trésor, c'est les monstres" pour prolonger l'idée d'objets animés que l'on peut voir dans la forêt (berrybats) et l'école (pendats, inkjets). J'ai tenté de m'inspirer des robots-sentinelles de HoB, avec leur derrière qui brille comme une gemme ... Les pinces étaient du coup des lames de sabre (ou des fermoirs de collier), les pattes des griffes-à-brillant pour une bague.  Mais le résultat ne m'emballe pas.

If I was to focus on the gameplay first, I'd love one of the monsters in the pyramid to provide a shell that can be kicked as a koopa shell. I confess: this is a game mechanics I love in Mario games and I'd really love to be able to use things like that in my own levels as well.

Puis je me suis remis à avoir envie de carapaces-de-koopa à lancer contre des murs et j'ai remis le couvert en essayant de faire en sorte que les "nasty bugs" puissent être utilisés comme des koopa une fois assommés. Il aurait avancé plus vite sur 4 pieds pendant sa "patrouille" que redressé sur 2 pieds en utilisant 4 pinces pour essayer de saisir Bilou. C'était sympa. Il resterait à lui coller une coiffe égyptienne ... sauf que les dernières tentatives lui prévoyait une taille presque plus haute que celle des pendats. J'ai essayé d'en refaire une version "couchée", mais le look ne convenait pas. Les pattes alignées les unes à côté des autres à la façon des araignées de Badman II étaient bof et ne laissaient que trop peu de place pour les yeux.


Puis j'ai un un flash en voyant les "tektites" du nouveau Link's Awakening pendant que J.L.N explorait la rivière Tal Tal: si je lui donne une démarche de crabe, sur le côté, mon scorpion devient plus expressif tout en restant mobile et tout en pouvant se transformer en une carapace-à-lancer en cas de besoin ^_^
Il me reste à décider si je lui donne une carapace qui est un gros joyau ou si je reviens vers quelque-chose de lisse, noir et luisant comme sur mon premier essai.

The final touch might come from (new) Link's Awakening tektites. With their front view and side moves, they provide interesting and easily recognisable shapes.

Ce qui est à peu près sûr, par contre, c'est que je lui mettrai une sonette-de-serpent au bout de sa queue de scorpion histoire de ne pas condamner l'unique angle d'attaque de Bilou.

Charly au Pays des Playmobils

 Me voilà enfin face au cauchemar ultime. En mode héroïque. Parce que c'est sans aucun doute une des améliorations que je préfère sur cette réédition de Link's Awakening version "au pays des playmobils": la possibilité de lancer une partie en mode difficile dès le déballage de la cartouche.

Pour un jeu que j'ai dû refaire entre 10 et 20 fois, le simple "dégâts compte double" n'aurait probablement pas eu autant d'impact que "dégâts x2, pas de petits coeurs, pas de petites fées". Un vrai challenge pour les vétérans de Koholint, qui m'aura fait recommencer le donjon #2 à peu près autant de fois que lorsque j'ai eu le jeu version GameBoy en main la première fois.

Depuis plus de 7 ans, le p'tit bonhomme en tunique verte aux oreilles pointues s'appelle "Charly" dans la maison (depuis que j'ai laissé *deline choisir le nom pour la première partie).

ça lui colle mieux que jamais, vu que cette fois, c'est manette en main que les enfants s'attaquent à l'aventure. Fini de regarder jouer Super Papa Bros.

Les enfants ont pris le bouclier en main assez rapidement (je trouve très rigolo la façon dont Link se met à avancer à petits pas saccadés dès qu'on sort le bouclier). L'épée, ça a été un peu plus laborieux. Au départ, J.L.N (presque 7 ans) s'en servait bien puis il s'est retrouvé confronté à nouveau aux Octorocks et il s'est concentré à nouveau totalement sur son bouclier, oubliant d'approcher assez les ennemis pour les occire, mais incapable (?) de prendre la poudre d'escampette tant qu'il y en a à l'écran.

Une fois dans la forêt, *deline a commencé fort avec le même genre de soucis, m^me si je dois reconnaître qu'elle s'est assez bien débrouillée pour une joueuse aussi novice. La présence de nouveaux blobs rouges qui redonnent des coeurs n'y était probablement pas étrangère.

à ma surprise, une fois la manette à nouveau en main, J.L.N ne s'est pas rué à son tour dans la forêt, mais il a plutôt découvert les joies du jardinage à l'épée dans le village des mouettes. Il essayait de trouver plein de rubis pour pouvoir les jouer au jeu de la pince (et gagner le Yoshi?) ... sans grand succès, le jeu étant "injuste, Papa!"

à la séance suivante *deline avait récupéré son yoshi. A ma grande surprise, ils ont tellement "farmé" dans le village qu'ils ont tous les deux la pelle, sans jamais avoir mis les pieds dans un donjon. Evidemment, ça ne les fait pas vraiment progresser dans leur cueillette de champignons, mais ils s'entraînent à l'épée. Le côté "cosy" du village leur combien parfaitement.

Je n'y avais jamais réfléchi auparavant, mais on a ici un environnement qui reste en permanence à l'abri du danger (contrairement aux "villages" de Link to the Past) à la fois fournisseur illimité et consommateur de rubis. Toute mésaventure avec un renard est vite oubliée... Au milieu d'un jeu orienté vers le défi et l'exploration, le village offre un environnement reposant et amical.

Ori and the Fantastic Beasts

Je crois avoir trouvé ce qui me dérangeais dans le bestiaire d'Ori. Ori lui-même et les deux NPC majeurs (sa 'mère adoptive' Naru et Gummo/Gollum) sont fortement exotiques à nos yeux. Et quelque part, ça a créé chez moi l'anticipation de jouer dans un monde onirique et exotique (au sens différent de tout ce qui m'est familier). Ce caractère est rencontré par certains des monstres, mais pas par la majorité de ceux qu'on rencontre au début de l'aventure. Les oiseaux et les araignées, notamment, sont à mon avis trop proche de ce qu'on peut avoir dans notre monde.

Ensuite il y a les blobs. Ils sont effectivement absent du monde réel, mais ils sont tellement présents (et cliché) dans les jeux vidéos que j'ai l'impression qu'eux aussi ne collent pas avec l'effet exotique attendu.

It took me time to pinpoint what was bothering me with the monster design in Ori and the blind forest, but I think I finally figured out. Ori, his "mother" Naru and Gummo-the-Spidey-Gollum have strongly exotic design -- by exotic I mean far away from what we could find in our world. Maybe "alien" would be a better term. Some monsters share this exotic trait, but others don't and tend to take me out of the "wow ... another world" feeling. Sometimes (e.g. for birds and spiders), they feel too close from what we can find in our world. Sometimes it is because they are too cliché (especially the blobs).

L'effet exotique est rencontré par contre dans les "frogillas / fronkeys", mélange de deux animaux tels qu'on pourrait le voir avec les pégases. L'effet est malheureusement réduit par le fait que cet ennemi est souvent vu "ramassé", en embuscade.

L'effet est maximal avec l'espèce d'orbe qui sert de mini-boss dans l'arbre et qu'on retrouve dans le volcan. Là, on est complètement dans un autre monde. L'effet est réussi aussi avec l'espèce de micro-rhinocéros auquel on peut faire perdre la carapace (si on découvre qu'il peut la perdre) et avec l'espèce de grenouille-cracheuse, parce que si elle gonfle son ventre comme une grenouille, elle se promène la bouche vers le haut, vers ses quatre patte telle une sorte de plante mobile. Mais tous ces personnages sont arrivés bien plus tard face à moi, et à part dans le "col du chagrin", ils restent minoritaires.

The most exotic ones are likely the shooting orb in the fire areas (and met once in the tree, for some reason --  This one even almost feel alien to Ori's world -- and the fronkey / frogilla, an efficient pegasus-like merge of two existing animals. The effect on the frogilla is however diminished by being too hard too read when crouched.

After closer analysis, what initially looked like "just a rhino" turned exotic when you realise you can make it lose all its armor (which only occured after I completed the game once), and when you note that the other frog-like monster (the one that spits at you) looks like a flower bulb on legs...

Even the crows were actually quite alien with their four eyes (spotted on some artwork). But honestly, who did notice that while playing ?

Je constate à posteriori qu'ils avaient dotés les "corbeaux" de 4 yeux (+exotique) mais c'est malheureusement indistinguable à la résolution choisie pour le jeu: on dirait juste des yeux obliques fâchés.

Dans l'ensemble, le jeu reste grandiose. Et si l'apparence des monstres a pu être décevante, la variété des interactions n'a rien à envier à commander Keen

C'est une image que j'aurais dû blogger depuis des années, où les monstres de "Shadowland" ont été triés selon leur niveau de résistance au tir de Keen (horizontalement, gauche = facile, droite = impossible) et de leur mobilité (verticalement. Haut = presqu'immobile, bas = peut occuper de très nombreux emplacements différents).

Deux coins y sont vides:  le supérieur gauche qui correspondrait à un ennemi quasi-immobile et éliminé en un tir -- donc inintéressant au niveau du challenge proposé. Ils sont pourtant présent dans Ori (via des blobs immobiles et passifs) et font office de cachette-à-bonus en début de partie. Le coin inférieur droit correspondrait à un ennemi invincible et succeptible de suivre le joueur dans toute la map. Un cauchemar, quoi. On pourrait y caser le "dopefish", celà dit, et c'est uniquement sa taille et sa lenteur qui permettent au joueur de s'en accomoder.

So finally, some monsters could have benefit from less detailed but more readable design, and only the blobs are truly lacking distinctive look. Unfortunately the blobs are from far the most ubiquitous monsters. Good news is that the design space for the interactions is varied enough. Some chase you, others don't. Some have a weak point to some of your other techniques, other don't. Some shoot things you can bash, other shoot spikes you *must* avoid, etc. I don't have yet a map to show all that as cleanly as with Commander Keen 4, but it still convinced me.
 
(that Commander Keen map had mobility on the vertical axis and stunnability on the horizontal axis: top-left corner = limited mobility and stunnable: given that SHOOT can be done from 4 directions at screen distance).

When I did the monster analysis of Keen, I noted the lack of monster in the "does not move, can be stunned" area. Such monster would offer no challenge, and the correspondant design space is thus empty in Keen. There is such monsters in Ori, though, and they serve as "coin blocks" and destructible walls. bottom right corner = free mobility and invulnerability, usually empty except ... Oh yeah, there should be the dopefish. Only its large size and slow speed make it manageable.

gameplay: les éthers

Je suis retombé sur un vieux document (~2005) présentant une mécanique de jeu qui n'a pas vraiment trouvé sa place dans Bilou : les Ethers. Je venais à l'époque de jouer à Minish Cap, Kirby: Amazing Mirror et à Cave Story et je cherchais quelque-chose succeptible de fournir un gameplay intéressant tout en intégrant la "progression" des pouvoirs de Bilou.

On aurait donc commencé le jeu avec un personnage capable tout juste de marcher, lancer des trucs ou faire des sauts d'une taille modeste. On aurait aussi eu dans le jeu des petits éléments à la forme indéfinie, mais brillants et colorés, qui influencent les actions possibles.

Here are sketches that pre-date NDS development by a few years. A colleague had just got me playing Cave Story after I had played Kirby Amazing Mirror and Minish Cap. I had found the way Cave Story introduced experience bits a great game design idea, giving you not-so-permanent upgrades for playing well. The sketches are all about adapting the idea to Bilou's Grand Adventure. I wasn't so fan of how Cave Story requires you to equip low-power weapons so that *they* get upgraded. Instead here, the experience bits -- dubbed 'ethers' -- would come in different hues, each corresponding to a category of moves that benefit from their collection.

Comprenons-nous: les pouvoirs évolutifs font partie intégrante du synopsys depuis sa première écriture en '94, mais à l'époque ils concernent essentiellement des "pouvoirs technomagiques" comme un tir laser, voler, paralyser les ennemis, etc. Et en plus, ils "consomment" de l'énergie magique que l'on doit ramasser ici ou là.

Les éthers doivent bien être ramasser pour octroyer le pouvoir correspondant, mais ils n'auraient pas été "consommés" quand on s'en servaient. Ils devaient aussi servir de points de vie (pour les Ethers bleus) ou invoquer Bouli (ethers jaunes) et utiliser des attaques combinées (ethers rouges). Les autres (cyan et verts) devaient principalement permettre de booster les capacités de mouvement de Bilou, plus que ses facultés d'attaque.

They should have replaced 'magic meter' that the BASIC-era game required to use the special powers acquired by defeating bosses. Comparatively, you don't consume ethers when you use them (e.g. running at top speed does not deplete your power meter), but you lose some of them if you get hit. And the harder you get hit, the more you lose.

à la place, ils sont perdus quand on se fait toucher ... et plus le choc est violent, plus on en perd. L'objectif étant de récompenser le joueur qui parvient à passer un obstacle sans dégats en mettant certains ethers uniquement avant l'obstacle et un secret/bonus nécessitant ces éthers de l'autre côté -- de la même façon que Kirby va nous inviter à traverser une zone tout en gardant un marteau qui sera nécessaire pour débloquer un coffre dans Amazing Mirror.

Seulement voilà. Je n'ai jamais trouvé un moyen convainquant de faire "gagner" des ethers à Bilou. Contrairement à Cave Story, ici, on est pas attaqué par des vagues de mini-monstres qu'il faut dégommer à toute vitesse. On est plutôt dans un jeu où "les bonus se dandinent à environ 1m du sol". Et les idées pour en obtenir à partir des p'tites pommes et des fleu-fleurs m'ont semblé 'anti-Bilou' sur le principe ... donc le tout est tombé dans l'oubli.

There's one issue I never solved, though: there aren't as many ennemies to defeat in Bilou's Adventure as there are in Cave Story. If ethers are needed e.g. to recover health, that means previous collectibles like apples or letters should somehow provide ethers. And well, I couldn't find a way to make that happen that wouldn't make Bilou fall into the dark side.

edit: Plus, "defeat, move, collect" formula works nicely with gameplay where defeating foes can be done at distance, like in a run-and-gun game. In Bilou, you need to be close to defeat anything anyway, so having then to chase bits of whatever to gain experience would be broken design (my opinion, 2023)

[done] remove import statement

Bion. Voilà une chose de presque faite. On pourra donc faire le nettoyage des commandes "import" (définissant les ennemis, etc) directement à partir de LEDS. De quoi permettre un peu plus facilement de passer d'un type de niveau à un autre en mode 'gamedev nomade'.

Je suis encore loin d'un outil qui soit "game-jam friendly": c'est pas avec SEDS+LEDS que vous allez remporter la Ludum Dare (mais si vous y arrivez, postez-moi le lien vers votre jeu, hein ^_^), même comme ça. Et avant de mettre ça sur ma DS, je devrai au minimum prévoir un message du type "êtes-vous sûr" ([done]), parce qu'en revanche, je n'ai encore rien pour permettre de rajouter des blocs définissant les machines d'états (ou autres) dans LEDS ^^"

---

Ah. Vous êtes toujours là ... je vous dois peut-être bien des excuses, du coup. C'est vraiment du micro-posting, je le reconnais. Le fait que j'aie commencé à parler de la feature il y a deux mois ne rends pas ceci beaucoup plus intéressant. C'était du micro-coding, aussi. Je dois m'y faire. Euh, bon, c'est vrai: je joue beaucoup à la switch ces derniers temps. Et j'ai repris une série de bouquins (Hyperion / Endymion) que j'adore depuis près de 20 ans, vu que ma collègue-et-les-méthodes-de-la-rationalité ne les avaient pas encore lus...