Plans
1. Généralités
1.1. À propos du document
L’objectif de ce document est d’énoncer la position et l’intention de Clarus Victoria concernant les jeux que nous voulons créer et le chemin que nous comptons suivre.
Les jeux que le studio développera dans les prochaines années sont considérés comme des étapes vers un projet plus vaste et de long terme appelé Nexus.
Ce document n’est ni une spécification technique, ni un cahier des charges, ni une promesse de délais ou de résultats précis. À mesure que le projet évolue et que de nouvelles idées apparaissent, il pourra être mis à jour et révisé.
Le document s’adresse aux joueurs intéressés par la vision globale du projet Nexus et par l’orientation du travail de Clarus Victoria, ainsi qu’aux développeurs souhaitant mieux comprendre les principes et mécaniques du nouveau système.
1.2. À propos du projet
Nexus est un jeu informatique universel dans lequel les joueurs peuvent créer et configurer leurs propres jeux, en mélangeant genres, univers et mécaniques, puis en les partageant avec d’autres.
Contrairement aux jeux traditionnels, Nexus ne propose ni genre prédéfini ni scénario unique. Ici, les genres sont des ensembles de règles et de scénarios que le joueur peut choisir, combiner et modifier en cours de partie.
Nexus n’est pas un simple Roblox ou Garry’s Mod de plus. Sur la plupart des plateformes similaires, les mondes sont assemblés à partir de scripts et d’éditeurs. Dans Nexus, les mondes sont construits sur un langage proche de la langue humaine. Il forme des sens, des règles et du contenu. Cette approche offre plus de flexibilité et de liberté pour choisir à quoi jouer et comment.
1.3. Structure du document
Le document est structuré en sections numérotées pour faciliter la navigation et le partage de liens.
La structure générale comprend les sections suivantes :
- La section 1 est introductive. Elle contient des informations générales sur le projet Nexus et sur ce document.
- La section 2 décrit un ensemble d’idées sur ce que pourrait être Nexus après sa mise en œuvre.
- La section 3 contient des idées et des approches permettant une mise en œuvre technique du projet.
- La section 4 est une feuille de route : une séquence d’étapes nécessaires à la création du projet.
- La section 5 couvre les défis : risques et contraintes du projet, ainsi que les approches pour y répondre.
Toutes les sections sauf la section 3 s’adressent à un large public. La section 3 est davantage orientée vers les spécialistes et les développeurs de jeux.
Le document a une structure modulaire et peut être lu de façon sélective, sans suivre strictement l’ordre des sections.
1.4. À propos de l’auteur
L’auteur du document est Mikhaïl Vassiliev, fondateur, game designer et développeur du studio Clarus Victoria. Le document reflète la vision subjective de l’auteur et ne prétend pas être exhaustif ni la vérité ultime.
2. Concept

