Une heure de jeu, cinq actes, zéro ennui : penser l'accroche comme une série Netflix
Le moteur tient, le scroll fluide passe. Il est temps de penser à ce qui va vraiment compter : pourquoi le joueur continue de jouer. Une soirée à creuser les techniques d'accroche sérielle, et les mécaniques de Lore of the Ember qui en découlent.
Le problème que j'ai trop longtemps repoussé
Ça fait plusieurs mois que je bosse sur le moteur. Scroll fluide, corruption de grille, sprites préparés à l'avance, peste qui se propage sans saccade. C'est beau, ça tourne, mais aucun de ces billets techniques ne répond à la vraie question : pourquoi quelqu'un irait finir ce jeu ?
La scène homebrew Atari ST produit pas mal de démos techniquement impressionnantes. Certaines sont magnifiques. Beaucoup sont abandonnées par le joueur après 15 minutes. Un scroll à pleine vitesse ne suffit pas. Ce qui retient, c'est l'envie de savoir la suite.
Alors j'ai posé le clavier et j'ai passé une soirée à creuser une question précise : qu'est-ce qui fait qu'à 2h du matin, on clique "épisode suivant" sur Breaking Bad plutôt que d'aller dormir ? Et comment on transpose ça à un jeu qui dure 1h, en 5 actes de 15 minutes, sur une machine de 1989 ?
Les trois moteurs qu'il faut connaître
L'effet Zeigarnik
Un peu de sérieux au fond ! En 1927, Bluma Zeigarnik montre qu'un serveur se souvient parfaitement des commandes qu'il n'a pas encore servies, et oublie instantanément celles qu'il vient de servir. Le cerveau retient les tâches interrompues beaucoup mieux que les tâches terminées.
Toute la structure du cliffhanger repose là-dessus. Si tu termines un épisode de série par une action complète (la porte se ferme, le générique), le cerveau passe à autre chose. Si tu termines au milieu d'une action (la porte s'entrouvre, noir), le cerveau reste bloqué dessus. C'est mécanique, pas culturel.
La mystery box
JJ Abrams, puis Damon Lindelof sur Lost, ont industrialisé une idée simple : une boîte fermée a un potentiel narratif infini tant qu'on ne l'ouvre pas. Le piège classique du procédé, c'est d'accumuler des boîtes et de ne jamais les ouvrir. La version saine, c'est que chaque mystère résolu ouvre un mystère plus grand. Récursion narrative.
La courbe d'intérêt fractale
Jesse Schell (Art of Game Design) parle de la courbe d'intérêt : hook de départ, escalade avec des pics et des creux, climax final. Et surtout, cette courbe est fractale. Le jeu entier a sa courbe, chaque acte a la sienne, chaque salle aussi. Sans creux, les pics ne se sentent plus comme des pics. Le calme narratif n'est pas un défaut, c'est une condition de la tension.
Les jeux qui ont résolu ça en format court
Quelques cas d'étude que j'ai regardés de près, parce qu'ils tiennent de l'accroche sans être des RPG de 80 heures :
- Return of the Obra Dinn (Lucas Pope) découpe un grand mystère en 10 catastrophes autonomes. Chaque révélation recontextualise les scènes précédentes. Le cerveau rejoue spontanément.
- Outer Wilds (Alex Beachum) fait de la connaissance elle-même la progression. Tu ne débloques pas d'objets, tu comprends. La boucle courte force le joueur à enchaîner naturellement.
- Dark Souls (FromSoftware) te montre des lieux lointains dès la première heure. Anor Londo visible au loin pendant 15h de jeu, ça crée un ancrage permanent.
- Hades (Supergiant) a une narration qui observe ton gameplay et y réagit.
Appliquer tout ça à Lore of the Ember
Les principes abstraits sont une chose. Les transposer à un jeu d'une heure sur cette machine en est une autre. Voilà les directions que je retiens.
Le canal textuel dialogué avec portrait du locuteur
Au départ, j'imaginais que la narration serait silencieuse ou ultra-minimale. En creusant, je me suis rendu compte que j'avais un personnage sous-exploité : la lanterne elle-même. C'est un objet qui parle au héros. Pourquoi s'interdire de lui donner une vraie présence à l'écran ?
Donc un encart texte style JRPG 16-bit, avec à gauche le portrait du locuteur : soit le visage du héros quand il pense ou parle, soit la flamme de la lanterne quand c'est elle qui répond. Pas de boîte de dialogue qui gèle le jeu en combat. Jamais de texte pendant que le joueur peut mourir. Uniquement dans les salles calmes, entre deux combats, ou sur les écrans inter-actes.
La bonne nouvelle, c'est que la brique de base, je l'ai déjà codée il y a quelques semaines en préparant les zones 3 et 4 de l'Acte I. Une boîte basse avec le portrait à gauche et le texte à droite, pagination au bouton, flèche clignotante "page suivante". Deux portraits sont en production, le héros et la flamme. Le monde de jeu se fige proprement pendant l'affichage, sans scintillement. Plusieurs déclencheurs sont câblés sur les zones 3 et 4 : marcher sur une tuile précise lance le dialogue, et le jeu retient ceux déjà lus pour qu'ils ne se redéclenchent pas.
Autrement dit, la brique est là et elle tourne. Ce que la recherche récente m'a apporté, c'est surtout de comprendre à quoi elle doit servir narrativement à l'échelle des 5 actes, et d'identifier les quelques couches qui manquent encore par-dessus.
Le truc rusé, c'est que le portrait du héros peut évoluer sur les 5 actes. Les cernes, la pâleur, le regard. Si je fais ça bien, un joueur attentif le remarque sans qu'on le pointe jamais du doigt. Le pipeline est déjà là pour le portrait de base : il suffit de dessiner quatre variantes et de basculer l'image selon l'acte courant.
Les graines plantées
Le principe est simple : dans chaque acte, un détail passif que tu ne remarques pas. Un sprite qui traîne au fond du décor, un son qui revient, un élément qui suit le personnage sans intervenir. Ces détails ne sont pas interactifs. Ils ne sont pas signalés. Ils sont juste là.
Plus tard dans le jeu, ce détail prend un sens. Le joueur se souvient l'avoir vu. Ça crée une sensation très particulière : l'impression que le jeu savait. Que toi tu n'avais pas vu.
Techniquement, ça coûte presque rien : un sprite en plus par acte, parfois juste un élément de décor modifié.
Les fins d'acte en action interrompue
C'est la partie où je reviens le plus sur mon propre travail. Les 5 textes inter-actes que j'avais écrits étaient tous réflexifs : le héros se pose une question et la formule. Ça marche pour un roman, pas pour un jeu.
Version corrigée : chaque fin d'acte termine sur un mouvement en cours. Une main qui se lève, un bruit dans le dos, un objet qui tombe. On ne termine jamais une phrase. On coupe en plein geste. Le cerveau du joueur termine à ma place, et c'est exactement ce qu'on veut. Zeigarnik.
Le compteur visible
Détail bête qui change tout : afficher en haut de l'écran inter-acte la progression (I / V, puis II / V, etc.). Gratuit techniquement, énorme en ressenti. Le joueur sait qu'il est à 40% de la vérité. L'anticipation monte avec le compteur.
Ce qui n'a pas changé (et ne changera pas)
La règle 1 reste absolue : aucun texte ne s'affiche pendant que le joueur est en action. Pas de dialogue qui coupe l'action. Pas de cinématique qui s'impose au milieu d'un combat. Les textes arrivent dans les respirations, sur les écrans inter-actes, et dans les salles-pièges qui sont volontairement calmes.
L'autre règle qui tient : pas de PNJ bavard, pas de marchand qui raconte sa vie, pas de quête secondaire textuelle. Juste deux voix écrites, le héros et la flamme, et le silence autour.
Priorités
La boîte de dialogue tourne déjà, avec freeze et portrait. L'architecture des couches qui viennent par-dessus est verrouillée, reste à coder et à dessiner les assets. Quatre briques dans l'ordre :
- Un mode discret, non-bloquant qui réutilise la même boîte basse, mais sans pagination et sans voler le contrôle au joueur. Une ligne de texte apparaît, tient environ trois secondes, se retire, et le jeu reprend la main. Il sert aux murmures courts qui doivent glisser pendant qu'on marche. Interdit pendant un combat, comme toujours.
- Le compteur de progression sur l'écran inter-acte : "I / V", "II / V", et ainsi de suite jusqu'à la fin. Le joueur voit en permanence où il en est dans les cinq actes, et sent l'approche du dernier.
- Réécrire la fin du premier acte pour qu'elle coupe en action plutôt qu'en question posée.
Le coût mémoire de tout ça est négligeable à l'échelle du STe. Le vrai coût sera l'écriture des lignes, qui est un exercice très différent du code.
Ce que j'ai appris en faisant cette recherche
Deux choses surtout.
La première, c'est qu'on peut passer des mois sur la technique sans que le jeu avance réélement. J'avais refusé de penser au game design narratif tant que le moteur n'était pas stable. Résultat : j'ai failli arriver à l'Acte II avec des écrans inter-actes qui ne donnent envie à personne d'enchaîner. Le fait de me forcer à une soirée de pure théorie m'a évité ça.
La deuxième, c'est que les grandes idées de narration sérielle sont étonnamment compatibles avec les contraintes du STe. Une boîte de dialogue avec portrait et texte coûte moins que beaucoup d'effets graphiques que j'ai codés. L'effet Zeigarnik ne demande rien d'autre qu'une phrase coupée au bon endroit. La graine plantée, c'est un sprite en plus.
La machine ne limite pas ce genre de design. Ce qui limite, c'est l'écriture. Chaque ligne doit peser, parce qu'il n'y en a pas beaucoup.
La suite
Spec verrouillée, il me reste à coder. Prochaine session je branche le mode discret, je dessine les variantes de portrait et j'écris les textes. Dans un prochain article je reviendrai sur les choix de rendu du texte (notamment comment faire apparaître une phrase en douceur, spoiler : pas de fondu, on fait de l'écriture dactylo). Et si ça tient ses promesses, je montrerai une petite démo qui enchaîne une séquence d'ouverture avec les deux modes d'affichage.
D'ici là, si tu as des références de jeux qui ont réussi l'accroche sur format court et que j'ai ratées, je suis preneur.
Laisser un commentaire