using around

I know it sounds like a detail, but trust me: if your game is lacking a "navigate around the corner of a block", it will significantly impede the gameplay. In some kind of games, it may even *ruin* the gameplay

I did not have it in Bilou RPG, and that meant you would be stopped as soon as your character slightly enters a solid tile. Sure, you can reduce the annoyance by making the box of your character smaller than its appearance on-screen.

You can also keep moving along one axis if the other is impossible. That's what's happening in the 'tutogit' demo, but you can spot times where the character suddenly stops and must be pushed again in another direction. It doesn't feel like how a professional game would behave.  

Super Mario World repousse Mario d'1 pixel par frame si le joueur est un peu trop proche d'un bloc lors d'un saut, autorisant jusqu'à 4 pixels de "débordement" avant de faire rebondir Mario plutôt que de le rediriger. ça n'a l'air de rien, mais c'est le genre de petit détail de gameplay qui fait qu'on peut se permettre des niveau un peu plus chauds sans réserver pour autant le jeu à une élite de speedrunners surentrainés. C'est ce qui faisait en '90 la différence entre Super Mario Bros et Great Giana Sisters.

C'est le genre de subtilité que je n'ai pas pu me permettre avec mes jeux BASIC et qui faisait pester les testeurs potentiels parce que le saut s'interrompait net alors qu'il passait presque. Le genre de subtilité avec lesquelles RSD Game-Maker ne s'embêtait pas et qui explique que Badman puisse filer le long d'un plafond défiant la balistique.

Le problème existe toujours avec GEDS, que ce soit en stoppand net le père Noël de la démo git ou en vous freinant pour rien pendant une ascension périllieuse dans le niveau secret de School Rush. Et donc, depuis aussi loin que j'ai un cahier-agenda, j'ai une page avec une petite note sur ce qui pourrait permettre de se coder ça pour le prochain jeu Bilou. Une page généralement couverte d'interrogations et assez pauvre en idées...

So as you can guess, I'm trying to find a solution to make that work with Bilou in my next game, but to be honest, there haven't been many ideas on the many pages dedicated to the topic in my notebooks. Then two things happened more or less on the same month. I've watched Wye's video showing the interaction points for Super Mario World and I got the idea of having a dedicated state for navigating around a block in my game engine. Which came first, I couldn't really tell any more. Unfortunately.

See, the idea so far was to have an around controller that would be part of the chain of micro-behaviours when Bilou's jumping. But what if we keep that chain unchanged, let the FAIL condition happen, and then check the testpoint and decide whether we could try moving around the blocking ceiling or not.

Mais ça va peut-être enfin changer si je prends le problème par un autre bout: plutôt que de faire un contrôleur qui anticipe la collision et déplace le joueur pour éviter que le contrôleur gravity ne signale un échec, je pourrais utiliser un contrôleur capable de nous diriger pour nous remettre dans l'axe après que la collision ait été détectée.

Une fois qu'il est à nouveau possible de monter, le contrôleur around nous en informerait par un évènement et on en profiterait pour restaurer la vitesse de Bilou au moment où il avait cogné le bloc.

We wouldn't try moving around if a testpoint located above Bilou is in a wall. That's the equivalent of Mario's head interaction point.

• The new controller would tell us whether to align left or right by acting instead of the dpad controller.
• It could report a failure if we're too far away for alignment or if we still cannot keep jumping after alignment happens -- that never happens to Mario because he's a bit narrower than one (16-pixels) block, but tiles in Bilou's world are 8x8.
• It wouldn't have to compensate for vertical speed or gravity because you'd use it in a state where gravity does not apply.
• It would fire an event once alignment conditions are met 

Granted, the behaviour will not be frame-perfect that of Super Mario, but it could be satisfying nevertheless, so it's worth giving it a try, imho.

Chose amusante: le point de "repousse" se trouve au niveau du nez de Mario. Notez que même une fois réaligné, le sprite déborde toujours par-devant le bloc. Et le point qui teste si sa tête a rencontré un bloc est pile entre ses deux yeux.

Bien sûr, avec l'approche que je propose, on aura pas le même comportement à la frame près: Bilou marquera un temps d'arrêt le temps qu'on le repousse. Il faudra tester ce que ça donne pour voir si c'est gênant ou non. Au pire, on ajustera un peu avec l'animation ...

So why reinventing the wheel, you wonder ? why insisting on using cando() while interaction points make things simpler ? well ... because the wheel of Super Mario World is far from being flawless. The gameplay it leads to may be an ideal to reach, but the quality of implementation belongs to the past.

Mario in Godot

Refaire Super Mario World dans le game-maker "Godot" ... j'ai envie de dire à la fois "tout ça" et "rien que ça". Pourtant, l'idée de Wye n'est ni de proposer un Mario World Studio ni son Mario World 3. L'idée, c'est de comprendre le fonctionnement du jeu d'origine en le reconstruisant dans un nouvel outil tout en apprenant l'outil lui-même. Et ça, ça me parle. C'est le genre de bouquin que je dévorerais mais ici, ce sont des vidéos youtube.

"In Super Mario World, Mario was considered fully underwater if both his head and body interaction points are touching water tiles. [...]

That's the kind of things you can learn by watching Wye's series on re-making Super Mario World in Godot, and learn how to use Godot in the process

I've been following the videos roughly since episode 1 or 2, but as Wye now address the water physics, I cannot just remain a silent watcher. I've spent too much time working on water physics myself, and I need to compare the approaches. Of course, Mario isn't using the "cando"  function. Instead, interaction with the world are guided by "interaction points" which remember the type of tile they're on. So for instance, 

"When Mario body is in the water but not his head, that means he is near the surface."

Du point de vue des collisions avec le niveau, Mario n'est pas une boîte. Il est ... une sorte de constellation de points qui ont chacun leur préférence sur le type de terrain 8 en tout, mais dont certains ne seront évalués que dans certaines conditions. Pour déterminer s'il faut nager ou non, ce sont par exemple ce sont les tests du milieu et de la tête qui entrent en ligne de compte. Et pour déterminer si on peut sauter hors de l'eau ? Bin il faut que le corps de Mario soit dans l'eau mais sa tête hors de l'eau. On évite en fait les complications du type "la surface est à la fois de l'air et de l'eau" dans lesquelles je me suis embarqué.

