Plans
1. General
1.1. About the document
The purpose of this document is to state Clarus Victoria's position and intent regarding what games we want to create and how we plan to get there.
The games the studio will develop in the coming years are considered steps on the path to a larger, long-term project called Nexus.
This document is not a technical specification, a requirements document, or a promise of specific timelines or results. As the project evolves and new ideas appear, it may be updated and revised.
The document is intended for players who are interested in the overall vision of the Nexus project and the direction of Clarus Victoria's work, as well as for developers who want to better understand the principles and mechanics of the new system.
1.2. About the project
Nexus is a universal computer game inside which players can create and configure their own games, mixing genres, settings, and mechanics, and sharing them with others.
Unlike traditional games, Nexus does not offer a predefined genre or a single scenario. Here, game genres are sets of rules and scenarios that the player can choose, combine, and change during play.
Nexus is not just another Roblox or Garry's Mod. In most similar platforms, worlds are assembled from scripts and editors. In Nexus, worlds are built on a language close to human language. It forms meanings, rules, and content. This approach provides more flexibility and freedom in choosing what to play and how.
1.3. Document structure
The document is structured as numbered sections for easy navigation and link sharing.
The overall structure includes the following sections:
- Section 1 is introductory. It contains general information about the Nexus project and about this document.
- Section 2 describes a set of ideas about what the Nexus project could look like after implementation.
- Section 3 contains ideas and approaches that allow the project to be implemented technically.
- Section 4 is a roadmap: a sequence of steps needed to build the project.
- Section 5 covers challenges: risks and constraints of the project, as well as approaches to addressing them.
All sections except Section 3 are intended for a general audience. Section 3 is more oriented toward specialists and game developers.
The document has a modular structure and can be read selectively without strictly following the order of sections.
1.4. About the author
The author of the document is Mikhail Vasiliev, founder, game designer, and developer of Clarus Victoria. The document reflects the author's subjective view and does not claim to be complete or the ultimate truth.
2. Concept

