A player wrote to us about a haulage business that had gone bankrupt in a way they thought was wrong. Fuel costs had jumped in a single quarter with no apparent cause. They sent the seed and the list of decisions they had taken.
We ran it. The same firm failed in the same month for the same reason, on our machines, at our desks, two hundred miles away. The cause turned out to be an interaction between a contract renewal date and the way we were applying an annual fuel duty change, and it was fixed the same afternoon. Without the seed, that conversation would have been three weeks of "we cannot reproduce it".
The same seed produces the same game, all the way down
Every career in Business Baron starts from a seed: a number that determines everything the simulation generates. The towns and their economic character, the businesses available to buy, the competitors and how they behave, the weather, the customers, the events. Give the engine the same seed and the same sequence of player decisions, and it produces the same game, turn for turn, penny for penny.
This is a stronger claim than it sounds. It means no system anywhere is allowed to consult the system clock, the operating system's entropy source, the order in which threads happened to finish, or anything else the machine knows and the simulation does not. It means arithmetic must produce identical results across platforms, which is why money is integer pence and why we are careful about where floating point is permitted to appear at all. It means iteration order over collections has to be defined rather than incidental.
None of that is free. It constrains how we write everything. We think it is the single most valuable property the engine has.
Random numbers come from separate streams, never a shared pool
The naive way to do randomness in a simulation is one generator, seeded once, which every system draws from. It works, and it makes the game impossible to maintain.
The problem is coupling. If the weather system, the customer arrival system and the competitor decision system all draw from the same stream, then the order in which they run determines what each one gets. Add a single new call to the weather code and every subsequent draw shifts. A save from last month's build no longer replays. A bug fix in one system silently changes the outcome of an unrelated one.
So each subsystem gets its own stream, derived from the master seed and a fixed identifier for that subsystem. Weather in Carlisle in March 1987 is derived from the seed, the place, the date and the word for weather. It does not depend on how many times the competitor logic rolled a number that turn, or on whether a player opened a menu.
The practical benefit for a player is that we can patch the game without invalidating saves in unpredictable ways. The practical benefit for us is that when we change something, the things that change are the things we changed.
A replay is a proof, not a description
The interesting consequence of determinism is what a save file becomes. It is not a snapshot of state. It is a seed plus an ordered list of decisions, which the engine can replay from the beginning to arrive at that state.
That changes what a bug report is. Normally a report is a person's account of what they think happened, filtered through what they noticed. With a deterministic engine, it is the thing itself. We can step through the identical run, pause at any turn, dump every intermediate value, and see the actual cause rather than a reconstruction of it.
It also means we can be held to account. If a player believes a figure is wrong, they are not arguing with us about what the game does. They can send the seed and we will both be looking at the same numbers. Several corrections in Business Baron came in exactly that form, and a couple of them were places where the player was right and we were not.
Testing decades in seconds is only possible if nothing is random
The engine runs headless. No graphics, no interface, just the simulation. In that mode a full run from 1930 to 2040 takes well under a second, which changes what testing can be.
We do not test a business simulation by playing it. We test it by running thousands of full-length games across thousands of seeds and asserting properties that must hold in every one of them.
- The books balance at the end of every period in every game. Assets equal liabilities plus equity, and the cash flow statement reconciles to the movement in the bank.
- No account ever holds a value that is not a whole number of pence.
- A business that is never trading never accrues a cost that only trading businesses incur.
- Tax charged in any year matches an independent recalculation from the rates table for that year.
- A player who takes no actions at all reaches the end of a full-length run without the engine entering an impossible state.
When one of those fails, the failing seed is recorded and becomes a permanent regression test. The suite grows by accumulating the specific games that once went wrong, and every future build has to survive all of them.
This is also how we balance. If we change the rent model, we can re-run twenty thousand games overnight and compare the distribution of outcomes before and after. That is a different kind of information from a designer's opinion after an afternoon of play.
The cost is that we cannot take the easy way out
Determinism is a discipline rather than a feature, and it makes some things harder than they need to be.
Anything that touches wall-clock time is suspect. Anything parallel has to produce results independent of scheduling. A convenience function from a library that happens to iterate a hash map in whatever order the hash produced is a latent bug we will find eighteen months later. Every time we want to add a system quickly, the rules say no.
It also means we cannot quietly rebalance a live game by nudging outcomes. If a business is too profitable, the fix is a change to the model, published in the notes, applying to everyone. There is no hidden hand adjusting your particular run to keep it interesting. Some games do that deliberately and there is a reasonable argument for it. It is not the argument we are making.
Why we care about this
A simulation that claims to be about running a business has to be reproducible, or it is not a simulation, it is a mood. Business Baron is built this way, and so is every business type in it, the free ones and the ones in the tracks alike, because they all run on the one engine. If you lose a company, the game can show you the exact sequence that lost it. That is the point.