Dans les .DAT de Fury

J'aurais préféré pouvoir dire "dans le code", mais à défaut,  moddingwiki sur shikadi.net a pas mal d'info sur la structure des niveaux d'un de mes jeux fétiches: Fury of the Furries. On y apprend pas mal de choses qui différencient le code du genre de code que moi j'aurais écrit. Comme ce tableau de 5 entrées pour "une zone d'eau" puis 5 autres "téléporteurs". Les concepteurs du niveau devront se débrouiller dans ces limites. Les zones sont forcément rectangulaires, aussi. De mon côté, n'importe quelle zone de 8x8 pixels du niveau peut devenir de l'eau, mais ça aura demandé pas mal d'efforts de développement.

C'est presque encore plus contraignant que les lignes de code BASIC que j'écrivais dans les années '90. Mais avec cette structure statique, on *peut* se faire un éditeur de niveaux et éviter de devoir lancer le jeu après recompilation pour vérifier que les coordonnées correspondent bien à ce qui est prévu. Et le nombre de zones reste suffisamment faible pour ne pas ralentir l'exécution ... même probablement plus efficace qu'avec une liste dynamique puisque les emplacement en mémoire de cette liste sont connus dès la compilation.

There are days where I'm proud of the game engine I've crafted for Bilou on DS and days where I can't help feeling ashamed for how much overhead it carries for things that would have been made so much simpler in the 16-bit age. So from times to times, I go for another hunt on "how 16-bit games stored their levels" in hope that it would teach me how the engine manipulates them.

I knew Fury of the Furries had a level editor. We even have some icons and UI elements in an LBM file shipped with the game. For years, that's been all we had, but now the moddingwiki also features a description of .BIN files for each level in the DAT/ directory. You can see there that there had been some agreement between coders and designers that 5-{anything}-ought-to-be-enough-for-everybody. 5 exits. 5 teleporters. 5 regions where Green's rope wouldn't attach. 5 pools of water ... within each entry, you just find coordinates of a rectangular area. 

I used to have IF XX > 150 AND XX < 270 AND YY > 160 THEN die() in my QBasic edition of Bilou ... well, this is more or less the same. Except you don't get a script line, but you do get a tool that can adjust those coordinates with the mouse and have the engine load them precisely where the game logic will scan them. In comparison, my current engine will instead provide a get_tile_type(x,y) function that looks up a value in a phys_level_map[WIDTH/8][HEIGHT/8] and then let the state machine adapt from that ... where Fury.c could have if in_water_area(furry.x, furry.y) swim(furry);

Of course, that puts a strong limit on how many things you may have in every level, and thus on the size of those levels. It works fine with Fury because levels are quite small, although you may stay longer in some of them than in a Super Mario Bros level. This approach wouldn't have worked for Badman II-styled level, nor for a metroïdvania level design ... But for the maps my brother had drawn for Bilou's Adventures, even the 10 ennemies per level limit could have worked.

Un autre élément intéressant: la façon dont les blocs destructibles sont gérés. Vu la palette réduite, il n'y a pas de "portion partagée du tileset" ici.

Certain tiles in the image file have special meaning.

The tile at 0,1 is a coin. If the player touches this tile in the level, they will gain a coin, and the tile will be swapped out for the tile at 0,0 which is always empty.

The tile at 0,2 is an extra life. If the player touches this tile in the level, they will gain an extra life, and the tile will be swapped out for the tile at 0,0.

The tile at 0,3 is a time extension. If the player touches this tile in the level, they will gain an extra 30 seconds on the clock, and the tile will be swapped out for the tile at 0,0. 

All the remaining tiles on rows 0, 1 and 2 in the map are destructible tiles.

Par contre, certains objets doivent systématiquement être à certains emplacements, comme la pièce (coordonnées 0,1), l'image à utiliser à sa place (0,0), les animations à afficher entre les deux. On a droit à tout une ligne d'images que Fury Rouge pourra grignoter, et les deux lignes en-dessous serviront pour les blocs un peu abîmés et très abîmés. Tellement plus simple que mes "mapanim" ^^"

They also had an interesting approach for animated tiles: the top rows of the tileset pictures (7 or 8 of them) have special meaning, as well as a few more on the leftmost column. You'll see the details in the quote above. An interesting alternative to the hard-coded crumbling floor logic of 8-bit titles like Manic Miner, if you ask me. It requires a good pre-production brainstorming to decide what sort of things we want/don't want in the level, but at least the level designer and the graphist are free to make anything crumbling / chunked by Red as they see fit without having to bother the coders with One More Change.

Mais ce qui m'a le plus surpris, c'est le nombre si faible de "sprites" autorisés dans le niveau combiné à la quantité d'informations associée à chaque sprite. Imaginez: seulement 10 ennemis par niveau !? Mais la raison, c'est qu'il n'y a pas ici "d'ennemi partagé" non plus: pour chaque ennemi, on définit les zones qui le déclenchent, les flots qu'il active/désactive (les interrupteurs et les ennemis sont donc gérés de la même manière). ça explique comment on se retrouve avec des comportements si différents pour le même visuel de monstre ... mais rien qui ne se comporte comme un koopa (avec un déplacement identique d'un bout à l'autre du jeu).

One even more interesting thing is the way sprites are handled. There are few of them per level, but they are given over 1600 bytes each. All the switches and doors and falling blocks that you push and then move into place, all this is achieved with those 10 sprites that can have up to 10 state each in the level. 

Et ce que vous voyez là ne fait même pas directement partie de la structure "sprite", c'est un des 10 états associés à un des sprites, avec leur propre vitesse, leur propre type de déplacement, 

10 states is rather few (pendats in SchoolRush have nearly twice that amount) but what makes it brilliant here is that these are no koopa-like sprites. Their state machine is level-specific and instance-specific. You don't craft a mummy that will turn back at the edge of any platform, you have an editor that let you say *this* mummy will cycle horizontally between *here* and *there*. Same for the falling bricks. or the doors.

RSD Game-make state machine could only have one "next state" for each state. Pretty limited. Here there are at least 8 state transition conditions (most of them being triggers), some about "when that position is reached", other "when that water area reached that level", etc. And yup, you can "name" a water area or another sprite, or even a "current" area (flowing air or water) and activate/deactivate that when your sprite reaches a give state. 

Even the elaborate level 2 of the Pyramid could be explained with pre-defined path alternating "move horizontally" and "falls & bounce", with triggers so that the rocks start falling... there's not even need for a multi-state orange box as I depicted: there is no "shooting" of rocks, just a stock of 3 rocks rolling left and 3 rocks rolling right, and each could unlock the next one when crossing some predefined trigger.  

