WorldX : un monde pixelisé piloté par quatre rôles de modèles distincts

Ce que la phrase d'entrée déclenche réellement

Le README ouvre sur un exemple concret : une rue de marché nocturne à Bianjing sous les Song du Nord, avec un devin, un prêteur sur gages, un voleur, un agent de police et un voyageur temporel. C'est le cas d'usage revendiqué. L'utilisateur décrit une scène, et le projet en tire une carte, des personnages et un état de simulation. La cible n'est pas le développeur qui veut un moteur de jeu, mais la personne qui veut voir une situation évoluer sans avoir écrit de scénario. Le README précise que les personnages prennent des décisions, interagissent avec le décor, nouent des relations, dialoguent, mémorisent et réfléchissent, et que des récits émergent sans être écrits à l'avance. Un mode dit dieu permet d'injecter des événements, de modifier la mémoire ou la personnalité d'un personnage et de converser avec lui hors du cadre de la simulation. La fonctionnalité de timeline permet de faire diverger plusieurs histoires depuis un même monde. Rien dans le matériel fourni ne quantifie la qualité de ces récits, et c'est un point à garder en tête : la promesse est narrative, pas mesurable.

Quatre rôles de modèles, quatre variables d'environnement

L'architecture de configuration est le point le plus concret du dépôt. WorldX ne parle pas à un seul modèle mais à quatre, chacun avec son préfixe de variables : ORCHESTRATOR_ pour concevoir la structure du monde, les personnages et les règles, IMAGE_GEN_ pour produire l'art de la carte et les portraits, VISION_ pour inspecter la qualité de la carte et localiser des zones ou des éléments, SIMULATION_ pour piloter le comportement des personnages à l'exécution. Chaque rôle attend typiquement trois variables : {ROLE}_BASE_URL, {ROLE}_API_KEY et {ROLE}_MODEL. Tous les rôles sauf la génération d'image passent par le protocole OpenAI compatible chat/completions. Le rôle IMAGE_GEN_ accepte en plus IMAGE_GEN_PROVIDER, avec deux valeurs : openai-compatible (valeur par défaut, adaptée à OpenRouter) et google-native (adaptée à Google AI Studio). Cette séparation a une conséquence pratique : on peut mettre un modèle de raisonnement coûteux sur ORCHESTRATOR_ et un modèle bon marché sur SIMULATION_, qui est appelé en continu pendant que le monde tourne. Le README illustre ce panachage avec DeepSeek pour la simulation et Google AI Studio pour le reste. La qualité du résultat dépend donc de quatre fournisseurs distincts, chacun avec ses propres limites de débit.

Le rôle VISION_ et la boucle de vérification de la carte

C'est la partie la moins commentée du README, et pourtant la plus intéressante techniquement. Le rôle VISION_ est décrit comme servant à examiner la qualité de la carte et à localiser des zones ou des éléments. Autrement dit, l'image produite par IMAGE_GEN_ n'est pas seulement affichée : elle est relue par un modèle multimodal qui doit en extraire une structure exploitable pour la simulation. Cela implique un aller-retour entre génération d'image et interprétation, et donc au moins deux appels de modèles payants avant que le premier personnage ne fasse quoi que ce soit. Le README ne documente pas le format de sortie attendu de cette étape, ni le nombre de tentatives en cas d'échec, ni ce qui se passe si le modèle de vision ne retrouve pas un élément demandé. C'est une zone d'ombre réelle : un projet qui génère une carte puis la fait relire par un modèle doit gérer le cas où la relecture contredit la demande initiale, et le matériel fourni ne dit pas comment. Le README signale par ailleurs une préférence nette côté génération d'image : il recommande nano banana 2 (gemini-3.1-flash-image) et indique que gpt-image-2 reste insuffisant en suivi d'instructions, ce qui provoquerait selon lui divers problèmes et dégraderait le résultat final. C'est un aveu utile : la chaîne est sensible au respect des consignes par le modèle d'image.

Démarrage : deux chemins, dont un qui ne demande qu'un seul modèle

Le README propose deux parcours. Le chemin rapide suppose de cloner le dépôt, copier .env.example vers .env, remplir uniquement les trois lignes SIMULATION_ puis lancer npm install et npm run dev, avant d'ouvrir http://localhost:3200 et de choisir l'un des deux mondes pré-générés. C'est un choix de conception appréciable : on peut voir une simulation tourner sans payer la génération de carte ni la relecture visuelle. Le chemin complet demande de remplir les quatre groupes de modèles, puis d'ouvrir http://localhost:3200/create et de saisir une phrase. Une variante en ligne de commande existe : npm run create -- suivi de la description entre guillemets, par exemple une boutique de ramen nocturne cyberpunk où hackers et androïdes échangent des informations. Le prérequis Node.js est inhabituellement précis. Le README exige Node.js 22.13+ et recommande la version 24 LTS, parce que la base de données utilise le module SQLite intégré node:sqlite, ce qui évite de compiler un module natif à l'installation. La plage utilisable annoncée est >=22.13 <23 ou >=23.4 : les versions 22.5 à 22.12 et 23.0 à 23.3 ne fonctionnent pas, car node:sqlite était encore derrière le drapeau --experimental-sqlite. C'est le genre de détail qui fait perdre une heure à quelqu'un qui a la mauvaise version.

