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.

Hang on!

It's one of the key mechanics I'd like to bring into my new game: being able to catch hanging things and hanging as well. It was a fun move in Commander Keen, it was amazingly expanded in Fury of the Furries and Mickey Magical quest ... And last week-end, I went on to try and get it prototyped.

I started with a summary of how Bilou can hang below spongebops in School Rush ... something we don't see a lot in the blog, mostly because Bilou is supposed to *ride* the sponges, not hang under them. Hanging was added as an "else" branch of another "else" branch:

when you hit the "HANDS" button mid-air, Bilou does a roll move trying to grab what's nearby. that is AIRGRAB state. The original idea was to test what was *below* him and either pick-up a dumblador or ride a spongebop... but the move shows the hand grabbing in front and rear directions as well ... so it would feel natural that Bilou could grab a sponge even if he's on the same horizontal line, like in the sketch on the left. Yet, snapping Bilou on top of the sponge from this location felt glitchy.

Bon, j'ai un p'tit Bilou suspendu sur une page de mon cahier-agenda depuis le début 2024 ... j'en ai un autre sur la bannière du blog ... je crois que l'appel du pied est assez clair: il serait temps de prototyper un peu ça, d'autant que cette fois ci, ce ne sont pas les coins de niveau où s'accrocher qui manquent dans le livre-secret-du-level-design.

Et pour "commencer simple", l'idée était de faire subir à Bilou le comportement des éponges. tout en réutilisant un des états codés pour l'interaction avec les éponges: rester suspendu (la feinte). Chose qui m'a tout de même demandé de me replonger dans pas mal de gobscript, parce qu'à la base, il est prévu que Bilou s'accroche *par-dessus* les éponges, et pas qu'il pende en-dessous. Le côté "pendu" n'a été rajouté que dans les derniers 20% du projet, entre deux séances de playtesting parce "bin, oui, c'est vrai au fait: pourquoi Bilou ne pourrait-il pas rester suspendu s'il était trop bas pour escalader l'éponge au moment ou la joueuse a appuyé sur (B) ?"

So instead, Bilou will enter AIRHOP move, getting an automatic double jump and automatically tracking the sponge's position. That feels fairly naturally when playing, that gives you a sort of "fair second chance" but it might fail anyway: you may fall below sponge's position again without having reached the "riding spot", with no hope of catching up. and *that* is the time when we finally switch to HANGING. 

There will be other objects to hang to in the game, especially bookmarks, vines, and the like. Some of them could be entities like spongebop (maybe moving a bit less), but sometimes it might also be nice to have tiles you can hook to. I have code to make some tiles react to collisions with the player, but that was not enough: the hitboxes used to detect spongebop explicitly search for baddies. And because I'm testing 3 areas over the course of the animation, I'm out of options to also test for friendly areas (which has been the case for all pick-ups so far ^^"). But hitting a tile can trigger an animation, and it can spawn an entity with proper hitboxes so that Bilou could hook to *that*. You couldn't really hook to a tile, anyway, because the BlockArea created during the collision test is immediately recycled, so you could not attach to it. 

Mon idée était ensuite d'utiliser un type de bloc spécial pour servir de point d'accroche, et d'aller "poker" quelques blocs de ce genre à des endroits bien sentis de la map "green" de la démo. ça non plus, ça n'a pas fonctionné comme j'espérais. Entre autres parce que quand Bilou cherche à s'accrocher à quelque-chose pendant sa pirouette-en-l'air, il cherche parmi la liste "EVIL" ... et les blocs interactifs, eux se présente automatiquement comme des "HERO".

Bon, ce n'est pas bien grave: puisque je voulais que Bilou s'attache au point d'ancrage, il fallait de toutes façons que j'introduise un GOB (game object) généré à partir du bloc spécial, un peu comme les scintillements qui suivent Bilou quand on ramasse un smiley bleu. Ce gob pourra être dans la liste que l'on veut. Pour éviter qu'on ne génère des quantités ridicules de gob-points-d'ancrage, on va (enfin) utiliser une animation de la map elle-même pour désactiver puis réactiver les propriétés du bloc pendant que le gob est présent. Exactement le comportement des blocs-question de SuperMario quand on les coup-de-boulise.

So the plan was the following: a new special block that would react to GRAB action. When that happens, it trigger the animation that actually leaves graphics untouched (with "spr0 ffff") but turns the physical tile into "plain fall-through" for 5 frames, and then restore the tile as "block 07" (thus interactive) again. Quite the kind of thing that SuperMario question blocks do on a daily basis, actually.

(It turned out meanwhile that using sprite 'ffff' did not work as intended, so I ended up adding a bbox statement to that animation -- effectively making it a special 8x8 tile rather than a 16x16 special block -- and fixed the code that plays mapanim so that "props" instruction is executed immediately rather than cached until the next "spr0" instruction)

anim9 spr:2 {
   spr0 7      # visuals for the "tile replacement",
   delay 5     # here just a Bilou hand ...
   done
}

state63 :anim9 {           # behaviour for that hand :
   using freemove          # just stay there, 
   area 0 (0,0)-(8,8) 1010 # accept GRAB hits.
}

state62 :anim9 {   # should have been the persistent state when Bilou hooked...
   using freemove
}

state63->state62 on found 0 [wc $1010 ?] (t) # detecting the actual hook-up hit
state63->nil on done                         # and disappear otherwise

using shgob(state63 is e:=1:6) as 6          # a special action to spawn the hooked hand
                                             # oh ... and it's an evil hooked hand.
block 06 {
    is gndhook "ff3c7cfebe2a2a00"  # the special tile 
    area (0,0)-(7,7) 1010          # will also detect GRAB hits
    on hit [t] (x6) :anim6         # and the 'x6' will invoke shgob registered 'as 6'
    props fc0
 }

That should have done it. I could see the hand showing up, and getting away, but I couldn't ever hook to it. I couldn't get an evidence of why it failed, but I believe it is rooted to the fact that bilou's own bbox must overlap the tile in order to trigger the "on hit" transition. but since all the hitboxes with the GRAB flag tend to be off-center, the second collision (with state63 entity) doesn't occur because there's no overlap.

Alors oui, je vous balance le script directement dans le browser. Parce que ça ne fonctionne pas. Enfin, après avoir corrigé la gestion de l'animation pour ne pas dépendre des changements d'affichage (qui expliquent le bout de terre manquant dans le screenshot là-haut), ajouté une "bbox" à l'animation (pour que le code sache qu'il ne doit manipuler que 8x8 et pas 16x16), je finis par avoir un objet qui est créé tandis que le bloc devient inactif puis se réactive ... le hic, c'est que il faut pour ça que le "corps" de Bilou soit en contact avec le bloc interactif alors que ce sont ses *mains* qui vont essayer de l'attraper. Et la zone à attraper est réduite à 8x8, de toutes façons mal positionnée... bref, je n'y arrive que 1 fois sur 5-6, donc le joueur n'y arrivera pas.

