Funghi vs. Appleman

Funky Funghi, un des plus anciens personnages de la Green Zone sur DS, vient de se ramasser une pomme. Jusqu'il y a peu, la pomme serait juste passée à travers, mais alors que ce blog va sur ses 20 ans d'existence, j'ai rajouté les quelques lignes de code script qui manquaient pour que l'interaction proposée début 2022 devienne une réalité: on va pouvoir dégager les champignons du chemin à coup de jets de pommes.

Throwing apples around is a bit more fun since they've started rolling when hitting the ground, but one thing has felt odd so far: seeing the appleman crossing the path of a bouncing Funghi without triggering any effect. Since early 2022, I had the idea that we could have Bilou *bouncing* when hitting the hat of Funghi rather than being hurt, and that implied of course that a thrown apple should bounce as well. It was now time to implement that.

Post by @PypeBros@mastodon.social

View on Mastodon

Ah, and yeah, I've played a good deal of the original Rayman, including throwing fist at bouncy plums and yin-yan balls to make them reach the place I wanted them to be. With all this new bounciness, Funghi is no longer just a hazard and you might actually want him to be *somewhere* rather than just wanting him away. Some of the initial ideas -- such as having the hat deflecting apples and only the foot being the target to hit if you want him moving -- quickly proved unpractical, and uselessly tricky to do, especially for a World-1 interaction.  

Bon, j'avoue que comparé aux "prunes rebondissantes" de Rayman, on est sur quelque-chose de nettement plus détendu: Funghi ne risque pas d'aller rebondir contre un mur et de revenir vous écrabouiller. Il ne reçoit que la moitié de la vitesse de la pomme et ralentit de moitié à chaque rebond. Juste ce qu'il faut pour passer d'une souche à "entre les deux souches" en une pomme. Mais ça devrait être marrant quand-même vu qu'il y a moyen de ramasser à nouveau la pomme et de la lancer une fois de plus. D'autant plus que maintenant, il va aussi être possible de rebondir sur le chapeau de Funky Funghi! (c'est peut-être encore un peu fort, d'ailleurs).

Post by @PypeBros@mastodon.social

View on Mastodon

La solution à laquelle je suis arrivé à coup de débuggeur d'expression est un rien intimidante ... entre autres parce qu'elle dérive de la collision destinée à faire rebondir Bilou, et que pour Bilou, je voulais que l'angle change selon qu'on arrivait plutôt sur le bord ou sur le centre de Funghi, comme s'il était vraiment un bumper de flipper. Pour ça, on va préparer deux valeurs et les combiner avec | dans le byte haut et le byte bas d'un entier 16-bit avant d'écrire le tout dans la 10e variable de Funghi avec :a. C'était rigolo avec l'appleman, mais ça devenait compliqué d'y ajouter le transfer d'énergie ... donc au final, pour l'appleman, Funghi agira toujours comme un mur qui absorbe 50% de sa vitesse horizontale et n'a aucun n'effet à la verticale. Et sur l'énergie absorbée, la vitesse acquise par Funghi est moitié moins importante que celle qu'avait l'appleman ce qui nous permet de calculer qu'un Funghi pèse à peu près 2 Applemen ;P

state0->state0 on found$apple [C_THROW we 0 >= w0 0 < & &]
                  (w0 2/ ~ $ff00 & w1 256 / $ff & | :a w0 4/ v0 + :0)
state0->state0 on found$apple [C_THROW we 0 < w0 0 > & &] 
                  (w0 2/ ~ $ff00 & w1 256 / $ff & | :a w0 4/ v0 + :0)

I ended up with something simple for Funghi/Apple interaction: half of the speed of the appleman (w0) is transferred to Funghi, and the other half is bounced back. But since Funghi is bigger, the half it takes only result in 1/4th of the speed. Not pushing him very far, I'm afraid. And well, that's only the part w0 4 / v0 + :0. All the things that happen before are reusing the "protocol" defined for throwing things where the thrower decides of the direction of the thrown object I already used for dumblador. The X speed and the Y speed will be set in the 10th register of funghi with :a and later used by the appleman with

$RTHROWN->$LTHROWN on hit0 [C_THROW wa 0 < &] (wa $ff00 & :0 wa 256 * :1)

Mais dans le code de l'appleman, j'ai quand-même gardé un code générique qui se contente d'appliquer le vecteur-vitesse qu'il trouve dans la 10eme variable de ce qu'il a heurté. ça pourra me permettre par la suite de faire en sorte que les branches rebondissantes puissent elles aussi renvoyer les applemen ^_^. Petite subtilité: la transition hit de l'appleman est testée avant la transition found de Funghi mais c'est found qui fournit le vecteur vitesse que hit va utiliser. c'est pour ça qu'il y a un test qui s'assure que wa < 0, pour que lors de la première frame de collision, l'appleman conserve sa trajectoire pendant que Funghi calcule l'impact. A la 2eme frame, wa est défini et la trajectoire de l'appleman pourra changer.

Et pour la collision Bilou/Funghi, c'est la distance entre le centre des hitbox (we) qui va déterminer l'angle de l'impulsion que Funghi va nous imposer, entre (-3,0), (-2,-1), (-1, -2), (0, -3) 

