Ceci est un retour d’expérience sur ma FI Derrière la cascade faite pour le FI Express du Concours 2026.
J’ai commencé ma FI avec la ferme intention de faire quelquechose en 4h. Promis. Je voulais vraiment. Genre, j’avais l’intention philosophiquement de parvenir à écrire ma fiction interactive en moins de 4h. Philosophiquement pourquoi ? Parce que je suis intimement convaincu qu’on (je) devrait pouvoir réussir à ne prendre que 4h pour écrire un jeu, et ainsi en faire plus régulièrement, en faire une collection qui, a terme, constituerait un très long jeu mais dont la publication serait épisodique. Ouais, j’avais des ambitions.
Bon, j’ai échoué. J’ai mis plus de 7h à faire le jeu.
Mon premier postulat, c’était de partir d’une base de code que je maîtrisais et qui me permettrait de simplement me concentrer sur l’implémentation de l’histoire. Je suis parti sur porcelaine mon petit framework en ink pour faire des fictions interactives environnementales (peu de lieux, des objets à examiner, à prendre et à utiliser). J’étais vaguement inspiré par le thème de la cascade, c’est un lieu “à tropes”, ça me semblait facile de trouver une intrigue puzzle-esque. Je suis retourné sur github pour prendre mon code et me refamiliariser avec.
On peut même dire “redécouvrir”, mon code a 4 ans et je remercie le smwhr de l’epoque d’avoir écrit un minimum de documentation pour mon moi d’aujourd’hui. Au bout d’une heure, j’avais les deux lieux (l’intérieur et l’exterieur) et une boite à ouvrir.
Il me fallait maintenant une histoire à raconter sur laquelle plaquer des puzzles. Dès le départ j’avais envie de partir dederrière la cascade, c’est mon twist. Je cherchais une motivation à la protagoniste (par défaut, s’il n’y pas de raison particulière à assigner un genre, mes personnages sont quasiment toujours genré au féminin) quand j’ai eu moi même envie de prendre une douche. Et il n’y pas plus grande frustration que de ne pas pouvoir en prendre une quand on se sent poisseux. Entre internet et l’eau courante, je choisis toujours l’eau courante, désolé pour le savoir universel, je ne suis pas fonctionnel si j’ai les mains qui collent…
J’utilise deux techniques principales quand je design mes enigmes : une que j’appelle “le milieu justifie les moyens” et l’autre est celle popularisée par Ron Gilbert des Puzzle Dependancy Chart. En fait c’est un peu la même mais y en a une qui part du début et l’autre de la fin. A moins que ça ne soit l’inverse.
La première version du jeu est la plus basique : pour se doucher, il suffit de passer sous la cascade. Bam done, “cascade > observer ; cascade > aller au nord; END”. Ma technique consiste alors à systématiquement engraisser le milieu du “walkthrough potentiel”. Les ingrédients étant des obstacles que notre personnage aura à déjouer. Pour savoir si ces obstacles sont interessants, je raconte le passage en question par une courte phrase dont le verbe sera l’action à accomplir (déposer un objet, sauter etc). Certaines étapes peuvent se faire en parallele ou dans le desordre, c’est là que le graphe de dépendance devient utile.
Tant qu’il tient dans ma tête (le graphe) je compose dans Notion, ça me permet de jongler l’écriture entre mon ordi et mon téléphone pendant que je vaque à mes obligations parentales et professionelles (ou dans les toilettes d’un bar au milieu d’une soiree, on sait jamais vraiment quand une idée d’énigme complètement foireuse peut vous tomber dessus). Mais rapidement j’ouvre un ink à part dans lequel je trace la chronologie de l’histoire que je veux raconter. La fonctionnalité de retour/undo de Inky est partie intégrante de ma manière de circuler dans les récits interactifs que je compose. Ça me permet très vite de savoir si deux passages fonctionnent l’un apres l’autre et vice-versa, si je vais devoir rajouter un indice ici ou là pour qu’un enchainement ait l’air cohérent, etc. Il m’arrive aussi de faire jouer mes enfants à l’oral, comme un jeu de rôle. Ils adorent me pointer les incohérences dans mes réponses !
Faut l’avouer, c’est sur cette partie là que je me suis foiré. J’ai rajouté trop de milieu. Je trouvais ma tropézienne pas assez appêtissante, je l’ai rendu écœurante. Ce qui m’a fait m’arreter : jouer aux SpeedIF (en particulier celles du 27 décembre 2008, car oui à l’époque, nos auteurs désoeuvrés se levaient avant 9h entre Noël et le jour de l’an pour s’adonner à leur passion : écrire du Inform 6). La simplicité des jeux écrits pour l’occasion m’a frappé : les walkthrough tiennent sur 6 lignes, les intrigues sont linéaires, peu de verbes, peu de texte ; c’est écrit en 4h, c’est joué en moins de 5’. Il fallait que je retrouve de vue mon objectif initial : simplicité, économie d’effort : on n’est pas là pour revolutionner la FI, on est là pour faire un truc sympa en moins de 4h.
Aller, on déclare que tout ce qu’on a rajouter cette dernière heure cumulée ne compte pas. Ça part à la benne et on dit qu’on n’en est qu’à 2h45 au compteur. Est-ce que c’est de la post-vérité ? Je vous en laisse seuls juges.
Maintenant, faut passer à l’implémentation. Deux choses sur ma méthode d’implémentation.
La premiere sur l’interactivité : on reproche toujours aux fictions interactives à choix d’être trop transparentes sur “le bon lien à cliquer”, qu’il est impossible de faire “Spider & Web” en fiction à choix ou cette fameuse lettre de je ne sais plus quel jeu qu’on peut decider d’ouvrir implicitement dans un jeu à parser alors que l’option sera forcément explicite dans un jeu à choix. J’essaie systématiquement de montrer que l’on peut être implicite (que ce soit la solution d’un puzzle ou un extra), quitte à même placer des choix explicites qui sont des dead-end (sauter dans le vide), et dans le même temps, d’obfusquer les possibilités derrière d’autres choix/combinaisons. Ici encore, mon éthique me perd, trouver des raisons pour mettre des solutions dans des endroits tarabiscotés, ça prend du temps. En plus j’ai du implémenter le fait d’avoir des liens dans les textes d’action (ce qui n’etait pas le cas dans la version originale de porcelaine) et ça m’a pris un temps précieux.
La seconde sur la structure de mon ink : j’use et j’abuse des threads. Je pense qu’a chaque instant presque tous les choix de tout mon ink sont proposés et tous ont des préconditions qui dépendent de l’état du jeu. Est-ce que le singe est réveillé et la boite ouverte mais le biscuit ne s’y trouve pas ? Alors tel choix devient actif. Une fois une option cliquée, je boucle et tous les choix du monde sont réévalués. Au final, mon fichier ressemble beaucoup plus à une source d’un fichier inform6 ou dialog qu’à ce qu’on a l’habitude de voir en ink. Pour le coup, c’est une force que j’exploite pour gagner du temps : rajouter une option, la tester, la valider est extrêmement rapide, il suffit de changer quelques variables et on a un “état du monde” personnalisé pour se confronter à la possibilité qu’on veut tester !
C’est le moment où il ne reste que 30 minutes, c’est parfait pour tester ! Et là c’est la catastrophe. Si “par bloc” la logique se tenait, en jouant de bout en bout je me suis rendu compte qu’il y avait beaucoup trop d’incohérences, de non-dits, de raccourcis, de choses mal implémentées. Bref que tout ça manquait de polish. Et aussi qu’on ne pouvait pas finir le jeu. Parce que j’avais mal utilisé les comparaisons de LIST, eh oui, ça arrive encore. Obligé de repasser partout et de retester de bout en bout plusieurs fois. C’est là que j’ai perdu le plus de temps. Presque 2h en plus de la deadline.
Mais voilà, au final, le jeu est en ligne !
Si je devais tirer quelques leçons de cette expérience de FI Express, je dirais
-
ce n’est pas le lieu pour innover
-
ce n’est pas le lieu pour prouver quoi que ce soit
-
basiques, basiques, basiques
-
tester au fur et à mesure et si un test de bout en bout prend plus de 3 minutes, c’est déjà trop long