Il vaut bien mieux que je me décide à dessiner un graphisme dédié (une racine ?) et que je fasse juste un GOB dédié... il y aura des import/exports mercurial à faire ... 

At some point I thought "hmm. I'll just have the little tile be a 8x8 hitbox in the middle of a 24x24 special box, that will do the trick", but it wouldn't work either: that 24x24 region around the corner of a pillar (for instance) would have "jump-through ground" on one tile, and "air" everywhere else... how could a single "props" instruction fix that ? okay, I could introduce "props(-1,0) fc4" to change one specific tile of the block but that sounds like the coding equivalent of "just stab me now" ... 

So, likely, I should forget about that "hook to tile" thing, accept that there's very little hookspots in the Dreamland levels anyway and kickstart my NDS to draw some root sprite in green.spr ... 

SMBW: Retournement

Une des premières mécaniques que j'ai vraiment appréciées dans Mario Wonder, ce sont les roulhippos. Je les range dans la même catégorie que les wallcreepers de Link Between Worlds ou le liquide rebondissant de Sonic Mania: on prend un élément de gameplay qui a bien cassé les pieds des joueurs sur les 30 dernières années et on lui donne enfin la possibilité de prendre sa revanche.

Et ici avec ces hippos mauves qui n'auraient pas dénoté dans Super Mario Land 2, c'est carrément sur les trous-sans-fond que Mario prend sa revanche ... c'est à dire sur son ennemi n° 1: la gravitation. Et pas qu'un peu puisque les trous ainsi bouchés se transforment en tremplins particulièrement puissants.

First wonderful mechanics in the game is the rolling hippos, and how they transform something truly annoying (bottomless pit) into something fun to interact with (a bouncy area). This is the same kind of flip-the-challenge move that was happened with the blue liquid of Sonic Mania, but it's of course something Nintendo people themselves are familiar with since this reminds the wallcreeper remastering of Link Between Worlds. Many further "wonders" of the game will also act as flippers, like allowing to walk on the background or ride / swim lava.

Monde 1 oblige, envoyer promener un hippo est plutôt simple: il suffit de lui sauter dessus. Notez au passage que s'ils peuvent se montrer piégeux (cogner un hippo renvoie Mario assez fort en arrière), ils ne sont pas blessant, chose plutôt rare au royaume champignon fleurs.

Mais les Roulhippos ne sont pas le seul moment où ce Mario Wonder renverse les règles, et les "prodiges" seront une occasion pour fournir ce genre de plaisir au joueur, comme ici où Yoshi se retrouve non seulement immunisé contre le feu mais aussi capable de nager dans la lave et d'utiliser les coulées plus denses comme des plateformes mobiles...
 

Chalk 2.0

In the first release of Bilou's Adventure solo anniversary level, I had to use a caption on the blog post so that players would know they need to break one "barrier" to keep going.

Later revision replaced it with a chalk, that can break if you fall from high enough. But that wasn't properly explained to player either.

• I have sketches of training rooms to teach players chalk can be broken
• Original level design had key-and-lock there, and one of the design decision for Bilou's Dreamland is "it is okay to rely on keys and locks"
• What if a simple jump was pushing the chalk down by 1 pixel ? (in addition to everything else you can already do with it)

Bon, ça ne devrait pas être une surprise: Bilou's Dreamland reprendra le niveau-anniversaire pour la school zone. Il a l'avantage supplémentaire que pas mal de mécaniques de jeu qu'on y trouve ont déjà passé l'épreuve du playtesting, même si ce n'était clairement pas parfait. Un des éléments qui a le plus causé de soucis aux joueurs, c'est cette craie-qui-casse que Piek jugeait zelda-esque. C'était pourtant une amélioration notable par rapport à ce qu'il y avait dans la première version nds du niveau, où il fallait lire le blog pour savoir que ce crayon-là peut casser, contrairement aux autres...

It might not be bad that you could push down the chalk-gate without ever making a bigger jump, mostly because those eraser monsters will put you under pressure while you're trying to do that. It wouldn't be a big deal either if you could lower it by e.g. 8 pixels with regular jumps, but that it then lift up by 1 pixel every time you jump from it, making the next jumps useless. But at least you've seen it is interactive.

