Plan de création de jeux

Introduction#

Je pense qu’il faut aussi expliquer pourquoi faire des jeux.

Pour être honnête, il n’y a pas de raison grandiose. Les récits sur le fait d’écrire du code plus vite avec l’AI sont déjà devenus courants, et je pense que beaucoup de gens sentent déjà ce changement par eux-mêmes. Le développement de jeux a justement commencé à partir d’une question un peu luxueuse : qu’est-ce que je peux réellement transformer en quelque chose de publiable ?

Autrefois, c’était un domaine dans lequel il n’était pas facile d’entrer, même si l’on ne regardait que les ressources de développement et d’exploitation. Aujourd’hui, on a l’impression d’être entré dans une époque où l’on peut commencer sans trop hésiter. En plus, construire quelque chose que je peux moi-même apprécier, et faire un développement plus proche d’un loisir que d’un métier, a aussi quelque chose d’assez romantique.

L’introduction a été plus longue que prévu. Dans cet article, je veux parler des genres de jeux que je compte pousser, et de la raison pour laquelle j’ai choisi cette trajectoire.

Ordre d’implémentation

Pourquoi commencer par Story Quiz#

Le premier genre que j’ai choisi est Story Quiz. C’est une structure proche du visual novel, où l’histoire avance et où le joueur gagne de l’expérience en résolvant des déductions au milieu ou à la fin. La raison de commencer par ce genre est simple. Le cœur du plaisir est clairement dans l’histoire et la déduction, tandis que la charge opérationnelle peut rester relativement faible.

Ici, il n’est pas nécessaire de mettre de l’AI partout. Au contraire, je pense que c’est précisément ce point qui compte. Dans Story Quiz, je veux que l’AI reste surtout du côté de la notation et de l’assistance à la production, tandis que l’expérience de jeu elle-même repose sur des règles et une mise en scène conçues par des humains. Cela évite que l’exploitation ne se dérègle, tout en permettant de tester un modèle dans lequel les auteurs publient leurs propres œuvres.

Nous sommes encore dans une phase initiale, mais la direction de l’implémentation va déjà dans ce sens. Il ne s’agit pas d’injecter directement les manuscrits dans la base de données, mais d’optimiser l’AI pour la production narrative au moyen d’un pipeline manuscrit Markdown → parsing → renforcement du script → génération de prompts → traduction → import.

source.md
-> parse-episode.py
-> script-doctor.py
-> prompt-gen.py
-> translate-story.py
-> /bo/story-quiz/games/import

Où en est l’implémentation de Story Quiz#

Si l’on se base sur le dépôt actuel, Story Quiz a déjà dépassé le simple stade de l’idée. Côté joueur, il existe déjà des API qui relient la liste et le détail du jeu, la création de session, la reprise, l’envoi des réponses et la consultation de l’épilogue. Côté backoffice, une structure gère déjà séparément les jeux, les personnages, les phases, les blocs, les quizzes et les assets de fond. À cela s’ajoute un flux d’import et d’export de l’ensemble des données du jeu au format JSON. Le système commence donc à être traité non comme un jeu isolé, mais comme un format de contenu publiable.

Le point important est que ce genre grandit en séparant les données de contenu et les sessions de jeu. Un jeu est découpé en personnages, phases, blocs, quizzes et assets de fond, tandis que la session gère séparément la phase courante, le quiz courant, les indices utilisés, le score et l’état d’avancement. En d’autres termes, le flux par lequel l’auteur modifie une œuvre et le flux par lequel le joueur la consomme sont déjà séparés en couches différentes.

La notation suit la même philosophie. Les questions objectives sont notées immédiatement, tandis que les questions subjectives passent par des stratégies distinctes comme KEYWORD_ONLY, LLM_ONLY, HYBRID et MANUAL, ainsi que par un flux de vérification backoffice. Ce qui compte pour moi n’est pas que l’AI ait toujours raison. Ce qui compte, c’est une structure dans laquelle seuls les problèmes adaptés à l’AI lui sont confiés, et où tout le reste reste vérifiable par des humains.

La couche de livraison est elle aussi en cours d’organisation pour l’expérience de publication. Les images de couverture et de carte sont livrées via des public source paths et des thumbnails basés sur des presets, et Asset Studio est déjà capable de gérer ensemble les assets de personnages et de fond provenant de Story Quiz et de Mystery. Au final, Story Quiz est à la fois un jeu et le premier terrain d’essai d’un pipeline de production, de vérification et de publication d’œuvres.

Pourquoi la suite est Mystery#

Si Story Quiz est plus proche d’une expérience structurée conçue par un auteur, Mystery est un genre beaucoup plus vivant. Le joueur ne s’arrête pas à lire des indices. Il prend un rôle, dialogue, soupçonne les autres et met à jour la situation en permanence. C’est un genre assez de niche, mais si cela fonctionne bien, le niveau d’engagement peut devenir beaucoup plus profond.

Et c’est précisément là que le poids de l’AI augmente fortement. Dans Story Quiz, on peut utiliser l’AI de façon limitée, mais dans Mystery, des domaines comme les réactions des NPC, l’interrogatoire, l’aide aux indices et le renforcement du scénario se rapprochent beaucoup plus du cœur de l’expérience. Je vois ce genre comme la deuxième étape, celle où l’AI entre vraiment dans l’expérience de jeu.

Où en est Mystery#

