La première version de BELTRUNNER n’était pas très bonne.

Matt Sephton avait construit un shooter orbital. Des cibles numérotées restaient sur des orbites fixes autour d’un soleil. Le prototype fonctionnait rapidement dans son nouvel outil Jinks, mais jouer revenait trop souvent à tirer sur des cibles immobiles.1

Il a jeté la structure orbitale.

Il a gardé les numéros, l’idée d’une chaîne et quelques éléments visuels. Puis il est revenu vers Asteroids.

Le postmortem de BELTRUNNER est intéressant précisément pour ça : il ne raconte pas une idée brillante exécutée d’un coup. Il montre comment un jeu emprunte des règles à quarante ans d’arcade, les teste, les casse et les transforme en quelque chose de neuf.1

Commencer par un jeu que le joueur connaît déjà

La première vague ressemble volontairement à Asteroids.1

Un gros rocher. Le vaisseau glisse avec son inertie. Les rochers se divisent. Le joueur apprend à bouger et tirer sans tutoriel lourd.

Puis le champ est nettoyé. Un trou noir s’ouvre. À la vague suivante, le vrai jeu apparaît : des portes numérotées doivent être traversées de 5 à 1 pendant que les rochers continuent à dériver.1

Sephton cite Donkey Kong ’94 comme inspiration pour cette fausse familiarité : commencer comme un jeu connu avant de révéler le système différent caché derrière.1

Ce choix remplit aussi une fonction pédagogique. Quelqu’un qui connaît Asteroids utilise immédiatement sa mémoire musculaire. Quelqu’un qui ne le connaît pas dispose quand même d’une vague entière pour comprendre le déplacement avant que la course ajoute une nouvelle contrainte.

Le tutoriel est le jeu lui-même.

Une mécanique, puis du temps pour l’apprendre

BELTRUNNER contient seize vagues organisées en quatre actes de quatre.1

Chaque acte introduit un nouveau comportement de porte, puis laisse plusieurs vagues pour le pratiquer avant de passer à la suite. Sephton appelle cette cadence « introduce → practice → practice → close » et l’associe à une manière très Nintendo d’enseigner une mécanique.1

Le point intéressant n’est pas le nombre quatre comme formule magique.

C’est le refus d’empiler immédiatement les nouveautés. Une mécanique vue une fois n’est pas encore apprise. Le jeu doit laisser assez de place pour que le joueur se fasse surprendre, comprenne ce qui s’est passé puis commence à anticiper.

Dans le code, les vagues qui gardent la configuration précédente peuvent même être presque vides : seules les différences sont décrites.1

Remplacer le hasard par un parcours qu’on peut connaître

BELTRUNNER utilise un flux pseudo-aléatoire déterministe.1

Les positions de départ, directions, placements et dispersions viennent d’un seed unique. Avec le même seed et les mêmes inputs, le parcours se reproduit.1

Sephton préfère cette logique aux variations entièrement imprévisibles parce qu’elle permet au joueur d’apprendre un « parcours » comme dans Pac-Man ou Donkey Kong. Elle simplifie aussi les replays et le réglage : on change une règle tout en rejouant exactement la même situation.1

Même les power-ups évitent la loterie. Un drop est armé toutes les huit destructions de rocher et suit une séquence déterminée au lieu d’utiliser une probabilité du type « une chance sur huit ».1

Le jeu peut donc sembler chaotique sans être arbitraire.

Enseigner un secret avec une note qui disparaît

Un autre système est presque invisible.

À partir de la vague 2, un gros rocher est mis en évidence. Le casser fait entrer une voix soutenue dans la musique : fondamentale, tierce, quinte, octave. Il faut ensuite casser les rochers éclairés dans le bon ordre.1

Si le joueur casse le mauvais, les voix s’arrêtent.

Aucun texte n’explique la règle. L’échec s’entend.1

Suivre la séquence finit par révéler un rocher en forme de trèfle qui libère un bonus secret. Avant de l’avoir découvert, la légende affiche ????. Après, elle montre EXTRA.1

C’est un joli usage du son comme canal de feedback. Un petit indicateur visuel manqué est facile à ignorer dans un écran rempli de rochers. Un accord qui s’interrompt brutalement est plus difficile à ne pas remarquer.

Le jeu n’explique pas le secret. Il donne au joueur les moyens de formuler l’hypothèse.

Les mauvaises idées nourrissent l’outil

Le postmortem contient beaucoup de petits changements provoqués par le jeu réel.

Les premières portes étaient rondes. Les passages rasants donnaient de mauvaises collisions, elles deviennent elliptiques. Le bonus STOP gelait d’abord les rochers mais laissait le chrono tourner, ce qui transformait la pause promise en piège ; le chrono finit par être gelé lui aussi. Un raccourci WARP apparaissait initialement au moment même où une nouvelle mécanique était introduite, donc exactement quand le joueur avait besoin de rester pour l’apprendre. Il est déplacé plus tard.1

D’autres problèmes ont forcé Jinks à gagner de vraies collisions polygonales, des ellipses orientées, une géométrie torique cohérente aux bords de l’écran et une simulation de rebond plus crédible.1

Sephton insiste sur un principe : ces ajouts ne restent pas codés spécifiquement pour BELTRUNNER. Ils rejoignent le moteur commun parce qu’ils peuvent servir aux jeux suivants.1

C’est une bonne manière de construire un outil créatif. Ne pas dessiner abstraitement toutes les fonctions qu’un moteur pourrait avoir. Faire un jeu, laisser le jeu casser l’outil, généraliser seulement ce qui a réellement été nécessaire.

Jinks reste une promesse en cours de construction

Jinks lui-même n’est pas encore publié.2

Sephton le décrit comme un moteur léger, un environnement de développement interactif et un langage dédié au jeu. Le core reste indépendant de la plateforme, chaque machine fournissant un shell mince qui dessine et joue ce que le core demande.2

Il affirme déjà utiliser le même core sur le web, macOS/iOS, Linux et du matériel plus ancien jusqu’à la Wii et la Dreamcast.2 Ce sont les déclarations du créateur ; nous ne les avons pas reproduites indépendamment.

Le système est conçu pour garder les jeux petits. Sephton annonce 475 lignes pour sa recréation d’Asteroids et environ 1 278 pour BELTRUNNER.2 3

Le nombre de lignes n’est évidemment pas une mesure de qualité. Ici il signale plutôt l’objectif : garder les règles du jeu lisibles et éloigner le plus possible le travail de plateforme.

BELTRUNNER est un bon test parce qu’il a réellement obligé ce système à évoluer.

Le meilleur outil de création n’est peut-être pas celui dont la liste de fonctions est la plus longue. C’est celui qui survit assez longtemps à la fabrication d’une chose complète pour découvrir les fonctions qui manquaient vraiment.