2.1. Objectif de la section
Montrer à quoi pourrait ressembler le projet Nexus et quelles pourraient être ses fonctionnalités après mise en œuvre. Dans cette section, nous examinons l’idée de la formation d’un genre — les jeux informatiques universels, dont Nexus devrait être un représentant.
Certaines idées décrites peuvent sembler difficiles à mettre en œuvre, mais elles sont considérées comme un repère et une direction de développement. La section est consacrée exclusivement au concept des mécaniques de jeu et à l’image globale du jeu. Les questions de conception des règles et de mise en œuvre technique sont déplacées à la section 3.
2.2. Démarrer le jeu
Le menu principal présente une interface vaguement inspirée de YouTube, mais au lieu de vidéos, elle affiche des scénarios de jeu. Le cœur de l’écran est constitué de blocs de recommandations et de la section historique. D’autres fonctions sont disponibles : listes des scénarios marqués comme appréciés et de ceux auxquels l’utilisateur prévoit de revenir plus tard.
2.2.1. Créer un jeu via les recommandations
S’il s’agit de votre première session, le jeu vous proposera des tendances dans différentes catégories avec divers scénarios populaires. Si ce n’est pas votre première session, le jeu connaît déjà vos intérêts et affiche dans les recommandations des scénarios que vous n’avez pas encore essayés mais qui devraient vous plaire. Par exemple, si vous aimez la Rome antique, l’espace et les courses, les recommandations peuvent inclure des thèmes : « Empereur Trajan », « Chute de Rome », « Anciens Germains », « Colonisation de Mars », « Circuit de Monza », « Moteurs à réaction ». Vous pouvez choisir n’importe quel thème.
2.2.2. Charger une partie
Vous pouvez ouvrir la section Historique et continuer une des parties créées auparavant — une présentation familière des sauvegardes et du retour aux sessions précédentes. Les sauvegardes peuvent être partagées avec d’autres joueurs.
2.2.3. Configuration du scénario
Après avoir sélectionné l’idée de base du scénario, vous pouvez définir le caractère de la campagne à venir. Si souhaité, des conditions de départ sont définies : caractéristiques du monde et de votre personnage, ainsi que les traits clés à partir desquels l’histoire commence.
2.2.4. Génération du jeu
À partir du scénario choisi, un monde de jeu est généré en accord avec le thème sélectionné. Même avec les mêmes recommandations, les conditions de départ peuvent différer, ce qui rend chaque début unique. Si souhaité, vous pouvez définir une « graine de jeu » pour reproduire des conditions de départ similaires lors d’une nouvelle partie.
2.3. Le monde
2.3.1. Règles
Les règles universelles du monde constituent un ensemble commun de régularités qui, dans leur forme idéale, convient aux jeux de rôle et de stratégie. Par elles, d’autres genres peuvent aussi être décrits — action, sport, course, aventure et leurs sous‑genres. Il ne s’agit pas de mécaniques spécifiques, mais de principes permettant d’exprimer la logique de la plupart des mondes de jeu.
2.3.2. Genres
Le jeu n’a pas de genres rigides qui limitent les mécaniques. Les genres existent plutôt comme des modules, combinables et configurables comme un jeu de construction. La base reste le jeu de rôle — la manière la plus naturelle et compréhensible pour une personne d’interagir avec le monde.
Si vous voulez une expérience stratégique et, par exemple, vivre la vie de César, vous dirigez des légions en tant que personne, en étant au cœur des événements et en participant aux batailles à la première personne. Si vous devez voir l’ensemble, vous pouvez sortir du rôle humain, vous accorder des capacités spéciales et observer le champ de bataille d’en haut, obtenant une vue stratégique. En mode rôle, les ordres ne sont pas exécutés instantanément : ils passent par une chaîne de messagers et d’officiers, peuvent être retardés, déformés ou même se perdre. Vous pouvez cependant sortir du rôle et vous donner la capacité de transmettre les ordres directement, comme par télépathie, obtenant une exécution immédiate et inconditionnelle — même si elle exige un sacrifice. Ce pas fait glisser progressivement l’expérience du rôle vers la stratégie classique, où les ordres s’exécutent immédiatement et précisément.
Dans les jeux d’action habituels, le facteur décisif est la réaction en fractions de seconde ; ici, l’issue dépend du niveau de compétence du personnage. Pour un héros particulièrement agile, le temps peut sembler ralenti. Dans les courses, réussir un virage à grande vitesse résulte de nombreux facteurs : compétences et état du pilote, caractéristiques de la voiture, qualité du revêtement, adhérence de la route, présence d’adversaires proches et une part de hasard.
2.3.3. La connaissance comme base du jeu
Le monde d’un jeu universel repose sur la connaissance : faits du passé et du présent, représentations du futur, ainsi que fiction et fantaisie. Cette connaissance se reflète sous forme d’entités de jeu, de propriétés et de relations avec lesquelles vous interagissez.
Biomes, équipements, créatures, phénomènes naturels, planètes et mondes entiers sont perçus comme des objets de cette connaissance. Dans son image de base, un tel monde est proche de la réalité : flore et faune, saisons, époques géologiques et historiques, développement scientifique et technologique. Les personnes ont des compétences, des forces et des faiblesses, une histoire personnelle et une motivation. Elles peuvent tomber malades, subir des blessures et mourir sans aide. Les scénarios fantasy, science‑fiction, alternatifs et post‑apocalyptiques se superposent à cette base en modifiant certains aspects du monde sans en détruire l’intégrité.
2.3.4. Événements
Les événements ne surgissent pas d’eux‑mêmes. Ils sont la conséquence d’autres processus. La sécheresse entraîne la mort de l’herbe, le manque d’herbe provoque la mort des herbivores, et les prédateurs affamés, privés de proies, peuvent commencer à attaquer les humains. Le monde évolue comme une chaîne de causes et d’effets, où chaque changement déclenche de nouveaux processus.
Le monde n’attend pas que vous interveniez. Son histoire n’est pas prédéfinie et ne se construit pas sur des scripts. Elle se forme à partir de vos choix, des actions d’autres entités, des lois du monde et du hasard. Si un scénario a une base historique, les événements se répètent non pas parce qu’ils sont « programmés », mais parce que les mêmes causes conduisent à nouveau aux mêmes conséquences — comme l’effondrement de l’âge du bronze, né d’une cascade de changements climatiques.
2.3.5. Conséquences des décisions du joueur
Les actions du joueur déclenchent des chaînes d’événements qui restent dans le monde. Par exemple, dans une situation critique, un chef de groupe peut décider de sacrifier un membre de l’équipe et ternir sa réputation, laissant une marque pour le reste de sa vie.
Plus l’influence est forte, plus les conséquences sont à grande échelle. On peut changer le cours d’une rivière et accélérer le temps d’un siècle pour voir comment le paysage change. On peut accomplir un exploit, disparaître mille ans et revenir dans une nouvelle époque où son nom est devenu un mythe.
Le monde tient sa propre histoire, conservant des événements clés, leurs causes et des résultats lointains. Vous pouvez étudier vos anciennes sessions de jeu des centaines d’années plus tard — à travers des livres et l’archéologie — et voir comment les décisions d’autrefois ont façonné le monde actuel.
2.3.6. Motivation
Toute entité — personne, animal, organisation ou État — agit dans le cadre de son rôle et de sa motivation. Elle poursuit ses propres objectifs indépendamment de vous. Rêve, amour, agressivité, cupidité — des états qui influencent le comportement des personnages et les poussent à agir. Par exemple :
- Une longue absence auprès d’une personne aimée peut affecter fortement l’état d’un personnage et modifier ses décisions.
- Un pharaon peut ordonner à un vizir de construire une pyramide, et pour le vizir cela devient une tâche déterminante.
- Les cerfs cherchent de la nourriture, se reproduisent et évitent les prédateurs.
- Un syndicat criminel cherche à étendre son influence et à saisir de nouveaux territoires.
2.3.7. Dramaturgie
Dans un monde entièrement simulé, de longues « périodes calmes » sont possibles. Si vous jouez un fermier, vous pouvez vivre dix ans sans guerres, catastrophes ni grands changements. Si l’objectif est de vivre honnêtement le rôle avec tous ses jours vides, le monde peut rester tel quel.
Mais si vous vous ennuyez, la dramaturgie peut être renforcée. Cela change la sensation générale : le rythme s’accélère, les événements se densifient, et l’équilibre entre moments calmes et tendus se déplace sans sortir de la logique du monde. Dans ce mode, le monde devient moins prévisible : petits incidents, rencontres inattendues et rares retournements du destin apparaissent. La simulation ne se brise pas, mais la vie du personnage devient plus cinématographique — ainsi, un policier ordinaire peut progressivement se retrouver dans une histoire faite de poursuites, d’enquêtes et de tournants dramatiques.
Si vous voulez un maximum de dynamisme, la dramaturgie peut être renforcée encore davantage — alors une nouvelle histoire surgira à presque chaque coin de rue, et ce qui se passe ressemblera à un blockbuster d’action.
2.3.8. Changer les règles du jeu
Vous pouvez à tout moment sortir du rôle choisi et changer les règles de ce qui se passe. Si, en jouant un employé de bureau japonais, vous décidez de devenir un super‑héros, ce n’est pas une action ordinaire dans le monde, mais un pas qui change la logique du récit.
Vous pouvez modifier le monde et ses lois : ajouter de la magie, changer les propriétés des objets et des créatures. Dans un tel monde, l’eau peut brûler comme du bois, et les pigeons peuvent devenir intelligents. Ensuite, le monde continue de se développer avec les nouvelles règles, en restant cohérent.
Vous pouvez même expérimenter avec les fondations et créer des mondes qui contredisent la logique familière : mondes de paradoxes, mondes miroirs, autres univers avec leur propre physique et structure de la réalité. Cette approche unit gameplay, simulation et édition du monde, ouvrant des possibilités presque illimitées. Même lorsque les lois changent, le monde reste cohérent car les principes de causalité continuent d’opérer dans le nouveau cadre.
Un instantané du monde actuel peut devenir la base d’un nouveau jeu. Un joueur, agissant dans le rôle d’un « dieu », peut créer un monde dans lequel d’autres vivront. Cela ressemble à un mod ou à un éditeur de cartes, mais intégré à la logique même du jeu universel.
2.4. Gameplay
2.4.1. Jeu de rôle
Souhaitez‑vous devenir la personne la plus riche ? Obtenir des super‑pouvoirs et vivre éternellement ? Conquérir l’espace ? Retourner dans le passé avec les connaissances du présent ?
Vous pouvez commencer immédiatement dans le rôle souhaité ou partir de zéro, en élargissant progressivement les capacités et les limites de votre personnage. Le jeu de rôle est possible non seulement en tant qu’humain, mais aussi en tant qu’événement, abstraction ou idée : un feu, une épidémie, une organisation, une religion, une langue. Le scénario initial ne fixe que le point de départ, et la suite dépend entièrement de vos décisions.
2.4.2. Objectif du jeu
L’objectif du jeu peut être défini par le scénario, par vous‑même ou par une combinaison des deux, ou encore être absent. Il peut aller d’une tâche quotidienne à un accomplissement d’époque — obtenir le travail de ses rêves ou inventer la « pierre philosophale ». Atteindre l’objectif ne met pas fin au jeu : le monde continue de vivre, et vous pouvez y rester aussi longtemps que vous le souhaitez.
2.4.3. Changement dynamique de rôle
À tout moment, vous pouvez changer de rôle et continuer l’histoire du point de vue d’une autre entité dans le même monde. Un tel changement n’interrompt pas ce qui se passe et vous permet de voir les événements sous un autre angle. Par exemple, vous pouvez incarner tour à tour différents membres d’une famille ou différents soldats sur le champ de bataille. Une telle expérience va au‑delà du jeu de rôle d’un seul personnage, à moins que le jeu lui‑même ne soit construit autour de l’idée de réincarnation.
2.4.4. Actions du joueur
Les actions disponibles correspondent à la situation actuelle et aux caractéristiques de votre personnage. Elles sont formées par le contexte de ce qui se passe et par qui vous êtes à ce moment‑là.
Par exemple, lors d’un incendie, les options attendues apparaissent généralement : fuir, éteindre le feu, aider les autres. Cependant, vous pouvez agir différemment et, par exemple, contribuer à la propagation du feu. Cette différence dans les actions disponibles reflète la nature du personnage — qui il est et comment il a tendance à agir. Pour un pyromane, la situation d’un incendie sera perçue différemment que pour une personne ordinaire.
2.4.5. Contrôle automatique et manuel
Par défaut, chaque entité dans le monde existe de manière autonome, agissant selon sa nature, ses motivations et ses objectifs. Cela s’applique aussi à votre personnage jusqu’à ce que vous preniez le contrôle. Si vous choisissez le rôle d’un leader et interagissez avec des groupes d’entités, le contrôle n’est pas perçu comme un contrôle direct mais comme un système de requêtes, d’ordres et d’attentes.
D’autres entités peuvent répondre à votre ordre ou refuser de l’exécuter — selon leur attitude envers vous, les ressources disponibles, la peur, la fatigue ou des limitations physiques.
2.4.6. Observation
Vous n’êtes pas obligé de jouer directement. Créez un personnage intéressant, placez‑le dans une situation inhabituelle, réglez le niveau de dramaturgie souhaité (voir point 2.3.7. Dramaturgie) et observez comment les événements se déroulent. Une telle expérience peut ressembler au visionnage d’un film dont l’histoire se déroule d’elle‑même.
Le résultat de l’observation peut être partagé avec d’autres joueurs en sauvegardant et en transférant l’état du monde. Peut‑être que l’histoire de quelqu’un deviendra un nouveau blockbuster. Ce mode convient non seulement au divertissement, mais aussi à la modélisation : vous pouvez créer, par exemple, une « civilisation de tortues » et suivre son évolution de l’âge de pierre jusqu’au vol spatial.
2.5. Interaction de gameplay
2.5.1. Caméra et présentation
Ce qui se passe dans le jeu peut être perçu de différentes manières : à la première personne, à la troisième personne, en vue de dessus, ou même sous forme de texte. La présentation change selon le contexte et le rôle choisi. Par exemple, il est naturel pour une personne de voir le monde à la première personne, les pensées peuvent être perçues comme du texte, et lorsque l’on joue un pays ou une planète, la vue se déplace vers une vue stratégique globale.
Un jeu universel n’est pas lié à une seule méthode de présentation et peut prendre l’apparence la plus la plus pratique selon le moment. Même une personne aveugle pourra interagir avec le monde, en percevant objets et événements par le son et la description.
L’étendue du monde perçu correspond toujours au rôle actuel. Si vous êtes une personne, vous êtes limité par les capacités de vos sens. Si vous vous accordez des capacités spéciales, la perception s’élargit, vous permettant de voir ce qui est caché ou éloigné.
2.5.2. Graphismes et son
L’interface, le style visuel, l’animation, la musique et le son renforcent l’expérience de jeu et vous aident à ressentir le rôle choisi. Dans un monde d’antiquité et de pensée magique, l’image visuelle et sonore souligne la dualité du monde des hommes et des dieux, créant la sensation d’une dimension supplémentaire où chaque action est chargée de sens sacré. Dans un cadre post‑apocalyptique, graphismes et son transmettent la fragilité de la survie, un sentiment de perte et de rares espoirs de nouveau départ. Dans le monde d’une chauve‑souris, l’espace est perçu différemment : l’échelle et la forme sont ressenties par le son plutôt que par la vue.
2.5.3. Carte
Le monde ou sa carte peut être n’importe quelle surface — une planète, une région, un navire ou même un corps humain — selon le rôle choisi. Par exemple, en jouant une fourmi, la carte devient une clairière près d’un ruisseau. La perception de l’espace change avec l’échelle : la vue peut zoomer ou dézoomer, et l’angle de vue peut se déplacer.
Lors d’un zoom avant, les détails apparaissent ; lors d’un zoom arrière, ils disparaissent, laissant place à des structures et des connexions plus vastes.
2.5.4. Temps
Le temps s’écoule à différentes vitesses selon le rôle choisi et vos préférences. En combat, il peut s’écouler en secondes. En mode global, lorsque l’on modélise des processus géologiques, une seconde de temps de jeu peut correspondre à des millions d’années. L’accélération est particulièrement appropriée lorsqu’on joue des êtres ayant une autre perception du temps — plantes ou formes de vie longévives.
Le temps peut être arrêté, accéléré, sauté ou inversé. Si vous le souhaitez, vous pouvez jouer en mode tour par tour sans précipiter les décisions. Dans certaines situations, le temps ne s’écoule que lorsque vous contrôlez un personnage précis et s’arrête lorsque vous réfléchissez à la prochaine étape.
2.5.5. Jeu en ligne
Les joueurs en ligne peuvent jouer simultanément différents personnages et entités dans le même monde, après s’être mis d’accord à l’avance sur les règles du flux temporel. L’un peut être Napoléon donnant des ordres à l’armée, un autre un grenadier attaquant des ennemis sur le champ de bataille. Les joueurs peuvent aussi être opposés : certains sont des villageois, d’autres des pillards terrorisant une colonie, d’autres encore des chasseurs de primes traquant des bandits.
2.6. Universalité
2.6.1. Sens
Nexus peut exprimer et reproduire la logique de la plupart des jeux existants au niveau de leurs règles et interactions. Il ne s’agit pas de copier des implémentations spécifiques, mais de reproduire leur logique de gameplay fondamentale.
Cela est possible parce que tout jeu est un ensemble de règles, et que les règles peuvent être décrites via de simples énoncés sémantiques (triplets).
Exemples : Dark Souls (en termes de règles) :
- Mort -> cause -> perte_d’âmes
- Feu de camp -> est -> point_de_réapparition
- Ennemi -> difficulté -> élevée
- Coup -> dépend_de -> endurance
Civilization (en termes de règles) :
- Tour -> durée -> dépend_de_ère
- Ville -> produit -> [unités, bâtiments]
- Victoire -> conditions -> [science, militaire, culture]
The Sims (en termes de règles) :
- Personnage -> besoins -> [faim, sommeil, socialisation]
- Besoin_faible -> cause -> mauvaise_humeur
- Action -> satisfait -> besoin
2.6.2. Mélanges de genres
Puisque les règles sont organisées en modules, elles peuvent être combinées. Cela permet d’assembler de nouveaux formats de gameplay à partir d’ensembles de règles connus.
Exemples : Dark Souls + Civilization :
- Vous gouvernez le royaume de Lordran comme une civilisation.
- Les combats et rencontres suivent les règles de Dark Souls (compétence, timing, danger).
The Sims + apocalypse zombie :
- Besoins quotidiens des Sims (nourriture, sommeil, socialisation).
- Au‑dessus, des règles de survie s’ajoutent (abri, armes, danger).
Principe d’universalité : si la logique du jeu peut être exprimée en mots, elle peut être mise en œuvre dans Nexus.
2.7. Exemple
2.7.1. Situation dans le monde
Le joueur est Ivan, un paysan du village de Zarechye. Il a faim, sa femme Maria est enceinte, et le voisin Piotr a perdu une vache. La pluie approche.
2.7.2. Comment le système la comprend (triplets)
À l’intérieur du système, cette situation est décrite par un ensemble d’énoncés simples :
- Ivan -> est -> paysan
- Ivan -> faim -> 30 % (ou Ivan -> satiété -> 30 %)
- Ivan -> situé_dans -> Zarechye
- Maria -> relation -> femme_d’Ivan
- Maria -> enceinte -> 8_mois
- Vache -> appartient_à -> Piotr
- Vache -> lieu -> forêt
- Météo -> approche -> pluie
Chaque énoncé est un atome de connaissance. Ensemble, ils forment l’état actuel du monde.
2.7.3. Ce que voit le joueur
La logique est séparée de la visualisation et reste inchangée. Selon le mode d’affichage, les mêmes triplets sont montrés différemment. Plus d’informations sur le langage UX se trouvent en section 3.9.
2.7.3.1. Mode texte
« Vous êtes Ivan, un paysan. Votre estomac gronde de faim. Votre épouse Maria va bientôt accoucher. Vous entendez votre voisin crier — sa vache s’est enfuie. Une brume pluvieuse est à l’horizon. »
2.7.3.2. Mode carte hexagonale avec icônes
- Case du village avec objets : 🏠 (maison), 🏚️ (grange), 💧 (ruisseau)
- Personnage : 👤 Ivan [🍞30 % rouge]
- Famille : 👩 Maria 🤰 ~30 jours
- Événement : 🏠 Piotr 🔊, traces 🐾🐾 -> 🌲
- Effet : 🌧️ approche
2.7.3.3. Mode 3D
Un village complet, le modèle d’Ivan se tient le ventre, Maria est assise près de la maison, au loin on entend des cris et on voit une clôture cassée, des nuages sombres à l’horizon.
2.7.4. Action du joueur
Le joueur formule une intention : « Aider Piotr à retrouver la vache » Cette action est convertie en triplets :
- Ivan -> intention -> aider
- Aide -> qui -> Piotr
- Aide -> tâche -> trouver_vache
Le système interprète : 1. Ivan peut‑il aider ? -> Oui (en bonne santé, à proximité) 2. Cela prend‑il du temps ? -> Oui (~1 heure) 3. Cela affectera‑t‑il la faim ? -> Oui (elle augmente) 4. Que va‑t‑il se passer ? -> Recherche dans la forêt, chance de trouver la vache
2.7.5. Résultat
Après une heure de temps de jeu :
- Vache -> lieu -> trouvée_au_ruisseau
- Ivan -> faim -> 20 % (augmentée)
- Piotr -> relation_avec_Ivan -> gratitude +10
- Piotr -> obligation -> aide_pour_toit
Visuellement :
- Le joueur voit l’animation du retour avec la vache
- 🍞 20 % (encore plus rouge)
- Une notification apparaît : « Piotr est reconnaissant. Il a promis d’aider pour le toit. »
2.8. Du concept à la mise en œuvre
Les sections 2.1–2.7 décrivent l’image souhaitée de Nexus du point de vue du joueur : ce qu’il voit, comment il interagit avec le monde, quelles possibilités il obtient.
Principes clés :
- Toute situation de jeu peut être décrite avec des mots.
- Les mots peuvent être formalisés en triplets (énoncés simples).
- Les triplets peuvent être interprétés (des inférences peuvent être faites).
- Le résultat peut être visualisé de n’importe quelle manière.
3. Concept d’implémentation

