Nexus engine architecture

How Nexus works

Flat complexity

The classical approach to games is built around rigid systems: every mechanic is separate code, every link between mechanics is yet more code. Even sandboxes remain collections of separate systems. Variety grows, but the architecture stays the same - and development complexity grows with it.

Nexus is built differently. The basic elements of a game are atoms from which everything else is constructed. Adding new mechanics doesn't increase architectural complexity.

Millions of elements, yet the architecture doesn't get more complex. The system scales - to mechanics, rules, and worlds of any complexity.

Semantic network

Nexus stores data as triples (facts) - simple statements in the format "subject → predicate → object". Both world facts and mechanic rules are described in the same format:

  • Apple → is → edible (world fact)
  • Deer → is → herbivore (world fact)
  • Strike → deals damage → 6 (mechanic rule)
  • Poison → ignores armor → yes (rule modification)
  • Grass → grows → when moisture is above a certain level (world fact)
  • Syndicate → controls → city district (world fact)

Data and rules are written in the same format, in the same graph. Triples describe everything: objects, properties, states, relationships, actions, technologies, magic. This is the key difference from classical approaches, where data and logic live separately.

The world rests on a large body of facts: animals, technologies, items, buildings, historical events - from general principles to specific details.

Interpreter

The interpreter processes triples and derives conclusions from facts:

  • Apple → is → fruit
  • Human → can eat → fruit
  • Conclusion: a human can eat apples

Conclusions are built by matching facts. Chains can be long. Here's a more involved example:

  • Goblin → is → creature
  • Creature → has → health
  • Conclusion: a goblin has health
  • Strike → deals → damage
  • Damage → reduces → health
  • Conclusion: a strike can harm a goblin

Add poison with a damage predicate - it automatically works against anything that has health.

The interpreter works with formalized queries, not natural language.

Knowledge graph

World objects and properties need to be described flexibly, without hardcoding.

At the foundation are entities: characters, items, animals, organizations, ships, plants. Facts are attached to each entity through predicates.

Each predicate expresses one relationship or one property:

  • "Is" (classification: goblin → creature)
  • "Has" (possession: creature has health)
  • "Damage" (impact: strike deals 6)
  • "Cost" (expenditure: strike costs 3 mana)
  • "Absorption" (defense: shield blocks 5)
  • "Attitude" (relation: goblin hates humans)

A strike has a Damage predicate = 6. A shield has an Absorption predicate = 5. The engine derives: 6 - 5 = 1 reaches health. One mechanic for any damage source and any defense - sword, poison, fire, spell.

Properties form a network where every link is a single fact. Rules and interactions live as data, not hardcoded in logic.

For performance, the system uses caching, indexes, and adaptive level of detail (LOD).

Rules as patterns

Data and logic alone aren't a game. Gameplay needs a layer of rules. In classical development, rules are code: every mechanic is written by a programmer. In Nexus, rules are described using the same triples as data.

At the core are universal patterns shared across all genres. Impact: a sword damages health, rust damages durability, inflation damages purchasing power. Expenditure: a strike costs mana, a building costs wood, a journey costs fuel. Absorption: a shield blocks damage, a counterargument blocks an accusation, insurance covers a loss.

The designer describes what happens, not how. "Strike deals 6 damage" - one triple. The engine determines on its own: damage passes through absorption, the remainder goes to health. The formula isn't written per action - it follows from the pattern.

Patterns combine freely. A card game uses impact and absorption. A strategy uses expenditure and accumulation. An RPG combines all of them.

A new game is new entities and new pattern combinations.

Agents

An entity can be described as an agent - with its own state and behavior rules. This is an optional property. An enemy in a card game picks its own action. Barbarians in a strategy attack when conditions allow. A merchant in an RPG travels between cities. An agent:

  • Perceives the world within the limits of its knowledge
  • Evaluates available actions
  • Makes decisions based on goals and the world's rules

An agent is described using the same triples as everything else. A blacksmith knows how to forge (fact), needs ore (fact), ore is in the mine (fact). From these facts the interpreter derives an action: go to the mine, extract ore. The mine is flooded - the blacksmith can't get ore - looks for a merchant - buys it. The behavior emerged from a chain of facts.

Scale without losing logic

In a deep simulation, the world can contain a vast number of processes: from animal migration and city growth to stellar system dynamics. Recalculating everything is impossible and unnecessary - the player always perceives the world subjectively and in limited scope.

The world is organized as a hex map. Each hex stores properties at its own scale: at the planetary level - climate and resources, at the regional level - cities and roads. Clicking a hex reveals the next level - a new map inside with more detailed properties. The algorithm is the same at every level - from a star system down to a single building.

Time and space

For long periods, the system can use statistical models instead of step-by-step calculation. You can move through time without simulating every moment. Over a thousand years, a forest may grow or vanish, a river may shift course, a settlement may expand or be abandoned. Trends and connections are preserved.

Spatial scaling determines the level of entities and processes. At large scale - climate, migrations, politics. At local scale - individual entities and their properties. The logic of cause and effect is the same at every level.

Abstractions accommodate a world of any scale: a village, a planet, a galaxy. Details appear when they become significant. The rest is described in simplified form, but with connections preserved.

The player can dig into how the world is structured, studying entities and following their properties - much like navigating a reference system.

World materialization

The world is built as it's explored. Until the player visits a location, it exists as data and rules. Objects appear at the moment of interaction, not stored in advance.

Beyond the player's view, events are determined by probability, not full simulation. The world feels coherent, even though details are created on demand.

Once the player interacts with a location, its state is saved and no longer recalculated.

Over long stretches of time, statistical trends take over. A thousand years after the start, the system determines by probability which species survive, how the climate shifts, where settlements appear.

Networked play

Networked play works on the same principle. The server stores data, rules, and what players have already discovered.

If multiple players are in the same area, the server assembles a shared state and synchronizes it between them.

Outside the play area, the world remains potential - rules and trends, without details.

The basic network architecture is already working: each player gets an isolated session that others can join by code. Actions are synchronized in real time.

Architecture as language

Data, rules, interface, and agent behavior - one format. Entities don't know about each other; connections arise automatically through shared predicates.

How does this work in practice? A forest is an entity with facts: has timber, is shelter, is flammable. An axe has the predicate Chopping. Chopping acts on timber. Fire acts on flammable things. Drought increases flammability. Each fact is one line. The forest doesn't know about axes, the axe doesn't know about the forest. The connection arises automatically through shared predicates. Add a laser cutter with a Chopping predicate - it works against the forest. Add a planetary bombardment with a Fire predicate - the forest burns.

If a game situation can be described in words, it works in Nexus.