And only when Mario is near the surface is it possible to jump out of water ... and only if pressing UP in addition to pressing the JUMP button ...

The concept of interaction points comes from the disassembly of SMW itself and was discussed in an earlier video. They replace hitboxes when it comes to interacting with the world and there are 8 of them for Mario. But as usual with 16-bit games, not all points are tested on every frame. What is interesting is that rather than testing e.g. "left side" when moving left, the game tests "left side" only if the left side is "smaller" than the right side, as a way to detect "new" things, assuming that what covers most of Mario's box has been tested in the past. "When Mario is on the right side of a tile, the two points on the left are ignored" is possibly a better way to describe what happens, indeed ^^".

I'd be curious to find out to what extent that keeps working where your level grid isn't exactly one hero wide ...

edit: while you need to *press* the jump button to make Mario jump when he hits the ground from a fall, you just need to be *holding the button down* when reaching the water surface to trigger "jump out of water".  (from the "extra bits")

MainFrames by Assoupi

Il y a longtemps, sur pixelation, un artiste nous a posté une animation d'un écran d'accueil d'un micro 8-bit, sauf que après avoir clignoté quelques fois, le curseur s'ouvrait et laissait sortir un petit personnage qui se baladait parmi les lignes de texte comme si c'étaient des plate-formes...

Alors vous pensez bien que depuis, trouver une manière de mettre en scène un curseur (pointu ou en forme de main) ou une petite diskette, ça s'en va et ça revient dans ma tête au fil des années. Alors quand je tombe sur la vidéo de lancement du jeu MainFrames, j'ouvre des yeux comme des billes façon "The Mask" ... 

Since that day where somebody on pixelation made an animation with a small character getting out of the "READY" blinking square of an 8-bit welcome screen, I've been toying with the idea of making a cursor-like / handcursor-like / floppy-like character. And there comes MainFrame, a game where you play a little floppy within the GUI of a multi-computer system, just as if it was a personnal gift to me.

Un p'tit personnage tout sympa, animé avec un brio plutôt rare, dans un monde qui rappelle l'esthétique des premiers systèmes Unix à Montefiore ... Des clins d'oeil au monde de la programmation, une véritable appropriation de la terminologie un peu bizarre de ces systèmes ... et un guide en forme de gros pingouin qui vient vous rappeler de faire marcher un peu vos neurones quand le jeu détecte que vous "calez" sur une difficulté. Ajoutez-y une bande son 9-bit sans faux pas, et vous avez là un titre à ne pas manquer.

Every artistic aspect of the game is wonderfully implemented. Visuals, animation, soundtrack. Plus you get winky references to programming and system operation every here and there, giving life to the most surprising terminology of computer science, like those "daemons" operating contraptions and wandering around or the huge penguin (officially the interactive manual of the system) that will give you hints when you're stuck in a specific screen.  

Voilà donc: c'est un jeu développé en France, et on ne va pas se mentir: c'est à peu près autant un die-and-retry que Meat Boy, mais dans un univers où le sang n'est pas nécessaire. C'était dur, mais j'ai adoré tous les petites référence et l'histoire de l'équipe en trame de fond, racontée à travers les fond d'écrans et les "emails" échangés.

C'était dur, et pourtant j'ai été surpris par la qualité de la maniabilité. Voyez cet écran: à un moment, il va falloir escalader par wall-jump les parois verticales puis atterrir sur la tranche de ces barres. Oui, sur une surface deux fois plus étroites que votre personnage. Eh bien on y arrive! et sans trop de difficulté, encore bien -- en tout cas comparé aux essais-erreurs qu'Ori and the Blind Forest nous imposait dans ce genre de situation :P

La clé pour rendre ça plus fiable, c'est un système d'auto-contournement d'obstacle assez poussé qui fait que si vous arrivez un peu court sur un saut (la plate-forme dans les dents), votre perso escalade automatiquement cette dernière pour atterrir dessus. 

Gameplay-wise, MainFrames remembered me of Super Meat Boy, without the uncanny blood. I tried numerous times, I failed a little less, I managed to chain improbable timed jumps and flips (not quite a double jump, but still significantly enhance how far you go) to challenges that seemed impossible at first and occasionally skipped 2 final rooms using the accessibility features because, hey, the goal is to have fun, not to get mad.

I've been assisted by the "workaround" mechanics of the JUMP move, that will make you auto-climb on corners when you bump into one, meaning that climbing and standing on those vertical black bars is actually comfortable (unlike in Ori and Whipseey). And I've been rewarded by improbable but memorable places like this coffee machine that would have been a perfect heal spot if the game had hitpoints.  

Il reste une dernière mécanique de jeu que je n'ai pas encore abordé: le déplacement de fenêtres. C'est un thème qu'on a retrouvé pas mal dans des petits jeux flash ou dans des titres de game jam ces dernières années: puisque le jeu se déroule sur un écran d'ordinateur (littéralement), on va pouvoir déplacer, agrandir, rétrécir, etc. certaines plate-formes comme on déplacerait/... des fenêtres à l'écran. ça se fait ici au 2eme stick pendant qu'on contrôle son personnage au premier stick mais surtout, c'est merveilleusement bien intégré. Aucun risque d'en venir à "bah, pourquoi sauter: je vais juste bouger la fenêtre" parce que les autres objets à l'écran vont contraindre les déplacements possibles. Et parce que c'est le niveau actuel, pas vous, qui dicte quelles fenêtres peuvent jouer un rôle et lequel. Et parfois, c'est en marchant vers la droite que la fenêtre s'étire, etc.

