The first thing we built for Business Baron was not a business. It was a ledger. Before there was a shop to buy or a town to buy it in, there was a double-entry accounting system that would not let a transaction exist unless it balanced, and a test suite that ran a decade of simulated trading and asserted the books still tied at the end.
That order of work tells you most of what you need to know about how we build Business Baron. The interesting part of a business simulation is not the shopfront. It is whether the numbers underneath it mean anything.
The engine is Rust, and the reason is boring
We write the simulation in Rust. Not because it is fashionable, and not for the performance in any graphical sense, because a turn-based economic simulation is not straining a modern machine. We use it for two properties that matter more.
The first is that the compiler refuses to let a whole category of mistakes exist. In a simulation with hundreds of interacting systems, the failure we care about is not a crash. It is a silent one: a value read after it should have been updated, a collection modified while something else was iterating over it, a number quietly going stale in a corner of the model. Rust's ownership rules make a lot of that impossible to write rather than something you hope to catch in testing.
The second is control over arithmetic. Money in the game is not a floating point number. It is integer pence, everywhere, with rounding rules written explicitly at every point where a division happens, because VAT on a £4.99 item and the apportionment of an overhead across four sites both have correct answers and we would rather match them than approximate them.
The engine is separate from the interface. The simulation can be run with no graphics at all, which is how we test it: a headless binary that plays out a century of a company's life in under a second and reports what happened.
The tax code is real and the companies are invented
We take the rules from primary sources. Corporation tax rates and the marginal relief bands, the VAT registration threshold and what happens when you cross it, PAYE and National Insurance thresholds, the Construction Industry Scheme deduction rates, business rates and the reliefs that apply below certain rateable values, capital allowances and the pools they sit in. These come from HMRC guidance, from the legislation itself, and for historical years from the records of what the rates were at the time.
Where a rate changes annually, the game holds a table of what it was in each year rather than a constant. Play a company from 1971 and you will pay purchase tax before VAT arrives in 1973, you will watch the standard rate move through 8%, 15%, 17.5%, 15% again, 17.5% again and 20%, and the threshold at which you have to register will move underneath you.
The businesses themselves are invented. There are more than two hundred business types in Business Baron, from a corner newsagent to a regional haulier, and each has a cost structure, a demand profile, a seasonality curve and a set of inputs. None of them is a real company and none of the figures is copied from a real set of accounts. They are constructed to be plausible: the ratios between rent, wages, stock and margin are drawn from what is publicly known about how those trades work, and then tuned until a competently run business makes a living and a badly run one does not.
The 91 towns and cities are real places with invented detail. Population, broad economic character and relative cost levels follow the actual place. The specific unit on the high street with a rateable value of £14,200 does not exist.
Every system has to be legible, or it does not go in
The temptation in a simulation is to add depth. More variables, more interactions, more hidden state. We have removed more systems than we have shipped, and the test is always the same: when this goes wrong, can the player find out why.
A player whose profit fell by £30,000 in a quarter must be able to trace it. Through the profit and loss, into the cost line, into the transactions, back to the decision. If a number moved for reasons the game cannot show on a screen, the number is a bad number, however clever the model producing it. We would rather have a simpler mechanism that a player can reason about than a sophisticated one that feels like weather.
This is also why the game exposes real financial statements rather than summary bars. A profit and loss account, a balance sheet and a cash flow statement, updated every period, all reconciling. People who run businesses read them without instruction. People who do not learn to, which is one of the better things the game does.
What we deliberately leave out
We are not modelling everything, and we would rather say so.
Employment law is present as costs and constraints, not as procedure. You pay statutory minimums, redundancy costs land when you make people redundant, and unfair dismissal is a risk with a price. You do not conduct a disciplinary hearing.
Individual customers do not exist. Demand is modelled at the level of a market segment in a place, responding to price, quality, competition and the wider economy. Simulating a hundred thousand shoppers would be expensive and would produce an answer indistinguishable from the aggregate one.
The macroeconomy is scripted rather than emergent for historical periods. The three-day week happens in 1974 because it happened in 1974. From the present day forward it becomes a generated economy with plausible cycles, because we are not in the forecasting business.
And personal life is kept to what touches the business. There are no lifestyle purchases. The game is about the business.
Why we care about this
Business Baron is built, and it is the only game we are making. The subjects we once planned as separate games now live inside it as business types, in the full game or in one of four add-on tracks, on the same accounting, the same tax year, the same towns and the same economic history. When we correct a rounding rule in the VAT calculation, it is corrected for the café and the housebuilder alike. It also means the mistakes are shared, which is a reasonable argument for getting the ledger right before drawing the shopfront.