Comme j’ai avancé sur plusieurs pistes en parallèle, Mystery est lui aussi déjà arrivé à un stade où l’on peut voir un petit prototype de ses propres yeux. Les API de plateforme relient déjà la consultation des scénarios, la création de session et l’entrée par code d’invitation, l’état prêt, le démarrage, les changements de phase, les notes, les objets et les historiques d’interrogatoire. Les sessions sont gérées autour des tickets, des codes d’invitation, des listes de joueurs et des transitions d’état, et des données comme les objets de départ, les notes de départ et les interrogatoires de départ sont accrochées séparément. Autrement dit, le modèle de session nécessaire pour faire tourner une vraie partie est déjà en place.

Le côté production est encore plus intéressant. Mystery dispose d’un flux backoffice appelé Draft Scenario, et les étapes de génération sont découpées en CONCEPT → TRUTH → CHARACTERS → TIMELINE → CLUES → ROLEPLAY → WORLD_BUILDING → SYNOPSIS → PROLOGUE → EPILOGUE. Il ne s’agit pas d’une simple génération de texte. C’est une manière de traiter la réponse, le mobile, les relations entre personnages, les alibis, les indices et les réactions de rôle comme des nœuds indépendants. Je pense que cette structure est essentielle. Dans Mystery, la cohérence logique doit passer avant les belles phrases.

Le côté dialogue temps réel possède lui aussi déjà une ossature. Les API de chat de session de jeu comprennent le dialogue avec les personnages, des réponses en streaming SSE et un chat avec un assistant AI, et toutes les conversations sont stockées dans l’historique des interrogatoires. Cela veut dire qu’on n’est pas dans une structure où l’AI se contente de jeter des réponses. Le système est conçu pour que la conversation s’accumule comme une mémoire à l’intérieur de la session. C’est probablement la zone où la dépendance à l’AI augmentera le plus vite.

Pourquoi MMORPG vient en dernier#

MMORPG est lié pour moi non seulement à une curiosité technique, mais aussi à une nostalgie personnelle. Je voulais tester jusqu’où je peux recréer une sensation proche de Lineage, auquel j’ai longtemps joué, avec les outils et la structure d’aujourd’hui. Si cela finit un jour par devenir commercialisable, tant mieux, mais avant cela, la vraie question est ailleurs : jusqu’où peut-on pousser un genre aussi lourd avec la manière actuelle de développer ?

Je pense aussi que, dans l’implémentation de MMORPG, beaucoup des structures mentionnées plus haut pourront être réutilisées ou adaptées au worldbuilding, à l’histoire et à la configuration des NPC.

MMORPG n’est-il pas trop difficile à construire#

Fait assez surprenant, le mmorpg-service actuel dispose déjà d’une quantité non négligeable de code généré à partir des spécifications. J’irais même jusqu’à dire que le niveau actuel des coding agents dépasse ce que la plupart des gens imaginent. Avec seulement quelques prompts, le client comme le serveur d’un MMORPG temps réel peuvent être générés.

Le jeu lui-même est prévu dans une forme proche de Lineage, auquel je jouais beaucoup, et côté serveur, un gateway basé sur Netty, un gestionnaire de sessions, la synchronisation des sessions avec Redis, la gestion des connexions en double, la création de mondes et de zones, le tick scheduler, les cartes et le pathfinding, la synchronisation AOI, la diffusion du combat, l’inventaire et la boutique, ainsi que les flux de drop et de spawn sont déjà implémentés et déployés comme un service séparé.

Du côté du runtime, GameWorld gère plusieurs Zones et rattache les joueurs en séparant les index de session et de monde. Les monstres ne sont pas gérés comme de simples objets de spawn, mais comme des entités runtime dotées d’états FSM tels que IDLE, PATROL, CHASE, ATTACK, RETURN et DEAD. Le système de triggers exécute directement des réactions du monde comme les dégâts de piège, les sorts, les dialogues et le chat. Au-dessus de cela, il y a même un WorldContinuum qui persiste séparément le temps et la météo du monde.

Construire une échelle#

Story Quiz est un genre pour expérimenter la publication d’œuvres avec une charge opérationnelle faible. Mystery est un genre pour expérimenter la déduction fondée sur les rôles au moment où l’AI entre dans l’expérience de jeu. MMORPG est un genre pour tester jusqu’où la méthode actuelle de développement peut aller dans le type de monde temps réel le plus lourd.

C’est pour cela que ces trois directions ne sont pas des projets séparés, mais plutôt les barreaux d’une seule échelle. Je veux d’abord installer le pipeline de production et la structure de vérification dans le genre le plus léger, puis augmenter la densité des interactions avec l’AI, avant de monter jusqu’au monde temps réel.

Au fond, la question que je veux regarder est simple. Ce n’est pas de savoir si l’AI permet de faire des jeux plus vite, mais à quel endroit elle doit être placée pour qu’un jeu reste un produit dont un humain peut porter la responsabilité jusqu’au bout. Pour moi, faire des jeux dans Omnilude est aujourd’hui la manière la plus sérieuse de tester cette question.

Conclusion#

Dans les textes précédents, j’ai parlé de l’évolution de la manière de coder et de la structure du backend. Celui-ci se rapproche davantage d’une réponse à une autre question : quels jeux suis-je réellement en train de construire sur cette structure, et dans quel ordre ?

La prochaine fois, j’aimerais resserrer le champ et expliquer plus concrètement soit comment tourne réellement le pipeline de publication de Story Quiz, soit comment je conçois la structure d’interrogatoire AI pour Mystery.