One last interesting gimmick that the game brilliantly executed, is that of "moving level parts as if they were things in a GUI". We've seen that in Flash games and jam entries before, but for the first time (afaik) it is integrated into a full-sized quest without breaking the core mechanics (jump) and finding the perfect balance between the move-stuff puzzle times and time-your-jumps skill times. Part of why it works lies in the fact that we've given restricted control, on a room-by-room basis. At one place, you can freely move one window (as long as it doesn't bump into something else), at another place, you can shrink some, sometimes you must use triggers to switch between which one to manipulate as you hop from title bar to title bar and sometimes you use GUI powers to guide another daemon to its escape pod lift. Refreshing.

Un tout grand merci et un bravo à l'équipe de développement d'Assoupi. 

'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.

Input Buffering.

Tout est parti d'un tweet de Case Portman, auteur du jeu "Flynn, Son of Crismon" dont je suivais le développement dans lequel il nous expliquait en quoi le "jump buffering" est fondamental dans tout jeu de plate-forme. Un nom un peu barbare pour les francophones qui consiste plus ou moins à faire du voyage temporel avec votre manette de jeu.

Quand le joueur est au sol et qu'il fait sauter son personnage, on s'attend à ce que le saut soit pris en compte à la frame exacte où le bouton est enfoncé. Pas trop difficile. Supposons que le joueur veuille rebondir sur le sol en finissant un saut. Il sera assez fréquent qu'il appuie sur le bouton de saut légèrement avant de toucher véritablement le sol. Son intention est de rebondir. Le code peut faire deux choses: soit ignorer la demande de saut vu qu'on est en l'air, soit effectuer un saut dès que l'on atteint le sol. Et clairement, les jeux qui suivent la première approche sont désagréables pour les joueurs.

In my notebook for 2022-2023, I had a small page about Case Portman's post on Jump Buffering (link recovered, thanks, search Engine :P), where the author of "Flynn, Son of Crismon" explains:

It's a nifty little feature that will add *a lot* more flow to your game. This can also be applied to almost any action! Shooting, melee attacks, dodge rolls, even menu selection.

Don't let the name frighten you: what it truly means is that you're time-traveling with your  DPAD, pretending than your jump button presses did not happen when they did. If time was a photoshop/gimp layer, then jump buffering would be something like "snap to guide". He went on with a detailed and beautiful gif animation showing how to achieve that and make the game more tolerant on the case where player is about to land on ground and press the jump button in one of the last few frames mid-air. Many 8-bit games failed to do so and feel unfair when played.

Dans mon moteur de jeu, tout celà est pris en compte par le contrôleur "dpad". Pour chacun des boutons, ce contrôleur retient si le bouton était déjà enfoncé lors de la frame précédente, et pendant combien de temps encore il doit être considéré enfoncé. La fenêtre de temps autorisée (6 frames, soit 1/10eme de seconde) sera la même pour tous les boutons. Je me suis refait un petit schéma de la manière dont c'était géré parce que je l'avais complètement perdu de vue. "to[i]" sur ce schéma, c'est le timeout associé à un bouton donné.

I realised then that how my engine does this slipped out of my brain: it was about time to document it and blog it. It all happens in the DPAD controller, where a counter will be started if a "new press" is detected and reset if the button is released. The counter is decremented every frame while you're holding the button. But earlier tests in SchoolRush shown that this is not enough. In some part of the character behaviour, we actually *must* indicate directly whether the button is still pressed. Without that, there's no such thing as "keep jumping higher as long as player holds JUMP button" or "keep floating as long as player holds JUMP button". My engine handles that with a bitmask that indicates which button should report "pressed" instead of "held".

Par contre, on peut définir état par état quels sont les boutons pour lesquels on veut un mécanisme du type "enfoncé il y a au plus 1/10eme de seconde" et ceux pour lesquels on veut "maintenu enfoncé depuis aussi longtemps  qu'on veut. 

Quand on définit "MOVE + FOOT" pour l'état "flotter" (dans les airs, façon super-cape de SMW), ça signifie que le DPAD et les boutons de sauts ne passeront jamais par "decrease timeout". l'état "chevauchée d'éponge" évitera quand à lui de faire expirer "MOVE + HANDS". Et pour tous les états où on a rien précisé, c'est le DPAD et la gâchette droite (qui sert de déclencheur pour la course) qui seront maintenus.

But watch the catch: while the controller code defaults to 'held', the script instead indicates which inputs are expected to be "held", and defautls to "press" ... that's why you see 'using dpad(MOVE|FOOT)' for the FLOAT state, where it prevents the press to expire while floating.

Funky 2.1 / A bridge to fun

Il y a bien longtemps (wow. 11 ans!), j'envisageais de faire un niveau vertical plein de Funky Funghis mais je voulais aussi quelque-chose qui soit plus original que la caverne aux champis de Commander Keen... Peut-être en utilisant un levier comme dans la BD.

Sauf que ... j'essaie que la forêt donne la sensation d'un environnement pas trop artificiel. Quelques statues, ok. Un puit, passe encore. Mais des planches-levier-d'acrobates ? J'aimerais autant pas. Bilou qui transporte des cailloux et des planches pour fabriquer lui-même le levier ? Je vais perdre les joueurs en route.

Back in '93, my brother had drawn a jumping mushroom, directly inspired from the Shadowlands of Commander Keen, and placed a few in the Green Zone. Back in October 2000, it became "Toadstool", the first ambiguous character, that is not 100% a baddy, but still not 100% friendly either. In February 2009, it became "Funky Funghi", and in 2012, as I tried to make it an area with plenty of them, again drawing inspiration from the Cave of Descendent of CK4, where we'd sometimes have one appearing from the top of the screen, sometimes have one catching our feet from below, and so on. There was also some places with something acting like a teeterboard, where Funky Funghi's siblings would (unvoluntarily?) help Bilou by propelling him upwards as they bop around.

J'ai tenté d'autres approches, inspirés par l'une ou l'autre vidéo let's play (mais j'ai oublié lesquelles ^^" de l'excellent Tiny Thor à venir), comme cette gelée/résine dans les branches d'arbres ... d'un point de vue purement mécanique, ça pourrait faire l'affaire. D'un point de vue intégration dans l'univers ... euh ... bof bof.

There was such teeterboard in the webcomic, and it is unclear where it came from. Bilou uses it for revenge. That could have been something Bilou made up on purpose.. who knows. But it would feel odd to see some in a green zone level, says my 23-years-older brain. I tried to come up with alternative recently, like this sort of jelly which could possibly work in another environment by which I can't convince myself truly works within a giant hollow tree.

Puis mes gamins sont passés à nouveau sur une plaine de jeu, et dans les plaines de jeux, il y a ces ponts suspendus sur lesquels les uns passent en courant pour faire tout trembler tandis que d'autres râlent, cramponnés aux rambardes, mais tentent de passer quand-même. Puis il y a ceux qui sautent pour tout secouer encore plus. Et dans ma green zone aussi, il y a des ponts (même si je n'ai encore presqu'aucun post qui en montre ^^"), bien qu'ils étaient assez peu marquant dans la version BASIC (en gros, certains morceaux pouvaient tomber. Voilà).

Mais pour "dreamland", ce serait assurément assez sympa que ce côté "un pont, ça tangue" soit exploité, et en particulier, que Funky Funghi puisse faire "voler" Bilou vers le haut si on a le bon timing.

So I'm glad my kids were on a playground last week-end, one with those bridges you run across to shake them more than the lad before did. There *are* bridges in the green zone already (I just haven't shown them to you yet). No sane level designer making a game a few years after Sonic the Hedgehog would craft a platformer without bridges. And I had thought of using them as trampolines, where you slowly get higher and higher by jumping again and again. Why not have Funky Funghi "use" them to propel you ?

