I started Ashes of the Unbound as a survival factory RPG. By the middle of April, the project already looked less like a single game and more like a small operating system whose processes happened to include combat, factories and magic.
That was not architecture for its own sake. The design asks a lot of the same world: persistent characters, dedicated servers, modular progression, dialogue, quests, production lines and movement between planets and moons. Letting all of that accumulate in one game module would make the first prototype fast and every later change terrifying.
So I spent the opening phase establishing boundaries before there was enough content to hide the mistakes.
Gameplay plugin architecture
The runtime systems became plugins with deliberately narrow responsibilities. Stats provide the underlying attributes. Vitals turn some of those values into survival pressure. Combat owns damage and the rules around it. Dialogue, quests and NPCs coordinate narrative state without becoming one inseparable narrative blob. Factory systems own production. Progression owns unlocks. Saves move versioned state across sessions.
This is not a claim that every plugin is finished. It is a claim that each one has somewhere honest to grow.
The practical benefit appears whenever two features meet. Combat may affect a vital, but it should not reach into a UI widget and alter a progress bar. A quest may depend on a factory milestone, but it should observe an exposed state rather than know the internals of a machine graph. Save code should ask a system for its chunk rather than reflect across the entire world and hope it reconstructs something coherent later.
The boundaries make dependencies visible. Visible dependencies can be tested, versioned and eventually replaced.
Fourteen editor domains
Runtime plugins only solve half the problem. A system is not useful if authoring its content requires remembering twenty unwritten rules.
GameContentTools grew into fourteen editor domains by 14 April. They cover the assets used across the game’s systems and give each family of content a place for creation, inspection and validation. The exact editor interface will continue changing, but the architectural decision is stable: content rules belong in tooling, not in the memory of whoever last touched the asset.
That matters for a project like this because content failures are often structurally valid Unreal assets. A data asset can load perfectly while referring to an impossible progression state, a missing stat, an invalid factory recipe or a dialogue transition which can never occur. The engine cannot know those are wrong unless the project teaches it.
The editor tooling is where those rules become executable.
Cross-plugin contracts
I have tried to keep cross-plugin communication boring. Interfaces and data contracts cross boundaries; implementation details do not. Editor-only modules stay out of packaged runtime code. Data that must persist gets an explicit serialized form. Systems expose enough state to cooperate without turning every class into a public drawer of internals.
This is slower than reaching for the first globally available object. It is much faster than discovering a year later that the save system, quest system and UI all depend on the same concrete actor type.
The most important contracts were already beginning to cluster around four questions:
- Who owns this state?
- Which machine is allowed to change it?
- What is its durable representation?
- What evidence proves that it survived the transition?
Those questions became even more important when dedicated multiplayer arrived. An editor session can get away with ambiguity about authority. A server cannot.
Why this architecture fits the game
There is a thematic reason this structure feels right for Ashes of the Unbound.
The setting is about replacing damaged, unreliable magic with infrastructure that can be understood. The player builds production because a physical system is dependable in a way the fractured Binding is not. The development process has been following the same principle: turn assumptions into machinery, give the machinery interfaces, and make the result observable.
A factory graph and a plugin graph are obviously not the same thing. They do share a useful idea, though. A complicated outcome becomes manageable when every stage has a defined input, output and failure state.
What was working by 14 April
By 14 April, all fourteen GameContentTools domains had complete initial implementations, the major gameplay areas had plugin homes, and persistence was becoming an ordered, versioned protocol rather than a last-minute snapshot. There was still an enormous amount of game left to build. The foundations were no longer hypothetical.
That distinction is useful when looking back at a project. “Architecture complete” would be absurd. “The project had explicit system boundaries and working authoring domains” is both narrower and more meaningful.
The next problem was authority. Once the same world can exist on a player client and a dedicated server, only one of them can be trusted to decide what is durable. That became the next development arc: Adding Dedicated-Server Persistence to Ashes of the Unbound.