The idea inintially was to use the same behaviour as the one I coded for Bilou, where the angle you're bounced depends on the position you hit Funghi on. That's decided in Funghi's script with

state0->state0 on found$bilou [C_THROW we 0 >= &] (we 4/ 256* we 4/ 3 - $ff & | :a)

where we is one of the collision-specific parameter (rather than an internal variable of the collided object) containing the center-to-center distance between Bilou and Funghi, ranging from -24 to +24. At the very edge of Funghi, you'll get bounce horizontally by (+-3, 0), and at the center of his hat, you'll be bounced by (0, -3). In between, you could get (+-2, -1) near the edge and (+-1, -2) near the hat. And yup, it's got the overall expr_1 256* expr_2 $ff & | shape again to put both together in a single variable.

I still had to do something for how static Funghi looks when hit by something. My first attempt failed because transanims with characters that are made of a single sprite, and so far, Funghi was still like that. But behold, Funky Funghi 2.0, remade in AnimEDS after I separated hats and feet, so that I can animate it more freely, at in-between frames of some sort, etc.

It doubles the amount of memory it takes, but I think it's worth it. 

Il me restait un truc à régler: Funghi donne l'impression d'être en béton et que rien ne peut lui arriver même quand on rebondit dessus ou qu'on lui lance une pomme. J'aurais bien essayé de réutiliser l'animation "rebondit au sol" dans un sens ou dans l'autre, mais Funghi est toujours un "SimpleGob" premère génération, et je ne leur ai manifestement jamais ajouté le support des transanims.

Je profite donc de la p'tite canicule du week-end pour redécouper un peu Funghi dans le Sprite Editor, refaire ses animations dans AnimEDS et rajouter un "fait rebondir un truc qui arrive du haut" ainsi qu'un "fait rebondir un truc qui arrive sur le côté". Ce n'est pas spectaculaire, mais ça donne plutôt bien quand-même.

Foreground for the underground ?

Something is annoying me with the underground section of the green zone levels: it's too repetitive. It shows in every screenshot I try to make. I have variation tiles that could make it less uniform, but they don't really work if we repeat them. I have plans for a background, parallax layer underground, but it only really works in open environments, not in tunnels, and underground areas are mostly made of tunnels. in the Green Zone.

But those funny pillars might work as foreground  layer as well! Maybe even better because they're bigger than the pebbles repeating tile of ground I have. They would focus the gameplay in a smaller part of the level just like a circle-of-light would, but with something pleasant to look at. The question is, how can I make it indeed focusrather than obscure. I don't want to make Infogramish game where you don't see where you're heading to because of the foreground.

Let's ask Bouli to make a bit of math, here: if my foreground layer advances by e.g 3 pixels everytime my regular layer advances by e.g. 2 pixels, then I just have to make a map that is 3:2 bigger than the playfield if I want to follow things properly.  

I mean, my "foreground" map would be drawn over a 150% zoom up of the main map, and that should be it. At least, that's the intuition. How to confirm it quickly ? Well, how about cutting some paper to make a live overlay and make it move around. Of course, you have to consider that only a part of the result will be shown to the player, too.

Does that mean I need a special mode or a variant of the Level Editor ? ... maybe not. At least, not more than "use the "physical" layer of gac.map (move by 2:3) and let me edit gacfg.map on top of that.

The fun trivia here, is that the initial motivation was to find a way to have VRAM for textures now that I know it does not require palette slots. But while comparing the options, I came to the conclusion that I had no real use of 3D in the green zone anyway, except maybe to render more trees in the background... but checking Case Portman's Lost in Fuzz video, I realised that proper amiga-style parallax would work better than any 3D and would be easier to make here. And yes, I'm only using 2 tilesets out of the 256K allocated to the background tiles in Dreamland, so I could fit a 3rd one and another "infinimap" in the unused space ...

Does it means textured 3D becomes out of reach ? No, but that Bilou's Dreamland will sometimes use 3D, sometimes not (plain 3D does not require more VRAM, but it consumes one layer).

Does it means Yoshi-Island-Style dual screen action should be forgotten ? No, but it would only work in levels where we have no 3D objects and no fancy lush background/foreground maps.

Does it mean having Bouli or another character "telling the story" on one screen while Bilou is "living the action" on the other impossible ? No, but Bouli may have to survive within 16K of sprite VRAM, using DKC-like live-update techniques for his animations.

edit: sidequest finding: shifting extended palettes from 64K to 16K VRAM isn't that trivial to do. (but not required unless we want to texture 3D stuff)
 

Fixing unimportant things

You know you're on a hobby project when you start fixing things that are on the bottom of your priority list first because you feel ashame of their current state and there's no one pushing you to do top-priority fixes instead.

Improving the graphics of the water slide was certainly no high priority except for my eyes. Having a special "patch sprite" to allow the desired shape that needed 3 layers despite I only have 2 map layers was inevitable after that, as much as patching the color cycler to avoid half-water half-rainbow effects.

Les graphismes des pentes-à-eau présentés fin 2025 (eh oui ... déjà) avaient un truc qui ne me plaisait vraiment pas : une jonction très "carrée" entre la cascade et la pente. Un problème qui est la conséquence d'un choix dans la construction de cette cascade:

elle est constituée de deux couches de graphisme superposés. ça offre des avantages, mais ça veut dire aussi qu'à part des sprites, je ne peux rien mettre en même temps. Un problème que j'avais déjà rencontré dans le dernier niveau de SchoolRush. Problème que j'ai retourné dans tous les sens pendant les mois de janvier et février (provoqué par le même genre de problème "quelle couche ?" autour du poing écrabouilleur) avant que l'évidence ne me frappe comme un boomerang revenant de l'ère 8-bit:

rajoute un sprite.

Well, adding a sprite overlay on top of the tiles layer is hardly any innovative. In fact, it was super-common in 8-bit and 16-bit games as soon as you aimed at something visually more sophisticated than Super Mario. But no. It took me almost two months to realise that was the solution I needed here.

And took me almost as long to realise that very dark greyish stone wouldn't work in the bright-and-colorful environment of Bilou undergrounds, and that since I'd like the peaks zone to feature purple rocks, I could start introducing purple rocks as soon as the first level.

Then in a single evening, I reconstructed a draft mockup of what I wanted to see: background dirt tiles and a waterfall, then the big rock and the wavy effect (that is still to be integrated), and in a couple of hours, I repainted the rocks in a quite satisfying way.

And when I saved things, I realised I was close to 90% of tile space consumption, while there are still a good deal of things I'd like to add to the green zone. So I wrote down a note to hunt for duplicatas later and a few other higher-priority things like drawing a background screen for the underground parts... and of course, the day after, I was marking duplicate tiles and then patching them in the level maps and noting where I had alternate dirt / rock tiles that I could use to break the grid, etc. Priorities will have to wait :P

J'ai donc profité d'une soirée où ma fée était au club-créatif du coin pour aller de fil en aiguille, dessiner quelque-chose qui ne me déplaît plus, faire le montage, ajuster les scripts et rajouter le code qu'il faut pour avoir une pente qui présente bien, avant de me rendre compte que oups, je commence à avoir trop rempli ma mémoire de graphismes pour la greenzone, marquer les duplicatas, les nettoyer, etc. au point que j'ai dû retransférer presque l'intégralité du contenu graphique de la green zone (y compris les maps des niveaux) de la DS au PC alors que je vais aussi devoir faire le transfert inverse pour les scripts de comportement ^^". 

Petit à petit, le niveau se construit...

Bon, j'ai passé un peu de temps dans mes éditeurs sur DS ces derniers jours pour habiller un peu plus le premier niveau et je viens de construire une map avec le 2eme (après un moment de frayeur de "est-ce que je ne viens pas d'écraser mon gac.map en essayant de créer gpc.map ?_?"), tout ça pendant que je faisais la mise au point des portes du côté PC.

• un arbre tout à gauche pour marquer le bord du niveau
• (pour une raison inconnue, sortir de la map par la gauche conduit à un plantage de runme ... à investiguer)
• une petite pente avant le premier arbre pour rendre le niveau moins plat, valider le graphisme des pentes et faire de la place pour des plate-formes avec les petits vers dessus (côté notuto)
• il faut encore une palette alternative pour la terre dure et des images de bord pour la terre d'arrière-plan
  

I've spent some times on PC to get doors working, but also some time on the NintendoDS itself, putting more tiles around the edges of crude level I had last week. I even tried to start importing the second green zone historical map, but a blue screen in LEDS put that to an end. (possibly linked to bad handling of color palette selection in "paint" mode). It highlighted I'm lacking some darker tones for some parts of the color palette (mostly dirt) and some edge tiles for the "far away dirt"

So here's a couple of screenshots that were part of the last "Screenshot Saturday". One of them illustrating an attempt to implement the "sliding stream from waterfall" which doesn't quite work the way it should: it's too easy to force your way by quickly jumping away again and again. plus, it doesn't kick out into the water once you're at the bottom of the slope. To be investigated

• première tentative pour la cascade-glissante
• quelque-chose empèche le système actuel de nous jeter hors d'une pente avec les tiles "tapis-roulant" ... à creuser.
• correction des hitbox de Bilou qui nage pour qu'il arrête de se manger les murs à tout bout de champ
• habillage de la "cachette sous l'arbre" ... je la trouve un peu petite dans son état actuel ...

Par contre, avant la prochaine release, il faudra vraiment que je prenne le temps de dessiner une deuxième moitié au décor de fond qui convienne pour "au plus profond des cavernes sous la forêt" ...

Tomba/ponkadunk pixelstudy

"Tomba!" by Ponkadunk, published in 2019 on pixeljoint and dug by PixelProspector. A pixel art mockup of what could have been the PSX game "Tomba" if developers had not opted for polygonal textured levels instead. It's been teasing me to pixel-study it for years now, so let's give it a try. About everything in this scene is a mastery: the characters, the pick-ups, the ground ... but if you don't mind, this time I'll focus on the background and maybe the rocky ground as these are the parts in my green zone that could use some more work.

I always interpreted the background as "leaves in jungle", but if you actually go beyond the fact that it's all green, you quickly note that these are bunch of leaves here and there over a rocks background. By playing with the palette, I could spot that the greens for the rocks and the greens for the leaves are actually two distinct ramps, only sharing their darkest parts.