The 'tutorial' option is to introduce the chalk gate first in a setup where the player is guided into thinking that it is a 'jump-through' platform, but reveal that it actually breaks when Bilou knocks it from below.

Alors ces derniers mois, j'ai rajouté quelques croquis dans mon cahier-design que je vous renumérise ici (panne de scanner) qui étaient sous-titrés "où on apprend que la craie, ça casse". Histoire que le joueur ait déjà des informations à propos de ce type de bloc quand il va devoir réfléchir à son sujet. Je sais: j'avais donné comme ligne de conduite pour Dreamland "on s'autorise des portes-qui-téléportent, des clés, des serrures et des interrupteurs", et dans le design d'origine, c'est un simple interrupteur qu'on utilise. Mais on est tellement proche d'un mécanisme intégré dans le monde du jeu que ce serait dommage de ne pas vérifier que c'est jouable...

And once you know they are breakable, it is much easier to create a setup where you learn that they can also be broken if you fall on them with sufficient speed. Especially if I add some screen shaking when you hit plain ground with that speed... and ask my brother to give me a dedicated sound effect for that.

Sinon, une dernière option serait que chaque saut sur la craie la fasse descendre d'un pixel si la vitesse de collision est insuffisante. De quoi confirmer au joueur que oui, c'est pas interactif et que oui, c'est en tombant que ça va marcher, mais là, ce n'est pas encore assez. Elle n'exclut pas les écrans préliminaires, cela dit... Avec un peu d'écran-qui-tremble quand Bilou arrive sur le sol avec une vitesse suffisante pour casser des choses, ça pourrait faire un combo gagnant.

Being so close to actual organic gate mechanics, I feel like it would be a pity to come back with a plain old key opening a plain old lock.

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.

Pyramid mechanics

Jusque là, j'avais prévu de me servir des "blocs poilus" pour servir de blocs destructibles dans la pyramide, mais je crois bien que j'ai trouvé mieux. Et tout simple, avec ça: des pots. Eh oui. Ils peuvent être brisés, ils peuvent libérer des trucs, ils peuvent bloquer le chemin de Bilou.

Bilou peut naturellement ramasser des trucs. Les pots aussi, mais on peut faciement dire que seuls ceux qui n'ont rien par-dessus. On peut construire plein de scènes sur cette base-là, où un 'mur' de pots bloque un accès, qu'on ne saura libérer qu'avec une carapace de scorpion.

What can play the role of breakable blocks in the pyramid ? I once thought it could be furry blocks, and possibly I'll keep them in some places ... but building walls with them ? or large structures like SMB3 "pyramidal stack" ? I finally found something that could work better. Okay, lifting up jars and throwing them against walls to get goodies isn't exactly an original mechanics, but it would work fine with the pyramid setup as well as with a shell from a scorpio.

On peut en imaginer des 'intacts' qui font faire demi-tour à la carapace et d'autres déjà fendus qui laissent passer d'un coup.

Enfin, on peut ranger des pots sur une étagères, on peut les faire tomber en cognant l'étagère ... bref, ils peuvent servir de 'briques en l'air' qu'on casse en tapant dedans par le bas.

L'autre truc qui ne me branchait pas, c'est les lanceurs de flèches. J'avais une note proposant 'des statues de chat pour les boules de feu, des statues d'aigle pour propulser vers le haut'. Mais des piafs embusqués qui tentent de becquer Bilou et dont on peut utiliser le cou comme tremplin-à-la-Ori, ça serait sans doute nettement mieux.

One other thing needed more thoughts: wall hasards. Like arrow throwers or spears pointing out and coming back. I loved the idea of them being helpful to climb up with the right timing, but we've been served the cliché of climbing up spears stuck into walls after you dodged them so many times ... It wasn't too clear what would throw them either.

But given how birds are expected to play a major role in the last world of "Bilou Dreamland", I thought "why not long-neck beaked baddies trying to snap Bilou and then getting stuck into the wall facing them, so we can use their neck to climb up ?

vannes à encre

Il y a bien eu quelques "vannes à fermer" dans School Rush mais la plupart des autres niveaux avec des zones d'encre dont la hauteur est variable, l'idée est plutôt de provoquer un transfert d'une zone vers l'autre, ou de déclencher la montée de l'encre qu'il va falloir prendre de vitesse.
J'aurais bien pris un mécanisme à la Fury of the Furries (un bloc à tirer pour créer un passage), mais il ne s'agit pas d'eau ici, mais d'encre-qui-blesse. Le plus prometteur serait d'utiliser un "accident" provoqué par un pendat qui se serait mis en chasse de Bilou.

Granted, there are a few “ink switches” in schoolRush, but most of the levels sketched which feature areas with variable ink level are designed around the idea of moving ink on-demand from one place to another. Original sketches suggested pull-me-blocks directly inspired from Fury of the Furries, but this is nor water we could swim in, but rather toxic ink. I think it would work better if we instead use pendats …

Ori et les tutoriels

