The World Could Not Keep Growing One Feature at a Time

Our latest Dominus development epic did not begin with a stock market, a cargo ship, or a grand plan for a modular engine.

It began with a janitor.

We were talking about Joe—the persistent person who can live anywhere in Dominus and become almost anyone. The obvious example was the President of the United States. A president has decisions to make, information to weigh, people to persuade, and powers attached to an office.

But then came the more useful question:

What if the player is the janitor working in the same building?

The janitor should not receive a president's menu with most of the buttons disabled. He should see the possibilities created by his life: his job, home, health, money, relationships, knowledge, loyalties, and the people around him. If a reporter wants information from inside the building, the opportunity should not belong to “the White House” as an abstract object. It should exist between people—a reporter looking for a source and a worker deciding whether money, loyalty, fear, resentment, or conscience matters more.

That conversation exposed a problem much larger than Joe.

Dominus had been growing one major system at a time. Governments, militaries, economies, diplomacy, intelligence, terrain, and time were all becoming deeper. But if every new kind of life or institution required another central menu, another special route through the engine, and another collection of exceptions, then the world would eventually become impossible to extend.

We could keep adding features. We could not keep adding them that way.

The game was not about the president

For a long time, national leadership was the clearest way to demonstrate Dominus. Presidents declare wars. Cabinets manage budgets. Generals move formations. Those actions are easy to place on a map and easy to explain in a strategy game.

They are also only a few jobs in a world containing thousands of them.

The emerging idea behind Joe changed the center of gravity. The player would select a person and see what that person could reasonably try to do. A secretary of state would see diplomatic possibilities. A company owner would see choices about the company. An entry-level worker might apply for a promotion, look for another job, miss a shift, join an organization, move apartments, borrow money, or decide how to respond to something happening at home.

The player would not move Joe like a piece on a board. The player would exert influence: set priorities, choose important moments, establish standing preferences, and sometimes let Joe act from his own personality and circumstances.

That sounded flexible until we tried to imagine writing it all down.

A police officer needs one set of possibilities. A teacher needs another. A restaurant manager, dockworker, journalist, nurse, soldier, landlord, union organizer, software engineer, parent, student, and retiree all inhabit different systems. Even two people with the same job may have different choices because one owns a home, another is ill, one has a child, another is in debt, and only one knows the person offering a dangerous opportunity.

A giant catalogue of Joe commands would fail before the world was interesting.

The solution was not to make a module for every job. That was our next important correction.

Modules are not jobs

At first, “module” sounded like a convenient way to package careers. Add a police module and police officers gain police interactions. Add a restaurant module and restaurant workers gain restaurant interactions.

But Dominus is not a career simulator with a world wrapped around it. Jobs are where people encounter larger systems.

A stock-market module is not a job. It introduces exchanges, securities, orders, ownership, settlement, company financing, household exposure, regulation, and the consequences of a market moving.

A maritime module is not a job either. It introduces ships, ports, cargo, routes, capacity, delays, ownership, imports, exports, and visible movement across the map.

Those systems may create jobs. They may also affect a president, a pensioner, a manufacturer, a family buying groceries, a reporter following a shortage, and a dockworker waiting for a vessel that has not arrived.

That was when the phrase Simulation OS began to fit.

The comparison is simple: Dominus should provide the shared world in the way an operating system provides a shared computer. Time, identity, location, permission, memory, history, and the basic rules for changing state belong to the foundation. New simulation domains should be able to join that foundation without rebuilding it.

The point was not to make the architecture sound grand. The point was to stop teaching the engine every future idea in advance.

A small center and a large world

Once we adopted the operating-system idea, the next temptation was to make the foundation enormous. If the engine might eventually support thousands of modules, perhaps it should anticipate everything those modules could ever need.

That would have created the same problem under a different name.

Instead, we chose a small center. The engine should know how time passes, how things are identified, where they exist, who is allowed to act, how scarce resources are reserved, how decisions become outcomes, and how history survives. It should not know what every ship, school, market, hospital, marriage, election, or profession means.

Those meanings belong to the systems that introduce them.

The boundary matters because a living world cannot allow every new system to rewrite everything else. A shipping system should not reach into a company's private records and change them directly. A market should not secretly alter a household. A news narrator should not create the event it claims to report.

Each part of the world owns its truth. When parts affect one another, they make requests, exchange information, reserve what they need, and leave receipts.

That sounds like a technical rule. The reason for it is narrative.

If a company fails because a shipment was delayed, Dominus should be able to show the delayed vessel, the missing inventory, the decision the company made, the workers affected, and the story the press eventually published. If one system can quietly edit another, the result may look right but the explanation will be fiction.