Evidemment, laisson à Funky Funghi son côté "utile, oui, mais attention". Par exemple, si Bilou se contente de passer sur le pont, on peut très bien imaginer que chaque fois que Funghi atterrit, il secoue assez le pont pour que Bilou perde pied. S'il retombe d'un grand saut, il pourrait faire décoller Bilou -- plus ou moins l'équivalent d'un saut normal, mais pas forcément vertical.

Now, it's still Funghi. Even when it is useful, it remains dangerous. we could imagine that if Bilou doesn't "prepare" the bridge for being propelled, he would just be bounced away towards Funghi, but not much higher than a regular jump would have. We can also imagine that when Funghi makes just a small bop, it just makes the bridge shake and be somewhat stunned by that.

Bon, un truc pareil, par contre, il faudra l'introduire pour que le joueur puisse l'exploiter. Par exemple quand c'est Bilou qui joue le rôle de poids lourd et un autre personnage (au hasard, Appleman) se fasse propulser. Ça ne sert pas à grand chose, mais c'est rigolo. Ne pas oublier de mettre des trucs rigolos dans un jeu vidéo: on est là avant tout pour s'amuser.

It will take some training if we want the player to figure out things like that. And training requires some sandbox to experiment. So why not make sure that the player will have encountered easy-to-handle baddies (e.g. applemen) on bridges before and had the opportunity to realize that stomping on a bridge has side-effects. It shouldn't be too hard to make it fun and it's always good to have a few things that are just fun in a game.

tuning de branche ...

Ben ça aura été une semaine de gros débugging pour ... pas grand-chose au final. Enfin, la bonne nouvelle c'est que la branche rebondissante a bien évolué. On avait quelque-chose de peu logique le mois dernier, là, j'ai repris le contrôle.

Le premier truc, c'était de re-définir le timing des interactions entre la branche et Bilou: quand on tombe dessus, la branche s'abaisse d'abord, puis nous envoie vers le haut. Evidemment, c'est seulement pendant la phase "remontante" de l'animation de la branche qu'on a envie qu'elle puisse propulser Bilou.

Il y a déjà (et depuis longtemps) ce qu'il faut pour ça dans AnimEDS, mais j'avoue qu'au moment de créer l'animation, j'avais un peu oublié comment ça marchait. En fait, au moment où on active le mode 'box', la ligne du temps en bas l'écran permet d'indiquer dans quelles frames la boîte est active.

A week spent in debugging because I had forgotten how my tools define over what part of the animation a collision box is active. I had also forgotten that the same keyword 'area' describes the sensitive-and-passive role of a collision for 'sprites' and the offensive-and-active role for special blocks.

Well, at least, it's almost clean now. I should be able to build a new demo version next week-end. But first, I will have to make a check list of the things that are still a bit weird in the current state.

Mais quand j'ai voulu faire les essais avec cette nouvelle animation, plus rien ne marchait. Enfin, la branche détectait l'arrivée de Bilou, provoquait un rebond et activait son animation, mais impossible de se faire projeter en l'air.

Tout ça parce que j'ai mélangé deux mots-clés dans la définition des blocs interactifs (dont la gomme-qui-rebondit qui a servi de modèle à la branche): dans les définitions de machines d'état, area introduit une zone sensible (et passive) pour les collisions alors que test introduit une zone offensive (et active). Pour les blocs spéciaux, il y a un seul mot-clé -- area -- mais il définit une zone offensive. Je l'avais oublié. Du coup, j'ai passé les soirées en mode 'guru meditation' ... pour rien.

Je ferais bien une nouvelle démo pour fêter ça, mais il y a deux ou trois trucs louches aux entournures ... je vais repasser par la case "faire une todo list", donc.

I did some playtesting with J.L.N and *deline ... They mostly wouldn't fall off the branch (I made sure that one wouldn't happen too often), but it wasn't obvious to them how to make big jumps. The thing is you don't need to press JUMP when stomping the branch, but *when it throws you back*. Maybe I should trigger a 'super-throw-back' if player hit JUMP when stomping ? so you don't have to bother too much about bumper timings in level 1 ?

Keen sur Switch!