Après autant le stress et les efforts de ce que je considérais comme le boss de l'arbre, je me serais attendu à une petite cinématique de détente. Que nenni. Me voici pris au piège dans un "évènement" de montée des eaux qui nous met sous pressions, avec une nécessité d'avoir maîtrisé la nouvelle compétence "BASH" à un niveau encore supérieur, alors que les terrains pour la prendre en charge deviennent progressivement inaccessibles. C'est l'inconvénient de cette nouvelle génération de platformers aux sauvegardes contrôlées et aux vies infinies: si vous n'y prenez pas garde, vous pouvez vous retrouver condamnés à passer un pic de difficulté avec une quantité insuffisante d'équippement ou d'entraînement. Il m'aura fallu pas loin de 40 tentatives étalées sur tout une semaine pour en venir à bout.

With all that stress in the ultimate puzzle room of the Ginso Tree (up to the point that I thought I had beaten a boss), I was expecting a sort of congratulation cinematic or at least a quiet time. How fool I was! Here I am, trapped into an "event" with rising water. Even more pressure, requiring to master the BASH move up to another level, with floor estate to use it shrinking again and again.

To some extent, it shows one of the limit of those 'new-generation' platformers with controlled save spots and infinite lives: if you aren't monitoring how much equipment/health/training you have, you may end up with no alternative but fighting against the same difficulty cliff again and again, with no other things to explore in the game. Here, it cost me almost 40 tries.

Un peu plus tard dans le jeu (les bois brumeux), je tombe sur une séquence d'escalade où il va falloir cette fois maîtriser BASH exclusivement dans l'air. Le coup de la longue traversée en propulsant les projectiles des adversaires, c'est déjà chaud. Mais ici, il va falloir le faire tout en planant d'un projectile à l'aurtre pour laisser le temps à leurs lanceurs de se manifester et de préparer leur nouveau tir.

Cette fois c'est dit: j'y vois un défaut dans la conception de la courbe d'apprentissage du jeu. Les phases d'apprentissages libre étaient à coup sûr insuffisantes!

A bit later, I stumble upon another climbing challenge (in Misty Woods) where you need to have mastered the mid-air BASH move. A long set of BASHes using ennemies' bullets is already tricky to do. Having to do so while gliding from one baddy to the next so that they have enough time to prepare their next shot pushed me close to my drop-the-game limit. 

At that point, I was convinced that there was a huge issue with the game's difficulty curve and the lack of free-to-play tutorial areas for the newly gathered skills. Before you grab BASH, there have been other mechanics to master. That makes sense: we're somehow in a metroïdvania game. But both were mere extensions to the JUMP mechanic: against walls or double-jumps. They are introduced in the now-classical dead-end that you can only leave using the new mechanic.

Avant BASH, il y avait déjà eu d'autres mécaniques à apprendre (logique: on est dans un métroïdvania): le wall-jump et le double-jump. Elles sont présentées (coup classique) dans un cul-de-sac dont on ne sait ressortir qu'en ser servant de la nouvelle mécanique. Si c'est un poil trop classique, ça signifie que pendant qu'on s'adapte à la nouvelle mécanique, on est en terrain connu et stable. Les mécaniques sont classiques elles aussi, et viennent assez naturellement, puisqu'il suffit de presser davantage sur le bouton de saut.

Pour arriver jusqu'au BASH, il aura fallu traverser tout une première partie de l'arbre Ginso .. une série d'épreuves qui demandent essentiellement la maîtrise de la dernière compétence acquise: le double-saut. (inattendu pour moi qui suis habitué aux donjons Zelda où la première phase est assez neutre en termes de mécaniques à maîtriser)

Une fois BASH acquis, il y a bien une série d'écrans-tutos avec aussi des boîtes de texte du style "presse X pour attrapper un ennemi et te projeter". Ah. Autant pour mon impression d'avoir été jeté dans la mélée sans préparation.

L'écran suivant va un cran plus loin, avec le mécanisme de projection des boulettes. Ici on peut non seulement se propulser mais aussi "tirer" dans la direction opposée. A défaut d'être en terrain connu, chacune des "salles" est assez petite pour qu'on ait la situation claire sous les yeux. On devrait donc être en mesure de voir ce qu'il y a à faire et se concentrer sur les manipulations nécessaires pour y parvenir.

Puis les choses deviennent plus sérieuses: tentacules tireuses (qui réagissent à notre présence, contrairement aux tireurs de boulettes périodiques), disparition du sol stable, téléporteurs à anticiper, ... Il faudra gérer la portée du BASH en l'air (apprendre une distance implicite), combiner le bash avec le double saut. Et la présence de tous ces pics nous décourage de créer un nouveau point de sauvegarde intermédiaire.

Then you face that "half-boss" monster

Il ne restera plus que la confrontation avec un ennemi qui fait demi-boss où l'on apprend qu'on peut renvoyer les tirs de n'importe quel adversaire.

Je dois bien revenir sur ma première impression après avoir refait cette section-là: il y avait bel et bien une phase tutorielle (même si essentiellement maquillée au notuto) et on y apprend bel et bien tout ce qu'il faut savoir avant d'attaquer la grande montée d'eau dans l'arbre Ginso.

Et si je compare avec la vitesse à laquelle on est supposé avoir maîtrisé le "charged wall jump" (qui arrive sur la fin du jeu) l'entraînement et l'exploitation étaient assez clairement découpés.

Ici (mont Horu?) on doit dès la deuxième utilisation utiliser des suites d'actions relativement longues et complexes. (wall jump suivi d'un double jump et on s'accroche pour escalader la paroi). Mais il est vrai que comparer à BASH, le nombre de paramètres à apprendre est réduit: pas de timing, pas de distance de capture de l'action, pas de précision à acquérir. Juste la portée résultante.

No precision to master, this time

Dans le code de Celeste ...