The story has to exist before the prose

Narration was part of the problem from the beginning.

A president may know why he ordered an attack. An intelligence officer may know only part of it. A reporter may have a source inside the government, but that source may be mistaken, disloyal, frightened, or selling access. The public newspaper should reflect what the reporter could learn—not the private truth stored inside the simulation.

We did not want to solve that by asking a language model to invent a convincing explanation after the fact.

The world must first preserve what actually happened: the choices that were available, the information each person could see, the guidance they received, the decision they made, the costs that were reserved, the outcome that followed, and the later consequences connected to it.

Only then should narration begin.

A biography, newspaper story, social post, cabinet briefing, or retrospective can tell the same event from different points of view. They can disagree. They can omit facts. They can even be wrong. But their disagreement has a structure beneath it. The prose is a view of history, not a substitute for history.

That principle became one of the most important lines in Dominus Development:

History is structured before it is narrated.

It is also what may eventually let a player look back over a Joe's entire life—not as a list of statistics, but as a real story formed by opportunities, choices, missed chances, relationships, consequences, and turning points.

The scale problem arrived immediately

The moment we imagined an expandable world, we ran into scale.

Suppose a company employs 100,000 people. Dominus cannot run 100,000 detailed minds every game minute just to discover whether any of them has something to do. Nor should it pretend all 100,000 people are individually simulated when only ten currently matter to a player, an organization, or an unfolding story.

The answer is not to make the unseen world false. It is to change its resolution.

Most people can remain inside truthful aggregates: workforce, households, consumers, voters, passengers, patients, students, and populations. A smaller number become explicit Joes because a player follows them, they hold an important role, or events make their individual decisions consequential.

Even explicit people do not need constant attention. Routine schedules and standing obligations continue. A person or module wakes when something is due or when a relevant fact changes. A worker is not reconsidered every minute; he is reconsidered when a shift begins, a bill comes due, a relationship changes, a job offer arrives, or the world gives him a reason to choose.

The rule we settled on was:

Attention changes resolution, not truth.

That is how a player can follow one janitor closely while a company, a city, and a planet continue around him. It is also how thousands of future modules can exist without every one of them scanning the entire world on every step of the clock.

We deliberately did not build the marketplace

Calling Dominus a Simulation OS naturally raised another question: could outside developers write modules for it?

Eventually, that is the ambition. We can imagine developers creating deep systems for medicine, policing, education, organized crime, shipping, aviation, entertainment, energy, religion, local government, particular industries, and kinds of work we have never considered.

Trusted modules can expand the simulation now. Data-only content can add approved records, rules, presentation, and narrative material without redeploying the game. The dangerous part—installing arbitrary third-party executable code into the live world—waits for a later version with the sandboxing, signing, moderation, and operational discipline it deserves.

This was restraint, not retreat. We built the doorway before inviting the city through it.

Two very different proofs

An architecture can claim to be general while quietly fitting only the examples used to design it. We needed two systems different enough to expose that mistake.

Maritime shipping gave us physical movement: ports, vessels, cargo, routes, capacity, schedules, delays, imports, exports, and objects visibly crossing the map.

Stock markets gave us something almost opposite: exchanges, securities, ownership, orders, prices, settlement, company financing, and financial exposure that can move without a single vehicle changing location.

If both could enter the world through the same foundation—without becoming the same kind of system—then the modular idea had earned some credibility.

The final proof connected them.

A trade creates demand for shipping. A vessel carries the goods. A delay changes what reaches a company and when. The company's position affects markets and organizations. Those changes reach individual people. The resulting events become news.

No single module owns that story. No writer scripts its ending. The story exists because several parts of the same world agree on how to affect one another and preserve the trail.

What Epic 192 actually changed

This stretch of development did not make Dominus look like a finished game. Much of its work lives below the surface. It changed what the next feature is allowed to assume.

A future medical system does not need to invent a second kind of person, a private clock, or its own history. A school system does not need to hard-code new navigation into the entire client. A crime system does not gain permission to see every secret merely because it was installed. A new industry does not need the central engine to learn its name before it can exist.

Most importantly, Joe no longer needs a menu containing every possible life.

Joe can ask the world a simpler question: Given who I am, where I am, what I know, what I possess, what I owe, and what is happening now—what can I try to do?

The answers can grow as the world grows.

That is the real accomplishment of Epic 192. We stopped treating expansion as a longer list of features and started treating it as a permanent ability of the world.

The president still matters. The stock exchange matters. The cargo ship matters.

So does the janitor.

And for the first time, they can all belong to the same story without the engine being rewritten around whichever one we build next.

• • the Dominus team*

---

← All dispatches