Oulah! On se calme tout de suite, les gars. Je vous vois déjà bondir sur le store, cartes visa dehors ... Il ne s'agit que de Keen Dreams, le poussin noir de la couvée. Le lost-levels 3.5 qui marque la transition entre le classique "invasion of the Vorticons" et le cultissime "Goodbye Galaxy".
Mais bon en promo à 2 euros, même si c'est le seul épisode pour lequel j'aie jamais dépenser un cent (bin oui, les épisodes 2,3,5,6 étaient introuvables dans mon rayon d'action et les épisodes 1 et 4 étaient redistribuables librement :-P), même s'il est affublé d'un scénario discutable, de graphismes meilleurs-mais-un-peu-à-l'arrache et d'un gameplay franchement perfectibles, je tente.

K1 : classique.	KD : meh.	K4 : cultissime

Allez, je remets un petit comparatif pour ceux qui étaient ailleurs dans les années '90. La première trilogie, c'est un personnage de taille modeste dans un environnement aux graphismes minimalistes: à-plats de couleurs, perspective frontale, décor épouillé ... mais c'est le tout premier jeu de plate-formes à scrolling sur PC alors on se l'arrache.

Overview: There are gems of game design in the 'Commander Keen' franchise. Okay, likely fewer of them in the 'Keen Dreams' episodes. And unfortunately, this is precisely the one for which we can find sources on the Internet and a port on the Nintendo Switch game store. It could have been a nice idea, but given how the original material was processed, it should rather have "crime scene ** do not cross **" banners around.

La suite "Goodbye Galaxy" prend le pari d'une perspective pas-complètement-cavalière (influence de Prince of Persia ?), offre un personnage plus grand et des décors nettement plus riche. Elle amène aussi une musique de fond et des effets numérisés (K1 devait se contenter de bruitages au PC-Speaker. Oui, ça fait mal aux oreilles).

Au niveau du gameplay, passer de K1 à K4, c'est un peu comme passer de MegaMan à MegaMan X: de 2 directions de tir, on passe à 4. On ajoute des pentes, la possibilité de s'accrocher aux rebords des plate-formes et de monter/descendre à des barres de pompier. Le jeu gagne ainsi énormément en souplesse. On rajoute aussi un saut plus ou moins haut et qui réagit au millipoil. Le saut minimum couvre les 2 blocs au-dessus de Keen. Le saut maximum (sans pogo) en prend 3 de mieux. (Keen faisant lui-même 2 blocs de haut).

Si graphiquement, on pourrait pardonner à Keen Dreams d'être un cran en-dessous du niveau de K4, le fait qu'on ne sache pas encore s'accrocher au bord des plate-formes fait nettement plus mal. En introduisant une perspective ou le sol apparaît presqu'aussi large que le personnage n'est haut, on introduit aussi une incertitude sur notre capacité à atteindre une plate-forme donnée. Comme en plus on nous a retiré le pogo, ça donne un jeu où on va souvent rater ses sauts. De plus, si KD réagit aussi au millipoil, il n'a qu'une hauteur de saut (peu s'en faut) à l'instar du classique "Invasion of the Vorticon". On ira donc souvent se manger le plafond ou finir dans les pieds du monstre situé au-dessus de nous, sur une plate-forme jump-through. Vérification faite: le jeu d'origine n'a pas ce problème (il y a 1 keen de différence entre le saut le plus bas et le saut le plus haut), pas plus que Keen 1. Avoir forcé une seule hauteur est une spécificité de la reprise sur switch.

#SHOOT: commander Keen's primary mean of defence is to shoot at baddies, in all episodes. 'Keen Dreams' shots significantly differ from all other episodes' neural stunner shots, though. They're affected by gravity rather than shot straight, but most of all, their effect is temporary. That wouldn't be so hard to stand if we had not such a limited stock of amno. The switch port of the game makes that even worse by resetting the amno counter when you enter a level. No more way to use the first levels to hoard amnos so you've got more shots allowed in a later, harder level.

Let's make it a lesson learnt for Bilou Dreamland: if you permanently consume something by shooting, then the effect of shooting should be permanent as well. As often as possible.

La dernière grosse différence entre Dreams et le reste de la série, c'est qu'ici Keen n'a pas un pistolet, mais qu'il lance des pastilles-fleurs affectées par la gravité. Vu le nombre d'années depuis ma dernière partie de Keen "canoniques", on va dire que je devrais m'y faire. En revanche, leur effet est limité dans le temps. A l'époque, ça m'avait valu quelques morts évitables. Ici, ce sera l'occasion de voir ce que les joueurs de Bilou: Dream Land ressentiront. Verdict: des munitions limitées avec un effet temporaire = panne sèche assurée. On veillera donc à ce que Dreamland garde "munition consommée = effet permanent" tout comme SchoolRush.

Que dire de l'adaptation sur Switch, donc ? Eh bien, figurez-vous qu'ils nous ont ajouté des musiques. Si si. En gardant un style assez proche des sonorités adlib de l'époque (bien), mais assez moyennement inspirées sur les thèmes. On est plus dans l'ambiance de Keen 6 que de Goodbye Galaxy et ses thèmes inoubliables, selon moi. Il nous ont aussi rajouté des petites bulles de texte ça et là, avec des polices de caractères improbables ou des menus avec des icônes douteuses. Jugez plutôt! Mais sinon, à part le fait que les vies semblent illimitées, on est dans une adaptation assez fidèle du titre original ils ont complètement ruiné l'intérêt principal du jeu.

Je m'explique: le coeur de Keen Dreams est de s'assurer qu'on a assez de bombes pour affronter le boss final, insensible au FlowerPower. Ces bombes sont cachées dans des recoins des niveaux (de certains niveaux, en fait). Et comme on ne peut visiter chaque niveau qu'une fois sur une partie, se ruer sur la sortie n'est généralement pas la bonne option. Pourtant, dans certains niveaux, atteindre la sortie est assez simple, voir trivial.

Je peux comprendre que les éditeurs du 'remake' aient décidé que les niveaux soient librement revisitables, mais avoir 'sucré' purement et simplement l'objectif premier, c'est à se demander pourquoi reprendre le jeu.

#game design: The ultimate goal of the original Keen Dreams episode is to find and collect Boobus Bombs. There are a few in many levels (but not all) and a warning is shown when you enter the level. If you've already played enough to reach the final boss' castle, most likely you've realised that you were short of those bombs, and that they were the only thing that could affect the boss. You can more or less start the whole game anew and be more careful not to rush for the exit of bombs-featuring levels.

