cultivation-world-simulator : un monde xianxia où chaque cultivateur est un agent LLM

Le problème : des PNJ scriptés qui ne surprennent personne

Dans un jeu de simulation textuel classique, les personnages suivent des tables d'événements. Le joueur finit par apprendre ces tables et le monde cesse de surprendre. cultivation-world-simulator attaque ce point précis : le README annonce que chaque cultivateur est un agent indépendant, doté d'une personnalité, d'une mémoire, de relations et d'une logique de décision propres, et qu'il observe l'environnement pour décider lui-même. Le joueur ne joue pas un cultivateur. Il tient le rôle du Tian Dao, l'instance qui fixe les règles du monde, observe et peut intervenir.

Le public visé est double. D'un côté les développeurs qui veulent modifier le code ou déboguer, à qui la documentation recommande explicitement le déploiement depuis les sources. De l'autre les joueurs qui veulent seulement essayer, orientés vers la version desktop gratuite sur l'Epic Games Store. Entre les deux, une troisième catégorie que le dépôt sert sans le dire : ceux qui veulent brancher un agent externe sur le simulateur via l'API REST, pour une boucle observation, décision, intervention, observation.

La promesse d'émergence a un coût direct. Si les décisions viennent d'un modèle, la qualité du monde dépend de la qualité du modèle et de la stabilité de son fournisseur. Le README le reconnaît à sa manière en listant justement l'hallucination et la divergence excessive comme le problème que le cadre de règles doit contenir.

Deux moteurs qui se disputent chaque décision

L'architecture décrite sépare nettement deux couches. La première est un système de règles : cultivation, royaumes, techniques, personnalités, sectes, pilules, armes, tournois martiaux, enchères, durée de vie. La seconde est la couche agents : chaque PNJ est piloté par un LLM et produit ses propres choix. Le README présente cette séparation comme le moyen de brider l'imagination du modèle dans un cadre xianxia crédible.

C'est un choix de conception défendable, mais c'est aussi un aveu. Le cadre de règles n'est pas là pour rendre le jeu amusant, il est là pour empêcher le modèle de dériver. Autrement dit, une partie de la complexité du projet sert de garde-fou, pas de gameplay. Quand la documentation parle de batailles de sectes, de conflits entre orthodoxes et démoniaques ou de la chute d'un prodige, elle précise qu'aucun de ces arcs n'est écrit à l'avance : ils résultent de la logique du monde. Le développeur lui-même ne sait pas ce qui va se produire à la seconde suivante.

Le point à retenir pour un évaluateur : la simulation ne génère pas du récit à partir d'un scénario, elle génère des décisions à partir d'un état. La narration est un sous-produit. C'est une différence structurelle avec un générateur de texte qui demanderait simplement au modèle de raconter une histoire de cultivation.

Ce qui tourne réellement : FastAPI derrière, Vue et PixiJS devant

Le dépôt est en Python, avec FastAPI côté serveur, et un front en Vue 3, TypeScript, Vite et PixiJS. Le point d'entrée du serveur est src/server/main.py, lancé avec le drapeau --dev pour le développement. La configuration système par défaut se trouve dans static/config.yml, décrit comme un fichier en lecture seule, avec notamment la clé system.host.