The rocks ramp goes from h120s66v30 to h118s79v15, with hue shifts towards h107 on the 2nd lightest shade and h123 on the second darkest. The leaves ramp goes from h93s84v33 to h103s76v20. (oh, I used a "hsv hue" layer in Gimp to tint the "rocks ramp" towards yellow so we can distinguish it better from the "leaves" ramp.

Note in the middle of the snippet that we have blade-like shapes with the rocks ramp, so likely darker leaves more than odd-shaped rocks. A reminder to not let the initial purpose of colours dictate you how you use colours when doing pixel art... not until you really have to ;)

The common darkest shade at h123s71v11 unifies the things together in a single shadow. While some elements are fully detailed over that background, other blend in and only reveal their contour with some of the darkest shades of the ramp.

The tiling of the pattern is huge -- some 164 pixels wide, which does not correspond to any hardware-friendly size, and this is no issue for a mockup.

Compared to Eagle Island or Sonic Mania background, this one has the advantage that it could fit fairly well the colour count and the memory of the "farground" in my engine.
 

gravity.flow ?

Je voulais faire tout autre chose, mais au moment de prendre le code en main, je me rends compte que j'ai une série de modifications qui n'ont pas encore eu droit à leur commit ... et que je ne sais plus trop à quoi elles correspondent.

Il s'agissait en réalité de deux modifications liées à l'eau: animer la surface (nager si bien avec un miroir en guise de surface, c'est un peu dommage ...) et faire en sorte qu'on puisse placer un jet d'eau dans une grotte. Parce que vous ne ça n'aura pas manqué de vous faire tiquer: il y a une sorte de rectangle moche au pied du geyser sur l'image ci-contre/dessus. C'est lié au fait que le geyser (tout comme la cascade) est obtenu en par une combinaison des deux couches de décor: l'une avec une animation de type "palette cycling" et l'autre avec une animation conventionnelle. Et donc pour mettre le geyser dans une grotte, il me faut deux nouveaux blocs "décor de geyser fusionné avec le décor de grotte".

After a fairly busy week and significantly busy Saturday, I wanted to try updating the Appleman behaviour, but I found my homebrew directory with different files uncommitted and changes involving binary files like maps. So I started by running the current code first on the emulator, and visit those maps to see whether there were any changes. And oh, of course. First change was animating the water line (see the mastodon video below). Second was an extra water jet in the second green map.

Quand je dis "je ne sais plus à quoi elles correspondent" (y compris une modification du code qui assure le palette cycling), comprenez "il a fallu que je fasse tourner le .nds pour m'en souvenir". Ce qui m'a donné envie d'en faire des petites captures (un jour après le ScreenshotSaturday ... pas de chance ^^"), et sur une de ces captures, on remarquait quand-même fort que le haut du geyser reste en permanence au même emplacement. Moi, j'aimerais qu'il monte et qu'il descende, pour ajouter un peu de dynamisme à la scène, et appeler à l'interaction.

See on that level editor, waterfalls and geysers are made of two layers of tiles combined. But that means you can't put a geyser over a dirt wall unless you've got tiles showing that in first place. Plus I'm using another palette slot for the dirt wall than the default one, meaning the cycling code had to be updated. That was ready for some screen-shotting. 

J'aurais peut-être pu utiliser le contrôleur "grid" de furblock, mais tôt ou tard, il faudra aussi que Bilou soit propulsé vers le haut par le geyser. Plan B: utiliser le même mécanisme de "flow" dans le contrôleur gravity que celui codé pour swim. Je profite donc que tout le setup wifi est là pour modifier le niveau et je définis un nouveau type de tile (les ^ mauves). ça donne des résultats rigolos avec Bilou, mais en réalité, ça ne marche pas: Bilou est bien ralenti quand il arrive dans le haut du geyser, il peut même remonter légèrement, mais au final, la gravité lui donne une vitesse suffisamment élevée (on peut aller jusqu'à 6px/frame) pour qu'il redescende, puisque le geyser le fait monter à une vitesse constante de 2px/frame. Bref, c'est bien pour des tapis roulants mais pas pour des geysers.

But then, the top of the geyser was very static ... I want it to wave up and down a bit. There are different ways I could do that in my engine, but only a few where not only the geyser top but also Bilou is lifted up when in contact with the stream. That implies a mechanism similar to the water flow designed last year, except this new special physics tile will define a property for the gravity controller instead. It will still be an "AIR" tile, though: we can fall through geyser, not swim them. (I hope to avoid nasty corner cases that way).

Unfortunately it didn't work the way I wanted. Lifting Bilou by 2 pixels (cyan lines on the diff) is fine as long as the vertical speed is lower than 2 pixels/frame downwards. It gives a nice boost when jumping and catches you when you're "stomping" the geyser, but while you're being stopped, your intended velocity keeps increasing, and at some point, you'll be fast enough to reach the ground again. Exactly as you start sprinting backwards on a conveyor belt.

So I ended up using the yellow code instead: directly change the polarity of the gravity based on the sign of the terminal velocity stored as a per-tile-type property. Not perfect, but close enough for now.

Mais en fait, il n'y a pas tant à changer que ça: plutôt que de déplacer Bilou, on va utiliser l'information stockée pour contraindre la vitesse maximale ... et tant qu'à faire, inverser la poussée si la vitesse maximale est négative. J'ai pris des vitesse identiques pour la gravité et le jet d'eau pour le "petit nuage" en haut du geyser, ce qui lui donne un mouvement symétrique alors que pour Bilou, la gravité lui permet d'acquérir une vitesse jusqu'à 3 fois plus grande, et il a donc tendance à s'enfoncer plus dans le jet d'eau. ça suffira pour le premier jet ;-)

edit: valeur maximale -2px/frame validée: il suffit de garder le bouton de saut enfoncé pour décoller bien au-dessus du geyser. Et si on tombe du sommet, on ne redescend pas trop bas.
 

Post by @PypeBros@mastodon.social

View on Mastodon

pixels, at last.

Une petite heure de week-end où j'ai pris le temps de me faire des petits pixels ... enfin. Après une autre petite heure plus tôt dans le week-end pour faire quelques essais de croquis.

L'écrabouilleur, d'abord, qui est la résultante de mes esquisses basées sur Ristar, des techniques proposées par Helm que j'avais utilisées pour les livres de l'école et de la réalisation que  finalement, des gants façon Mickey donneraient sans doute mieux dans l'univers de Bilou que ma propre main.

Il se trouve que j'avais déjà tenté de dessiner ma main, et j'avais la S-Team en entier et le verdict est sans appel: le nouveu design, plus anguleux, s'intègre mieux.

Finally, I managed to find 2 hours to work on the missing pixels I need for Bilou's demo. First the smasher punch, using all the observations I made while posting about my Ristar pixel study. It's more squarish (and the S-Team girls like it), it has cartoony-4-fingers look and is modeled after a cartoony glove rather than my own hand. Quite close to the sketch I made the day before. I'm still undecided about the thumb position ...

Second, the top-of-waterjet sprite. I won't try to make a tutorial of how-to-animate it: there is very likely room for improvement, but it does a fair enough job (imho) and nicely fits the style of the jet (see below for the in-game montage ;). I'll still have to make it wave up and down and make it so that the jet pushes Bilou upstream on contact.

Deuxième morceau: le haut du geyser inspiré de GoodboyGalaxy. Il faut dire que les derniers tests se déroulaient sur une map où j'ai ajouté l'animation pour la partie verticale du jet ... et bon, voir le jet se terminer par une ligne nette comme ça, ... ça picotte aux yeux.

Je ne suis pas franchement au niveau de hot_pengu, mais je crois que ça devrait faire l'affaire malgré tout (NB, c'est plus fluide en vrai sur la DS).

