Recharger à chaud le game design comme du code

La plupart des moteurs livrent des binaires opaques. RakuAI livre du texte que vous pouvez differ, relire, et recharger à chaud — avec le système nerveux IA adressable directement dans le fichier. Ce choix est ce qui permet à toute une équipe d'agents de construire à vos côtés.

Week-end format de fichier. L’IA est une primitive du runtime dans ce moteur, pas une fonctionnalité boulonnée à côté. C’est l’argument architectural que j’ai déjà fait. Ce billet parle du format de fichier qui le rend concret.

Si vous construisez un jeu sur la plupart des moteurs, l’artefact que vous livrez est un binaire, un bundle de projet, une base de données d’assets, ou une combinaison des trois. Ce que vous créez vit à l’intérieur d’un éditeur propriétaire. Ce que vous livrez est opaque aux outils que votre équipe utilise déjà. Differ deux versions d’une expérience signifie lancer le même éditeur deux fois et espérer que le journal des modifications soit honnête.

Nous avons pris l’autre chemin. Une expérience RakuAI est un fichier .raku. Le fichier est du JSON. Vous pouvez l’ouvrir dans n’importe quel éditeur. Vous pouvez differ deux versions dans n’importe quel outil de relecture de code. Vous pouvez le valider contre un schéma. Vous pouvez le versionner dans git. Vous pouvez le relire dans une PR. Vous pouvez le recharger à chaud. Vous pouvez écrire une expérience à la main si vous le souhaitez.

Le format de fichier n’est pas glamour. Il est porteur.

À quoi ressemble un vrai fichier .raku

Voici une vraie définition de jeu, réduite pour le billet :

{
  "schema_version": "1.0",
  "game": {
    "title": "My Space Shooter",
    "genre": "space_shooter",
    "template": "space_shooter",
    "mode": "prototype",
    "max_players": 1
  },
  "ai": {
    "dda_enabled": true,
    "target_flow_state": 0.7,
    "profiler_mode": "active",
    "emotional_tracking": true,
    "adaptive_music": true
  },
  "entities": [
    {
      "type": "player_ship",
      "health": 100,
      "shield": 80,
      "speed": 22.0,
      "fire_rate": 0.09
    },
    {
      "type": "enemy_wave",
      "count": 8,
      "health": 15,
      "ai_behavior": "strafe",
      "properties": { "enemy_id": "interceptor" }
    },
    {
      "type": "boss",
      "health": 500,
      "ai_behavior": "boss_pattern"
    }
  ]
}

C’est la majeure partie d’une expérience. Un en-tête versionné par schéma. Un bloc game avec les métadonnées de surface. Un bloc ai avec la configuration de l’IA du runtime. Un tableau entities décrivant ce qui se trouve dans le monde et comment chaque entité se comporte.

Quelques éléments qui méritent d’être soulignés.

Le bloc ai est le contrat du runtime

Regardez à nouveau cette partie :

"ai": {
  "dda_enabled": true,
  "target_flow_state": 0.7,
  "profiler_mode": "active",
  "emotional_tracking": true,
  "adaptive_music": true
}

C’est là où le fichier dit « le système nerveux IA est activé ». Pas « demande à GPT de m’écrire un niveau ». Activé. Au niveau de la couche runtime, à chaque frame, pendant que le joueur joue.

dda_enabled active l’ajustement dynamique de la difficulté. Le runtime profile ce que fait le joueur et remodèle les rencontres en vol. target_flow_state: 0.7 est la bande de difficulté que le runtime vise. profiler_mode: "active" dit que l’IA lit le comportement du joueur, pas simplement qu’elle l’échantillonne. emotional_tracking et adaptive_music sont la même idée appliquée à d’autres sous-systèmes.

Un moteur à motif factory ne pourrait pas avoir ces réglages au niveau du fichier. Il n’y a pas d’IA de runtime à laquelle le fichier puisse s’adresser. Dans notre moteur, ces réglages sont la façon dont un auteur dit au système nerveux quel genre d’expérience être.

Vous pouvez relire ce bloc dans une PR. Vous pouvez faire du A/B testing sur deux valeurs en CI. Un producteur qui n’a jamais vu un éditeur peut lire ceci et avoir une conversation avec l’ingénierie sur ce que signifie l’état de flow cible. Le format de fichier rend la décision de design visible.

Le comportement IA par entité est une chaîne, pas une intégration

Chaque entité du fichier peut porter un champ ai_behavior :

{
  "type": "enemy_wave",
  "count": 8,
  "ai_behavior": "strafe"
}

"strafe" n’est pas une invocation de modèle. C’est un comportement enregistré dans le runtime que la couche système nerveux pilote. La même entité peut être "patrol" ou "boss_pattern" ou tout ce que le runtime sait faire d’autre. Le fichier n’importe pas de modèle. Il adresse une capacité.