Les limites que le dépôt admet lui-même

Le badge de statut indique Alpha, et le README le reformule : le cœur est utilisable, l'optimisation se poursuit. Aucune release n'a été récupérée, ce qui signifie qu'il n'existe pas de version étiquetée sur laquelle s'appuyer : on suit la branche main. Le README ne décrit ni tests automatisés, ni procédure de migration de schéma pour la base SQLite, ni stratégie de compatibilité entre versions. Pour un projet qui stocke des mondes, des personnages et des mémoires dans une base locale, l'absence de chemin de migration documenté est une vraie contrainte : une mise à jour peut rendre un monde existant inutilisable, et rien dans le matériel fourni ne dit le contraire. Deuxième limite, structurelle : tout le comportement émergent dépend d'appels à des API externes. Une coupure réseau, un quota atteint ou une clé expirée arrêtent la simulation. Il n'existe pas de mode hors ligne mentionné. Troisième limite, la qualité est déléguée au modèle d'image, et le README reconnaît explicitement qu'un mauvais suivi d'instructions dégrade l'ensemble. Enfin, le coût n'est pas trivial : quatre rôles, dont un appelé en boucle pendant la simulation, sur des modèles qui peuvent être facturés à l'usage.

Ce qui distingue WorldX d'un moteur de jeu classique

La comparaison utile n'est pas avec un autre projet de simulation d'agents, mais avec un moteur de jeu comme Phaser seul. Phaser 3 est présent dans la pile, et le rendu pixel art vient de là. Un moteur de jeu classique exécute une logique écrite à l'avance : les personnages suivent une machine à états, les dialogues sont des chaînes prévues, et le contenu est fini. WorldX déplace la source de la décision vers un modèle de langage appelé à l'exécution. Le décor et les portraits restent des assets générés, mais le comportement n'est pas scripté. La différence se paie en prévisibilité : un moteur classique donne le même résultat à chaque partie, WorldX non. Elle se paie aussi en latence, puisqu'une décision de personnage implique un aller-retour réseau. À l'inverse, un projet qui se contenterait de Phaser plus des dialogues écrits serait plus rapide, gratuit à l'exécution et reproductible, mais ne produirait pas de récit non prévu. Le choix dépend donc de ce qu'on cherche : un jeu à contenu fixe ou un bac à sable narratif dont on accepte l'imprévisibilité et le coût par appel.

Licence MIT et coût de maintenance

Le dépôt est sous licence MIT, ce que confirme le badge du README et le fichier LICENSE référencé. Concrètement, cela autorise la réutilisation, la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver l'avis de licence. Aucune clause de copyleft ne contraint le code dérivé. Ce point n'a rien d'anecdotique ici : un projet qui dépend de quatre fournisseurs de modèles peut intéresser quelqu'un qui veut le rebrancher sur son infrastructure interne, et la MIT le permet sans négociation. Le coût de maintenance, lui, ne vient pas du code mais des dépendances externes. Le README ne mentionne aucun mécanisme de versionnage des modèles : les exemples utilisent des identifiants comme gemini-3.1-pro-preview ou gemini-2.5-flash-preview, et un changement de comportement côté fournisseur se répercute directement sur la simulation. Le suivi de la branche main, sans release étiquetée, signifie aussi qu'il faut relire les changements avant de mettre à jour. Pour un usage expérimental, c'est acceptable. Pour un déploiement durable, il faudrait épingler les identifiants de modèles dans le .env et vérifier soi-même la compatibilité du schéma SQLite après chaque mise à jour.

Conclusion éditoriale

WorldX convient à ceux qui veulent observer une simulation d'agents LLM dans un rendu pixel art sans écrire eux-mêmes la boucle d'orchestration, et qui acceptent les contraintes d'une alpha. Ceux qui cherchent un moteur de jeu déterministe ou un système sans dépendance à une API payante doivent passer leur chemin. Avant d'investir du temps, vérifiez la version exacte de Node.js avec node --version et testez le mode A avec les deux mondes pré-générés : cela isole les problèmes de configuration SIMULATION_ de ceux liés à ORCHESTRATOR_ et IMAGE_GEN_.

Sources officielles

1. Issues
2. License: MIT
3. README
4. YGYOOO/WorldX on GitHub