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.

Gare aux taches d'encre ...

Au-delà des pentes plus ou moins pentues et des personnages en 3D, il y a un "monstre" supplémentaire qui attend de rejoindre la school zone et qui n'en est plus qu'à quelques pas: "inkjet", l'encrier tacheur.

Petit tour d'horizon sur la façon de le réaliser, à l'ancienne sur une feuille quadrillée avant d'aller dormir... Chose amusante, je me rends compte qu'en réalité les 2 formes d'encrier ("volant" ou "poussable") présentés ici pourraient très bien être 2 GOBs aux machines d'état totalement distinctes.

As the real life gets a bit more quiet, I managed to find half an hour with pencils and paper ... just enough to make a quick list of what should be done in order to bring inkjets to life. A first one would be "turn back" special blocks that floating inkjets use to change (progressively) their direction (as opposed to an "invisible wall" that would immediately stop the inkjet).

Parmi les "petits défis techniques" posés par Inkjet, j'ai recensé le "demi-tour de plate-forme mobile", nécessitant un contrôleur adapté.
Rien de particulier pour que Bilou puisse être transporté par un inkjet, en revanche: ce sera entièrement dans le code de Bilou que ça se passera.

As far as "carrying" is concerned, nothing special should be needed in inkjet.cmd file -- except a special flag assigned to some hitbox. Bilou's state machine is fully responsible of the additional "carried" state. What we might want is a "throw up" state that allows a hitbox to cancel the droplets generation, so that droplets are created *only* if no character was carried (and thrown up).

Envoyer Bilou en l'air s'il est présent et lancer des gouttes d'encre dans le cas contraire ? C'est possible. Il suffit d'une zone de collision associée à l'animation "projeter". Si elle rencontre un personnage compatible (transition "found"), elle interrompt l'animation (et le projette). Les gouttes d'encre ne seront générée que si l'animation prend fin naturellement (transition "done" dans ma machine d'état).

Interestingly enough, all this is independent to what would happen to the "standing" inkjet (on the ground) and the transitions used to allow it to be pushed by Bilou.

Pour l'encrier au sol, je devrai procéder en 2 temps. Tout d'abord, m'assurer qu'il est effectivement "solide" pour les marcheurs, qui fasse faire demi-tour aux dumbladors et force Bilou à passer en mode "pousser".

Ensuite seulement, une 2eme collision dans le sens inverse force l'encrier à se déplacer.

Bon, là-dessus, je vais m'installer pépère dans un fauteuil et faire quelques petites animations supplémentaires dans SEDS...

Checklist:

• [check] special block digits are read horizontally first, then vertically
• [oops!] 1xxx is for "interacts with monsters" "interacts also with monsters", 2xxx is for "doesn't trash graphics while removing properties" "doesn't disappear when touched", but we could use "on hit [0] ()" in block description to prevent it.
• [oops!] "block 1002 {" effectively encode properties of block using digits 1,0,0,2 on the level editor and not some other funny 0x1002 value that wouldn't make sense. (block 82 is required.)
• [ok] states doesn't prevent collisions to be detected.
• [fixed] decrease controller can cannot be used as expected.
• [bugfix] GameScript::content() should allow \t tabulations in cmd files.

Back to School

Coïncidence ? Manigance ? Fait du hasard ou du destin ? Toujours est-il que c'est aujourd'hui que réapparaissent des pixels de la school zone sur ma DS.

Eh oui. J'aimerais bien pouvoir bénéficier des idées de niveaux cogitées ces 5 dernières années... Et pouvoir un jour montrer à mon p'tit n'veu Rémi (qui n'est plus si p'tit) que j'ai pu exploiter le niveau qu'il avait dessiné.

Is it coïncidence ? Is it providence ? Is it fate or hasard ? Here comes some new School zone pixels for Bilou on the Nintendo DS...

The fact is that most of the level design efforts of last years are located in the school zone, and I'd like to give them a try. Not mentionning the fact that I still have to show my lil' n'phew that I'm indeed able to bring the level he drew to life.

statW20->statI4 on fail