2.1. Purpose of the section
To show what the Nexus project might look like and what its functionality could be after implementation. Within the section we consider the idea of forming a genre — universal computer games, one of which should be Nexus.
Some of the ideas described may look hard to implement, but they are considered a reference point and a direction of development. The section is devoted exclusively to the concept of game mechanics and the overall image of the game. Questions of rule design and technical implementation are moved to Section 3.
2.2. Starting the game
The main menu presents an interface vaguely reminiscent of YouTube, but instead of videos it displays game scenarios. The core of the screen is recommendation blocks and the history section. Additional functions are also available: lists of scenarios marked as liked and those the user plans to return to later.
2.2.1. Creating a game through recommendations
If this is your first launch, the game will offer you trends in different categories with various popular scenarios. If this is not your first launch, the game already knows your interests and shows in Recommendations scenarios you have not tried yet but that you should like. For example, if you like Ancient Rome, space, and racing, recommendations might include topics: "Emperor Trajan", "Fall of Rome", "Ancient Germans", "Colonization of Mars", "Monza Circuit", "Jet Engines". You can choose any topic.
2.2.2. Loading a game
You can open the History section and continue one of the previously created games — the familiar presentation of saving and returning to past game sessions. Saves can be shared with other players.
2.2.3. Scenario configuration
After selecting the base idea of the scenario, you can further define the nature of the future campaign. If desired, starting conditions are set: features of the world and your character, as well as the key traits from which the story begins.
2.2.4. Game generation
Based on the chosen scenario, a game world is generated that matches the chosen theme. Even with the same recommendations, starting conditions may differ, so each beginning feels unique. If desired, you can set a "game seed" to reproduce similar starting conditions in a new playthrough.
2.3. The world
2.3.1. Rules
The universal rules of the world are a common set of regularities that in the ideal form fits role-playing and strategy games. Through them, other genres can also be described — action, sports, racing, adventure, and their subgenres. This is not about specific mechanics, but about principles that allow expressing the logic of most game worlds.
2.3.2. Genres
The game has no rigid genres that constrain mechanics. Instead, genres exist as modules that can be combined and configured like a construction set. The foundation remains role-playing — the most natural and understandable way for a person to interact with the world.
If you want a strategic experience and, for example, to live the life of Caesar, you lead legions as a person, being inside events and participating in battles in first person. If you need to see everything as a whole, you can step outside the human role, grant yourself special abilities, and observe the battlefield from above, receiving a strategic overview. In role-playing mode, orders are not executed instantly: they go through a chain of messengers and officers, may be delayed, distorted, or lost entirely. However, you can step outside the role and give yourself the ability to transmit orders directly, as if telepathically, achieving immediate and unconditional execution—even if they require self-sacrifice. This step gradually shifts the experience from role-playing perception to classical strategy, where commands are carried out immediately and precisely.
In familiar action games, the decisive factor is reaction in fractions of a second; here, the outcome is determined by the character's skill level. For an especially agile hero, time may be perceived as slowed. In racing, successfully taking a high-speed turn manifests as the result of many factors: the driver's skills and condition, the car's characteristics, surface quality, road grip, nearby opponents, and an element of randomness.
2.3.3. Knowledge as the foundation of the game
The world of a universal game relies on knowledge: facts of the past and present, ideas about the future, as well as fiction and fantasy. This knowledge is reflected as game entities, properties, and relationships with which you interact.
Biomes, equipment, creatures, natural phenomena, planets, and whole worlds are perceived as objects of this knowledge. In its base image, such a world is close to reality: flora and fauna, seasons, geological and historical epochs, scientific and technological development. People have skills, strengths and weaknesses, personal history and motivation. They can get sick, suffer injuries, and die without help. Fantasy, sci-fi, alternative, and post-apocalyptic scenarios are layered on top of this foundation, changing individual aspects of the world without destroying its integrity.
2.3.4. Events
Events do not arise by themselves. They are the result of other processes. Drought leads to the death of grass, lack of grass leads to die-off of herbivores, and hungry predators, deprived of prey, may start attacking people. The world develops as a chain of cause and effect, where each change triggers new processes.
The world does not wait for you to intervene. Its history is not predefined and not built on scripts. It is shaped by your choices, actions of other entities, the laws of the world, and randomness. If a scenario has a historical basis, events repeat not because they are "programmed" but because the same causes lead to the same consequences again—like the Bronze Age collapse that arose from a cascade of changes caused by climate.
2.3.5. Consequences of player decisions
Player actions trigger chains of events that remain in the world. For example, in a critical situation a group leader may decide to sacrifice a team member and tarnish their reputation, leaving a mark on the rest of their life.
The stronger the influence, the larger the consequences. You can change a river's course and accelerate time by a century to see how the landscape changes. You can perform a feat, disappear for a thousand years, and return to a new era where your name has become a myth.
The world keeps its own history, preserving key events, their causes, and distant results. You can study your past game sessions hundreds of years later—through books and archaeology—and see how decisions made long ago shaped the current world.
2.3.6. Motivation
Any entity—person, animal, organization, or state—acts within its role and motivation. It strives toward its own goals regardless of you. Dream, love, aggression, greed—states that influence character behavior and push them to actions. For example:
- Long absence from a loved one can heavily affect a character's state and change their decisions.
- A pharaoh may order a vizier to build a pyramid, and for the vizier this becomes a defining task.
- Deer seek food, reproduce, and avoid predators.
- A criminal syndicate seeks to expand influence and seize new territories.
2.3.7. Dramaturgy
In a fully simulated world, long "quiet periods" are possible. If you play as a farmer, you can live ten years without wars, disasters, or major changes. If the goal is to honestly live the role with all its empty days, the world can be left as it is.
But if you get bored, dramaturgy can be intensified. This changes the overall feel: the pace becomes higher, events denser, and the balance of calm and tense moments shifts without breaking the world's logic. In this mode, the world starts behaving less predictably: minor incidents, unexpected meetings, and rare twists of fate appear. The simulation does not break, but the character's life becomes more cinematic—so that an ordinary police officer may gradually end up in a story with chases, investigations, and dramatic turning points.
If you want maximum dynamism, dramaturgy can be intensified even more—and then a new story will arise around almost every corner, and what happens will resemble an action-packed blockbuster.
2.3.8. Changing the rules of the game
You can always step outside the chosen role and change the rules of what is happening. If, while playing a Japanese office clerk, you decide to become a superhero, this is not a usual action within the world, but a step that changes the logic of the narrative.
You can change the world and its laws: add magic, change properties of objects and creatures. In such a world, water may burn like wood, and pigeons may become intelligent. After that, the world continues to develop with the new rules, remaining consistent.
You can experiment with the foundations themselves and create worlds that contradict familiar logic: worlds of paradoxes, mirrorlands, other universes with their own physics and structure of reality. This approach unites gameplay, simulation, and world editing, opening almost unlimited possibilities. Even when changing laws, the world remains coherent because principles of causality continue to operate within the new framework.
A snapshot of the current world can become the basis for a new game. One player, acting in the role of a "god", can create a world in which others will live. This is similar to a mod or map editor, but built into the logic of the universal game itself.
2.4. Gameplay
2.4.1. Role-playing
Would you like to become the richest person? Gain superpowers and live forever? Conquer space? Go into the past with the knowledge of the present?
You can start immediately in the desired role or go from scratch, gradually expanding the abilities and boundaries of your character. Role-playing is allowed not only as a person, but also as an event, abstraction, or idea: a fire, an epidemic, an organization, a religion, a language. The initial scenario sets only the starting point, and further development is entirely determined by your choices.
2.4.2. Game goal
The goal of the game can be set by the scenario, by you, or a combination of both, or it can be absent altogether. It can be anything from an everyday task to an epochal achievement—getting a dream job or inventing the "philosopher's stone". Reaching the goal does not end the game: the world continues to live, and you can remain in it as long as you want.
2.4.3. Dynamic role switching
At any moment you can change roles and continue the story from the perspective of another entity in the same world. Such a change does not interrupt what is happening and allows you to see events from a different point of view. For example, you can alternately role-play members of one family or inhabit different soldiers on the battlefield. Such an experience goes beyond the usual role-playing of a single role, unless the game itself is built around the idea of reincarnation.
2.4.4. Player actions
The actions available to you correspond to the current situation and the characteristics of your character. They are formed by the context of what is happening and by who you are at that moment.
For example, in a fire, the expected options usually appear: run away, extinguish the fire, help others. However, you can act differently and, for instance, contribute to the spread of the fire. This difference in available actions reflects the nature of the character—who they are and how they tend to act. For a pyromaniac, the situation of a fire will be perceived differently than for an ordinary person.
2.4.5. Auto and manual control
By default, each entity in the world exists autonomously, acting according to its nature, motivations, and goals. This also applies to your character until you take control of them. If you choose the role of a leader and interact with groups of entities, control is perceived not as direct control but as a system of requests, orders, and expectations.
Other entities may respond to your order or refuse to carry it out—depending on their attitude toward you, available resources, fear, fatigue, or physical limitations.
2.4.6. Observation
You may not play directly. Create an interesting character, place them in an unusual situation, set the desired level of dramaturgy (see item 2.3.7. Dramaturgy), and observe how events develop. Such an experience can resemble watching a film where the story unfolds on its own.
The result of observation can be shared with other players by saving and transferring the state of the world. Perhaps someone's story will become a new blockbuster. This mode is suitable not only for entertainment but also for modeling: you can create, for example, a "turtle civilization" and follow how it goes from the Stone Age to spaceflight.
2.5. Gameplay interaction
2.5.1. Camera and presentation
What happens in the game can be perceived in different ways: first-person, third-person, top-down, or even as text. The presentation changes depending on the context and the chosen role. For example, it is natural for a person to see the world in first person, thoughts may be perceived as text, and when playing as a country or planet the view shifts to a strategic top-down overview.
A universal game is not tied to a single presentation method and can look the way that is most convenient for you at the moment. Even a blind person will be able to interact with the world, perceiving objects and events through sound and description.
The scope of the perceived world always corresponds to the current role. If you are a person, you are limited by the capabilities of your senses. If you grant yourself special abilities, perception expands, allowing you to see the hidden or distant.
2.5.2. Graphics and sound
The interface, visual style, animation, music, and sound enhance the game experience and help you feel the chosen role. In a world of antiquity and magical thinking, the visual and sound image emphasizes the duality of the world of people and gods, creating a sense of an additional dimension where every action is filled with sacred meaning. In a post-apocalyptic setting, graphics and sound convey the fragility of survival, a sense of loss, and rare hope for a new beginning. In the world of a bat, space is perceived differently: scale and form are felt through sound rather than sight.
2.5.3. Map
The world or its map can be any surface—a planet, a region, a ship, or even a human body—depending on the chosen role. For example, when playing as an ant, the map becomes a glade by a stream. Perception of space changes with scale: the view may zoom in or out, and the viewing angle may shift.
When zooming in, details appear; when zooming out, they disappear, giving way to larger structures and connections.
2.5.4. Time
Time flows at different speeds depending on the chosen role and preferences. During combat it may run in seconds. In global mode, when modeling geological processes, one second of game time can correspond to millions of years. Acceleration is especially appropriate when playing as beings with a different perception of time—plants or long-lived life forms.
Time can be stopped, sped up, skipped, or reversed. If desired, you can play in turn-based mode without rushing decisions. In some situations, time only passes when controlling a specific character and stops when you are thinking about the next step.
2.5.5. Online play
Players online can simultaneously play as different characters and entities in the same world, having agreed in advance on the rules of time flow. One may be Napoleon issuing orders to the army, another a grenadier attacking enemies on the battlefield. Players may also be in opposition: some are villagers, others are raiders terrorizing a settlement, others are bounty hunters hunting bandits.
2.6. Universality
2.6.1. Meaning
Nexus can express and reproduce the logic of most existing games at the level of their rules and interactions. This is not about literally copying specific implementations, but about reproducing their core gameplay logic.
This is possible because any game is a set of rules, and rules can be described through simple semantic statements (triplets).
Examples: Dark Souls (in terms of rules):
- Death -> causes -> loss_of_souls
- Bonfire -> is -> respawn_point
- Enemy -> difficulty -> high
- Strike -> depends_on -> stamina
Civilization (in terms of rules):
- Turn -> duration -> depends_on_era
- City -> produces -> [units, buildings]
- Victory -> conditions -> [science, military, culture]
The Sims (in terms of rules):
- Character -> needs -> [hunger, sleep, socialization]
- Need_low -> causes -> bad_mood
- Action -> satisfies -> need
2.6.2. Genre mixes
Since rules are organized as modules, they can be combined. This makes it possible to assemble new gameplay formats from known sets of rules.
Examples: Dark Souls + Civilization:
- You rule the kingdom of Lordran as a civilization.
- Battles and encounters follow Dark Souls rules (skill, timing, danger).
The Sims + zombie apocalypse:
- Everyday needs of Sims (food, sleep, socialization).
- On top of them, survival rules are added (shelter, weapons, danger).
Principle of universality: if game logic can be expressed in words, it can be implemented in Nexus.
2.7. Example
2.7.1. Situation in the world
The player is Ivan, a peasant in the village of Zarechye. He is hungry, his wife is pregnant, and the neighbor Pyotr has lost a cow. Rain is approaching.
2.7.2. How the system understands it (triplets)
Inside the system, this situation is described by a set of simple statements:
- Ivan -> is -> peasant
- Ivan -> hunger -> 30% (or Ivan -> satiety -> 30%)
- Ivan -> located_in -> Zarechye
- Marya -> relation -> Ivan_wife
- Marya -> pregnant -> 8_months
- Cow -> belongs_to -> Pyotr
- Cow -> location -> forest
- Weather -> approaching -> rain
Each statement is an atom of knowledge. Together they form the current state of the world.
2.7.3. How the player sees it
Logic is separated from visualization and remains unchanged. Depending on the display mode, the same triplets are shown differently. More about the UX Language is in section 3.9.
2.7.3.1. Text mode
"You are Ivan, a peasant. Your stomach growls with hunger. Your wife Marya will give birth soon. You hear your neighbor shouting—his cow has run away. A rainy haze is on the horizon."
2.7.3.2. Hex-map mode with icons
- Village tile with objects: 🏠 (house), 🏚️ (barn), 💧 (stream)
- Character: 👤 Ivan [🍞30% red]
- Family: 👩 Marya 🤰 ~30 days
- Event: 🏠 Pyotr 🔊, tracks 🐾🐾 -> 🌲
- Effect: 🌧️ approaching
2.7.3.3. 3D mode
A full village, Ivan’s model holds his stomach, Marya sits by the house, in the distance shouts are heard and a broken fence is visible, dark clouds on the horizon.
2.7.4. Player action
The player formulates an intention: "Help Pyotr find the cow" This action is converted into triplets:
- Ivan -> intention -> help
- Help -> whom -> Pyotr
- Help -> task -> find_cow
The system interprets: 1. Can Ivan help? -> Yes (physically healthy, nearby) 2. Does it take time? -> Yes (~1 hour) 3. Will it affect hunger? -> Yes (it will increase) 4. What will happen? -> Search in the forest, chance to find the cow
2.7.5. Result
After one hour of game time:
- Cow -> location -> found_at_stream
- Ivan -> hunger -> 20% (increased)
- Pyotr -> relation_to_Ivan -> gratitude +10
- Pyotr -> obligation -> help_with_roof
Visually:
- The player sees the animation of returning with the cow
- 🍞 20% (even redder)
- A notification appears: "Pyotr is grateful. He promised to help with the roof."
2.8. From concept to implementation
Sections 2.1–2.7 describe the desired image of Nexus from the player's perspective: what they see, how they interact with the world, what opportunities they get.
Key principles:
- Any game situation can be described in words.
- Words can be formalized as triplets (simple statements).
- Triplets can be interpreted (inferences can be made).
- The result can be visualized in any way.
3. Implementation concept