Granted, this is an arguable game design choice by 202x's standard. It already was when I played it after DKC! But it is the keystone of the whole game. Levels in Keen Dreams aren't SMB-like course to complete left-to-right. They aren't either key-and-locks mazes of earlier "Invasion of the Vorticon" episodes. You may have a tall waterfall level where the exit is a few hops ahead to the right, but that has depth and heights to explore for you to find the precious bombs.

The switch review allowed levels to be re-visited freely, killing the thrill of not finding enough bombs. It revealed secret passages with a changed color. Worst of all, it adds a 'RUN' mechanics that means some of the jump-puzzles were you where teased with bombs but then had to figure out how to reach them got completely undermined. Oh. And they screwed the *JUMP* mechanics.

Autre point douteux: l'ajout d'une mécanique de "course" ... à savoir la possibilité pour le
personnage de doubler sa vitesse, ce qui casse évidemment certains puzzles basés sur les sauts. Dans la ville des patates, par exemple, on pouvait voir assez facilement la position de ces bombes, mais elles sont hors d'atteinte. Pour les choper, il va falloir aller jusqu'à la fin du niveau, remarquer une libellule-plate-forme parmi les autres libellules, grimper jusque tout en haut et réussir un sans-faute dans un enchaînenement de sauts. Puis revenir.

Comme si ça ne suffisait pas, tous les passages secrets vous sont révélés. Oui, vous m'avez bien entendu: alors que les passages cachés (et où vous êtes invisible) sont une des pierres angulaires de Goodbye Galaxy (et donc de Dreams), ici, on a marqué leur emplacement par du sol plus clair. Plus aucun mystère, du coup.

#COLLECT: Keen games have always featured lot of sweets to pick up. ultimately, they would grant you 1-UPs, and with a game where any hasard means insta-death, 1-UPs are key to success. That was balanced with 1) perma-completion of levels 2) exponential target (next 1-UP will cost higher) and 3) positioning of high-value sweets in dangerous spots. The switch edition breaks this completely. Levels can be re-visited at will, but there is no 1-UP any more (they aren't even replaced with something else) because you've got infinite stock of retries. The only thing you could earn for picking a sweet is ... increasing the completion meter for the level. This is actually frustrating because of the high-value (lost) high-danger (preserved) hidden sweets: you'll get something more only if you find 100% of the sweets in a level, but even a 10-years-old can see that goal is actually unreachable (especially since the level doesn't remember collected sweets if you die).

Est-ce qu'il y a encore quelque chose à dire ? Circulez, m'sieur-dames: y'a rien à voir.
oui! Les munitions! j'ai déjà expliqué en quoi la combinaison tir-qui-assomment et munitions-limitées font mauvais ménage. La réponse de gamer à ce problème épineugle est d'utiliser les premiers niveaux pour maximiser son stock de munitions tout en contournant les ennemis, évidemment. Une grande partie des maps des niveaux qui ne contiennent pas des bombes ont des cachettes à 'graines de fleur' en dehors du chemin principal, histoire de quand-même récompenser la récolte. Mais dans cette version sur switch, votre compteur de munitions est remis à 10 chaque fois que vous entrez dans un niveau. Aucun intérêt, donc.

Resterait-il les bonus-à-points ? même pas! Ils servent normalement à gagner des vies, mais on l'a vu: les vies sont ici illimitées (et donc les 1-UPs retirés des maps). On pourrait se dire que 'c'est pas grave: ce sont des gougouilles, ça reste sympa de juste essayer de les attraper toutes. Oui, sauf que chez ID, ils aimaient bien mettre une part de gateau derrière un obstacle bien chaud, et comme on a qu'un seul point de vie, on est en réalité invité à décider si on se sent capable de prendre le risque ou pas. Tenter le 100%, c'est la mort assurée. Du coup, même J.L.N s'en rend compte: c'est nul.

The true Mario Jump

J'ai un vieux post, le premier qui raconte comment on peut faire sauter un personnage dans un jeu vidéo. Dedans, il y a une image où j'explique que la physique de SMB3 est un peu 'truquée' du côté des sauts. Mais bon, j'avais fait ça à la grosse loupe sur une vidéo youtube, alors que l'ami Upsilandre, lui, a du lourd sur le sujet: il a analysé en détail les mouvements de Mario et ceux de TinyToons Adventure pour voir s'il y avait eu des fuites de code source entre les deux jeux.

When I was writing one of my first post about having a character jump in a tile-based game, I had the surprise to see that Super Mario bros. 3 doesn't seem to use Newtonian gravity. Instead of having a smooth parabolic curve, there seems to be linear rise, parabolic climax and linear fall in a Mario jump. But I did that just by checking a let-s-play video on youtube. On his French blog, Upsilandre did a detailed comparison of SMB3 and Tiny Toons Adventure where he gathered all the impulse and gravity constants, so why not pay him a visit ?

Il pointe notamment une correspondance exacte pour les impulsions de saut. au centième de pixel par frame près. Troublant ? Eh bin, rappelons-nous: quelques paragraphes plus haut, il relevait aussi que les deux jeux utilisent le même format de nombre pour les vitesses: 4,4 bit

La vitesse dans Tiny Toon est encodée exactement dans le même format à virgule fixe 4b.4b que je n'ai vu que dans SMB3 (même pas dans SMB1), en général c’est plutôt du 8b.8b (voir du 3b.5b). [...] La même force de gravité faible de 0.06 tant qu’on maintient le bouton saut (comme si on était sur la Lune) et une force de gravité forte de 0.31 (retour sur Terre) quand on lâche le bouton ou que la vitesse verticale passe en dessous des 2 pixels par frame (donc quand on approche du sommet du saut). [...] [on va retrouver] strictement les mêmes 5 valeurs d’impulsion à la décimal prêt (respectivement 3.44, 3.56, 3.69, 3.94 et 4.00 ppf). La seule chose qui diffère c’est la valeur qui sert à caper la vitesse max de chute qui, comme pour la glissade en pente, est plus basse dans TTA.