Après relecture du code "la tête froide" (comprenez, en prenant un Ice Tea sur la terrasse du Fagotin de ma fée entre la grèle et la panade pour *deline), il s'avère qu'aucun état "on pousse" n'est nécessaire pour règler les problèmes de collisions. Une meilleure sémantique pour la décision "FAIL" des contrôleurs a suffi, et je devrais pouvoir encore simplifier un peu la sauce. Cf.

• Bilou behaviour script using one-letter state hinting (e.g. statW% for walking, statI% for idle)
• controllers.cxx, saving impact speed
• GameObject.cpp moving GOB by (stepx, stepy) before investigating state transitions

I managed to find some time to study back my engine code this week-end, and it turned out that no "push" state was actually required to solve stuck-on-corner issues I observed last week. Quite good news, somehow: that means I won't need extra states when it'll come to do climb/walk transitions.

Btw, I applied to Bilou the same kind of "reuse impact speed for bouncing" than I previously used for little stars... It's pretty much working, but it is tedious to maintain the state of variable: when hitting a wall first, and then the ground, we should still bounce with the floor-hitting vertical speed (rather than wall-hitting speed).

It isn't obvious to implement at the moment, requiring to manually reset the "impact speed" in every transition that enters "Fall*" state. I'd prefer to have "impact_y:=0" defined as a "state initialisation action" ([todo] a part of the UmL state machine model I'm still missing). But first, I'll have to check whether removing the extra "landing" delay will affect it or not.

Les test-points sont à revoir

Décidément, le mécanisme des test-points ne cesse de me jouer des tours >_<. Une fois encore, alors que j'ajoute un état "pousser" pour débloquer Bilou des murs, ils me "lachent" de nouveau. L'idée, quand j'étais passé au mécanisme cando(), était de conserver les test-points en complétment, pour permettre de choisir la bonne action à effectuer. En clair "ok, tu ne sais plus marcher, mais je fais quoi ? je pousse ou je tombe ?"

It looks like I definitely can't make test-points and cando() tests live together well. Despite a new state for "wall-pushing" that should have solved Bilou's behaviour, I still observe that you might end up unable to advance up to the wall for the simple (?) reason that the test-point that should enable "walk->push" transition haven't seen the wall yet due to a cancelled move. I fear controllers and test-points are too much desynchronised, and most likely, I'll have to print out some code on paper to re-think the whole problem and come with a better, integrated, system.

Mais ils sont évalués indépendamment du mouvement qui a été tenté, et donc, régulièrement, le "point-détecteur-de-mur-devant-Bilou" ne détecte rien du tout parce que le mouvement qui aurait dû conduire Bilou dans le mur a été annulé. Bref, ça sent l'impression de code et le débugging à coup de fluo et de tasse de thé :P

Maintenant, poussez !

Armé de mes débuggeurs, je suis à la chasse aux petits "glitches" dans le jeu. Bilou reste parfois bloqué en bas d'une pente sans pouvoir continuer ... ou bien il ne sait pas s'introduire dans des conduits un peu plus étroits, etc. Sans doute des effets combinés du mouvement contrôlé par les animations et des conversions virgule-fixe-vers-entier.

If you have tracked updates of the last 'todo' post, you know I'm busy hunting and fixing all behaviour glitches in the current demo before I move forward to the Apple Assault mini-game. It's not that nice to have a gameplay where your hero might remain stuck at the bottom of a slope or where he's remaining stuck in narrow corners. Many of these oddities are side-effects of animation-controlled moves, which is intended to make Bilou better "fit" his world.

I had the opportunity last night to proceed to instruction-stepping of one such issue (g++ -O3 overdid it: it's impossible to check whether the algorithm is properly working at source code level anymore), which ended up with "Bilou's behaviour isn't buggy: it's incomplete!"

Après un retraçage complet au niveau assembleur (l'optimiseur de C++ fait trop bien son boulot: ce n'est plus possible de suivre l'algorithme au niveau symbolique), j'en arrive finalement à la conclusion que mes efforts pour "corriger le tir" sont vains: le déplacement de Bilou n'est pas buggué, il est juste incomplet. L'animation prévoit que l'on se déplace par pas de 2 pixels. Pas moyen d'y déroger. Si bilou n'est qu'à 1 pixel du mur, il ne s'en rapprochera jamais plus, mais du coup (cf capture d'écran), il ne saura pas sauter puisqu'il n'a pas complètement le champ libre vers le haut >_<.

Bref, pour résoudre ce problème, il me faudra une animation supplémentaire "pousser le mur" (que je pensais toutefois introduire plus tard) dans laquelle le déplacement est indépendant de l'animation (bin oui, quand il pousse, Bilou peut "patiner" sur place, ça ne gène pas). Du coup, je peux déplacer Bilou d'un-demi pixel à la fois s'il le faut pour qu'il vienne se coller au plus proche du mur ... sans y rester scotché ^^".

The 'walking' animation currently imposes that Bilou moves by two 2 pixels increments only. Whatever smaller speed I enforce at "controller" level or in the doslopes() function, they'll be accumulated until a move of at least two pixels is allowed. Of course, if you're only one pixel ahead of a wall, the move is impossible, and therefore it is cancelled. This happens at a point in the code where reasons of the move have been lost, so we're stuck in a dead-end situation. That gets even more troublesome if, such as on the screenshot, Bilou is trying to take a narrow corner: he can't move forward to align with the wall, but he can't jump until that alignment occurs.

Altogether, it looks like I'll have to introduce "wall-pushing" animation much earlier than I initially thought just to ensure that alignment to walls is possible. In such a "push" animation, I can decouple movement from animation frames and therefore I can move Bilou by half-a-pixel if needed, and noone will contest/modulate decisions made by controllers.

Les plate-formes

Le prochain "gros challenge" pour mon moteur de jeu (sur lequel je cogite actuellement, en tout cas), c'est sans hésitation les plate-formes. Tous ces objets mobiles, assenceurs, radeaux, etc. qui tout en ayant leur comportement propre altèrent celui du personnage ou agissent comme des parois solides. Bref tout une série d'objets qui vont venir perturber les belles règles de gestion des collisions du moteur de jeu.
Technically speaking, the next challenge for my game engine is platforms. Those moving objects you'll find in any decent platformer that have their own pattern and that alter the player's behaviour (and sometimes ennemies' as well) to create interesting levels and gaming experience. It's still very sketchy in my mind, in "look for use cases" stage that happens to take place by drawing gaming moments in this project -- fairly funnier than rationale UML, if you ask ;)

J'en suis encore fort au stade "conceptuel", qui est franchement sympa dans ma manière de travailler, puisqu'il s'agit de "mises en situations" à coup de crayon pour voir si la solution que j'ébauche tient suffisamment compte des différents aspects. Du style "non, on ne peut pas lier définitivement un contrôleur à une plate-forme, parce qu'il pourrait y avoir aussi des petits vers sur les champignon-ascenseurs".

Après deux ou trois tentatives peu convaincantes, j'en arrive à la conclusion que mon système "un contrôleur par état" est un peu limitatif. De la même manière que j'essaie de faire de la composition de micro-programme dans mes recherches sur les protocoles réseaux, pourquoi ne pas faire de la composition de contrôleurs dans le moteur de jeu ?

Encore trop tôt pour commencer à faire des changements dans le code, mais on dirait bien que ce genre de mécanisme qui transforme la fonction de contrôle unique en "lire_le_pad -> pousser_un_objet -> suivre_une_pente -> marcher" s'appliquerait aussi bien aux objets déplaçables ou aux pentes fixes (en plus des plate-formes mobiles). Le même micro-comportement "marcher" pourrait prendre comme "input" la lecture du pad directionnel ou la position relative de Bilou par rapport à un appleman ...

Plein de choses intéressantes, donc, que je continuerai à creuser dès que j'aurai un peu dompté la forêt vierge qui me sert de jardin.

The thinking about supporting moving platforms also questions the way i'm coding controllers, that is, a large chunk of code that does everything a specific state needs, including reading Dpad, adjusting speeds, checking that the current move is possible and make it possible if speeds need to be aligned to avoid entering walls. Such an approach doesn't let me easily alter behaviour due to a lift or a pushable ennemy.

Instead, i'll investigate the option of a chain of controllers, each of them doing only a simple action such as reading the pad, or updating speeds according to momentum. It could also be "zero speed if character pushes into the moving block's direction" or "prevent the character from falling as long as he's on a platform". Still a bit early to change all the code base, but ...

2024 #choice reality check: it worked. See the iGobController tag for the details. Obvious controllers like walker or dpad got completed by some motion-smoothing momentum or all-purpose decrease that turns any variable of your entity into a timer/counter.

Johnny Platform's Biscuit Romp

C'est toujours sympa de tomber sur un bon petit homebrew qu'on ne connaissait pas et qui vous accroche pour un week-end. c'est le cas de Johnny Platform's Biscuit Romp par Craig Forrester (ishisoft).

I stumbled upon "Johnny Platform's Biscuit Romp" game by Craig Forrester a couple of days ago: exactly the kind of puzzle platforming game i love. The goal is simple (dismantle robots to get out of there), but with enough variations between levels to make it a brain-teaser with cute graphics.

Biscuits will play a major role since you can push them around and use them as platforms or weapons to reach the goal. One level at a time, you will learn how to use them by yourself, using simple puzzle first before it gets more complicated. I especially love how Craig made it without introducing spoiling-text trying to hint you as tutorials tend to do. When you've tried everything you know your character can do and the level seems to have no solution, think out of the box: you haven't discovered all the possible moves/uses of the game yet.
Biscuit Romp a tout pour faire le bonheur d'un amateur de "puzzle platformers" comme moi : un environnement coloré et sympathique, un principe simple (éliminer les robots pour faire apparaître la porte de sortie) mais dont les variations mettent vos neurones à l'épreuve et des graphismes pas-tout-à-fait-oldskool-mais-presque ...

En déplaçant les biscuits (carrés et ronds), notre protagoniste au bonnet rouge va devoir traverser des lacs, escalader des obstacles, etc. Les usages multiples de ces deux éléments sont tout simplement épatants. Et le "wrapping" (à la bubble-bobble) sélectif (présent dans certains niveau mais pas dans tous) permet d'étendre la zone de jeu tout en gardant l'ensemble du puzzle immédiatement visible. Histoire de varier un peu les choses, Craig introduit progressivement des plate-formes aux propriétés inspirées des casse-briques de mon enfance ...

Bon, je regrette un peu les "contours noirs omniprésents", évidemment, et je n'ai pas bien compris pourquoi ce personnage fait une fixation sur les tasses, mais bon ... Si les robots sont assez esthétique, le personnage principal fait un peu peine à voir, avec son visage verdâtre et ces membres à peine esquissés. Dommage au milieu de décors si bien réussis.

Hazards and levels are varied, clever use of the wrapping makes whole level fit the double screen of the DS and keep the whole puzzle in front of your eyes. Dodging bullets is probably the hardest part of the gameplay for me -- i guess i have been too much used to those bullet-bill that can be jumped.

It's always nice to see some standalone author to come up with a game which is fun to play. This is a huge achievement per se (i have enough not-yet-ready-to-play demos of my own to value it properly), and still, i can't help thinking that a little gem could use some more polish.
The protagonist, at first, looks odd to me. Who's that guy ? how comes he's surrounded by biscuits and is so interrested in cups ? His arms and legs look a bit unfinished ... i'm sure guys at pixelation would call him a placeholder. That's a bit of a pity, because otherwise, the graphics were quite enjoyable.

Next, the sound is poor. Craig reported that he's been facing technical issues with sound hardware of the console, and i can't really blame him for this... but those voices do not match characters: neither the hero nor the robots. I'm really tempted to suggest my bross CJ to write a couple of tracks for the game and ask Craig his sources to see if i can use ntxm player for his game ... but i just lack time for this, and will hope for an update ... or another game from ishisoft ;-)
Gros point noir: la bande son. Effets enregistrés à la voix à une fréquence douteuse et pas de musique de fond (suite à des soucis techniques, dixit l'auteur qui n'en est encore qu'à son premier homebrew sur DS). C'est un peu dommage. J'aurais bien envie d'envoyer tonton CJ à la rescousse et de bidouiller les sources pour activer le xmplayer que j'utilise pour arranger tout ça :)

Beware Inkers ...

Parmi les "monstres" proposés pour la "school zone" par Pierrick, il y avait entre-autres cet encrier "qui ne blesse pas quand on le touche, mais qui envoie des gouttes d'encre vers Bilou".

Tout comme ça été le cas pour l'éponge, j'ai passé (du côté du mois de mars) pas mal de temps à essayer de repenser le personnage de l'encrier. Je savais déjà qu'à certains moments, Bilou allait devoir le pousser, et éventuellement s'en débarasser en le faisant tomber pour le briser. Mais ce qui était plus louche, c'est que dans le design de ses niveaux, mon frère me mettait à plusieurs reprises des encriers "volants" qui servaient de plateformes mobiles.

Among the 'foes' of the School Zone that Pierrick suggested ages ago, there was the inker. "He doesn't hurt Bilou when he touches him, but he throws deathly ink droplets", he wrote. So just like i've been re-designing Sponge Bop, i tried to figure out more ways to interact with the inker.

It was already decided that Bilou will sometimes have to push it out of his way, breaking it by making it fall off a book, or using its weight to activate some mechanism. In early levels, my brother used them as "floating platform" too, which somehow sounded weird by that time : foes that help you :-\

Not that the idea itself was bad, i actually love the use of koopa's shell in Super Mario Bros. serie, and the overall idea of being forced to use something dangerous to go on is what i call brilliant level design. Still, it's only a few weeks ago that i managed to find a 'logical' way for inkers to be both pits and platforms: they just need to be wide enough so that they can hold Bilou, but too narrow to really let Bilou fall into them.

Assez étrange, de se retrouver avec des monstres qui sont aussi des 'aides', mais quelque-part ça m'arrangeait. J'ai toujours un fan des koopa-troopa de Super Mario qui sont à la fois monstres et outils, et dont le maniement nécessite de prendre ses précautions si on ne veut pas être le dindon de la farce en se prenant dans les dents un "retour de carapace".

L'astuce, ici, c'était de proposer des encriers qui sont assez étroits pour que Bilou ne tombe pas dedans. Selon les instances, ils pourraient ou non envoyer des gouttes lorsqu'ils sont supposés servir de plateformes, ce qui veut dire qu'il faudra prendre ses précautions et ne pas se jeter sur un encrier avant de savoir s'il ne va pas justement balancer de l'encre. SuperFrog et Sonic sont bourrés de ce genre de détails croustillants ^_^

I can also use the amount of ink in the inker as a visual hint on its "aggressivity". Half-empty inkers should shoot less often and be safer platforms than half-full ones that will likely shoot at you all their spare time. And before you actually jump an inker for a ride, you'll have to take care of their shooting rate if you don't want to get "inked" on the fly. Sonic and Superfrog are full of these crunchy details that keeps the game challenging.
I even drew a whole room with a "floating inkers puzzle" where you have to cross a large pit from inker to inker -- which i won't show you until it is playable, of course ^_^.

Je m'étais même fait une 'salle' complète avec un dédale d'encriers qui bougent les uns vers les autres. De nouveau, je ne vais pas vous la dévoiler, hein: ça gâcherait tout le plaisir du jeu quand ce sera codé.

Et dernière petite touche sympa qui est beacuoup plus récente: utiliser les encriers comme des Geisers, soit en leur collant un bouchon sur la tête, soit en sautant simplement dedans. Ils s'immobilisent alors et projettent Bilou à toute vitesse dans les airs ...

Ca plus l'idée que leurs gouttes d'encre pourraient bien trainer un peu au sol, et que même au sol ils ne seraient pas forcément immobiles, et on commence à avoir quelque chose ded bien plus intéressant au niveau du level design ^_^

Last but not least, i might consider adding inkers a "geiser" capability -- which my brother suggests to introduce gradually. Using ever-better-hidden corks, you can "block" an inker, climb it and wait for its internal pressure to be so high that it will throw you up to the stars. And then came the idea of letting inkers wander around (they were so far almost immobile foes) and having their droplets stay for a while on the ground, surrounding the inker with deathly traps.

Let me tell you: designing and playing levels with such inkers promise to be real fun. Now let's get back to the code ^_^