C’est comme cela qu’on découple le format de fichier d’un modèle spécifique. L’auteur écrit une intention. Le runtime décide quel modèle, quels poids, quel repli déterministe utiliser pour livrer cette intention. Changez de modèle le trimestre prochain et les fichiers .raku ne changent pas.

Cette séparation compte plus qu’il n’y paraît. Chaque équipe à qui j’ai parlé qui a boulonné un LLM spécifique dans un moteur a dû refaire l’intégration quand le fournisseur de modèle a bougé. Nous, non.

Pourquoi JSON

C’est la question que je reçois le plus quand je montre le format de fichier. Pourquoi JSON et pas un DSL sur mesure avec une syntaxe plus agréable pour les expressions mathématiques, le scripting en ligne, et les liaisons réactives ?

Trois raisons.

Un : chaque outil parle déjà JSON. Relecture de code. Outils de diff. Contrôle de version. Linters. Validateurs de schéma. Pipelines CI. Analyse statique. Chaque éditeur sur chaque plateforme. Nous n’avons rien eu à construire de tout ça. Nous l’avons récupéré gratuitement.

Deux : les humains lisent le JSON assez bien. Le fichier ci-dessus n’est pas beau, mais un designer senior peut le lire sans formation. Comparez cela à un DSL qui prend une semaine à apprendre avant que quiconque puisse relire une PR.

Trois : les assistants IA lisent le JSON extrêmement bien. Celle-ci compte plus en 2026 qu’il y a trois ans. Quand un designer demande à un assistant IA de « rendre le boss plus effrayant », l’assistant peut lire le fichier, proposer un diff, et l’humain peut accepter ou rejeter le diff. Un DSL sur mesure nécessiterait d’enseigner une nouvelle grammaire à chaque assistant.

Le coût est réel. JSON est verbeux. Il n’a pas de math en ligne, de commentaires, ou d’abréviations. Nous sacrifions l’expressivité en échange de l’ubiquité de l’outillage. Jusqu’à présent, l’échange s’est remboursé plusieurs fois.

Ce que cela permet

Quelques choses changent une fois que votre expérience est du texte.

Relecture PR pour le game design. Un designer change target_flow_state de 0,7 à 0,5. Le changement apparaît comme un diff d’une ligne dans une pull request. L’ingénierie et le design relisent le changement ensemble. La conversation dans la PR est un enregistrement de pourquoi l’expérience se joue de la façon dont elle se joue. Six mois plus tard, quand quelqu’un demande pourquoi la courbe de difficulté ressent ce qu’elle ressent, la réponse est dans le journal des commits.

CI pour les expériences. Un fichier .raku échoue la validation de schéma. Le build échoue avant que le changement ne soit livré. La même CI qui exécute vos tests unitaires exécute vos définitions d’expérience.

Rechargement à chaud. Le fichier change sur le disque. Le runtime le remarque. Le monde se met à jour sans redémarrage. La boucle de développement se resserre à quelques secondes.

Retour en arrière. Un changement a cassé le combat de boss. Annulez le commit. L’expérience revient en arrière. Pas d’éditeur, pas de reconstruction d’asset, pas d’aller-retour d’une semaine.

Création par IA. Un membre de l’équipe décrit ce qu’il veut en langage naturel. Un assistant IA écrit le diff .raku. Un relecteur humain l’approuve. Le diff est auditable, versionnable, et relève de la même discipline de relecture que tout autre changement de code.

Ce ne sont pas des capacités exotiques. C’est ce que toute équipe logicielle moderne tient pour acquis pour le reste de sa base de code. Nous l’avons étendu au game design.

Ce qui est difficile

Les coûts honnêtes.

JSON n’a pas de commentaires. Nous compensons avec des fichiers .md annexes pour l’intention de design et avec des noms de champs descriptifs, mais c’est une vraie friction.

Le schéma doit évoluer avec précaution. Nous sommes passés de schema_version: 1.0 à 2.0 une fois quand la génération de monde a dépassé la forme originale. Chaque fichier existant en circulation avait besoin d’un chemin de migration. Ce travail fait partie du job, et il n’est pas gratuit.

Il y a une tentation d’ajouter continuellement des champs. Nous y résistons plus fort qu’il n’y paraît. Chaque champ ajouté est un contrat que le runtime doit honorer perpétuellement. Le biais est de garder le fichier petit et de mettre la complexité dans le runtime, pas dans le fichier.

Et enfin : les définitions d’expérience basées sur du texte ne comptent que si le runtime en fait réellement quelque chose d’intéressant. Le format de fichier est en aval de la décision architecturale sous-jacente. Si le moteur traite l’IA comme une usine à contenu, le fichier n’est qu’un manifeste. Si le moteur traite l’IA comme une primitive du runtime, le fichier est la partition.

Si vous voulez lire le format de bout en bout, le schéma vit dans la documentation publique et les fichiers d’exemple sont livrés dans le dépôt. Ouvrez-en un. Lisez-le comme du code, parce que c’est ce que c’est.

Deux jours de travail sur le format de fichier dans la boîte. Retour au moteur le week-end prochain.