Petite précision: cette histiore de 4,4 (ou 4b.4b selon la formulation d'Upsilandre) signifie que toute vitesse est exprimée en un nombre entier de 16 de pixel/frame. et on peut aller de -16 à +16 pixels par frame (mais personne n'ira jusque là). Du coup, 0.44 c'est 7/16, 0.56=9/16, 0.69=11/16 et 0.94=15/16. Déjà beaucoup moins surprenant. Notons au passage que la gravité lunaire de 0.06 pixels/frame² correspond à une simple décrémentation de la vitesse en 4,4bit. C'est 1/16eme. Tout simplement. Sur un processeur tel que le 6502, si on peut décrémenter plutôt que de soustraire 2, c'est toujours ça de pris.

The most interesting part is that the game uses two different gravity values. the 'ramp up' part of the jump uses the lowest possible gravity the game can deal with, of 1/16th pixel per frame². The switch to another gravity happens when we reach a vertical speed of 2 pixels/frame (or if the button is released), and we then go for 5ppf².

The impulse value may seem surprising, especially when expressed as decimal values like 3.69ppf. In fact, they integrate to nicely integer jump height expressed in Super Mario Blocks. What it means is that any game that wants to use the same gravity as SMB3 and a map made of 16-pixels blocks is likely to need the same impulse values as well.

Mais pourquoi ces valeurs-là ?
C'est le moment de ressortir un autre vieux post où on reverse-designait Super Mario World. Le game design forum y pointait que tout se mesure en bloc, dans le monde de Mario. Y compris la hauteur et la longueur des sauts. je ne serais pas surpris de découvrir que les impulsions correspondent aux vitesses qui permettent de franchir un obstacle de 3, 4, 5 ou 6 blocs le plus justement possible. Mais on a les valeurs, donc vérifions!

Voilà donc: selon l'impulsion initiale (v0), la hauteur atteinte (y2) au moment où la vitesse vaut 2 (et où on applique une gravité "normale" proche de 5/16 ou 6/16 ppf²). Avec en prime le temps mis pour y parvenir. Les valeurs 'magiques' correspondent à un obstacle de 4, 4.5, 5 et 6 blocs respectivement.

During the fall down, the game physics makes the terminal velocity kicks in very soon. As soon as 2 blocks high, actually. It may be an important part of consistent air control, giving you equal chance to hit RIGHT and reach a platform regardless of how long you've been falling down. The quasi-linear ramp up with super-small gravity does its best to mimic that for gameplay symmetry and ensures that we don't need speeds near 1 tile/frame if we want to jump up to 6 blocks high, as 1 tile/frame is almost warp speed for a 8-bit game engine.

ça, c'est pour la montée en gravité lunaire. Avec une gravité de 5/16, il faudra 22 frames pour tomber de 65 pixels de haut, mais 2 frames plus tard, on aurait déjà franchi 80 pixels. Enfin, ce serait en supposant que les programmeurs de SMB3 n'aient pas mis une 'terminal velocity' pour la chute libre en-dessous de 6ppf². En réalité, comme le fait remarquer Upsilandre, la vitesse de chute est limitée à 4+5/16 ppf par la "friction dans l'air". La mini-gravité en début de saut est essentiellement là parce que le gameplay veut une hauteur qui ne devrait pouvoir être atteinte qu'avec une vitesse de chute supérieure à cette vitesse terminale. Sans ça, il faudrait une impulsion de plus de 7+8/16 ppf pour dépasser 6 blocs de hauteur. On s'approche dangereusement de la limite de 1 tile / frame à partir duquel le code de détection de collision avec le niveau doit être radicalement modifié.

Au final, 

• la descente de Mario est principalement linéaire. Il n'y a accélération que pendant les 2 premiers blocs (1 mario) de hauteur.
• la montée de Mario n'est pas strictement linéaire, mais la gravité est si faible que la différence est à peine perceptible. Elle va surtout agir comme un compteur intégré de frames de montée forte avant de passer à la phase 'sommet du saut'
• le changement de gravité au moment de relâcher le bouton offre une alternative sympa à ma solution de "forcer la vitesse de saut à -2 si on relâche le bouton [et que...]" 

edit: j'en profite pour sortir d'un vieux draft un autre schéma 8-bit d'upsilandre: la comparaison des courbes d'accélération de différents personnages.

edit+: en comparaison, Gomez ne sait sauter que par-dessus un obstacle de 2 blocs de haut mais peut s'accrocher à un rebord à 3 blocs de hauteur. Plus approprié pour un jeu de puzzle comme FEZ.

Sonic Mania

Il faut le reconnaître: Sonic Mania est une réussite. Ces nouvelles couleurs sont tout simplement fantastiques. Le mélange entre ancien et nouveau est particulièrement réussi. Je trouve le design franchement bien pensé, avec un premier niveau par zone qui est un hommage au niveaux originaux alors que la 2eme zone se lache pour étendre la formule. On retrouve ainsi un lac souterrain et des totems géants en deuxième volet de la "Green Hill Zone" (et si je ne me trompe pas, on peut déjà en avoir un aperçu dans certains itinéraires de la première zone).

Le changement est encore plus marquant dans la Chemical Zone, qui offre un revisitage de mécanique de jeu qui n'est pas sans rappeler la main-du-maître revisitée dans Link Between Worlds.Je m'explique.