Goodboy('s geyser) was here

J'ai quand-même commencé à tenter de dessiner un jet d'eau. J'avais lancé un appel sur twitter, pour essayer de trouver des références. Il faut dire que les cascades de l'époque 16-bit étaient encore plus convainquantes que les jets d'eau de la même période.

J'ai eu une réponse en or, du genre de celles que j'ai eues pour les arbres l'an dernier. Le temps de faire le point, et je vous raconte tout ça ;)

"I can't draw convincing water jet from below" did not sound like a very convincing reason for not using a water jet if it is the proper game mechanic to use. I finally have a good one to pixel study and started doing my own, as you can see on the photo, but allow me to rewind and start where it started.

Un pas en arrière pour revenir à l'époque 16-bit. On préférait souvent éviter d'avoir de trop grosses animations à gérer sur ce genre de machine, et animer de l'eau se faisait généralement avec un dégradé et une modification cyclique sur la palette de couleur (palette cycling). Le foncé devient blanc pendant que le clair devient foncé, le très clair devient clair et le blanc devient très clair...

Back in the 16-bit era, it was frequent to do color cycling to animate a waterfall. Sometimes it worked nicely, sometimes it was so-so. It works best if the raster is long enough and if the animation speed remains movie-quality. At cartoon-12fps, you start seeing as flashing more than falling down water.

But you'll note the bottom of the waterfall is often missing in those scenes. And when you look at the few game art that tried having upwards water jet, you understand why: it no longer works. We expect water to become darker with density increase. In a waterfall, vertical density variation are interpreted as downwards waves, but when water eventually widens up in a fountain-like mushroom cap, it is always more dense at the center and less dense on the "edges". If you do palette-cycling here, you break that.

ça donne une illusion potable de cascade, pourvu qu'elle ne soit pas trop grande et que la vitesse d'animation soit réglée au millipoil. Et si possible, utilisez plus que 4 couleurs pour le cycle, parce que sinon on se retrouve avec quelque-chose comme le décor de Yoshi's Island qui tient plus du clignotement que de l'écoulement d'eau. 

Et malheureusement, la même stratégie est appliquée dans les (nettement plus) rares jets d'eau de l'époque. Je dis "malheureusement" parce que pour un jet d'eau, on va forcément devoir aussi animer le "chapeau de champignon" qui va avec, pour lequel la surface animée est encore plus grande. Et l'effet clignotement encore amplifié. On l'a déjà dans Bubsy, où les pixels isolés clignotants ne parviendront pas à faire oublier le fait qu'ils sont statiques. On l'a dans le final de Link's Awakening et dans le jet d'eau d'un jeu obscur avec la mascotte du Mac Do.

In Bubsy, for instance, the artist sprayed out the water pixels as the water starts falling down. This is coherent with the style, but animating them will just give you blinking static pixels of water. And the stylized 'mushroom cap' used in Link's Awakening and Mac Do game flashes even more aggressively.

Là où ça coince tout particulièrement avec le "champignon", même quand on évite les pixels statiques, c'est qu'avec ce type d'image, le clair et le foncé ne sont plus interchangeables. On voudrait que le bord soit plus clair parce que l'eau y est plus éparpillée. Faites-y du palette-cycling et vous aurez des images qui donnent l'impression d'être en négatif.

J'avoue que je trouve un peu dommage qu'avec les resources graphiques de la SNES, on en soit réduit à ça pour animer l'eau. Mais il faut reconnaître qu'en misant tout sur de la RAM vidéo, la console n'a plus la possibilité de reprogrammer les plages d'adresses (bank switching) pour faire des "animations gratuites" comme la génération 8-bit. Toute animation va impliquer un transfert DMA vers cette VRAM et le budget pour ces transferts est limité (comme toujours).

Truly, the "cap" of the fountain/geyser needs dedicated animated tiles, but we're unlikely to see that on 16-bit engines. 8-bit machines could have done that with more ROM and evolved mapper chip, but 16-bit consoles no longer try to pull pixels directly from the ROM. They put them in dedicated video RAM, and rely on DMA channels to bring animation frames in due time. But the amount of pixels you can transfer per frame is limited. Animating Bubsy's geyser that way at 60fps would consume 25% of your animation power:

On NTSC with overscan mode turned off, there are 262 - 224 = 38 scanlines in vblank. Subtract one scanline for prerender time, and you may end up with 165.5 * 37 = a smidge under 6 KiB per vblank.

6K, sur SNES, c'est 46 blocs-question de Super Mario World. Animer quelque-chose de la taille de la fontaine de Bubsy à 60fps, ça demanderait donc 1/4 de la puissance dans la partie critique du moteur de jeu.

Bon, et après l'époque 16-bit, alors ? Du côté de Super Princess Peach, par exemple, qui est plutôt réussi côté pixel art ? Un jeu ou pleurer est une mécanique de jeu, il doit bien y avoir des jets d'eau dedans non ? 

So, well, my game is not for a 16-bit system anyway, so could there be any water jet pixel art for 32+ game that I could study instead ? Say, in Super Princess Peach ? A game where you cry waterjets sure should also have some geyser-like elements, right ?

Well, it does indeed, in Wavy Beach 2. It uses a "cone" of water that might be animated through color cycling plus a "flower" top that follows the rule "keep the center dark and the edges light". But even then, I don't find it appealing, and I don't see how I could make it match anything but the super-stylized environment of SPP.

Eh bien oui, en effet. Dans le niveau 2 de la plage. Mais je dois bien avouer que je ne suis que moyennement emballé par le style. On a un premier élément (le cône) qui utilise un effet de palette qui ne fonctionne pas trop mal, les traîts latéraux restant sombres en permanence. Puis on a cette "fleur" qui grandit et rétrécit, gardant toujours le sombre au centre et se permettant des éclaboussures au bord des "pétales" sur la dernière frame.

Mais ... bof. Même en corrigeant le truc pour que la princesse apparaisse par-devant la fleur, ça ne me convainc pas. Oh, ça marche plutôt bien avec le reste de l'esthétique stylisée de SPP, mais ce type d'animation dans Bilou ? Pas convaincu.

Et depuis ? Parce que bon, le modèle pour la cascade de Bilou, il ne date pas de 2005. Mais le truc, c'est que j'ai surveillé les cascades en pixel art pendant pas mal d'année, sachant que j'en aurais besoin tôt ou tard. Alors que des geysers, c'est plutôt un truc de dernière minute.

Et c'est là que hot_pengu, l'auteur de Goodboy Galaxy, m'a pointé vers la vidéo de son jeu sur GBA

And so I finally asked hints to people on twitter who might have seen something I could use as a reference, or ever proper keywords to search for one, and to my surprise, I received an answer from indie game developer hot_pengu:

We call it a 'geyser' internally for goodboy, and this (timestamped vid) is how we represent it.

Je jette un oeil, je prends un petit screenshot pas fou mais qui pourrait donner un point de départ, et là,

Here's a better look, if it's useful! (there's two versions, one comes out of a monster)

He added as I posted a quick snapshot for future pixel study, handing the Goodboy Galaxy spritesheet with 2 sizes of exactly-what-I-needed material that you see printed on the top photo. 6-frame stunning animations, with tileable base and stylish top. Even the style isn't that different from the one I have for my waterfall!

Une animation pixel-art moderne, tout en fluidité et utilisant bien les 6 frames, qui peut être étirée en hauteur comme on veut ! C'est celle que vous avez vu tout en haut de cet article, imprimée et que je suis occupé à étudier. Parce que là, j'ai bien mieux qu'une référence pour donner une seconde chance au cas du bouchon: j'ai une idée.

Voyez, ce geyser, je peux le placer au fond du trou, directement, sans avoir besoin de bouchon. Il bouge, il attire l'attention. Pas moyen que le joueur ignore sa présence. Il a un look quelque-part entre la plate-forme et le bumper ... on pourrait toujours sauter dessus, on ne sait jamais. 

I like how it simply requires the player to hop into the proper spot to trigger. Much cleaner gameplay than the "pull the cover" I had thought about, but it remains interactive. Plus, by being already flowing before we interact, there's no more questions about "where does this water comes from, where does it goes afterwards", etc.

Deuxième bon point, une fois que Bilou a sauté dessus, je peux réutiliser le type de comportement que le joueur rencontrera plus tard avec Inkjet: Bilou reste "coincé", la pression s'accumule et wouf! on est projeté vers le haut.

And that would match the way 'inkjet' monsters will lately be used as delayed bumpers in the School Zone ... Since this game will no longer feature a welcome screen with the inkjet, it's a good thing the player can be shown early what happens after the "caught in a boiling pot" animation.

Et si il a raté son premier saut, il peut retomber sur le "chapeau" du geyser et re-sauter de là.

Mieux encore: si le joueur n'est pas resté dans le geyser jusqu'à être projeté, on peut le pousser vers le haut s'il entre en contact avec le "pied" du geyser. Et si rien de tout ça ne se produit, on peut directement réessayer la même manipulation. Pas de risque d'aller se coincer en nageant, de faire redescendre l'eau trop tôt ou quoi que ce soit de ce genre.

Bref, j'avais pensé vous redessiner *mon* geyser sur DS pendant la petite semaine de vacances, mais au final, j'ai juste eu le temps de faire une petite feuille de notes pour illustrer ce que j'imagine comme mécanique avec mon geyser ... parce que les vacances d'une famille 11 + 15, ça ne ressemble pas vraiment à la dynamique 8 + 12 et ses plaines de jeu à surveiller :-P

I expect that the platform-look of the geyser top will invite even the younger players to jump on. I expect that its animation will catch their attention much more than a purple block or handle. Should they fail to use the bump effect to reach the key, they can be caught by the platform-top and jump again. If they jumped out before the geyser happened, they can jump into the flowing geyser and be pushed up to the platform-top. It's flawless ^_^

Now I just need to find enough time in the upcoming evenings to complete it ^^"

PS: if you want to animate something like that, consider animating it without the vertical motion first: just the wobbles and the sparkles, and only then apply the vertical shift to each frame. Unsure I will follow that advice myself this time.

'faut pas pousser!

Vous êtes devant une porte verrouillée au fond d'un tunnel. Il y a un trou rempli d'eau sur le chemin menant à la porte, alimentée par une chute venant de la galerie supérieure. Votre sens de l'exploration vous sussure que la clé pour la porte doit se trouver dans une des galleries supérieures que vous avez aperçues durant votre chute. Vous pouvez sauter avec (A) et ramasser des objets moins lourds que vous avec (B), mais la galerie supérieure est trop haute pour que vous puissiez l'atteindre en sautant.

Bon, vous l'aurez compris, je suis à la recherche d'une alternative pour le niveau 1-1 de Bilou qui ne dépende pas d'une action a priori peu maîtrisée à ce stade comme "pousser un bloc". Mais j'ai quand-même envie que le joueur ait la sensation de s'être tiré d'affaire, pas juste d'avoir fait demi-tour.

Ayant tout juste rejoué à DK Tropical Freeze, ma première idée était de mettre un gros bouchon au sol et de le retirer avec (B). Si il faut, on pourrait même faire en sorte que le bouchon dépasse un peu et qu'il laisse passer une goutte de temps en temps, pour attirer l'attention du joueur. Sauf que ... dessiner un geyser, c'est plus facile au bic qu'en 256 couleurs ... l'animer, c'est plus facile dans la tête du lecteur qu'à l'écran... Et ce n'est pas l'époque 16-bit qui va m'aider, cette fois-ci. >_<

How do you get yourself out of a hole when all you can do is JUMP and GRAB but you cannot jump high enough ?Maybe you're lucky and there's a plug-like think holding water that was just waiting for you to spring out. That would save me the trouble of needing to code raising water level and making the player confident that they won't drown if they fill the room with water ... But I have no idea how I could make a convincing geyser and '90s pixel art really does not help this time.

A supposer même que je trouve des graphismes concluants, et si le geyser a l'avantage de ne pas demander de jouer dès le niveau 1 avec de l'eau qui change de niveau, il reste un problème physique: il faudra que je trouve un layout qui explique que l'eau du geyser monte alors que l'eau du "puits" non.

Est-ce qu'on pourrait s'en sortir avec le bouton de saut ? C'est quand-même la mécanique de jeu n°1 ... On pourrait donner un coup de tête dans un truc ou tomber sur un machin qui ferait apparaître des plate-formes (disons des feuilles depuis des lianes, pour rester dans le thème de la forêt) puis sauter de feuille en feuille pour se tirer d'affaire.

Mais j'ai le même soucis qu'avec les Ethers en 200x: c'est un comportement de sale garnement et je voudrais que Bilou reste un personnage exemplaire (malgré son caractère ronchon). (De nouveau, le lecteur attentif sentira l'influence de DKTF et de ses plate-formes rangées contre le mur qu'il faut faire basculer à l'horizontale ... mais dans l'autre sens)

Could there be anything that would trigger a useful event if jumped on ? Like making buds bloom into leaves large and strong enouh to be used as a platform. But unfortunately the only such trigger I could think of imply that Bilou is hurting the target and that pain is the thing that forces blooming. I'd rather not have Bilou do such things if I can avoid it.

Par contre, l'avantage de cette idée, c'est que comme j'ai l'intention de permettre à Bilou de s'accrocher en appuyant sur (B) en l'air, on peut remonter soit en combinant attraper/sauter, ou en utilisant le "mécanisme" pour faire apparaître les feuilles. (détail sans importance puisque le joueur un poil rôdé au jeu n'aura pas oublié d'aller chercher la clé en premier)

Mais sinon, il y a une alternative plus sympa, inspirée du "dragronce":

Dans un recoin obscur, vous remarquez une sorte de tête, mi-crocodile, mi-végétale inconsciente et a l'aspect desseché. Vous faites immédiatement le rapprochement entre la texture de son "cou" et celle des lianes qui sortent ça et là de la paroi

 But maybe there could be something that can be grabbed and carried around to produce the same effect. Like the head of a thirsty dragonthorn, since there's water just nextdoor. That would be nice from Bilou to bring them into water. Might be a bit tricky to draw too ... even with pencils, I'm not convinced by those sketches... and it's a bit ... convoluted.

On peut ramasser sa tête comme les autres objets... on peut l'amener jusqu'au point d'eau pour qu'il reprenne des force et que ses feuilles se changent en plate-formes. La bonne nouvelle c'est que ça fonctionne même si le joueur n'a pas encore compris que B=ramasser et pas B=frapper.

Et avec le saut comme mécanique, est-ce qu'il n'y a pas moyen de faire quelque-chose qui soit sympatique ? Disons qu'il y ait une grosse racine qui soit juste un poil trop haut pour profiter de toute cette eau pour grandir, hein ? il suffirait de lui tomber dessus pour l'enfoncer un peu, elle se réveille, elle boit, les feuilles repoussent. C'est simple, c'est visuel, c'est le bon plan. Non ? 

'bin pas forcément si j'en crois mon frangin... lui, en tous cas, il n'a pas franchement accroché à cette approche.

Or maybe there could be something that wouldn't mind being jumped on and yet make the leaves bloom? Like a big fat root just about to reach water? It would actually be friendly and helpful to push it into the water just enough so that it could come back to life, bloom, etc. Well, I thought I had the perfect solution here until my brother seemed unconvinced.

Bon, qu'est-ce qu'il me reste ? En fait, dans le design d'origine, il n'y a même pas ce genre d'ascenseur interactif à mettre en marche. Le frangin, il avait dessiné un tuyau, une chute d'eau alors qu'on est déjà un demi-écran en dessous de la galerie supérieure, une pente-qui-pousse avec l'eau qui dévale et qui nous entraine jusqu'au bassin Est.

Celui qui n'a pas la clé n'avait qu'à penser à aller dans l'eau et prendre le téléporteur si tant est qu'on ait de l'air jusque là ... ou mourir et recommencer.

That brought me back to the original level design from my brother, only to realise that there was just nothing to help you climb back and get the key you need. Actually, he did even put one-way-watery-slope (inspired by Sonic's Labyrinth zone ?) to push the player into dive-or-door decision. If you dive, you'd have had limited time to locate the teleporting device that brings you back overworld where you could try a better route and find that key.

I don't think it could be used as-is in a modern game (and I want Bilou's Dreamland to feel modern) but since I now have waterflow tiles, I could definitely have some spot reachable from the water surface (Bilou can't dive freely in this game) where you're swallowed by a stream bringing you back where the teleporter would have dropped you. I think I'll have that anyway. But not just that. 

Pendant tout un temps, pour la reprise du niveau, c'était hors de question parce que mourir, c'est has been et que l'eau nous fait flotter, pas couler, donc pas question d'aller explorer le fond des choses avant d'avoir débloquer le bon pouvoir (metroïdvania avant l'heure).

Mais là, maitenant, j'ai des blocs qui permettent d'envoyer le joueur à travers un courant forcé ... je peux donc prévoir qu'une petite partie de ce bassin serve de départ pour une trajectoire "remontante" vers l'emplacement prévu pour la sortie du téléporteur "ah ouais. Comme dans Bubsy" ajoute mon frère.. visiblement, cette stratégie-là, ça lui parle. Je tâcherai donc de la mettre dedans, mais j'aimerais quand-même avoir une alternative plus directe pour le joueur qui a envie de trouver la "solution" plutôt que de contourner le problème.

Dragronce

Petite fantaisie que je m'étais permise en 2009, peu après la révision des "berry bats". Publiée sur le blog-dessin, mais qui pourrait être utile d'ici le prochain post ... Quand-même une pointe de fierté pour l'avoir dessiné avant l'arrivée de Rayman Origins dans lequel il serait tout à fait à propos.

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.