Le serveur expose une surface d'intégration stable, ce qui est l'élément le plus intéressant du dépôt pour un lecteur technique. Deux espaces de noms : /api/v1/query/* pour la lecture et /api/v1/command/* pour l'écriture contrôlée. La documentation cite comme points d'entrée courants GET /api/v1/query/runtime/status, GET /api/v1/query/world/state, GET /api/v1/query/events, GET /api/v1/query/detail?type=avatar|region|sect&id=<target_id>, puis POST /api/v1/command/game/start, POST /api/v1/command/avatar/* et POST /api/v1/command/world/*.

La séquence minimale donnée par le README est claire : interroger runtime/status pour connaître l'état courant, appeler game/start si aucune partie n'est lancée, puis lire world/state et la suite. Cette séparation lecture et commande est une bonne décision, parce qu'elle rend possible un agent externe qui observe sans pouvoir corrompre l'état par accident. Elle est aussi incomplète dans la documentation fournie : les routes sous avatar/* et world/* ne sont pas détaillées, et la fin du passage est tronquée. Il faudra lire le code du serveur pour connaître les paramètres exacts.

Mise en route : trois chemins, un seul est recommandé

Le chemin recommandé par la documentation est le déploiement depuis les sources. Il demande Python 3.10 ou plus, Node.js 18 ou plus, et un service de modèle disponible. Les commandes données sont pip install -r requirements.txt, puis cd web && npm install && cd .., puis python src/server/main.py --dev. Le mode développement lance automatiquement le serveur front, généralement accessible sur http://localhost:5173, adresse à confirmer dans les journaux de démarrage.

Le second chemin est Docker. La documentation le marque explicitement comme non testé, ce qui est une information utile : clone du dépôt, docker-compose up -d --build, puis accès sur http://localhost:8123. Le conteneur backend persiste les données via la variable CWS_DATA_DIR=/data, qui couvre les réglages, les clés, les sauvegardes et les journaux. Le volume est mappé par défaut vers ./docker-data sur la machine hôte, et les données survivent à un docker compose down suivi d'un up.

Le troisième chemin est la version desktop gratuite sur l'Epic Games Store, pour ceux qui ne veulent pas d'environnement de développement. Dans tous les cas, la première étape après le lancement est la même : passer par la page de réglages pour configurer un preset de modèle, par exemple DeepSeek, MiniMax ou Ollama, avant de commencer une nouvelle partie. La configuration est enregistrée dans le répertoire de données utilisateur. Un détail pratique : la documentation signale que l'interface mobile n'est pas entièrement adaptée et qu'un accès depuis un téléphone relève de l'essai, pas de l'usage.

Pour consulter les informations du monde, les actions ou les sectes, le README mentionne la génération d'un wiki local via tools/wiki.

Le modèle est une dépendance externe, pas un composant du dépôt

C'est la limite la plus lourde et la documentation la plus discrète sur ce point. Le simulateur ne fonctionne pas seul : sans service de modèle configuré, il n'y a pas de partie. Le projet ne fournit pas de modèle, il fournit des presets. Cela veut dire que le coût d'usage, la latence et la disponibilité du monde dépendent d'un tiers que vous choisissez.

Les conséquences sont concrètes. Si vous utilisez une API distante, chaque décision d'agent est un appel réseau, et le rythme de la simulation dépend de la latence et des quotas. Si vous utilisez Ollama en local, vous échangez la facture contre du matériel et du temps de calcul. Le README ne donne aucune estimation de consommation par tour ni de nombre d'appels par cycle, et je ne peux pas en déduire une. Ce que l'on peut dire, c'est que la conception multi-agents multiplie les appels par le nombre de PNJ actifs.

Deuxième limite, plus structurelle : une simulation dont les décisions sont produites par un modèle n'est pas reproductible. Rejouer la même graine ne donnera pas la même histoire, puisque le modèle n'est pas déterministe par défaut. Si votre objectif est de comparer deux variantes de règles dans des conditions contrôlées, cet outil est le mauvais choix : il n'offre pas de protocole expérimental, et le README ne revendique rien de tel.

Troisième point, la licence. Le dépôt est classé NOASSERTION, ce qui signifie que GitHub n'a pas pu identifier automatiquement une licence reconnue. Le fichier LICENSE n'est pas reproduit dans le matériel fourni, et je ne peux donc pas dire quelles conditions s'appliquent à la redistribution ou à la modification. Pour un projet qui encourage explicitement la création dérivée, c'est l'information à vérifier en premier. Rien dans ce qui précède ne constitue un avis juridique.

Face à un moteur de simulation classique, la différence est dans la boucle

L'alternative évidente est un moteur de simulation déterministe avec des agents à états finis, du type de ceux qu'on écrit en Python pur avec des tables de probabilités et des transitions explicites. La différence d'approche n'est pas cosmétique. Dans un moteur déterministe, la décision d'un PNJ est une fonction de son état et d'un générateur aléatoire avec graine. Vous pouvez rejouer la partie, instrumenter une décision précise, et expliquer pourquoi un personnage a fait ce qu'il a fait.

Ici, la décision passe par un modèle de langage. Vous gagnez en variété de comportements et en plausibilité contextuelle : un cultivateur peut réagir à une situation que le concepteur n'avait pas anticipée. Vous perdez la traçabilité exacte et la reproductibilité. Le README assume ce compromis en parlant d'émergence et en admettant que le développeur ignore la suite.

Le second point de comparaison est l'API REST. Un moteur classique expose rarement une interface d'observation et de commande aussi nette, avec séparation lecture et écriture. C'est ici que le projet se distingue le plus de la catégorie des jeux textuels : il se présente autant comme une plateforme d'expérimentation d'agents que comme un jeu. Pour quelqu'un qui travaille sur les workflows agentiques, la boucle runtime/status, game/start, world/state, events est plus intéressante que le rendu visuel en PixiJS.

Version 4.0.1 et ce qu'il faut vérifier avant d'adopter

Le dépôt n'est pas archivé et le dernier push date du 16 août 2026. Les versions récentes listées sont v4.0.1 le 2 août 2026, v4.0.0 la veille, et v3.9 le 19 juillet 2026. Cette cadence indique un projet actif, avec des changements de version mineure rapprochés. Le coût de maintenance à prévoir n'est donc pas celui d'un logiciel figé : une version majeure tous les quelques mois signifie relire les notes de version avant de mettre à jour une instance Docker ou un déploiement source.

La persistance des données limite la casse. En Docker, tout passe par CWS_DATA_DIR, réglages, clés, sauvegardes et journaux, mappé vers ./docker-data. Reconstruire l'image ne devrait donc pas effacer une partie en cours, mais la documentation ne décrit pas de procédure de migration de sauvegarde entre versions majeures. C'est un point à tester sur une copie du répertoire de données avant de mettre à jour une instance que vous utilisez.

Qui devrait adopter cet outil : un développeur qui veut étudier une architecture où le LLM produit des décisions dans un cadre de règles, ou qui veut brancher son propre agent sur une API d'observation et de commande. Qui devrait passer : une équipe qui a besoin d'un banc d'essai reproductible, ou un utilisateur qui ne veut gérer aucun service de modèle. Ce qu'il faut vérifier en premier : le fichier LICENSE à la racine, puisque le classement NOASSERTION laisse la question ouverte, et le fonctionnement du preset Ollama avec un modèle que vous avez déjà, puisque c'est le seul chemin qui évite une API distante.

Conclusion éditoriale

À adopter si vous voulez étudier une architecture multi-agents où le LLM produit des décisions et non du texte narratif, en acceptant de configurer vous-même un backend de modèle. À éviter si vous cherchez un bac à sable batch reproductible ou un runtime sans dépendance à un service de modèle. Avant de vous engager, lisez le fichier LICENSE à la racine et vérifiez que le preset Ollama fonctionne avec le modèle que vous avez déjà.

Sources officielles

1. 4thfever/cultivation-world-simulator on GitHub
2. Issues
3. README
4. Releases