(PS: j'en profite pour introduire le tag "level data", et attendez-vous à ce que j'essaie de trouver l'équivalent pour d'autres jeux)

#20games

Bon, il y a 20 jours, j'ai décidé de suivre l'exemple de Sverx et d'essayer de poster chaque jour "un jeu qui m'a marqué". Je l'ai compris au départ comme "qui est une de mes sources d'influences dans les jeux que je conçois et réalise ... on y trouvera donc pas Link to the Past, même si c'est à son donjon des glaces que je repense chaque fois que je dois trouver la détermination d'envoyer un recommandé ou de renvoyer des couriers administratifs d'un bureau à l'autre du même bâtiment en passant par ma boîte aux lettres ^^".

J'avais dans le passé déjà voulu participer à un autre challenge du genre puisqu'il y avait jusqu'à hier un tag "10 games" avec 3 posts ...  Croyez-moi si vous voulez, le plus difficile aura été d'attendre chaque fois 24 heures avant de parler du jeu suivant ^^".

I've followed Sverx's example and try to identify 20 games that have been most influential to me as a gamedev. Having to wait for the next day before picking the next game turned out to be one of the trickiest part of the challenge to me ^^". The challenge also said "no explanation, no particular order", but it turns out the first four I picked were among games that I go back for reference very often.

Le challenge disait "pas d'ordre particulier" (avoir Goodbye Galaxy en #1 ne veut donc pas dire qu'il s'agit du meilleur jeu ou du plus important), et surtout "pas de commentaire". Mais sans grande surprise, j'aimerais maintenant revenir sur chaque choix et contextualiser.

"Commander Keen in Goodbye Galaxy", donc, qui a été _le_ jeu utilisé par mon frère pendant qu'il dessinait les premiers niveaux de Bilou. Sans oublier les imports aux monstres de "Secret of the Oracle" pour les ennemis de la Green Zone. Il est probablement aussi parmi les jeux dont j'aimerais le plus mettre la main sur le code source. Même s'il y a les sources de "Keen Dreams", le moteur de GG est plus abouti, ça se sent manette en main...

Some of the games I mention on this blog are so influential they even get their own tag in the cloud! That's the case for Commander Keen, the game that formatted my brother's level design and monster rooster, but also for Fury of the Furries, where *I* draw inspiration during so many levels revival and where I've truly learnt pixelart. 

"Fury of the Furries", que ce soit les graphismes, les musiques, le thème, le level design, ce jeu revient tout le temps dans mon esprit dès que je travaille sur mes propres jeux, donc bin ... évidemment, c'était le n° 2. Lui aussi, j'aimerais sacrément tomber sur son code source... la physique de l'eau, du sable, la corde ... vraiment curieux de voir comment les gars s'y étaient pris. (note au passage: il y a toujours le projet FuryStudio à étudier et les infos sur shikadi.net ). C'est aussi le premier jeu que j'ai pu utiliser comme référence pour le pixel art vu que tous ces graphismes étaient des .LBM.

Vient ensuite Prehistorik 2, qui reste une référence pour moi en matière de bonus, de cachette ... et de comment faire une démo d'un niveau capable de captiver une bande de gamins/jeunes pendant tout un après-midi. Comment Bilou.BAS faisait tomber les pommes pour le décompte du score à la fin du niveau ? Prehistorik 2. Comment le niveau-anniversaire essaie de vous pousser à faire un 100% sur un unique niveau un peu corsé quand-même ? Prehistorik 2. La révision des éponges pour les pendre au bout d'un fil ? Encore prehistorik 2. Lui ... trouver son code ... je ne sais pas trop. Ce serait peut-être un sacré travail de l'étudier si jamais il faisait surface, vu les stratégies "tout assembleur" si chères à M. Zmiro ... Mais on a toujours le site mine.nu et sa page sur le format des niveaux. (Il y a une réécriture SDL2 en C, cela dit ... )

The next two may not have their own tag, but their impact on game mechanics and how to make a compact game interesting over the long run are still fundamental. They are also two of the games for which I'd definitely like to see the source code, and figure out what design choice the developers have taken.

Et Pharaoh's curse. Il a beau être simpliste au regard des précédents, c'est peut être le meilleur exemple pour moi de rapport qualité de gameplay / quantité de contenu. Ceux qui lisent ce blog depuis assez longtemps n'auront pas manquer de noter que je finis régulièrement par revenir à des mécaniques tirées de ce jeu C64 ... et j'espère toujours voir débarquer la version remasterisée de notre ami Lazycow ... Notez que pour ce jeu-là, le code source, c'est de l'assembleur, donc plus facile à reverse-engineerer. Et quelqu'un s'y est déjà attelé.

guest star: François Rimasson

C'est une histoire qui avait commencé mi-février 2021 avec un tweet ... une capture de vidéo pendant un lets-play de Fury of the Furries qui me fait prendre conscience que "#infinitepyramid hints from #furyofthefurries: make sures the spikes stand out." Et là, j'ai un François Rimasson qui répond

• I did all the graphics in 1993

J'enchaîne: You did a wonderful job, then. It has been my first good reference to get into pixelart. Huge thanks!

No kidding! I was already studying it in 2006 before I made my first NDS homebrew. And I was still using it last year.

Je dirais même que si "Badman II" a pu avoir des graphismes entièrement originaux (pour la 1ere fois), c'est grâce à l'étude des palettes de couleurs du désert et de la forêt de Fury. Donc Super-merci ^_^

Je le réaborde quelques semaines plus tard:

Tiens, à propos de Fury of the Furries, il y a ~10 ans, j'avais fait un petit test avec une de tes planches de décor pour illustrer mes outils (homebrew) de création de jeu sur Nintendo DS. Je n'étais pas allé plus loin vu que je n'avais pas les droits dessus.

Là (Mars 2021) mon gamin a l'air d'avoir bien accroché au "let's play" du jeu donc j'envisage de quand-même refaire une conversion aussi du personnage principal pour qu'il puisse s'entrainer le temps que papa ait terminé sa pyramide à lui.

est-ce que j'aurais ton autorisation de rediffuser ces graphismes au format NDS avec mes outils pour un tutoriel, ou est-ce que je garde ça dans le cercle familial ?

Et François de répondre:

• Oui, bien sûr, fais-en ce que tu veux, c'est tellement vieux, et si quelques personnes peuvent s'amuser avec ... je n'ai plus les planches de sprites originales.
• Je suis content que ça te plaise :)

J'ajoute : bin le côté facile avec Fury of the Furries, c'est qu'on a l'ensemble des fichiers .LBM directement dans le jeu. Evidemment, il y a peut-être des planches de pré-production que je n'ai jamais rencontrées.