3.1. Objectif de la section
Cette section est consacrée à des idées sur la manière dont le projet Nexus peut être implémenté techniquement et structuré en interne. Elle ne décrit pas des solutions techniques spécifiques, mais des principes et des directions qui rendent un tel jeu possible. Les implémentations concrètes sont censées être déterminées pendant le développement et affinées en pratique.
La section ne traite pas les concepts de jeu en tant qu’idées en soi ; l’accent est exclusivement mis sur les approches de leur mise en œuvre. La section est principalement destinée aux spécialistes et aux développeurs de jeux vidéo.
3.2. Approche flexible
L’approche classique de création de jeux vidéo repose sur des systèmes de jeu rigides conçus à l’avance, à l’intérieur desquels le joueur est autorisé à agir. Même les jeux bac à sable offrant un haut niveau de liberté restent essentiellement un grand ensemble de systèmes séparés. Cela donne une impression de variété des possibilités, mais le principe d’une architecture rigide ne change pas. Ajouter de nouveaux systèmes au fil du temps accroît surtout la complexité de développement et de maintenance, sans élargir qualitativement l’expérience de jeu.
Pour atteindre une véritable flexibilité, il faut repenser la base de cette approche. L’ajout de nouvelles mécaniques ne doit pas augmenter la complexité architecturale du projet. Au contraire, les éléments de base du jeu doivent être organisés comme des atomes — des unités minimales, universelles et mutuellement compatibles, à partir desquelles tout le reste peut être construit.
Minecraft illustre bien cette approche. Il permet de créer des constructions extrêmement complexes — châteaux, villes ou stations spatiales entières composées de millions de blocs. En même temps, la croissance du nombre d’objets n’entraîne pas une plus grande complexité interne : le système est conçu pour l’évolutivité dès le départ.
Dans un jeu profondément universel, un principe similaire peut être appliqué à toute l’architecture. Le nombre de mécaniques peut être arbitrairement grand, mais elles doivent être organisées de manière cohérente afin de coexister, se combiner et former des mondes de toute complexité sans perdre l’intégrité et la maniabilité du système.
3.3. Réseau sémantique
Une manière d’implémenter une approche flexible est de représenter les données du jeu sous forme d’unités logiques atomiques — des triplets. Un triplet est un énoncé simple du type « sujet – prédicat – objet ». Par exemple :
- Pomme – est – comestible
- Pomme – a valeur_nutritive – 5
- Humain – peut_manger – fruits
- Herbe – pousse – à humidité au‑dessus d’un certain niveau
- Cerf – est – herbivore
- Syndicat – contrôle – un quartier de ville
À travers les triplets, tout peut être décrit : objets, propriétés, états, relations, actions possibles, règles de jeu, technologies ou magie. C’est une représentation des connaissances qui n’est pas liée à une implémentation spécifique du jeu. Ce n’est pas seulement un format de données, mais une manière de décrire le sens du monde.
Pour que le monde soit profond et cohérent, il s’appuie sur un grand volume de données — des principes généraux de structure du monde aux faits de jeu individuels. Ces données sont remplies de contenu concret : animaux, technologies, objets, bâtiments, événements historiques et autres entités.
3.4. Interpréteur
Au‑dessus de la couche de données opère un interpréteur. Il peut être basé sur des systèmes logiques (par exemple Apache Jena) ou sur des approches neuronales. Sa tâche est de traiter les triplets et de réaliser des inférences logiques. Par exemple :
- Pomme – est – un fruit
- Humain – peut manger – des fruits
- Conclusion : un humain peut manger des pommes
L’interpréteur obtient cette conclusion en combinant plusieurs faits. Les chaînes d’inférence peuvent être bien plus longues.
Dans le jeu, l’interpréteur est utilisé pour peupler le monde et déterminer les actions autorisées. Il répond à des questions telles que :
- Quels arbres peuvent pousser dans le désert tropical d’Arabie.
- Quelles actions les gens peuvent entreprendre envers un chien à l’âge de pierre et à l’époque moderne.
- Quels objets sont disponibles à la perception du joueur à l’instant donné.
L’interpréteur décompose ces questions en requêtes de données plus simples et les ramène à une représentation sémantique unifiée, sur la base de laquelle la réponse est formée. Il travaille avec des requêtes déjà formalisées et n’interagit pas directement avec le langage naturel.
3.5. ECS sémantique
Pour que le monde d’un jeu universel fonctionne sur la base de la sémantique, de la logique et de grands ensembles de faits, il lui faut une architecture capable de décrire les objets et leurs propriétés de la manière la plus flexible possible, sans hardcode rigide.
Ce problème est résolu par l’ECS sémantique — une variante de l’ECS classique adaptée à la représentation des connaissances et des relations entre entités. Dans ce contexte, l’ECS est considéré avant tout comme un modèle de données plutôt que comme une boucle de mise à jour, et sert de point d’entrée pratique plutôt que d’architecture finale.
À la base du monde se trouvent des entités : personnages, objets, animaux, organisations, navires, plantes. Comme dans l’ECS classique, une entité ne contient ni logique ni données ; elle sert d’identifiant auquel des composants sont attachés.
La différence clé réside dans la structure des composants. Dans un ECS traditionnel, un composant est une structure avec des champs. Dans un ECS sémantique, au lieu de grands composants, on utilise des composants‑prédicats : « Est », « A », « Contient », « Peut », « Se rapporte à », etc. Chaque prédicat exprime une relation ou une affirmation sur le monde.
Par exemple, l’entité « Pomme » peut avoir le composant‑prédicat « Est », pointant vers les entités « Fruit » et « Comestible ». En même temps, « Comestible » est aussi une entité avec ses propres propriétés : « A – Nutrition », « A – Goût ». Chaque composant de valeur stocke exactement une valeur, par exemple : « Nutrition = 5 », « Goût = sucré », « Poids = 0.2 ».
Cela forme un réseau ou un arbre de propriétés où chaque lien reste atomique. Tout objet, propriété ou relation dans le monde est décrit par un fait minimal séparé. Grâce à cela, les règles et interactions ne sont pas codées en dur, mais existent comme des données.
Le caching, les index et les mécanismes de niveau de détail (LOD, voir ci‑dessous) assurent la performance. Cela permet de modéliser un monde composé de millions de faits tout en restant performant, logiqueiquement cohérent et pilotable via des règles sémantiques.
3.6. Règles du jeu
Les données et la logique de traitement ne constituent pas un jeu en soi. Pour que le gameplay apparaisse, une couche supplémentaire est nécessaire — les règles du jeu. Elles ne sont pas codées en dur ; elles étendent les règles de base du langage et peuvent être connectées selon les besoins. Comme dans les jeux de mots, leur rôle est de poser des limites : ce qui est permis ou non, quels objectifs existent, quels rôles sont possibles et comment le gameplay se développe. Les règles réduisent les possibilités presque infinies du langage à un espace limité où le gameplay prend forme.
Dans l’industrie du jeu, on construit généralement les règles de jeu à partir de zéro pour chaque nouveau jeu. En même temps, les différences entre les jeux ne sont souvent pas fondamentales : la plupart des RPG et des stratégies sont conceptuellement similaires, différant par des détails mécaniques, les graphismes ou le lore. Cette approche est devenue la norme de facto, et l’uniformité de l’expérience est perçue comme normale. La variété est obtenue principalement par le style visuel, l’atmosphère et le récit, non par des différences fondamentales de capacités.
Des règles universelles impliquent la systèmesatisation et l’unification des mécaniques éprouvées. Cela permet aux développeurs de ne pas reconstruire la base à chaque fois, mais de se concentrer sur des aspects plus complexes et de plus haut niveau. Les règles peuvent être organisées en modules et connectées selon les besoins pour former une expérience de gameplay spécifique.
Cette approche ressemble à la structure des moteurs de jeu. Par exemple, Unity ou Unreal Engine évitent aux développeurs d’implémenter des fonctions de bas niveau. Ici, il ne s’agit pas d’implémentation technique mais de règles universelles de jeu. On trouve des idées similaires dans des systèmes de jeu de rôle sur table comme GURPS, ainsi que dans des sandboxes complexes comme Minecraft, Dwarf Fortress ou RimWorld, où certaines règles ont déjà un caractère universel.
Par défaut, les « règles » sont une structure vide qui ne gagne du contenu que lorsque des modules sont connectés. La composition des modules détermine le comportement du monde : comment les dégâts sont calculés, ce qu’est l’initiative, comment l’économie fonctionne, comment les entités interagissent, comment les événements sont traités et quelles contraintes s’appliquent. Cette approche permet d’assembler les mécaniques du monde comme un jeu de construction.
Les modules peuvent librement combiner les genres. Si vous ajoutez un module de combat à un module au tour par tour, les pièces deviennent des personnages avec santé et compétences. Si vous ajoutez un module de plateforme, les entités gagnent la capacité de sauter, et l’ajout d’un module d’économie introduit la production de ressources. La configuration des règles devient une partie du jeu lui‑même : scénarios, univers et genres se configurent comme n’importe quel autre élément du monde.
Au final, la modularité des règles transforme la logique du jeu d’un ensemble fixe de contraintes en une architecture flexible. Cela permet au même système de prendre en charge des RPG, stratégies, simulations, jeux de course et autres genres sans changer le code — par la combinaison de règles et de données. C’est précisément cette modularité qui rend un jeu universel réellement universel.
3.7. Abstractions et LOD
3.7.1. Perception limitée et besoin d’abstractions
Le monde d’un jeu universel peut contenir un nombre énorme de processus : des migrations animales et de la croissance des villes au comportement des microorganismes ou à la dynamique des systèmes stellaires. Un recalcul complet de tout l’espace et de toutes les échelles est impossible et inutile — le joueur perçoit toujours le monde subjectivement et dans un cadre limité. Le système utilise donc une couche d’abstractions qui permet au monde de rester scalable sans perdre sa logique.
Les abstractions s’appliquent là où un haut niveau de détail n’affecte pas le résultat du gameplay. Dans le micro‑monde, au niveau de la biosphère d’une planète ou d’un système stellaire, différentes entités et règles sont utilisées, adaptées à l’échelle de ce qui se passe. Ainsi, le système ne modélise pas le comportement de chaque entité individuelle, mais prend immédiatement en compte le résultat global des processus.
3.7.2. Mise à l’échelle du temps et de l’espace
Lorsque le temps est accéléré, le jeu ne recalcule pas chaque moment sauté. À la place, le système analyse l’état actuel du monde, applique des relations de cause à effet à une échelle agrégée et interpole des résultats probables : comment la population évolue, quelles tendances s’intensifient, quels événements sont les plus susceptibles de se produire. Cela permet d’avancer de décennies ou de milliers d’années tout en conservant la cohérence du monde.
La mise à l’échelle de l’espace ne change pas la structure du monde, mais détermine le niveau des entités et des processus avec lesquels la simulation travaille. À grande échelle, on considère des entités et processus agrégés — climat, migrations, structures politiques. En passant à une échelle locale, le monde s’ouvre aux entités individuelles et à leurs propriétés. Dans tous les cas, une logique unifiée de cause‑effet est préservée.
Les abstractions permettent au jeu de contenir un monde de n’importe quelle échelle : un village, une planète, un écosystème ou une galaxie. Les détails n’apparaissent que lorsqu’ils deviennent significatifs pour le joueur ou pour la logique des événements. Tout le reste est décrit de manière simplifiée, tout en préservant les relations de cause à effet.
Le joueur peut plonger dans la structure du monde, étudier des entités et naviguer dans leurs propriétés comme dans un système de référence. La seule limite ici est la disponibilité des données et des règles du monde.
3.7.3. Matérialisation du monde
Le monde se forme à mesure qu’il est exploré. Jusqu’à ce que le joueur visite un lieu, il existe sous forme de données et de règles sans objets concrets. Les objets ne se matérialisent que lorsque le joueur interagit avec le monde. C’est similaire au chargement par chunks dans Minecraft : le monde n’est pas entièrement calculé, mais est subjectivement perçu comme déjà existant.
Les événements sont générés comme si le monde existait dans toute sa complexité, même au‑delà de l’observation du joueur.
Après la fin de l’interaction avec un lieu ou des entités, son état est stocké comme nouvelle connaissance du monde et ne participe plus aux calculs actifs. Cette approche permet au monde de s’étendre vers l’extérieur et l’intérieur — du micro‑monde aux galaxies — sans stocker et recalculer des détails inutiles.
Pour de grands intervalles de temps, des tendances statistiques sont utilisées. Par exemple, on sait que des astéroïdes de l’ordre du kilomètre entrent en collision avec la Terre environ une fois par million d’années. Des modèles estiment la probabilité de disparition d’une civilisation technologique sur un horizon de milliers d’années. Ces estimations ne fixent pas un résultat précis, mais déterminent une plage de scénarios possibles. Ainsi, lorsque le joueur avance de mille ans, le système choisit l’un des futurs plausibles — ruines de civilisation, développement stable ou autre scénario cohérent.
3.7.4. Jeu en ligne
En mode en ligne, le même principe de matérialisation par interaction est utilisé. Le serveur ne stocke pas le monde comme une carte entièrement calculée et fixe. Il fonctionne avec des données, des règles et des faits déjà manifestés — ce qui a été découvert ou modifié par les joueurs.
Lorsque un ou plusieurs joueurs interagissent avec une zone, le serveur forme un état matérialisé partagé, synchronisé entre tous les participants. Cet état existe exactement au niveau de détail qui est effectivement observé et utilisé.
En dehors de la zone d’interaction, le monde n’est pas recalculé en continu. Il reste dans un état potentiel décrit par des règles, des tendances statistiques et des faits accumulés. Cela permet de maintenir un monde unique, vaste et continu avec de nombreux joueurs, en ne synchronisant que ce qui est réellement observé et pertinent pour le gameplay.
3.8. Agents et simulation du monde
Toute entité dans le monde — personne, animal, organisation ou État — est considérée comme un agent avec ses propres objectifs, motivations et états. Un agent :
- Perçoit le monde dans les limites de ses connaissances.
- Évalue les options d’action disponibles.
- Prend des décisions en fonction de ses objectifs et des règles du monde.
- Déclenche des événements qui modifient l’état du monde.
Le monde dans son ensemble fonctionne comme une simulation multi‑couches :
- La nature évolue sous l’influence du climat et des ressources disponibles.
- Les écosystèmes réagissent aux changements environnementaux.
- Les personnes et les sociétés réagissent aux changements de la nature, de la technologie et de la politique.
- Le joueur entre dans ce processus en tant qu’une des entités du monde.
L’histoire du monde n’est pas prédéfinie et n’est pas écrite à la main. Elle émerge de l’interaction de nombreux agents qui agissent dans des lois communes et des relations de cause à effet.
Par exemple, la sécheresse entraîne moins d’herbe, le manque d’herbe entraîne la faim des herbivores, la faim entraîne la migration, et la migration entraîne des affrontements avec des prédateurs ou des humains. De telles chaînes se forment sur la base de faits et de règles, déterminant ce qui découle naturellement des conditions actuelles.
3.9. Langage UX
Le langage d’interaction avec le jeu est construit sur une logique proche du langage humain. Par ce langage, le joueur et le jeu communiquent efficacement entre eux. Le langage dispose d’un ensemble de règles dans lequel on peut former des constructions significatives de presque n’importe quelle complexité.
Chaque état de l’interface ou de la carte peut être vu comme une question : « Que vois‑je maintenant ? », et l’ensemble des actions disponibles comme la question « Que puis‑je faire dans la situation actuelle ? ». Le jeu, en analysant l’état du monde, la position de l’avatar et l’objet d’interaction visé, forme une réponse sous la forme d’un nouvel état du monde et d’une nouvelle présentation de l’interface.
Au niveau le plus simple, le langage désigne les choses perçues dans le monde : « arbre », « mère », « soleil ». Au niveau suivant, le langage permet de décrire leurs propriétés et états : « personne en colère », « beaucoup d’étoiles », « lion fort », « 300 Spartiates ».
Dans le jeu, ces concepts peuvent être représentés littéralement — comme des entités spécifiques — ou conditionnellement, par des pictogrammes. Chaque mot ou concept correspond à une icône.
Les propriétés des objets sont exprimées par des techniques visuelles :
- « En colère », « mauvais », « négatif » — un fond rouge pour l’icône.
- « Beaucoup », « 300 », « millions », « infini » — un mini‑pictogramme de multiplicité avec une valeur numérique spécifique ou abstraite.
- « Fort », « dangereux », « puissant », « niveau 3 » — un mini‑pictogramme de niveau avec indication de valeur.
- La couleur du cadre peut montrer l’appartenance d’une entité à un autre joueur ou à une faction.
Des pictogrammes supplémentaires, des animations, des halos et autres éléments visuels peuvent être ajoutés à l’icône principale pour transmettre des propriétés fréquentes ou une tonalité émotionnelle. Pour des caractéristiques plus complexes ou rares, des icônes auxiliaires sont utilisées à côté de l’entité principale ou intégrées en plus petit.
Les icônes peuvent être animées, ajoutant une couche d’information supplémentaire. Par exemple, à un niveau de santé critique, un cœur sur l’icône peut battre de manière irrégulière et faible, indiquant un état dangereux.
Le langage reflète également les connaissances limitées du personnage. Si l’avatar rencontre un représentant d’une autre culture et ne comprend pas sa langue, les icônes peuvent être déformées ou devenir illisibles. Si seule une partie de l’information est connue, les éléments correspondants sont masqués : le joueur peut connaître le type d’ennemis mais pas leur nombre.
Les mêmes entités peuvent apparaître différemment selon les cultures. Les anciens Égyptiens verront des hiéroglyphes, tandis que des êtres robotisés verront des symboles technologiques et numériques.
Quand le joueur effectue une action, il interagit avec des objets du monde. En simulation directe, cela peut être une action physique à la première personne, et en modes abstraits, la sélection d’icônes conditionnels. L’action elle‑même se forme à partir d’une construction linguistique de base.
Au cœur du langage de jeu se trouvent les triplets sémantiques : sujet – action – objet.
Exemples :
- « Je – veux – une pomme »
- « Nous – déclarons – la guerre – à vous »
- « Nous – attaquons – la tribu de la Plume blanche »
Dans l’interface, cela ressemble au choix d’un sujet (l’avatar du joueur ou une autre entité), à la sélection d’un objet et à la spécification d’une action.
La construction peut être compliquée par l’ajout de modificateurs : temps, adjectifs, conditions. Par exemple : « Esclave (sujet) – construire (prédicat) – pyramide (objet) – rapidement (modificateur du prédicat) ». Le modificateur « rapidement » signifie que des règles spéciales s’appliquent : le travail est effectué plus vite, mais le risque d’accidents augmente ou la qualité du résultat diminue.
Si l’action est dirigée non pas vers l’avatar lui‑même mais vers un autre sujet, elle est interprétée comme une requête ou un ordre.
4. Feuille de route