Je m'étais fait une conversion epub du code de Celeste, peu après avoir reçu mon boox, pour étudier un peu tout ça pendant que *deline était à son cours de sport. Il faut bien dire que ce n'était pas simple à suivre, entre les hyper-jump et compagnie. Mais ici, un des développeurs vient de tweeter une série de mini-vidéos pour montrer toutes les ruses de gameplay qui ont été mises en place pour que le gameplay soit satisfaisant.

A few time after I got my first boox, I found the code for the game Celeste by Matt/Maddy Thorson. It seemed appropriate to study it while *deline was having sports in the evening, and it did give me some difficulties with all those hyper-jumps and similar advanced techniques. Especially since I barely started a game of Celeste on my switch and I'm nowhere in mastering those advanced moves. But the developer did tweet a list of 10 tricks they used to make the gameplay more satisfying.

Oh, j'ai une partie en cours sur Switch, aussi ... mais M. Oshiro en furie me mène la vie dure.

• De 1 à 4: on a des techniques équivalentes dans Bilou
• 5 - contourner les coins au lieu de se cogner la tête dessus. Pas encore.
• 6 - s'aligner sur une plate-forme à sens unique quand on passe à travers
• De 7 à 10: différentes manières d'étendre les zones de collisions avec les murs / plate-formes pour compenser des pressions de touches un peu tardives de la part du joueur (un peu comme le vile-coyote-time, mais dans d'autres circonstances - notamment pendant un wall-jump).

edit: ça y est! j'ai passé M. Oshiro!

Tiens, pour la comparaison, on atteint quand-même les 5000 lignes de code pour Player.cs (qui pourrait contenir plus que le code de Madeline, hein)

The tricks are the following (if twitter dies, they are hosted on "Celeste & Forgiveness" with their original animated gifs)

1	coyotte time	You can still jump for a short time after leaving a ledge.	done
2	jump buffering	If you press and hold the jump button a short time before landing, you will jump on the exact frame that you land.	done
3	Halved gravity jump peak	If you hold the jump button, the top of your jump has half gravity applied (gives more time to adjust for landing)	done
4	Jump corner correction	If you bonk your head on a corner, the game tries to wiggle you to the side around it.	todo
5	Dash corner correction	if you dash sideways and clip a corner, it'll pop you up onto the ledge.	todo
6	Dash corner 2	also pop you up if it is a semi-solid platform	todo
7	Lift momentum storage.	Add momentum of upwards-moving platform to regular jump impulse, but allow to use it even a few frames after platform stopped moving upwards.	done
8	coyotte wall-jump	you can wall-jump 0.25*playerwidth away from the actual wall	d.n.a.
9	8 for super-wall-jump		d.n.a.