La Chemical Zone de Sonic 2 est remplie d'un liquide chimique pénible, avec en plus des gouttes d'un autre liquide chimique. L'un tue rapidement, l'autre lentement (enfin, l'inverse). C'est probablement le premier véritable obstacle du jeu, et on a beau faire, contrairement à de la lave qui nous blesse mais sur laquelle on peut courir pendant nos phases d'invincibilité, dans un produit chimique, Sonic coule.

Mais dans le 2eme niveau de Sonic Mania, on fait apparaître des switches qui permettent de faire réagir ces liquides chimiques pour produire une sorte de slime ultra-élastique et obtenir un trampoline géant. La difficulté transformée en fun par l'intermédiaire des actions du joueur, c'est déjà bien chouette. Quand en plus ça se traduit en trampoline (sans pics par-dessus) dans un jeu de plate-forme, c'est fun-compte-double.

Bien sûr, on saute dans un jeu de plate-forme. Mais régulièrement, on ne saute pas assez haut. Parfois il y a un bumper pour nous propulser plus haut, mais il y a alors le risque de mal retomber, ou de rater sa cible. Une salle-trampoline, c'est de la pure gourmandise: saut jusque tout en haut, on peut tout attraper, on ne prend aucun risque. 

(Bon, ça fait un moment que Sonic Mania est sur ma switch, bien sûr. Les notes qui disent "J.L.N a encore les réflexes un peu lent pour éviter les crabes qui lancent des boules en ouvrant les pinces" doivent dater du mois d'Avril).

Pour l'instant je cale sur le boss de la Flying Battery Zone, mais il y a un dernier élément sur lequel j'aimerais revenir: la boule-rouge-à-ressort de StudioPolis Zone. Une variation sur le thème du trampoline qui vaut la peine qu'on y regarde de plus près.

Ceux-ci ne propulse franchement pas haut, mais on a bien le temps de profiter de leur animation atypique. En plus, ils déclenchent "à la demande" une animation normalement plutôt rare de Sonic (celle utilisée pour le faire marcher dans les pistes-tourbillon de la GHZ).

Leur forme sphérique s'accompagne d'une mécanique où on est propulsé un peu dans n'importe qu'elle direction, les transformant en un mélange entre bumper et tapis-roulant, mais comme ils sont placés en groupes assez généreux et à l'écart des dangers, ils restent fun.

owlboy: drôles de contrôles.

Les graphismes d'Owlboy sont superbes, les musiques plantent une ambiance idéale et j'adore l'histoire. Pourtant, pendant tout le début de l'été, je n'ai pas ressenti cet effet d'appel à jouer que j'ai pu avoir avec hob ni meme flinthook. La progression est laborieuse, j'ai la sensation d'être brouillon et de ne pas bien comprendre ce que le jeu attend de moi.

J'ai commencé par penser qu'il s'agissait d'un problème d'interface: si seulement je pouvais
forcer le jeu à tirer quand je pousse sur Y plutôt que de réclammer un ZR, tout irait beaucoup mieux, non ? Ça me remettrait dans une configuration identique à celle d'Iconoclast et de Flinthook auxquels j'étais aussi en train de jouer. Les choses deviendraient enfin naturelles. D'autant qu'en y regardant de plus près, c'est aussi le mode de fonctionnement que j'ai utilisé sur Super Mario World et Donkey Kong Country.

Puis je me suis rendu compte que ce serait incompatible avec le système de visée du jeu et j'ai commencé à prendre conscience de tous les raccourcis prévus dans les actions du joueur. J'ai alors commencé à reconsidérer le jeu, non plus comme un jeu de plate-fomes où on sait voler, mais comme un shoot-em-up avec des phases au sol, et à laisser le jeu en mode "tir automatique" par moment pour me concentrer sur mes mouvements d'esquive.

Et des "raccourcis", il y en a des fameux. Voyez, en bleu la séquence d'actions que j'effectuais jusqu'à la fin du deuxième "donjon" pour pouvoir tirer: d'abord commencer à voler puis invoquer mon partenaire, et enfin, viser et tirer. Il y avait aussi une autre possibilité consistant à faire apparaître d'abord le partenaire, puis à le 'ramasser'.

Tout celà est rendu encore plus compliqué par le fait que certaines pressions de touches peuvent nous faire revenir en arrière, et que lorsqu'il est au sol, il faut être assez près de son partenaire pour pouvoir le ramasser. En clair, dès que le boss va venir vous mettre la pression, c'est fini. D'autant que la plupart des coups qu'on encaisse projettent notre personnage et son partenaire dans des directions différentes. Mais heureusement, si on se concentre sur le côté "shoot-em-up" du jeu, bin le réflexe quand on s'est fait toucher n'est plus de sauter mais bien de se remettre à tirer. Et là, bonne nouvelle: utiliser le bouton de tir nous "téléporte" instantanément dans l'état "en train de voler avec son partenaire accrocher qui se met à tirer dans la direction indiquée par le 2eme stick. On peut dès lors oublier toute la partie bleue dans les phases d'action et se concentrer sur l'essentiel: un stick pour bouger, un stick pour viser, une gâchette pour changer d'arme et une gâchette pour tirer.

Je pensais plus ou moins jusque là que les noms "plate-forme", "beat-em-all" et "shoot-em-up" n'avaient d'utilité que dans un catalogue ou un magasin, mais après plus de 20 ans de pratique du jeu vidéo, on dirait que ça va plus loin. Le fait de penser "c'est un shoot-em-up" semble activer un autre ensemble de réflexes, y compris un mode de vision plus global pour surveiller les trajectoires de plusieurs projectiles à la fois.

Et pourtant, pendant une bonne partie du jeu (et en particulier presque tout ce deuxième donjon), le fait de tirer est beacoup moins impliqué: on va essentiellement résoudre des énigmes en transportant et lançant des objets (ennemis-bombes, nuages ou cruches d'eau pour éteindre les monstres de feu, etc). De quoi endormir le peu de réflexes qu'on aurait pu se constituer dans les phases d'action du premier donjon.

Bref, Owlboy a fait le pari d'un jeu multi-facette, qui alterne des phases de shoot-em-up, des phases de puzzle "à la zelda" et des phases (rares) de réel platforming ("Attention: ces gnomes ont une ouïe super-fine. Ils t'entendraient battre des ailes à 100 mètres. Quoi qu'il arrive, ne t'envole surtout pas!"). Une richesse indéniable, mais pas toujours claire à appréhender pour le joueur. Et qui va vous demander -- tout comme le personnage doit le faire dans le jeu -- d'abandonner derrière vous vos a priori si vous voulez continuer à aller de l'Avent.