Four Primitives, Any Game System: How AxiomWeaver's World Builder Works

When I started designing AxiomWeaver's world-building engine, I had a choice: build a separate system for every concept authors need — a character system, an inventory system, a quest system, a skill tree system — or find the primitives underneath all of them and build those instead.

I chose the primitives. Four of them. Everything else composes from there.

The four primitives

Entities. The nouns of your world. A character, an item, a location, a faction, a skill, a quest — they're all entities. The system doesn't care what "type" something is at a deep level. An entity is a thing with properties.

Templates. The molds. A template defines what properties an entity has and what it can do. "Warrior" is a template that gives an entity HP, STR, DEX, and a weapon slot. "Potion" is a template that gives an entity an effect and a consumed flag. Templates compose — a Human Warrior merges two templates into one entity.

Relations. The verbs. "Kira equips Soulreaver." "Borin is a member of the Ashen Compact." "Vex is rivals with Kira." Relations are bilateral — create one direction and the inverse appears automatically. They can also carry grants: equip a sword, gain +5 STR. Join a faction, gain a reputation property.

Ledger. The history. Every change to the world is an event anchored to a position in your manuscript. "Chapter 12: Kira acquires Soulreaver." "Chapter 31: Wraith ambush, Kira HP -340." The ledger is what makes the temporal engine possible — scrub to any scene and the engine replays the ledger to compute world-state at that moment.

That's it. Entities, templates, relations, ledger. The design thesis from day one was: no concept requires its own engine.

How concepts emerge

This is the part that surprised me. I expected to build special-case systems eventually. I didn't.

Equipment is just relations with grants. "Kira equips Soulreaver" creates a relation between two entities. That relation is marked as grant-active, which means Soulreaver's stat modifiers (+15 Shadow damage) flow into Kira's computed state. Unequip, and the grants vanish. No equipment engine — just the relation and grant primitives.

Skill trees are progression tracks on templates. A progression track has tiers with triggers ("requires Level 10"), rewards ("grants +3 STR"), and prerequisite links between them. The skill tree visualization is just a ReactFlow graph rendering the progression data. No skill tree engine — just templates with progression tracks.

Factions are entities with membership relations that carry grants. Join the Thieves Guild? The membership relation grants a Stealth bonus and a Reputation property. Faction hierarchies are just nested relations between faction entities. No faction engine.

Template composition handles hybrid entities. A Human Ranger is composed from a Character template, a Human template, and a Ranger template. Properties merge. Equipment slots combine. The character sheet renders the composed view automatically.

The quest system proved the thesis

The moment I knew the primitive approach worked was the quest system.

A quest in AxiomWeaver is just an entity. Its template has progression tracks (objectives), relations (quest-giver, quest targets), grants (quest rewards), and constraints (prerequisites). That's it. No quest engine. No special-case code. The same primitives that model a character sheet also model a quest log.

The only new work was UX — a quest log view that reads quest entities and renders their progression state. The data model was already there.

This pattern kept repeating. When I built the Action system in March — named actions like "Attack," "Rest," "Level Up" with delta patterns and typed slots — it was the same story. Actions compose from existing primitives. The narrative event composer that turns "Kira attacks the Hollow King with Soulreaver" into a structured event with stat deltas? Built on the same four primitives.

Mutations, revelation, and the weird edge cases

The real test of any architecture is the edge cases. The things that make you say "well, I guess I need a special system for that." So far, the primitives have held.

Mutations are templates that act as diffs. A "Lycanthropy" mutation suppresses certain properties and adds new ones. A "Lost Arm" mutation removes an equipment slot. The composition resolver handles this in two passes: collect all composed properties, then apply subtractive effects. No mutation engine — just templates with a different flavor.

Contextual layers let one entity have multiple presentations. Think Wade/Parzival in Ready Player One — same person, different properties depending on context. Toggle the context, see different stats. Still just an entity with layer metadata.

Revelation layers are the one I'm most proud of. Every entity and event has an Author Truth layer and configurable Reader Knowledge layers. A cursed sword's luck drain is mechanically active from the moment it's equipped, but the reader doesn't learn about it until chapters later. The engine tracks what's real separately from what's revealed. Same entity, same properties, different visibility.

The constraint philosophy

One design decision I made early and have never regretted: constraints are always advisory.

The engine will warn you if a Dark Elf Embassy doesn't make sense in a human city. It'll flag a potion that shouldn't work on undead. But it never blocks. The author decides.

This matters because fiction isn't a game. A game enforces rules because the player might cheat. A story breaks rules because the narrative demands it. The tool should inform the author's decisions, not override them.

What's coming next

The primitives are solid. The next layer is making them smarter:

Template inheritance. Right now, templates compose but don't inherit. The next step is parent-child template trees — a Sword inherits from Weapon, which inherits from Item. Properties cascade down. Races and classes become templates rather than entities. "Elf" is a child template of "Character" that grants Darkvision and Dexterity.

Entity descriptors. Composable capability adjectives — Active, Attachable, Carriable, Fillable, Traversable. Assigning a descriptor automatically creates the mechanical properties it requires. A sentient sword gets Active + Carriable + Attachable, and the engine knows what it can do.

These aren't new engines. They're refinements of the same four primitives, making them express more with less author effort.

Why this matters for your writing

If you're an author, you probably don't care about primitives and composition resolvers. That's fine. Here's what it means in practice:

You can model any game system your story uses. D&D-style stats with equipment and levels. Cultivation realms with qi and body refinement. Tier-based progression with bronze/silver/gold ranks. Skill-only systems with no traditional stats. Mix them in the same project if your story crosses systems.

You define the rules. The engine enforces them (gently). And every change is tracked in the ledger, so you can see the state of your world at any point in your manuscript.

That's the point of building on primitives instead of special-case engines. Your world doesn't have to fit my assumptions about what a "game system" looks like. You build the system your story needs, and the tool adapts.

If that sounds useful, request early access to the alpha. Or come talk world-building on Discord — I'm always there, and I genuinely want to know what systems you're building.