(the 'done/todo' status indicates whether I have a corresponding solution in Bilou's game engine/state machine)

Ori and the difficulty curve

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

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

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

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

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

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

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

Please define 'casual'

Is the NintendoDS retro ? will it ever be ? the question raised on twitter. Thinking about it, how it was launched and how different the titles available at launch were from other now-definitely-retro consoles (including SNES, PS1, and even GBA),
I'd say the NDS will have harder time to feel retro in general (although some games certainly will). The reason is that, by the time the Nintendo DS came out, the kind of games we played had changed significantly. GBA games play much like slightly simplified versions of SNES games all over the life time of the console. And they play themselves much like more refined versions of the NES games. The reason for all this is the controller.

To me, holding an SNES controller is a well-known feel. I don't have to think about where X or A stands. It is immediate. And it definitely wasn't the case when the SNES cames out: SMW gave me a hard time compared to the 1-button + dpad games I was used to (okay, I pressed SML B button from times to times). And for most games on those devices, it was frequent that you'd need to train yourself to the core mechanics and grow your controller skills before you could proceed further than world 1.

The DS, instead, came up in the world of casual games. Not games that you happen to play casually (as opposed to competitively), but those explicitly designed so that you don't really need training to experience their core gameplay. Zoo Keeper, for once, perfectly fits that line of titles targetted at bejeweled players. They're built around more intuitive and direct actions (thanks to the stylus). Any grown up can start playing them even when they have almost no training with gaming devices. They don't require players to know that they should hunt for 1-UPs or stock power-ups if they want to stand a chance against the end-of-world boss. Really, these are games that Hudson Hawk could have enjoyed despite he's been in jail since Pong is out.

That doesn't mean that there are no retro-like games on the system, but they were pretty rare gems compared to the avalanche of stylus-driven titles. And chances are that the youngster who had a DS as her first gaming system will have nostalgy towards titles that no longer plays like a DPAD+buttons retro game.

Will the NDS ever be retro ? of course. But it might have to wait until we no longer use touch screen as our primary model to design games. When virtual/augmented reality games become the norm, maybe.

Augmentons la Gravité ?

J'ai eu l'honneur (et un peu la chance, il faut l'avouer) d'avoir un retour de Romain Claude -- dévelopeur principal de Splashers sur mon School Rush. Un feedback assez technique et qui ne sera pas facile à prendre en compte, parce qu'on s'attaque ici au coeur du gameplay.

Mon principal retour pour le moment concerne la prise en main, que je trouve assez raide. De plus, le fait que le jeu soit assez mou rend le tout assez hardcore, même en facile ... Côté contrôles vous devriez avoir un air control progressif (de moins souple à beaucoup plus souple), et ceci marié à une gravité plus forte rendra la prise en main plus réactive et agréable. Par contre pour retrouver la même hauteur de saut il faudra augmenter la valeur de l'impulsion.

I'm honoured and proud that Romain, main designer of the platformer "Splasher" took the time to try and give detailed and technical comment on my own "School Rush". In the upcoming weeks, I'll likely be busy understanding the implications of his proposals and doing attempts to adjust the gameplay of SchoolRush accordingly.

The first suggestion is to increase the gravity to get more a reactive experience -- which echoes a comment from Kirby Kid in a previous iteration. That's not something to be taken lightly, though. Many things in the game depends on the gravity. Changing it by a ration g'/g means that you have to modify the jump impulse v1 so that the maximum height of the jump -- v1²/2g -- remains constant. But even so, the amount of time you stay in the air is reduced due to the increased gravity, meaning that the distance you can clear with a jump is shortened.

Mais changer la gravité, c'est changer beaucoup de chose. En plus d'ajuster la puissance de l'impulsion, je dois aussi ajuster la vitesse de déplacement de Bilou puisque le temps qu'il passe en l'air, lui a été réduit. Sans celà, il faudrait revoir tous les obstacles du jeu.

En fait, une fois tous les paramètres dépendants de la gravité réajustés, on a le même jeu mais avec le temps accéléré. Ce n'est pas déplaisant, mais ça va demander aux joueurs d'être plus alerte, parce que du coup, je vais devoir aussi augmenter la vitesse de l'encre sans ça elle est complètement à la traine. Peut-être devrai-je aussi accélérer les pendats...

By increasing the walking and the jumping speed of Bilou with the appropriate factor, I can keep the levels unchanged and enjoy a more engaging gameplay. I'll have to speed up the rise of the ink: at the moment, the game has turned too easy and I might also have to speed up pendats, so that Bilou don't outrun them too easily, which will shrink the response time allowed to the player (to 86% of the current value for g'/g=4/3) ... but it still leaves 500ms+ to react, so that should work.

J'essaierai celà dit d'éviter "l'effet Meat Boy" si je le peux, à savoir d'avoir le contrôle en l'air tellement élevé que l'on finit par "glisser" dans l'air et se déplacer plus vite horizontalement que verticalement. Mais en ajustant la vitesse horizontale maximale, il devrait y avoir moyen d'éviter ça.

Directly linked to the change of gravity, Romain suggests progressive air control. The current code controlling Bilou has some momentum while mid-air with an acceleration that is 1/2 of the one you have on the ground.

In his interview about Splasher, Romain says:

Air control is a touchy subject: you need sufficient control so that player can compensate for an imperfect impulse (imperfect timing or speed) while still having an interesting skill floor, but not give too strong air control, else the player will [go wild at uncontrolled speed] at the slightest move of the joystick.

To balance things in Splashers, Romain used delays, so that the air control just after the impulse is not as strong as it is some frames later.

This happens in Super Meat Boy too, with a character that initially struggles to work against its original impulse, but that gets increasing amplitude as you maintain the joystick pushed into one direction. To be honest, Super Meat Boy isn't one of my reference in terms of gameplay. I would even consider it as a counter-example of convincing physics

Dans le "School Rush" actuel, j'ai un système qui encourage le joueur à prendre le temps de courir avant de sauter: une fois en l'air, on peut ralentir et faire demi-tour (Bilou reste tout de même un explorateur de l'espace, ça offre quelques mouvements inaccessibles aux simples humains), mais on ne pourra jamais atteindre à nouveau la vitesse maximale avant d'avoir touché le sol pour courir à nouveau.

Ma première tentative pour m'approcher du "contrôle de plus en plus souple" (que je traduis par "augmentation linéaire de l'accélération horizontale avec le temps passé en l'air") consistait simplement à autoriser une vitesse horizontale plus grande en phase descendante par rapport à la phase ascendante. Mais ça, ça n'a pas été un succès.

Pause Ahead

Très sympathique petit jeu que ce "pause ahead". Un petit labyrinthe, un personnage qui se cherche, et un mécanisme de gameplay tout à fait intéressant de manipulation du temps. La mise en pause n'agit pas complètement sur le personnage: il conserver son inertie et "dérive" sans que plus aucun danger ne puisse les blesser. Un mur pourra par contre annuler leur déplacement horizontal ou vertical.

Au bout de quelques niveaux, malheureusement, c'est devenu trop dur pour moi. La marge de manoeuvre pour construire la bonne vitesse, et le timing autoriser pour y parvenir devient trop juste pour un "casual gaming" du soir.

PS: le temps d'écrire ceci, de finir d'écouter ma fée, mon laptop s'est mis en mode "powersave (800MHz)" et le jeu s'est du coup ralenti au point que j'ai pu avancer jusqu'au boss (final?). que je n'ai quand-même pas pu finir. "Don't dumb it, slow it down", qu'il disait.

En direct de Leilani's Island

Dans son petit coin de web, Ishi (Craig Forrester, auteur de Johnny biscuit et Princess Chardonnay entre-autres) nous prépare un adorable jeu en pixel art dont le gameplay rappelle assez bien celui de son jeu favori: Wario Land. Bien qu'étant un jeu de plate-formes, le jeu s'articule surtout sur la "roulade" de cette charmante protagoniste. Du coup,

• la roulade permet d'aller plus vite que si on courait,
• la roulade permet d'attaquer certains ennemis de face, plutôt qu'en les écrabouillants. En fait, tout comme dans SML3:WL, sauter sur un ennemi ne l'élimine pas. Faire une roulade bien.
• le saut est volontairement limité (3 blocs, 4 en rebondissant sur un ennemi) pour qu'il soit plus intéressant de se servir de la roulade que de l'éviter.
• Certaines plate-formes (les cordes) ne peuvent être traversées qu'en roulade. 
• C'est en poussant sur ROLL en l'air qu'on lance l'attaque spéciale de la fleur de feu, et parce que ça fait bizarre que le bouton ne fasse rien dans certains cas, Ishi ajoute un "annulateur de saut" pour celui qui fait "ROLL" en l'air sans avoir ce power-up.

Hats off to Craig Forrester (Ishisoft) for his brilliant work on Leilani's Island. I hope he won't mind that I keep note here of the good design decision he took to have the game focus on one rich, interesting and funny mechanic: the island girls' ROLL move. If you really don't read French, I suggest you randomly click links in the French text to be sent to some of Craig's updates that I found especially interesting. I hope I'll be able to make Bilou's Adventure as rich as this. Btw, have you noted that Craig selected the 400x240 resolution of the 3DS ?  

Décision sympathique, c'est en ajoutant une fleur dans ces cheveux que Leilani augmente sa force. Et oui, elle peut aussi utiliser une fleur de feu. Mais ici il s'agira d'une attaque-roulée plongeante, capable de détruire des blocs. La combinaison de l'attaque-rodéo de Mario et le bouclier de feu de Sonic. L'utilisation de la diagonale lui permet de rendre les choses plus prévisibles (plus de timer "chéri, ça va couper"), plus faciles à viser (qu'à l'horizontale, en tout cas), et moins génant pour celui qui voulait simplement faire une roulade en atterissant. Bien vu.

Avec son mécanisme de "j'te roule en boule", le jeu permets plein d'aspects-puzzle, renforcé par les effets de réactions en chaîne sur les blocs. Oui, parce que -- contrairement à Bilou jusqu'ici -- le jeu assume pleinement l'héritage de Mario avec des blocs-à-bonus que l'on peut frapper verticalement ou latéralement, et d'autre blocs qui se fractureront si on les frappe assez fort. Cette histoire de réaction en chaine est encore renforcée par des séquences d'objets. Bref, côté éléments à coder, Ishisoft n'est pas en reste.

C'était déjà riche comme ça, mais Ishi nous rajoute encore les fruits, éléments interactifs un peu comparables aux carapaces de koopa, sauf que je n'en ai pas encore vu blesser le personnage. Et pour s'assurer que tout va bien, rien de tel qu'une map-unit-test qui montre en un écran toutes les interactions possibles entre les différents éléments du jeu.

Ishi nous dévoile aussi un truc que je ferais bien de réutiliser dans le développement de Bilou:  l'enregistrement de la trajectoire lors d'une scéance de jeu qui peut servir par la suite à placer des bonus précisément sur la trajectoire proposée au joueur (c'est très KirbyKid-esque, ça ;)

Il est aussi fréquent qu'il teste ses idées de jeu (ennemis, éléments spécifique à un environnement) dans un décor de blocs colorés tout génériques ... le graphisme vient alors plus tard.

Il me reste un gros morceau à lire: le système d'interaction entre les objets.

Object-to-Object collision has been recently revamped in Leilani's engine. In most collision, one object sends several "collision probe", to which the other object replies with either "NONE" or with a custome message indicating how the originator (typically Leilani herself or a rolling baddie) should react.  I think I keep preferring my own approach combining the active/passive roles of Out'm'Up with the CAN_xxx flags of Xargon Engine.

In my engine, I'd have

• Leilani.walk { test F_COLLECT ; area F_HIT }, 
• Leilani.roll { test F_COLLECT|F_ROLL } as well as Baddie.roll { test F_ROLL|F_COLLECT }. 
• Shells would be passive and have only {area F_COLLECT }. Possibly you could need a second flag for F_COLLECT_PUP, so that only Leilani gets flowers. 
• Spiky.walk would have { test F_HIT; area F_ROLL } : it actively hurts leilani, but may be rolled into.

those "test" and "area" commands may correspond to distinct hit boxes, allowing e.g. spiky to be rolled in the back, but still hurt in the spike.

Beyond the blogosphere.

Yes, I am nostalgic of the time I had plenty of things to discover on my Google Reader, and I have a feeling that the blogosphere has disappeared -- at least the one I was part of. I'm trying to re-construct a similar network, and I came to the conclusion that twitter alone won't suffice my needs.

Ce n'est pas vraiment comme du temps de Google Reader, mais j'ai trouvé un ou deux presque-blogs intéressants. Pour ce soir, on va plutôt parler des mini-vidéos de Keith Burgun. Pour aller plus loin que les questions-réponses de Mario et Socrates, il nous propose quelques étapes qui jalonnent le chemin jusqu'à un jeu (un vrai ?)

There are a few interesting things that happen on Youtube. The good thing is that they are easy to watch while I'm preparing the dinner or cleaning the kitchen mess. The bad thing is that they are hard to find back, when you want to reference them to someone. Yesterday's pick was a tube from Keithburgun about the layers that turns an interactive item into a game. Something I bet Kirby Kid would have enjoyed although he might use a different terminology.

Pick something that people can interact with, but don't give any rule, any objective, just freedom to explore what is possible and what isn't with that item: you have a toy. Some "video-games" are actually toy, although they're more often coined as "sandbox games". My early "demo levels" are typically toys. Playing "School Rush" in easy mode almost turns it into a toy as well.

Au commencement, il y a le jouet. Le jouet, c'est juste un truc avec lequel on peut intéragir, c'est tout. Pas de règle, pas d'objectif venant de l'extérieur. Juste l'objet et la possibilité de découvrir ce qui est possible de faire avec .. et ce qui ne l'est pas. Certains jeux vidéos sont volontairement de tels "bac à sable", mais parfois on essaie juste de faire un jeu et on termine sur un jouet. C'est sans doute ce qui guette de nombreux projets de jeu de plate-forme : sans un objectif défini, on sait juste explorer les possibilités du moteur de jeu. Autre élément intéressant: en mode "easy", rien n'empèche un joueur (plus jeune) de se servir de School Rush comme d'un simple jouet.

Put a goal to a toy (some condition to which you can say "congrats!") and you get a puzzle -- or at least something that is functionally equivalent to a puzzle. It can be as simple as "collect all the blinking items on screen", but it will only be truly a puzzle if you have unlimited attempts and significant freedom to reach the goal. If I remove bonus-counting from the 'anniversary level', it is likely to turn closer to a puzzle: you can retry as much as you want without loss (further than your actual position), and each challenge is essentially to find out how to proceed through.

Pour passer au "puzzle", il faut ajouter un objectif. Quelque-chose qui décide qu'un état du jeu est "gagné" ou "résolu". Ramasser tous les . Détruire tous les . Avec plus ou moins d'effort de réflexion selon les gens que l'on cherche à intéresser, en fait. Si on élimine les contraintes du type temps-réel pour les présenter comme un RPG de table, la plupart des jeux de plate-forme où il faut atteindre la fin du niveau se transforment en puzzle: 

• P: alors je saute par-dessus le picot sur la plate-forme
• MDJ: la plate-forme s'écroule
• P: je re-saute plus vite et j'active mon hélicoptère

Pour que ce soit un vrai puzzle, j'imagine qu'il faudrait aussi pouvoir revenir un pas en arrière presqu'aussi souvent qu'on veut. Dans une certaine mesure, avant que je n'ajoute le système "plus on a ramassé des bonus et plus on a une image intéressante à la fin du niveau", le niveau-anniversaire de Bilou dans l'école était très proche d'un puzzle.

Add session limitation (e.g. time constraint) to such a interactive+goal and you get a "contest". A contest is something where you measure some skill of yours, and compare that measurement with what others achieved. I bet C64 ski was essentially a contest: turn left or right, avoid obstacles, hit the gates. The score will tell how well you performed. Unlike a puzzle, a contest cannot be "solved" -- i.e. put in a state when there is nothing more you can do about it. As soon as you reward players of your labyrinth depending on how fast the found the solution, you're turning the puzzle into a contest, because they could try and improve their score.

Ajoutez des limites sur le fonctionnement du puzzle et on arrive à une forme de concours. Ce n'est plus seulement "trouve la sortie du labyrinthe" mais "sors du labyrinthe le plus vite possible". Il n'y a plus uniquement une décision "gagné/perdu", mais une mesure de la performance. Pour un véritable concours, l'idéal, c'est qu'il n'y ait pas de minimum absolu imposé à la performance (sinon, en fait, on passe dans une version plus sophistiquée du puzzle, tout simplement).

Le dernier pas à franchir pour obtenir un jeu c'est que le joueur n'a pas l'entièreté de l'information qu'il faudrait avoir pour s'y attaquer comme à un puzzle. Que ce soit parce qu'il affronte un autre joueur dont la stratégie ou la main lui est inconnue, ou parce que le jeu ne lui dévoile qu'une petite partie (la vidéo) de l'état du jeu (vecteur vitesse, compteurs internes, taille et emplacement des zones de collisions, etc.) Si le joueur pouvait voir à tout moment les trajectoires futures des ennemis et de ses projectiles avant de décider de tirer, on fait un pas en arrière pour se rapprocher d'un puzzle et s'écarter d'un jeu.

Chose intéressante, si on suppose que SMB est effectivement un jeu à cause de l'ensemble de détails qui sont inconnus du joueur lors de sa première approche, un entrainement et un apprentissage suffisants permettent au joueurs de l'aborder comme un pur concours (le speedrun).

To some extent, I am tempted to consider Apple Assault as such a contest. There is a goal (punch all the apples), but there is limitation both at large-scale (berry-bats will get you if you don't progress) and at small scale (press the buttons in time or you will be hit by the approaching applemen).

What Keithburgun calls "a game" is a contest where the gamestate is obfuscated. You're forced to make decision based on incomplete knowledge of what happens. That's clearly the case when you play against an opponent and don't know what she planed to play next. Or where her units are. That's the case when you play "Apple Assault" and don't quite know what the hitboxes or the behaviour of applemen are. Technically speaking, the game is solvable (? doesn't that kill its "contest" component ?), just like a puzzle, but in practice, you have to rely on heuristic strategy to overcome your own human limitations.

I would be tempted to add that some video games that are primarily skill-based can turn into pure contests once player have fully understood the rules of the game and become capable of anticipating -- through memorization, trial-and-error or modelling of the software threads -- any progress of the game state. That is, imho, what happens when players starts speed-running a game like Super Mario Bros. There's nothing more they have to understand about the game. It just became a super-evolved instance of a virtual parkour and they're in a contest to see how fast they can manoeuvre within it.

Another interesting idea from Keith is to define a mechanics as the combination of an action and a purpose. In Ishisoft's "chardonnay in Bomb Kingdom", for instance, we have "fire a bomb to jump" and "fire a bomb to blast a wall" as two separate mechanics. Yet it makes it difficult with that definition to describe "core mechanics"