3.1. Purpose of the section
This section is devoted to ideas about how the Nexus project can be implemented technically and how it can be structured internally. It does not describe specific technical solutions, but principles and directions that make such a game possible. Specific implementations are expected to be determined during development and refined in practice.
The section does not consider game concepts as ideas in themselves; the focus is exclusively on approaches to their implementation. The section is primarily aimed at specialists and computer game developers.
3.2. Flexible approach
The classic approach to creating computer games is built around pre-designed rigid game systems within which the player is allowed to act. Even sandbox games that provide a high level of freedom are essentially a large set of separate systems. This creates a sense of variety of possibilities, however the basic principle of a rigidly defined architecture does not change. Adding new systems over time primarily leads to growth in development and support complexity, but not to a qualitative expansion of the gameplay experience.
To achieve genuine flexibility, the foundation of this approach must be reconsidered. Adding new game mechanics should not increase the architectural complexity of the project. Instead, the basic elements of the game should be organized as atoms—minimal, universal, and mutually compatible units from which everything else can be built.
A good illustration of this approach is Minecraft. It allows creating extremely complex constructions—castles, cities, or entire space stations composed of millions of block elements. At the same time, the growth in the number of objects does not lead to greater internal architectural complexity: the system is designed for scaling from the start.
In a deeply universal game, a similar principle can be applied to the entire architecture. The number of game mechanics can be arbitrarily large, but they must be organized so that they coherently coexist with each other, combine, and form worlds of any complexity without losing the integrity and manageability of the system.
3.3. Semantic network
One possible way to implement a flexible approach is to represent game data as atomic logical units—triplets. A triplet is a simple statement in the format “subject – predicate – object.” For example:
- Apple – is – edible
- Apple – has nutrition – 5
- Human – can eat – fruits
- Grass – grows – at humidity above a certain level
- Deer – is – a herbivore
- Syndicate – controls – a city district
Through triplets, everything can be described: objects, their properties and states, relationships between them, possible actions, game rules, technologies, or magic. This is a representation of knowledge not tied to a specific game implementation. It is not just a data storage format, but a way of describing the meaning of the world.
For the world to be deep and consistent, it relies on a large amount of data—from general principles of the world's structure to individual game facts. These data are filled with concrete content: animals, technologies, items, buildings, historical events, and other entities.
3.4. Interpreter
Above the data layer operates an interpreter. It can be based on logical systems (e.g., Apache Jena) or on neural network approaches. Its task is to process triplets and perform logical inference. For example:
- Apple - is - a fruit
- Human - can eat - fruits
- Conclusion: a human can eat apples
The interpreter obtains this conclusion by combining several facts. Inference chains can be much longer.
Within the game, the interpreter is used to populate the world and determine allowed actions. It answers questions such as:
- Which trees can grow in the tropical desert of Arabia.
- What actions people can take toward a dog in the early Stone Age and in modern times.
- Which objects are available to the player's perception at the current moment.
The interpreter breaks such questions into simpler data queries and brings them to a unified semantic representation, on the basis of which the answer is formed. The interpreter works with already formalized queries and does not interact with natural language directly.
3.5. Semantic ECS
For the world of a universal game to function based on semantics, logic, and large arrays of facts, it needs an architecture capable of describing objects and their properties as flexibly as possible, without rigid hardcode.
This problem is solved, for example, by semantic ECS—a variant of classic ECS adapted for representing knowledge and relationships between entities. In this context, ECS is considered primarily as a data model rather than a system update loop, and is used as a practical entry point rather than a final architecture.
At the foundation of the world are entities: characters, items, animals, organizations, ships, plants. As in classic ECS, an entity itself does not contain logic or data; it serves as an identifier to which components are attached.
The key difference lies in the structure of components. In traditional ECS, a component is a structure with a set of fields. In semantic ECS, instead of large components, predicate components are used: “Is,” “Has,” “Contains,” “Can,” “Relates to,” and similar. Each such predicate expresses one relationship or one statement about the world.
For example, the entity “Apple” can have the predicate component “Is,” pointing to the entities “Fruit” and “Edible.” At the same time, “Edible” is also an entity with its own properties: “Has - Nutrition,” “Has - Taste.” Each value component stores exactly one value, for example: “Nutrition = 5,” “Taste = sweet,” “Weight = 0.2.”
This forms a network or tree of properties where each link remains atomic. Any object, property, or relationship in the world is described through a separate minimal fact. Thanks to this, rules and interactions are not hardcoded, but exist as data.
Caching, indices, and level-of-detail (LOD, see below) mechanisms are used to ensure performance. This makes it possible to model a world consisting of millions of facts while remaining performant, logically consistent, and manageable through semantic rules.
3.6. Game rules
Data and the logic of working with it are not a game on their own. For gameplay to emerge, an additional layer is needed—game rules. They are not hardcoded; they extend the basic rules of the language and can be connected as needed. Like word games, their role is to set boundaries: what is allowed and what is not, what goals exist, what roles are possible, and how the gameplay develops. Game rules narrow the almost infinite possibilities of the language to a limited space in which gameplay arises.
In the game industry, it is common to build game rules from scratch with each new game, starting from a base level. At the same time, differences between games are most often not fundamental: most RPGs and strategies are conceptually similar, differing in mechanical details, graphics, or lore. This approach has become the de facto standard of game development, and the uniformity of gameplay experience is perceived as normal. Variety is achieved primarily through visual style, atmosphere, and narrative, not through fundamental differences in capabilities.
Universal game rules imply systematization and unification of proven mechanics. This allows developers not to rebuild the base every time, but to focus on more complex and higher-level aspects of the game. The rules can be organized as modules and connected as needed to form a specific gameplay experience.
This approach somewhat resembles the structure of game engines. For example, Unity Engine or Unreal Engine remove the need for developers to implement low-level functions. However, here we are not talking about technical implementation but about universal game rules. Similar ideas can be found in tabletop systems like GURPS, as well as in complex sandboxes like Minecraft, Dwarf Fortress, or RimWorld, where some rules already have a universal character.
By default, “rules” are an empty structure that gains content only when modules are connected. The composition of modules determines world behavior: how damage is calculated, what initiative is, how the economy works, how entities interact, how events are processed, and what constraints apply. This approach lets you assemble the world's mechanics like a construction set.
Modules can freely combine and mix genres. If you add a combat module to a turn-based module, pieces become characters with health and skills. If you add a platformer module, entities gain the ability to jump, and connecting an economy module introduces resource production. The configuration of rules becomes part of the game itself: scenarios, settings, and genres are configured just like any other elements of the world.
Overall, the modularity of rules turns game logic from a fixed set of constraints into a flexible architecture. This allows the same system to support RPGs, strategies, simulations, racing games, and other genres without changing code—through the combination of rules and data. It is precisely modularity that makes a universal game truly universal.
3.7. Abstractions and LOD
3.7.1. Limited perception and the need for abstractions
The world of a universal game can contain a huge number of processes: from animal migrations and city growth to microorganism behavior or the dynamics of star systems. A full recalculation of all space and all scales is impossible and unnecessary—the player always perceives the world subjectively and within a limited scope. Therefore, the system uses a layer of abstractions that allows the world to remain scalable without losing logic.
Abstractions are applied where high detail does not affect the gameplay result. In the microworld, at the level of a planet's biosphere or a star system, different entities and rules are used, appropriate to the scale of what is happening. Therefore, the system does not model the behavior of each individual entity, but immediately accounts for the overall result of processes.
3.7.2. Scaling time and space
When fast-forwarding time, the game does not recalculate every skipped moment. Instead, the system analyzes the current state of the world, applies cause-and-effect relationships at an aggregated scale, and interpolates likely results: how the population changes, which trends intensify, which events are most likely to occur. This allows moving forward decades or thousands of years while maintaining world consistency.
Scaling space does not change the structure of the world, but determines the level of entities and processes that the simulation works with. At a large scale, aggregated entities and processes are considered—climate, migrations, political structures. When moving to a local scale, the world opens up to individual entities and their properties. In all cases, a unified logic of cause-and-effect relationships is preserved.
Abstractions allow the game to contain a world of any scale: a village, a planet, an ecosystem, or a galaxy. Details appear only when they become significant to the player or to the logic of events. Everything else is described in a simplified form while preserving cause-and-effect relationships.
The player can delve into the structure of the world, studying entities and navigating their properties like a reference system. The only limitation here is the available data and rules of the world.
3.7.3. Materialization of the world
The world is formed as it is explored. Until the player visits a location, it exists as data and rules without specific objects. Objects materialize only when the player interacts with the world. This is similar to chunk loading in Minecraft: the world is not fully calculated, but is subjectively perceived as already existing.
Events are generated as if the world existed fully in all its complexity, even beyond the player's observation.
After interaction with a location or entities ends, its state is stored as new knowledge about the world and no longer participates in active calculations. This approach allows the world to scale outward and inward—from the microworld to galaxies—without storing and recalculating unnecessary details.
For large time intervals, statistical trends are used. For example, it is known that kilometer-scale asteroids collide with Earth roughly once every million years. There are models that estimate the probability of a technological civilization disappearing on a horizon of thousands of years. These estimates do not set a precise outcome, but determine a range of possible scenarios. Therefore, when the player moves forward a thousand years, the system chooses one of the plausible futures—civilization ruins, stable development, or another coherent scenario.
3.7.4. Online play
In online mode, the same materialization-by-interaction principle is used. The server does not store the world as a fully calculated and fixed map. Instead, it operates on data, rules, and already manifested facts—what has been discovered or changed by players.
When one or more players interact with a single area, the server forms a shared materialized state for it, synchronized among all participants. This state exists exactly at the level of detail at which it is actually observed and used.
Outside the interaction area, the world is not continuously recalculated. It remains in a potential state described by rules, statistical trends, and accumulated facts. This allows maintaining a single, large, continuous world with many players, synchronizing only what is actually observed and relevant to gameplay.
3.8. Agents and world simulation
Any entity in the world—person, animal, organization, or state—is considered an agent with its own goals, motivation, and states. An agent:
- Perceives the world within the limits of its knowledge.
- Evaluates available action options.
- Makes decisions based on its goals and the world's rules.
- Triggers events that change the state of the world.
The world as a whole works as a multi-layer simulation:
- Nature changes under the influence of climate and available resources.
- Ecosystems respond to environmental changes.
- People and societies respond to changes in nature, technology, and politics.
- The player enters this process as one of the entities in the world.
The history of the world is not predefined and not written by hand. It emerges as a result of interaction between many agents acting within shared laws and cause-and-effect relationships.
For example, drought leads to less grass, lack of grass leads to herbivore hunger, hunger leads to migration, and migration leads to clashes with predators or humans. Such chains are formed on the basis of facts and rules, determining what naturally follows from the current conditions.
3.9. UX language
The language of interaction with the game is built on logic close to human language. Through this language, the player and the game effectively communicate with each other. The language has a set of rules within which you can form meaningful constructs of almost any complexity.
Each state of the interface or map can be viewed as a question: “What do I see now?”, and the set of available actions as the question “What can I do in the current situation?”. The game, analyzing the world state, the position of the player's avatar, and the intended object of interaction, forms an answer in the form of a new world state and new interface presentation.
At the simplest level, the language is the designation of things perceived in the world: “tree”, “mother”, “sun”. At the next level, the language allows describing their properties and states: “angry person”, “many stars”, “strong lion”, “300 Spartans”.
In the game, such concepts can be represented literally—as specific entities—or conditionally, through pictograms. Each word or concept corresponds to an icon.
Object properties are expressed via visual techniques:
- “Angry”, “bad”, “negative” — a red background for the icon.
- “Many”, “300”, “millions”, “infinite” — a mini-pictogram of multiplicity with a specific or abstract numerical value.
- “Strong”, “dangerous”, “powerful”, “level 3” — a separate mini-pictogram of level with a value indication.
- The color of the frame can show an entity's belonging to another player or faction.
Additional pictograms, animations, glow, and other visual elements can be added to the main icon to convey frequently used properties or emotional tone. For more complex or rare characteristics, auxiliary icons are used next to the main entity or embedded within it at a smaller scale.
Icons can be animated, adding an additional layer of information. For example, at critically low health, a heart on the icon may beat unevenly and weakly, indicating a dangerous state.
The language also reflects the limited knowledge of the character. If the avatar encounters a representative of another culture and does not understand their language, icons may be distorted or turn into unreadable symbols. If only part of the information is known, the corresponding elements are hidden: the player may know the type of enemies but not their number.
The same entities may look different for different cultures. Ancient Egyptians will see hieroglyphs, while robot-like beings will see technological, digital symbols.
When the player performs an action, they interact with objects in the world. In direct simulation, this can be a physical first-person action, and in abstract modes, the selection of conditional icons. The action itself is formed from a basic language construction.
At its core, the game language relies on semantic triplets: subject - action - object.
Examples:
- “I - want - an apple”
- “We - declare war - on you”
- “We - attack - the White Feather tribe”
In the interface, this looks like choosing a subject (the player's avatar or another entity), selecting an object, and specifying an action.
The construction can be complicated by adding modifiers: time, adjectives, conditions. For example: “Slave (subject) - build (predicate) - pyramid (object) - quickly (predicate modifier)”. The modifier “quickly” means special rules are applied: work is performed faster, but the risk of accidents increases or the quality of the result decreases.
If the action is directed not at the avatar itself but at another subject, it is interpreted as a request or command.
4. Roadmap

4.1. Strategic vision
This section describes the plan for implementing the Nexus project.
An approach with developing a single project and then early access is not suitable in this case. A more appropriate approach is step-by-step development of a series of projects, each of which will implement and test individual ideas and directions, bringing the project closer to the final vision of Nexus. Each stage project will work with feedback and criticism, allowing assessment of the project's alignment with the initial concept and the correctness of the chosen direction. Over time, such projects will become more complex and higher quality, and one of them may eventually grow into a full Nexus project described in Section 2.
The development of Nexus is broken into a series of stage-projects. For stages closer to the present, goals and objectives are formulated more clearly and concretely. More distant stages are described at the level of general directions and ideas, without detailed elaboration. The order of stages is not rigidly fixed. The roadmap sets the overall direction of the project, not a detailed plan. As development progresses, stages and tasks may be refined and supplemented.
4.2. Stages
4.2.1. Stage 0. Forming an understanding of the universal game (completed)
The work of Clarus Victoria since 2013, the release of six projects, as well as many years of research, experiments, and prototype creation have made it possible to form a base understanding of what a universal game can be and what principles underlie it. The result of this stage was the creation of this document.
4.2.2. Stage 1. ECS and entity unification (completed)
- The ECS architecture was validated on the Next Run project. Entities are represented as empty containers with a set of components, which allows flexible formation of world objects: items, creatures, biomes, events, and effects.
- A number of ideas related to universal game mechanics were validated, including the combination of RPG and strategy without hard division, universal actions, a model of time flow, and squad control.
- For the first time for the studio, a hexagonal map was implemented and tested, allowing quick creation and combination of different types of game worlds.
- For the first time for the studio, support for modifications via Steam Workshop was added.
More about this stage - in the article: https://clarusvictoria.com/blog/almost-ten-years-of-search
4.2.3. Stage 2. Real-world gameplay (in development)
The Next Run project allowed testing many universal game ideas, but it is limited to a fantasy setting with conditional laws of the world. As part of the second stage, a transition to modeling the real world with its natural and social patterns is expected. The goal of the stage is to lay a realistic gameplay foundation based on the logic of the real world, its natural and social patterns.
Features to implement:
- Evolution of societies: from a primitive human living alongside animals and following the same survival rules, to the emergence of the first civilizations.
- Biomes and tile ecosystems: hunger, migrations, and competition for resources. Plants, animals, and terrain directly affect human survival.
- Game situations and events arising as a result of game rules, not predefined scripts. For example, resource shortages may lead to conflicts between groups of people and attacks by predators.
- Automation of unit actions or manual control—player's choice, including group control through shared behavior rules. Possibility of both active play and observation.
- Ability to play as individual characters or groups.
- Multiple players on one map competing with each other.
- Return of the technology tree familiar from previous Clarus Victoria games.
- Configurable game world: map size, era, climate, and regional features.
- First versions of the agent model.
- Possible world setting: the Stone and Bronze Ages.
4.2.4. Stage 3. Semantic architecture (planned)
One of the key steps to reduce the risks of the Nexus project is the transition to the semantic foundation of the game architecture (see sections 3.3–3.5).
At this stage, all systems are introduced at a basic level, with minimal functionality:
- Semantic triplets as a way to describe entities in the game world.
- Interpreter.
- Transition from classic ECS to semantic ECS.
- Basic rules for the new architecture.
- Possible world setting: one of the early civilizations.
From a gameplay mechanics point of view, no new complexities are expected at this stage. The main task is to transfer already proven solutions and mechanics to the new architectural foundation.
4.2.5. Stage 4. Agent model (planned)
At this stage, it is expected to implement critical systems considered too risky to introduce at Stage 2. This is about deep elaboration of subjects within the agent model. Stage 2 prepares the ground for them, but at Stage 4 agents are fully implemented. The game architecture begins to support more complex real-world processes, allowing modeling of societies with a higher level of complexity compared to Stage 2.
Features to implement:
- A full agent behavior model: entities get goals, states, and motivations.
- A system of requests and commands to subjects, where execution is not guaranteed and depends on the current state and context.
- Increased richness of the world, more complex systems and object logic.
- Individual inventories for subjects, logistics chains, and a transport system.
- Moving part of the game logic out of hardcode into Lua to allow players to create complex mods.
- Possible world setting: the ancient world.
4.2.6. Stage 5. Abstractions and LOD (planned)
Semantic architecture and the growing complexity of game worlds increase the computational requirements of players' devices. At this stage, abstract game rules are expected to be introduced to exclude entities outside players' areas of action from active simulation (see item 3.7). This should allow game worlds to become significantly more complex without proportional growth of load, and also make it possible to run such games on low-end and mobile devices. The order of implementation of stages may be adjusted during development.
4.2.7. Stages 6+. Key functions of the Nexus engine (planned)
Stages 1–5 form the base functionality of Nexus. Starting from stages 6+, development shifts toward expanding engine capabilities, adding scalable features, details, and content described in sections 2 and 3.
At these stages, the following areas are expected to be developed and implemented:
- Scaling time and space, levels of detail and abstractions.
- Network play.
- Generation of game scenarios and configurations.
- Support for different visualization modes: from first-person view to global scale.
- Adaptive interfaces and sound for different play styles and immersion levels.
- Additional functions described in sections 2 and 3.
4.2.8. Nexus 1.0 (planned)
The moment of Nexus 1.0 release is determined by achieving a base implementation of the key ideas and functions described in sections 2 and 3.
5. Challenges
5.1. High computational complexity
Challenge: Semantic architecture with a large number of triplets can be too heavy for real-time operation and may not scale on available hardware.
Response: This is addressed with abstraction rules and LOD. Only entities that the player interacts with to some extent are computed. See item 3.7 for details. The semantic representation of the world does not mean all game queries are processed through logical inference; direct data structures and cached results are used for frequently used operations.
5.2. Blurry gameplay focus
Challenge: The universality of Nexus can lead to the absence of a clear gameplay focus and a sense of purpose, when the player has to decide what exactly they are playing. Everything is possible, but it's not clear why.
Response: Nexus does not require a rigidly defined goal. Direction is formed either by a scenario or by world logic and the player's role in it. Universality does not mean the absence of structure—the world itself limits the scale. The player gets exactly the amount of control and information that corresponds to their role. For example, if a player acts as a ruler, they do not need to manage thousands of villages directly—assistants and ministers handle that.
5.3. Risk of an unfinished project
Challenge: Due to the scale and complexity of Nexus, there is a probability that the project will stay in development for a long time and not reach a clearly fixed finished state. From the outside, it may be perceived as an AAA-level project requiring significant financial resources and a large team.
Response: Nexus develops as a single product through sequential stages with regular releases and concrete results, each bringing the project closer to version 1.0. Development is not carried out as a “long prototype,” but as a steady progression with completed intermediate versions and verifiable outcomes. Success criteria and player feedback help keep the project on the intended course.
5.4. Difficulty of debugging and logic control
Challenge: Semantic architecture and the interpreter can lead to high complexity in debugging logical chains and inferences, which complicates development, balancing, and control of world behavior.
Response: The difficulty of debugging semantic logic is considered an integral part of the architecture, not a side effect. In Nexus, control of cause-and-effect chains, inference sources, and states is built in as a base requirement of the system, because without explainability and observability such a world model is not manageable.
5.5. Risk of lacking early focus
Challenge: The breadth of the Nexus concept at early stages can make it difficult to form a clear MVP, to test interest with a specific audience, and to understand for whom the project is being created, which increases the risk of investing resources in architecture before validating game value.
Response: Clarus Victoria has an established niche and audience with which the studio has worked for more than ten years. Instead of a separate abstract MVP, standalone projects with clear and familiar gameplay are used. With each new project this gameplay gradually expands and becomes more complex, moving toward Nexus 1.0. The criterion of success is player feedback and the alignment of results with the stated direction of development.
Document last updated: 18.01.2026