4.1. Vision stratégique
Cette section décrit le plan de mise en œuvre du projet Nexus.
Une approche consistant à développer un seul projet puis à passer en accès anticipé ne convient pas ici. Une approche plus appropriée est le développement progressif d’une série de projets, chacun mettant en œuvre et testant des idées et des directions particulières, rapprochant le projet de la vision finale de Nexus. Chaque projet‑étape travaillera avec les retours et les critiques, permettant d’évaluer l’adéquation du projet au concept initial et la justesse de la direction choisie. Avec le temps, ces projets deviendront plus complexes et de meilleure qualité, et l’un d’eux pourra finalement devenir un projet Nexus complet décrit en section 2.
Le développement de Nexus est divisé en une série de projets‑étapes. Pour les étapes plus proches du présent, les objectifs et les tâches sont formulés de manière plus claire et concrète. Les étapes plus éloignées sont décrites au niveau de directions et d’idées générales, sans élaboration détaillée. L’ordre des étapes n’est pas strictement fixéé. La feuille de route donne la direction globale du projet, pas un plan détaillé. Au fil du développement, les étapes et les tâches peuvent être précisées et complétées.
4.2. Étapes
4.2.1. Étape 0. Former une compréhension du jeu universel (terminé)
Le travail de Clarus Victoria depuis 2013, la sortie de six projets, ainsi que des années de recherche, d’expérimentation et de prototypage ont permis de former une compréhension de base de ce qu’un jeu universel peut être et des principes qui le sous‑tendent. Le résultat de cette étape a été la création de ce document.
4.2.2. Étape 1. ECS et unification des entités (terminé)
- L’architecture ECS a été validée sur le projet Next Run. Les entités sont représentées comme des conteneurs vides avec un ensemble de composants, ce qui permet de former de manière flexible les objets du monde : objets, créatures, biomes, événements et effets.
- Un certain nombre d’idées liées aux mécaniques de jeu universelles ont été validées, notamment la combinaison de RPG et de stratégie sans séparation rigide, les actions universelles, un modèle d’écoulement du temps et le contrôle des escouades.
- Pour la première fois pour le studio, une carte hexagonale a été implémentée et testée, permettant de créer et de combiner rapidement différents types de mondes de jeu.
- Pour la première fois pour le studio, la prise en charge des modifications via Steam Workshop a été ajoutée.
Plus d’informations sur cette étape — dans l’article : https://clarusvictoria.com/blog/almost-ten-years-of-search
4.2.3. Étape 2. Gameplay du monde réel (en développement)
Le projet Next Run a permis de tester de nombreuses idées de jeu universel, mais il est limité à un univers fantasy avec des lois du monde conditionnelles. Dans la seconde étape, un passage à la modélisation du monde réel avec ses régularités naturelles et sociales est prévu. L’objectif de l’étape est d’établir une base de gameplay réaliste reposant sur la logique du monde réel et ses régularités naturelles et sociales.
Fonctionnalités à implémenter :
- Évolution des sociétés : de l’humain primitif vivant aux côtés des animaux et suivant les mêmes règles de survie, jusqu’à l’émergence des premières civilisations.
- Biomes et écosystèmes des cases : faim, migrations et compétition pour les ressources. Plantes, animaux et terrain affectent directement la survie humaine.
- Situations et événements de jeu résultant des règles du jeu, et non de scripts prédéfinis. Par exemple, les pénuries de ressources peuvent entraîner des conflits entre groupes humains et des attaques de prédateurs.
- Automatisation des actions d’unités ou contrôle manuel — au choix du joueur, y compris le contrôle de groupes via des règles de comportement partagées. Possibilité de jeu actif et d’observation.
- Possibilité de jouer des personnages individuels ou des groupes.
- Plusieurs joueurs sur une même carte en compétition les uns avec les autres.
- Retour de l’arbre technologique connu des précédents jeux Clarus Victoria.
- Monde de jeu configurable : taille de la carte, époque, climat et caractéristiques régionales.
- Premières versions du modèle d’agent.
- Cadre possible : âges de pierre et du bronze.
4.2.4. Étape 3. Architecture sémantique (prévue)
L’un des pas clés pour réduire les risques du projet Nexus est la transition vers une base sémantique de l’architecture du jeu (voir sections 3.3–3.5).
À ce stade, tous les systèmes sont introduits à un niveau de base, avec une fonctionnalité minimale :
- Triplets sémantiques comme moyen de décrire les entités du monde de jeu.
- Interpréteur.
- Passage du ECS classique au ECS sémantique.
- Règles de base de la nouvelle architecture.
- Cadre possible : l’une des premières civilisations.
Du point de vue des mécaniques de gameplay, aucune nouvelle complexité n’est attendue à ce stade. La tâche principale est de transférer des solutions et mécaniques déjà éprouvées vers la nouvelle base architecturale.
4.2.5. Étape 4. Modèle d’agent (prévue)
À ce stade, il est prévu d’implémenter des systèmes critiques jugés trop risqués pour être introduits à l’étape 2. Il s’agit d’une élaboration profonde des sujets dans le cadre du modèle d’agent. L’étape 2 prépare le terrain, mais à l’étape 4 les agents sont pleinement mis en œuvre. L’architecture du jeu commence à prendre en charge des processus du monde réel plus complexes, permettant de modéliser des sociétés d’un niveau de complexité supérieur par rapport à l’étape 2.
Fonctionnalités à implémenter :
- Modèle complet de comportement d’agent : les entités reçoivent des objectifs, des états et des motivations.
- Système de demandes et d’ordres aux sujets, où l’exécution n’est pas garantieée et dépend de l’état et du contexte.
- Enrichissement du monde, systèmes plus complexes et logique d’objets plus riche.
- Inventaires individuels pour les sujets, chaînes logistiques et système de transport.
- Déplacement d’une partie de la logique du jeu hors du hardcode vers Lua pour permettre aux joueurs de créer des mods complexes.
- Cadre possible : l’Antiquité.
4.2.6. Étape 5. Abstractions et LOD (prévue)
L’architecture sémantique et la complexité croissante des mondes de jeu augmentent les exigences de calcul des appareils des joueurs. À ce stade, des règles abstraites sont introduites pour exclure de la simulation active les entités situées en dehors des zones d’action des joueurs (voir point 3.7). Cela devrait permettre de rendre les mondes de jeu beaucoup plus complexes sans augmentation proportionnelle de la charge, et de rendre possible l’exécution de tels jeux sur des appareils faibles et mobiles. L’ordre de mise en œuvre des étapes peut être ajusté au cours du développement.
4.2.7. Étapes 6+. Fonctions clés du moteur Nexus (prévue)
Les étapes 1–5 forment la fonctionnalité de base de Nexus. À partir des étapes 6+, le développement se déplace vers l’extension des capacités du moteur, l’ajout de fonctions évolutives, de détails et de contenus décrits dans les sections 2 et 3.
À ces étapes, les directions suivantes devraient être développées et mises en œuvre :
- Mise à l’échelle du temps et de l’espace, niveaux de détail et abstractions.
- Jeu en réseau.
- Génération de scénarios et de configurations de jeu.
- Prise en charge de différents modes de visualisation : de la vue à la première personne à l’échelle globale.
- Interfaces et sons adaptatifs pour différents styles de jeu et niveaux d’immersion.
- Fonctions supplémentaires décrites dans les sections 2 et 3.
4.2.8. Nexus 1.0 (prévue)
Le moment de sortie de Nexus 1.0 est déterminé par l’atteinte d’une implémentation de base des idées et fonctions clés décrites dans les sections 2 et 3.
5. Défis
5.1. Complexité de calcul élevée
Défi : Une architecture sémantique avec un grand nombre de triplets peut être trop lourde pour un fonctionnement en temps réel et ne pas évoluer sur le matériel disponible.
Réponse : Cela est résolu grâce aux règles d’abstraction et au LOD. Seules les entités avec lesquelles le joueur interagit d’une manière ou d’une autre sont calculées. Voir le point 3.7 pour plus de détails. La représentation sémantique du monde ne signifie pas que toutes les requêtes de jeu sont traitées par inférence logique ; des structures de données directes et des résultats mis en cache sont utilisés pour les opérations fréquentes.
5.2. Focus de gameplay flou
Défi : L’universalité de Nexus peut entraîner l’absence d’un focus de gameplay clair et d’un sentiment d’objectif, lorsque le joueur doit décider lui‑même à quoi il joue. Tout est possible, mais on ne sait pas pourquoi.
Réponse : Nexus n’exige pas d’objectif rigide. La direction se forme soit par un scénario, soit par la logique du monde et le rôle du joueur en son sein. L’universalité ne signifie pas l’absence de structure — le monde lui‑même limite l’échelle. Le joueur obtient exactement la quantité de contrôle et d’information correspondant à son rôle. Par exemple, si un joueur agit en tant que souverain, il n’a pas besoin de gérer directement des milliers de villages — des assistants et des ministres s’en chargent.
5.3. Risque d’un projet inachevé
Défi : En raison de l’ampleur et de la complexité de Nexus, il existe une probabilité que le projet reste longtemps en développement et n’atteigne pas un état final clairement fixé. De l’extérieur, cela peut être perçu comme un projet de niveau AAA nécessitant des ressources financières importantes et une grande équipe.
Réponse : Nexus se développe comme un produit unique à travers des étapes successives avec des sorties régulières et des résultats concrets, chacune rapprochant le projet de la version 1.0. Le développement ne se fait pas sous la forme d’un « long prototype », mais comme une progression régulière avec des versions intermédiaires terminées et des résultats vérifiables. Les critères de succès et les retours des joueurs aident à maintenir le projet dans la direction prévue.
5.4. Difficulté de débogage et de contrôle de la logique
Défi : L’architecture sémantique et l’interpréteur peuvent entraîner une complexité élevée du débogage des chaînes logiques et des inférences, ce qui complique le développement, l’équilibrage et le contrôle du comportement du monde.
Réponse : La difficulté de débogage de la logique sémantique est considérée comme une partie intégrante de l’architecture, et non comme un effet secondaire. Dans Nexus, le contrôle des chaînes de cause à effet, des sources d’inférence et des états est intégré comme exigence de base du système, car sans explicabilité et observabilité un tel modèle de monde n’est pas maîtrisable.
5.5. Risque d’un manque de focus précoce
Défi : L’ampleur du concept Nexus aux premières étapes peut rendre difficile la définition d’un MVP clair, la validation de l’intérêt d’une audience spécifique et la compréhension de pour qui le projet est créé, ce qui augmente le risque d’investir des ressources dans l’architecture avant de confirmer la valeur de jeu.
Réponse : Clarus Victoria possède une niche et une audience établies avec lesquelles le studio travaille depuis plus de dix ans. Au lieu d’un MVP abstrait distinct, des projets autonomes avec un gameplay clair et familier sont utilisés. À chaque nouveau projet, ce gameplay s’étend et se complexifie progressivement, se rapprochant de Nexus 1.0. Le critère de réussite est le retour des joueurs et l’alignement des résultats avec la direction de développement annoncée.
Dernière mise à jour du document : 18.01.2026