Et donc on s'y met ... 

6 mars ... "oh birds! @F_Rimasson put so much pixels per spritesheet in Fury of the Furries that it used a buggy part of my conversion scripts that had never been used before ^^"

7 mars ... Hopefully, when you strip out the 'mask' sprites and re-align the sprites that were past the 'checkered' barrier, we're back to an acceptable amount. Actually, it would be perfect to illustrate UsingSprites::granularity.

8 mars ... I was about to suggest that 16-pixels and 4bpp sprites might be an Amiga sprites constraints, but it looks like Amiga sprites were actually 2bpp (https://stashofcode.fr/afficher-sprites-et-bobs-sur-amiga-1/), and likely did not need those mask pictures.

Bon, après ça, j'admets que les interactions ont été plus anecdotiques, avec quand même une phrase qui m'aura inspiré du monster design pour la castle zone:

• Il ne faut pas confondre un fantôme asperger et un spectre autistique

ok, c'est décidé: si je mets des fantômes dans ma zone des châteaux, ce seront des fantômes de légumes. des citrouilles, bien sûr, mais aussi des fantômes asperges qui te crachent de l'ectoplasme dessus.

The first push

J'avais un joli projet pour le niveau 1 de la Green Zone: si le joueur est arrivé à la porte sans la clé, il pouvait libérer l'eau d'un réservoir et s'en servir pour remonter plus haut dans le niveau rechercher la clé manquante. Et pour décider si l'eau est là où pas, j'envisageais un mécanisme-à-la-fury où on pousse un bloc pour lui faire un passage.

Le hic, c'est qu'on est dans le niveau 1-1, là, et que ce sera aussi la première fois que le joueur devra pousser quelque-chose. Est-ce que je ne risque pas de reproduire le problème de la craie des 20 ans où une majorité de joueurs vont se retrouver bloqués après quelques écrans parce que tout un coup, il ne suffit plus de pousser sur A ou B mais qu'il faut interagir avec le décor en insistant un peu alors qu'on ne sait même pas si l'eau est dangereuse ou non.

How do you set up your level design so that players understand they should push a block to keep going? How will they understand that they're not in a dead end, but that there's just one more interaction to learn and use to progress further into the game ? I wonder because I thought about using "push-the-block" as a way to get my players out of what would otherwise be a dead-end.

Par curiosité, je suis passé voir des vidéos pour me remémorer comment d'autres jeux ont géré la chose. Dans Fury of the Furries, notamment, où on va pourtant pas mal se creuser les méninges par rapport à un Kirby, il faut quand-même aller jusqu'au niveau 9 du désert (premier monde, qui en comporte 10). Et là, le bloc à pousser n'est pas dans un coin ou masqué dans un mur ni rien de ce genre. Il est clairement positionné en "porte" entre le haut (vide, joli, mais inintéressant) de l'écran et le bas (clairement là où il faut aller, avec des panneaux, des objectifs, des dangers ...)

I had memories that almost every platformer character of the '90s would be able to push things, so it would be easy to see where they first do it and what the level looks like around them. But let's be honest: finding pushers among platformers isn't that easy and numerous characters don't do it. Cool spot, Aladdin, Zool, Mickey (in Magical Quest), Twinbee, Soccer Kid ... and that's only to name those which I truly expected to push things. I did not even thought you'd encounter that in Rayman, Donkey Kong or Titus games given their primary mechanics. 

But Fury of the Furries did ... you won't have to push anything before you reach level 9/10 of the first world! And there, the first block to push is clearly not part of a puzzle. It is merely a door between you (in a non-interactive rectangular space) and the level you're about to play. And even that wasn't obvious to everybody since I heard a twitcher noticing loud that "ah ? So we can push things, too" and checking the user manual live.  

Et même comme ça, on a des joueurs qui ont twitché "ah !? ils peuvent pousser des trucs, aussi" et de ressortir la page du manuel avec les mouvements possibles. Alors bon, moi avec mon bloc tout seul dans un recoin où le joueur peut légitimement se demander s'il ne va pas mourir noyé s'il pense que le bloc pourrait éventuellement être poussé, hein ...

Bon, évidemment, il y a des jeux où "pousser un truc" est au coeur du gameplay, comme une version plate-forme de waimanu Daring Slides. Et des jeux où "pousser" est une mécanique secrète pour dévoiler des salles cachées du même tonneau que le "reste abaissé 3 secondes devant le soupirail" de Titus the Fox. Je ne suis pas dans le premier cas avec Bilou (le coeur du gameplay, c'est sauter+attraper) et si ce serait sympa d'utiliser le poussage de blocs pour trouver des cachette secrètes, ce n'était pas l'idée ici.

Alors il y a l'approche moderne, évidemment: mettre le budget pour traduire une infobulle dans toutes les langues possible, et indiquer au contact du premier objet à pousser comment il faut faire pour le déplacer. Et pourtant, je sais que j'ai perdu un long moment dans une partie de Ori parce que je ne me rendais pas compte que je devais pousser quelque-chose plutôt que de trouver un double-jump.

But let's be honest: even if I did invest time into a printed manual, future players of Bilou: Dreamland are not going to read it. Players of School Rush barely checked the interactive book on the bottom screen unless they had a sibling actively watching them play! How is that handled nowadays ? Ori did push things in the Blind Forest... It requires you to hold a trigger while you move left or right. Pushable things are highlighted as you approach them and you've got a helper text when you first encounter one. That should be perfect, right ?

Well, unfortunately it isn't. I remember I got stuck at some point in some game of Ori by something I should simply have pushed but I couldn't remember how and I had forgotten what the highlighting meant. It was as simple as picking an old save months after finishing the game: the helping text will only show up once. Not 'only for the first block you have to push', mind. Really just once. How cool for kids that are not reading yet, or not that language, or are distracted by something (a monster and freaky spikes ?) while they should be reading ? 

C'est que ce message-tuto, il ne s'affiche pas systématiquement: uniquement au premier contact. Heureusement, sinon l'aspect "utilise tes méninges", ce serait un peu loupé... Avec un rocher qui se retrouve entouré d'un halo quand on arrive au contact, on a peu de chance de s'en servir pour des cachettes. En revanche, le fait de devoir maintenir un bouton pour pousser les choses, ce n'était pas naturel pour moi, et donc faute d'emploi régulier, une pause un peu longue dans le gameplay ou un retour en Nibel au milieu d'une partie sauvée, et je me suis retrouvé obligé de retourner voir un let's play T_T

Sonic utilise des blocs à pousser, et c'est probablement la manière la plus propre possible de l'introduire:

• ils n'arrivent qu'en 2eme monde, quand le joueur est bien rôdé sur les mécaniques principales du jeu
• il est d'abord utilisé en mode 'clé' : le joueur sera obligé de maîtriser ça avant de passer à la suite.
• le bloc à pousser et l'endroit où le placer partagent une palette de couleur qui est absente du reste de l'écran
• dans les écrans précédents, on a régulièrement été confronté à un obstacle qui nous oblige d'attendre et où le joueur verra Sonic tenter de pousser l'obstacle s'il maintient la manette dans la bonne direction
• what could possibly go wrong ? (est-ce qu'on peut bloquer ce bloc contre le mur, au fait ?)

So where did I get that feeling that "every character will push", then ? Marble Zone, of course. It had a significant impact on my brother when he drew his first level maps. And I must say that the introduction of pushing blocks in Marble Zone is almost flawless. You've just been forced to stop and wait by crushers, maybe for the first time of the game, so you've see your hedgehog pushing the wall or the crusher while you had the DPAD pushed to the left while waiting. It is world 2, so you already have good knowledge and understanding of all other actions and you can use some concentration to notice that. Maybe you're in a dead end, but there's a unique color-coding for that unique-looking block and that switch that makes the gate open when you stand on it. And the block would fit that slot almost perfectly. The only thing that could go wrong would be that player could push it to the left until it is stuck against the wall. Nothing to prevent that. 

J'ai continué mon tour d'horizon, mais il faut bien le reconnaître, l'omniprésence de l'animation "pousser un bloc" dans les jeux de plate-forme 16-bit, c'était une hallucination de ma mémoire. C'est fréquent, mais c'est loin d'être omniprésent. Et même quand c'est utilisé, c'est loin d'être une action de base. On en trouvera 2 ou 3 apparitions, à des positions diverses dans le parcours d'un jeu à l'autre mais jamais autant que les blocs-à-pousser de Zelda. Et sans grande surprise, il faut le reconnaître: dans un jeu de plate-forme, il y a quand-même nettement moins de variantes possibles.

There are quite a number of other blocks to push in the Marble Zone. It is quite unusual even among the games that use push blocks. Fury won't reuse them until mid-world 2. The Lost Vikings have one at the end of world 2, one at the start of world 3 and then nothing until the end of world 3. Bubsy only in level 7, and never mandatory (although used to create a nice puzzle in the hideout to get a Continue). It would have been tricky to make it mandatory in a game where you're killed so easily and when there are so many alternate routes that they can hardly be called "routes". 

It should also be mentioned that the pushable block for Bubsy is a crate, and there had been many crates before. They're almost like Sonic's TV blocks. Crates with collectibles, crates with traps, crates with bananas or anvils. But these two in the desert have no label. They don't break when you jump on them like any other crate in the game would do. That's teasing enough to make the player want to find a way to open them, in my opinion.

Mention spéciale pour Bubsy, qui n'utilise que deux fois (dixit la soluce) la mécanique, et dans le 7eme niveau. En particulier dans un 'puzzle' où il faut pousser la caisse et faire un détour pour la pousser à nouveau, mais l'enjeu est de taille: un "continue", l'item le plus précieux dans ce jeu die-and-retry.

Est-ce que le joueur a eu l'occasion d'expérimenter avec les caisses avant ? Bin dans le jeu, on en a juste eu une plus tôt pour nous éviter de devoir faire demi-tour dans un wagon. Mais soyons sérieux un instant: si le joueur ne se rend pas compte qu'il peut pousser cette caisse et essaie de passer malgré tout, il se prendra les pics, mourra instantanément ... ce qui arrive en général toutes les 30 secondes dans ce jeu. Au prochain passage, il sera probablement trop rapide pour ne serait-ce qu'apercevoir la caisse, vu le nombre de trajets alternatifs que le jeu propose. Et puis un joueur qui arrive au 7eme niveau de Bubsy n'est certainement pas un débutant. Il a d'autres jeux derrière lui où il a pu apprendre à pousser des trucs ... et en particulier des caisses. Une caisse dans un jeu, c'est à peu près aussi "louche" qu'un bloc avec un point d'interrogation dessiné dessus.

Another first-push that is worth noting is in Mr. Nutz. You'll have to push a chair next to a table so you could progress in the Living Room level. Nice little puzzle in an action platformer, and quite unusual to have something that big that your character can push. But what makes it interesting is that the same wood texture is used on the table's legs and when you encounter the chair, you've just been walking past the table unstopped. I'm sure half of the kids have started pushing the chair without even thinking about it because they had not realised it was in their way. It was just like the table and like everything else since the start of that level: scenery.

Other good point on how Mr. Nutz introduces those pushable platforms: they cannot be pushed too far and couldn't be locked or fall out of the place where they are helpful. 

Le plus étonnant dans les setup, ça restera Mr. Nutz, où la chaise-à-pousser est une énigme pour le début du niveau du living qui est probablement devenue iconique du jeu, et révélateur d'une époque de conception. Mais le plus impressionnant, c'est que ça marche sans le moindre accroc. Au moment de rencontrer la chaise, on vient de passer 3 écrans à avancer tout droit devant un décor détaillé mais vide d'un point de vue level design: pas d'ennemi, pas de bonus, pas de power-up. Rien. Et au milieu de ce décor, la table, qui utilise les même recettes graphiques que la chaise. On est passé devant sans soucis, et donc alors qu'on aurait pu avoir le réflexe de sauter par-dessus un rocher ou de faire demi-tour devant un mur, ici on va spontanément se mettre à pousser la chaise (dans le mauvais sens) parce qu'on ne se rend pas compte qu'elle nous barre la route.

Autre jeu dans lequel on pousse sans s'en rendre compte: Mickey Mania. En tout cas, si vous tombez à l'intérieur de la cabine du bateau. On voit à peine son personnage, et il passe derrière le décor, donc pourquoi ne sortirait-il pas par derrière les caiss... ah ? il les pousse ? ... okay. ça me va aussi.

Notez qu'on ne peut pas pousser les caisses vers l'intérieur du bateau, par contre.

I'm more sceptical regarding how Mickey Mania deal with it: you've got an exemplary use of the pushed blocks with the crates next to the cabin of Steamboat Willie: you've fallen into the cabin and when you move left to go back, you see yourself through the window but you don't see whether there's a wall or not on the left. And as you keep moving left, you end up pushing crates, opening your way out of the cabin again. Here you didn't realised you were going to push something because you didn't know where you were. That's great.

Unfortunately, it isn't a mandatory step and the other things to push in the game will not have such clear level design. A giant chest or some plump pudding, where you can easily jump over them if you thought they are an obstacle. With a good amount of other things in the same room that might distract your attention so you could think "noo! why have I killed that monster ? now I can't use it to bounce my way over that wall and I have to reset and redo ..." . Well, you see what I mean.

Enfin, ce que je dis là vaut pour le premier niveau. On retrouve des objets à pousser plus loin dans le jeu (fiole, plum pudding, coffre ...), et là c'est "débrouille-toi, mon grand". L'objet est mis au milieu du reste dans des salles remplis de trucs. Si on compte sur le fait que la cabine du bateau était une salle bonus secrète, un joueur pourrait très bien débarquer là-dedans sans avoir eu droit au tuto "si, regarde, on sait pousser des trucs", et là, bon courage sans SOS vidéo games ...

En comparaison, Ardy Lightfoot prend littéralement le joueur par la main, avec une caisse-tutorielle dans le "prologue" du jeu (même si un speedrunner trouvera le moyen de passer sans pousser) avant de s'en servir au sein d'un puzzle dans la pyramide du niveau 8. Les développeurs iront même jusqu'à utiliser le niveau-prologue en mode "démo automatique", histoire que le joueur puisse voir que "ah, mais attend ça ce pousse, ça!".

Bref, je vais devoir en rester là. Si vous mettez une caisse-à-pousser dans votre niveau 1, l'approche de Ardy est probablement ce qu'il y a de mieux à faire pour éviter les frustrations, sauf si elle sert pour un passage secret.

Two last to check: Super Mario Wonder below, with clever use of a dedicated foe to show you some stuff may now be pushed -- but we're quite far from level 1 although we're still in world 1, and Ardy Lightfoot (above) that will introduce pushing crates mechanics in the 1st level, let you see that it can be used in the "prologue" demo that actually plays level 1 with credits, and then use them in puzzles in the pyramid level, somewhat near the half of the game.

edit: challenger de dernière minute ... Wonder serait-il le premier Super Mario où l'on peut pousser des trucs ? Avec carrément un Koopa dédié au fait de nous montrer que c'est possible sans devoir nous le dire. (ce qui n'est pas sans rappeler les WaddleWing de NSMBWiiu, soit dit en passant :)

Well, I guess that's all. Push mechanics is less frequent and less helpful in platformer where you can easily jump over things that could be pushed than in top-down games like Zelda. If you have to use some in your game, better introduce them at the start of the level where they are used, although it cannot hurt to have them shown up front in level 1 like in Ardy. But if you do have them in your level 1, it will be critical to setup the stage so that the pushable element stands out ... unless it is just a way to open a secret passage, of course.

Nager mieux

I like to release a demo on special occasions like new year or my birthday. It is twice unfortunate that I had none to show by the end of 2023 since it was the 30th anniversary of Bilou's original design. But there was something still lagging behind: for an untrained player, it takes countless trials to get out of the water in the green room. When the season holidays started, I thought I could just change the state machine a little bit so that Bilou would jump out of water if we hold the FOOT button.

Il y a un élément qui m'empêche encore de faire une nouvelle démo avec les améliorations de l'an dernier: c'est difficile de sortir de l'eau. Je m'en suis rendu véritablement compte en laissant un peu la démo actuelle entre les doigts de J.L.N ... Je m'étais donc donné la mission d'essayer de faire fonctionner ça pendant le congé, mais avant même le premier essai, j'ai compris que ça n'irais pas comme je voudrais. Parce que pour qu'on puisse "jaillir de l'eau si on a appuyé sur le bouton de saut près de la surface", j'ai besoin de pouvoir mémoriser que ce bouton a été enfoncé. 

It didn't work as I expected though. Maybe it could be adjusted with some cleaner input buffering, but since I intend to use some different SWIM mechanics to help the game being fun, it seems silly to hack something else first. So I went on, picked my animation editor and started crafting swim left, right and up animations, each split so that they player would have to chain button pressing to reach full speed and Bilou could come back to some "rest position" otherwise.

ça pourrait être réglé avec une peu de tuning sur l'input buffering, j'imagine. Mais comme j'ai aussi prévu de passer à un autre système de nage dans lequel Bilou reste dans l'équivalent d'un dash sous-marin pendant quelques frames quand on a appuyé sur "pieds", ce serait naturel que l'on jaillisse automatiquement si on est dans cette phase de dash. J'ai donc passé deux petites soirées à faire des animations dans MEDS pour que notre brave Bilou brasse mieux.

Manque de pot, une animation supplémentaire s'est invitée dans le fichier. J'ai prévu 4 "pages" d'animations pour bilou.spr, mais cette nouvelle animation est sur la page 7, décalant toutes les nouvelles animations

- code avant la nage avec les sprites avant la nage:
  - démarrer la pyramide: ok
  - passer de la pyramide à l'école: ok
  - sortie de l'école: gros crash.

Une petite modif' plus tard (là, ce soir) pour éviter que l'animation excédentaire soit à la fois sous le contrôle du jeu et sous le contrôle du reste (sinon, ça fout un chaos digne de Jurassic Park dans le gestionnaire de mémoire) et j'ai de quoi commencer à utiliser toutes ces jolies nouvelles animations. Sauf que ça fait bizarre de voir Bilou essayer de rejoindre la surface la bouche grande ouverte (animation "super jump" recyclée) puis fermer la bouche une fois qu'il arrive à l'air libre :-P Edit et il va falloir que j'en fasse une ou deux de plus pour permettre au joueur de quand-même avancer. Sur base des animations de Fury ? Pourquoi pas ...

But unfortunately, some bits got twisted, and I ended up with an undesired 'temporary' animation stuck in the bilou.spr file. Then I picked the wrong decision of ignoring it while loading rather than fixing the editor and saving the file again. It worked when I tried the animations in the green room, but when I tried to 'move' between rooms later on, everything blew up. I had HDMA experiments catching my attention, so I was all out of holidays when I finally understood why it broke and how to fix it. Sounds like you'll see the swimming another time ^^"
Edit: one more thing ... Dash-swimming might be fun, but I also need something to use when player just navigates with the DPAD. Maybe Fury's swim sheet will be the template I need for that ... 

Edit²: give it a try in the latest demo

Fury 2 ?

Je dois reconnaître que celle-là je ne m'y attendais pas, mais figurez-vous qu'une équipe s'est mise en tête de nous faire une reprise de Fury of the Furries! Eh oui. J'en veux pour preuve une vidéo "playthrough" du nouveau château. Bon, je suivais à distance le projet depuis un moment, et je ne peux évidemment pas m'empècher (après Giana et Bubsy) de juger "ce qui marche et ce qui ne marche pas" dans cette adaptation.

Tout bon: le pixel art. Sur les décors principalement, bien que les sprites ne soient pas en reste. Les graphistes semblent avoir bien capturé le côté "di-chromie" du premier opus et s'en servent judicieusement (mur du fond dans les tons mauves et boiseries qui ressortent bien) ainsi que les "textures" variées des briques et autres éléments de décors.

A améliorer: la bande son. N'allez pas me faire dire que l'artiste en charge ne fait pas de belles choses, mais sincèrement, comparé au travail d'El Mobo sur l'original (remixé?), on se sent loin du compte. Ça manque de punch et de personnalité. J'aurais presque envie de dire à CJ "allez, je leur laisse Pikaboo Castle" (mais il est déjà dans Wolfling ^^")

Know what? One of the authors of the original Fury of the Furries game has started an indie Furry 2 project! From times to times, we get videos of in-progress game development - and recently, that was a full playthrough video of one of the environments: the castle. Great pixel art, improvable soundtrack and a mood that feels like keeping the genome of the original game. Let's see whether we can say more about game design...

Interpellant: la longueur des niveaux. Fury, c'était un 'puzzle platformer'. Pas que la dimension "casse-tête" soit majoritaire comme dans un "Toki Tori", mais enchaînant des niveaux plutôt courts les uns derrière les autres. ça donne la possibilité de se concentrer sur l'exploration/l'observation d'un des niveaux pour trouver les mécanismes à activer, les passages secrets, etc. Ici, on a une map plutôt grande concentrant tout ce qu'il y a a dire (?) sur le chateau, et dans laquelle on nous invite à trouver un bon millier de fruits et légumes cachés. Pas loin de 40 minutes pour une exploration exhaustive sans respawn, c'est long, comme session de jeu.

Levels are much *much* longer than in the original puzzle-platformer game. That somehow make sense since the 'puzzle' part seems to have been dropped in favour of a more regular "explore-platformer with some local puzzles to get extra things". When you're designing a puzzle, you want to expose as much of the items to your player's eyes, so they brains can solve the puzzle instead of trying to remember what they've seen elsewhere. You also need to ensure failing the puzzle (which often implies dying or retrying from the start in the original game) won't ask your player to redo too much again, and short levels help on that. Still, here we've got about 40 minutes of video for a collect-all-items playthrough.

Mitigé: les pouvoirs. Fury, c'est 4 pouvoirs différents et (le plus souvent), la possibilité de passer de l'un à l'autre. Jaune = attaque, Rouge = mange-mur, bleu = nageur, vert = acrobate à la corde ninja. Le principe est conservé ici, bien que si je ne me trompe pas, il est maintenant possible de changer de pouvoir instantanément, sans attendre d'avoir mis son personnage à l'arrêt (ce dont je ne me plaindrai probablement pas). J'avoue que le côté " vert se balance avec sa langue" a un côté dégueu-kid-paddle dont je me serais passé, mais je suis prêt à le concéder comme liberté artistique des nouveaux (?) auteurs au même titre que je passe l'éponge sur l'exagération graphique de Rayman Origins/Legends. 

Bleu peut maintenant cracher de l'eau, ce qui donne lieu à quelques interactions sympas (je ne vais pas appeler ça des puzzles) comme ici avec un canon qui perd toute sa vigueur si on noie sa mèche. Il faut toujours Jaune et ses kameah pour se débarasser de la plupart des ennemis, donc ça reste équilibré et ça atténue un peu l'effet "Bleu ne sert à rien, y'a pas d'eau" du jeu original.

Rouge a maintenant la possibilité de voler en pétant. C'est kid qui va être ravi. La mécanique est rigolote, le contrôle en vol plutôt correctement dosé (à vérifier manette en main) entre trop fort et pénible-à-la-Donkey-sur-un-tonneau-fusée, l'habillage (comprenez les prouts) bien en phase avec le personnage (dévore tout et n'importe quoi) et la fonction (mon filleul parlait déjà des prouts de Yoshi pour justifier sa faculté à voler un petit moment dans Yoshi's Island). J'ai un peu peur que ça ne rende les acrobaties de Vert fort anecdotiques, par contre. Pourquoi se prendre la tête à faire le ninja quand on peut léviter ?

The general idea of 4 characters with different abilities and a way to swap between them (you only ever control one avatar) has been kept and the overall ability scheme has been preserved: Yellow shoots, Red eats, Green swing and Blue swims. Well, Blue can also exhale water (solves some puzzles, and used as a weak weapon). And green can slurp bonuses at a distance (possibly swallow small baddies ?). The most modified one is Red. He can now fart-fly for significant distances. To what extent will that break platforming or rope-swinging, I'm unsure of. I understand this won't disappear because it was the core gameplay of a mobile game I've never played. It doesn't look very balanced on the video, but maybe that's because player has already collected some fart-more-power-ups or something similar (I see hints that Yellow has now limited shots despite the counter never goes down, either). Anyway, since there are already portals that forbid the use of one character for one area, there's a clear way to enforce player would use rope-swinging or jumping in some specific room if level designer decides so.

Enfin, et c'est sans doute lié au passage du puzzle à une approche plus "collect-platformer", les retraits de pouvoirs semblent plutôt rares. Le jeu d'origine nous mettait souvent dans un niveau avec seulement 2 pouvoirs, et un 3eme à réactiver dans une zone précise. Ici, c'est plutôt "les 4 font la fête" en permanence avec quelques passages "Regarde Maman! Sans les mains!" pour l'une ou l'autre salle bonus.

Très bien: le côté décalé. On a gardé les loups-garous qui se changent en lapinou, les parodies de Dracula, les clins d'oeil aux flippeurs et compagnie. Trop tôt pour dire si les cameos seront aussi nombreux que dans l'original (en particulier dans le niveau final. On dirait bien), mais on a ni renié ses origines façon préhistorik-supernes, ni sombré dans un excès qui perd toute saveur façon film de Jim Carrey.

A tester: la barre de vie. Fury était un die-and-retry. Tout comme Commander Keen et Rick Dangerous, tout contact y était fatal. C'était précieux pour certains puzzles mais ça pouvait devenir franchement gonflant quand le moindre pet de mouche dans la tronche vous éclate. Là, avec 6 points de vie en début de niveau et des ennemis qui explosent au moindre tir (le jeu d'origine vous demandait régulièrement de bourrinner le bouton de tir 5 à 10 secondes pour la moindre araignée) et distribuent généreusement des petits coeurs, j'aurais du mal à fixer un pronostic.

One last item that might be worth tuning is the amount of hitpoints for both baddies and furries. The original game had a die-and-retry aspect for the player while any baddies would require numerous shots to be defeated. Here this is the opposite: plenty of hitpoints for the player and most ennemies explode in one shot, often releasing a heart for the player to recover. I know I've been wondering whether some god mode was enabled while watching the video. But it wouldn't be too hard to make that customizable by the player, adjusting heart-drop-probabilities or baddies resistance to Yellow's shots through menu or collectibles. Don't let that prevent you from wishlisting the game!

Bref, vous l'aurez compris: Fury 2 n'est pas un remake de Fury 1, mais il reste fidèle à l'esprit et à l'ambiance de l'original. J'aurais envie de comparer l'évolution de gameplay à ce que l'on a pu voir entre Ori 1 et Ori 2. Je souhaite une bonne finalisation au projet et un grand merci au Cyrille qui bosse là-dessus de nous proposer un retour en Furries. Wishlistez bien ^_^

Hints to make a Pyramid.

#infinitepyramid hints from #furyofthefurries. #1: make sure the spikes stand out.

Hint #2: push things around to solve problems	Hint #3: when you cannot push, pull.
Hint #4: Get rid of extra sands to unlock doors	Hint #5: push sands where it actually helps.

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 ?

Pac In Time sur GameBoy

Dans la liste "Prêtés à Pype" de mon frère, il y a depuis un moment "Pac In Time", comprenez pour les anciens possesseurs de machine Commodore "Fury of the Furries moddé par Namco". Je me refais un petit essai ce soir avant d'aller dormir. Pour la micro-machine de nintendo, l'animation est fluide, les graphismes parfaitement lisibles (GameBoy advance micro, avec un perso rouge sur décor gris) le son de bonne qualité. La physique des personnages est parfaitement rendue. En fait, il suffirait presque de faire un rom hack pour ré-ébouriffer la boule de poile vedette pour retrouver le "bon vieux jeu de Kalisto Atreïd Concept" (sur une licence qui n'était pas à eux :P)

I'm playing Pac in Time, borrowed from my brother. Yes, that's it, a game boy color cover of my puzzle-platformer reference game: Fury of the Furries, but de-vamped with a pacman character. Animation is smooth, graphics are readable and sound quality is quite great. The gameplay and physics are perfectly aligned with my memories of the Amiga/PC game. I cannot tell the tale of how an almost-original concept turned recycled into a franchise, and that's typically the kind of things that make me sad for people who try and be creative.

Instead, allow me to point out two major drawbacks of the conversion. First, with sound design. It is not uncommon to die a lot in Fury of the Furries and even when you don't, levels tend to be fairly short, at least at the start of the game. In this context, the 5-second pacman jingle repeated everytime you enter the level tend to break game immersion, considering that Moby's soundtracks were long and varied enough so that they could loop and keep you entertained. Even worse, pressing "pause" mutes the song altogether.

Comment "Fury of the Furries" a-t'il pu se faire dévisager en "Pac In Time" ? J'aimerais beaucoup avoir le fin mot de l'histoire, bien sûr. Disons que comme pièce à conviction, j'aimerais que la cour prenne connaissance de la spritesheet de la zone du chateau. Le jeu est plein de clins d'oeil du genre "pop culture", mais il se peut que les éditeurs aient estimé qu'on était trop près d'un plagiat des personnages de Pacman pour oser une sortie sur console ... voire que Namco, irrité des fantaisies sur micro aient exigé réparation avec une "vraie licence" où ils recevraient une part des ventes du jeu.

Deux points noirs, cependant. Niveau sound design, d'abord, avec le jingle de pacman qui prend 5 secondes avant le début de la musique, et qui casse l'immersion là où FoF d'origine nous gardait le thème du niveau en boucle. Idem quand on met la pause qui nous plaque un gros silence radio...

Niveau game design ensuite. Qui dit Fury dit "changer de pouvoir régulièrement". Dans la version PC, ça s'accompagne d'un petit son sympa lorsqu'on maintient le pad vers le bas alors que notre perso est au sol. on sélectionne son pouvoir avec gauche/droite, on valide avec le bouton de pouvoir. Nickel. Sur gameboy, tout ça se fait par l'intermédiaire de l'écran de pause, forçant des coupures régulières dans le gameplay. Ça casse l'ambiance... dommage.

Enfin, il y a la taille de l'écran. Dès que les niveaux deviennent un rien exigeant, les panneaux "attention danger" de FoF ne suffisent plus. On doit faire des sauts sans pouvoir voir la fin des pics qu'on cherche à éviter ... et ça c'est quand on peut voir les pics au moment de commencer à sauter. L'écran de la gameboy fait la moitié de la largeur du 320x200 d'un Amiga. Ça tue le plaisir de retrouver le jeu...

The second drawback comes with game design. Playing Fury of the Furries implies that you're frequently switching between characters to pick the special power you need to progress (block-chomping, fireball-throwing, ninja-roping or swimming). In the PC version, you'd do that without interrupting the game by pressing *down* while your character stands on ground and then switch character with left/right. Here, it happens in the "pause" screen. You lose contact with the world (a blank screen and muted soundtrack), and the ambiance is broken every time you use what defines the game the most.

Finally, compared to the original game, most hitboxes are very rough compared to the original, and several baddies feel unfairly dangerous compared to their look. Yet, the game is made much more accessible by the fact that *every* level now has a corresponding password, where the floppy version only granted you a save state every 6 levels

edit: deux cachets d'aspirine plus tard, je suis au niveau 2-6. Les maps de HOL me permettent d'aller voir ce que ni l'écran ni ma mémoire ne peut me dire. Certains ennemis ont été supprimés, mais le système de collision "au pixel près" a été remplacé par des hitbox grossières (sans doute faute de puissance de traitement sur le Z80 du gameboy), et il vaut mieux résister à la tentation de se faufiler entre les ennemis. Les limites de temps sont beaucoup plus serrées que dans la version originale, mais le système de mots de passe niveau par niveau permet de revenir à la charge (une sauvegarde automatique tous les 6 niveaux avec assez peu de vies dans l'original). Les niveaux bonus auraient-ils complètement disparu ?

encre ? yeah !

Je ne veux pas me contenter de flaques d'encres immobiles pour la School Zone de Bilou. Je veux pouvoir en profiter pour construire des puzzle autour du principe des vases communiquants. Je veux aussi pouvoir utiliser un seul niveau qui monte pour tout le niveau, histoire de proposer des niveaux à terminer dans un temps limité.

So far the ink is static. Puddles where you shouldn't fall in or some bottom-of-level deathly trap. I want to go beyond that. One of my favourite puzzle elements in Fury of the Furries was involving sand or water level that you raise or lower to transform the level. It re-appears in two of the levels I had envisioned for the School Zone, and it would be the base for both deep-ink-pit and rush-to-completion arcade-games I have in my furnace. Several elements need to be sorted out to get that working, though: rendering, interaction with monsters and implementation of the levels equilibrium mechanics.


Côté implémentation, j'ai écarté l'utilisation d'un plan dédié (je n'en ai plus). Combiner une ligne de sprites pour l'animation de la surface avec un remplissage de l'arrière-plan par des pavés tout noirs pourrait faire l'affaire quand l'encre va toujours vers le haut, mais pour des vases communiquants, qui pourrait "réparer" la map quand l'encre descend ? ... A moins que la map complète en mémoire ne soit jamais dégradée, et que seule sa copie à l'écran ait des pavés noirs. Mais Infinimap n'est pas conçu dans ce sens-là. Des gros sprites partout, ça ne marchera pas bien. Le plus souple, ce serait sans doute de règler ça à coup de polygones.

Rendering still has a few options possible on the DS, but in my current setup, the constraints start to pile up. I cannot have a dedicated BG layer. I don't have any left since I introduced 3D objects, which need their own layer. I might be using 3D polygons when the ink sits "between" the two layers of the playground -- that's for Deep-Ink-Pit and Bilou's Adventure. When the ink rise up through the whole level as in Rush-to-Completion, I'd better use the "window" feature (or possibly a raster interrupt to affect background priorities on the fly). For the animated surface of the ink, sprites are the best I can think of.

Ensuite, il y a les personnages. En remplaçant les codes du bloc d'encre sur la map du niveau d'*deline, j'ai pu faire en sorte qu'un taille-crayon lancé dans l'encre fasse des gouttes. C'est aussi un premier pas pour faire en sorte qu'une éponge qui tombe sur l'encre flotte (enfin, à moins que Bilou ne se tienne dessus assez longtemps).

Spongebops and other monsters might have to interact with the ink. I made a first step with Dumblador getting "killed" when touching the ink and generating droplets. That required to change the tile properties so that monsters can also interact with the ink. Initially, I thought making spongebop floating on contact would require some intermediate "liquid" tile before the interactive "kill-Bilou" blocks, but it turns out that the same interactive block can also trigger state transitions such as fall/float for spongebop. neat.
That's actually very good news. It means I don't *need* the ink to be tiles in order to trigger the floating. A GOB with the appropriate collision mask will transparently produce the very same kind of state transition.

Je pensais au départ ajouter une couche de tiles "flotteurs" par-dessus les tiles qui blessent Bilou, mais le même code "F_INK" peut à la fois se traduire en une transition tombe/coule pour Bilou et tombe/flotte pour l'éponge. En en faisant une collision ordinaire (et pas un type de tile spécifique, ce que je garderais pour l'eau), ça veut dire aussi qu'un GOB qui possède la bonne zone de collision F_INK peut interagir avec les éponges, y compris pour l'encre qui monte et qui descend.

A partir de ce moment-là, je peux commencer à concevoir les réactions "vases communicants". Un objet-déclencheur peut forcer les deux GOB-surface à se mettre en mouvement. On peut aussi les lier l'une à l'autre pour leur permettre de s'équilibrer, avec une variante du contrôleur qui ajuste la distance entre Spongebop et son pivot. Reste un élément délicat: comment faire en sorte que les niveaux d'encre se mettent en mouvement simultanément ? Un coup de sonde à l'aide d'une zone de collision bien calibrée pourrait faire l'affaire (de la taille du bouquin central, par exemple), sauf que les zones de collision sont normalement définies pour un état donné, pas pour un objet donné.

If the part of the ink that's animated is allowed to be a GOB, the use case of ink-level-equilibrium turns closer to something GobScript can readily handle: it mostly comes down to two ink-surface objects that adapt to each other so that they reach the same level, possibly assigning them top speed that depends on the width of the pit they're in. Then, I have to figure out a way to kick them so that they start moving simulatenously (e.g. after Bilou opened some path between the two pits). I could build something inspired from Badman II boss rooms in RSD Game-Maker, with a lock-type block that shoots invisible trigger-sparks moving along the same kind of directional block as those controlling inkjets.

J'ai donc commencé à construire quelque-chose qui fait fort penser aux boss de Badman II: faire en sorte que la serrure génère des "étincelles déclencheuses" (invisibles) vers la gauche et la droite et placer le même genre de blocs-directionnels que ceux qui contrôlent les déplacement des encriers pour faire en sorte que les GOB-étincelles atteignent simultanément les deux surfaces pour les mettre en mouvement.

If that's funny to demonstrate that the a-priori simple engine can handle elaborated things, it would quickly turn into a nightmare for any sophisticated situation, like the twin-corks in Remi's level (where each cork might trigger raising ink from the other's position). You'd end-up crafting chuchu-rocket puzzles on your map and hope the timing you computed in your mind is correct when launching the level. As a second thought, I'd rather have the surface GOBs both attached to the "lock" and start raising when this link is lost. Yet, it would be nice to have test-zones that can be defined through GOB variables so that the level editor can precisely define a trigger region for each of them (but it's unclear I have true *need* for that in any of the level I designed so far).

C'est rigolo un instant, et ça fait plaisir de constater que les abstractions construites jusqu'ici sont suffisament Turing-esque (comprenez, expressives) pour ce genre de déviance. Mais soyons clair: si on veut passer à un niveau un tout petit peu plus élevé -- les bouchons jumeaux du niveau de Rémi, par exemple -- on peut rapidement se retrouver à construire un puzzle à la chu-chu-rocket qui va promettre de sérieuses migraines au moment de la mise au point.

Il y a bien une autre possibilité: quand un Gob (ici, la surface d'encre) est attachée à un autre (la serrure), il reçoit un évènement si le Gob de référence disparaît. On peut alors faire monter le niveau d'encre suite à la disparition du bloc-serrure -- ou du bloc invisible qui s'est fait détruire par le bouchon-qui-s'enfonce. La bonne nouvelle, c'est que l'éditeur de niveau supporte déjà ce genre d'approche. La moins bonne, c'est qu'un Gob ne peut être attaché qu'à un seul autre. On saura donc faire des niveaux avec 2 bouchons, mais pas avec trois. Cela dit, ça mériterait vérification, mais je pense bien que je dois pouvoir m'en sortir avec juste "2 bouchons" dans tous les niveaux dessinés jusqu'ici.