Developer journal · Far Reach Industries

Why I Built the Simulation First

How the Far Reach Industries simulation works, what it can already do, and why a colony's failures need to be explainable.

For the last two and a half months, most of my work on Far Reach Industries has gone into the part of the game you can't see.

Not the buildings. Not the terrain. Not the interface.

The simulation underneath them: the code that decides how much power a solar array produces at dusk, when a storm arrives, how much ice a mine can pull out of the ground, and whether there's enough air for the people who just landed.

That's also why there's only one screenshot on this site so far, and it's the main menu. The buildings on screen are still placeholders, and pictures of stand-in art wouldn't tell you much about the game.

What I can tell you about is the foundation.

How it's put together, why I made the decisions I did, what it already does, and where the gaps still are.

The Thing That Frustrated Me Most

When I played Outpost as a kid, my colonies failed almost every time, and I usually had no idea why.

That experience shaped almost every technical decision in this project.

I want a colony simulation where failure can be understood. If your colony runs out of food, you should be able to follow the problem back to its cause. If a building refuses to run, the game should be able to tell you what's wrong. And if something strange happens in a long campaign, I should be able to reproduce it and find out why.

Those are simulation problems before they're interface problems.

A clear warning screen doesn't help much if the underlying system can't explain its own behavior.

So I started with the system.

The Game Runs Fine Without Unity

The simulation is a C# library with no rendering, no UI, and no dependency on Unity.

Its first client is a console harness. I can type run --max-sols 60 and watch a colony live or die in a terminal, or sweep a few dozen seeds and read the results when they finish.

Unity is the second client. It links three DLLs, sends commands, and draws a read-only snapshot of the world after every step. Unity sets the pace, but it can't reach into the simulation and change a value. If I want something different on screen, the simulation has to produce it first.

I chose that boundary for a few reasons.

The first is a practical one: when I started, I couldn't decide which game engine I wanted to use.

Rather than let that decision hold up everything else, I built the part of the game that doesn't care. The rules of the colony don't need to know what's drawing them. Keeping the simulation in its own library meant I could start on it right away and leave the engine question open. That choice deserves its own article, and I'll write more about it later.

The second is testing. When the rules of the colony live in one library, I can test them without launching a game, loading a scene, or clicking through menus. A console run tells me whether the colony survived. A test tells me whether a rule still holds.

The third is trust. When there's only one place that decides what happens, there's only one place that can be wrong. The visual client can't quietly invent its own version of events.

If the simulation didn't decide it, it didn't happen.

Every Command Gets an Answer

Every command the player gives is either accepted or refused.

A refusal comes with a typed reason code, and the game turns that code into a plain-English explanation.

That sounds like a small detail, but it's one of the earliest rules I set, and it comes straight from that Outpost frustration. A refusal without a reason leaves the player guessing. A refusal with a reason teaches them something about how the colony works.

Typed codes also matter on the development side. Because each refusal is a specific, named case rather than a loose message string, the tests can check that the right refusal happens for the right reason, and the explanation the player sees is generated from the same code the simulation produced.

If the game refuses you, it has to be able to say what's wrong.

One Hour per Tick, Forever

The simulation advances in ticks, and each tick is one hour of colony time.

A sol, the local day, is 24 ticks. A year is 8,766.

That never changes with the game speed. Speed only controls how many ticks run per real second: zero when paused, and up to 24 at the fastest setting for now.

I chose a fixed tick because I didn't want the rules of the colony to depend on how fast the player happens to be watching. Fast-forwarding through a dust storm plays exactly the same hours you'd see at normal speed. A battery drains the same way. A storm ends at the same hour.

Within every tick, 18 systems run in a fixed, documented order: commands first, then life support, power, logistics, extraction, population, and on down the list.

Two of those slots are empty stubs, reserved for features that don't exist yet.

Fixing the order matters because the systems depend on one another. If power ran before life support on one tick and after it on the next, the same colony could produce different results for no reason a player could see. A documented order means every system knows what has already happened in this hour and what hasn't.

Same Seed, Same Colony

The simulation is deterministic.

Give it the same world seed and the same commands, and it produces the same state, hour for hour, on any machine.

That's a harder promise to keep than it sounds. It took a few rules I don't get to bend.

No floating point in the simulation state

Everything in the simulation state uses fixed-point math.

Floating-point numbers can produce slightly different results depending on the hardware, the compiler, or the order of operations. In a game that runs for thousands of hours, a tiny difference can grow into a different colony.

The JSON parser for game data is hand-written for the same reason. A float can't sneak in through a content file.

No shared random number generator

Every random roll is derived from the world seed, the tick, the system, and the entity asking.

With a shared generator, the result of each roll depends on how many rolls came before it. Add one new random check to one system, and every roll after it shifts. Deriving each roll independently means a change in one place doesn't ripple through everything else.

Pending commands are part of the state

Two worlds that look identical but have different orders waiting in the queue don't hash the same.

That closes a subtle gap. If the hash only covered what had already happened, two saves could look the same while being about to diverge.

The Baseline Has the Final Vote

Determinism is only useful if I can prove it's still true after every change.

So every change has to pass a baseline check. It builds the project, runs the full test suite, validates the content, then plays 50 seeds for 10,000 ticks each and compares their state hashes against a record I've already approved.

If a hash moves and I can't explain why, the change doesn't go in.

That rule has a practical payoff. A save plus its command log replays byte for byte.

So "my colony starved around sol 50" stops being a story I have to interpret and becomes something I can reproduce, step through, and fix.

A bug I can replay is a bug I can understand.

Data, Saves, and the Boundary

Buildings, planets, sponsors, cargo, and events live in JSON files rather than in code.

Part of the reason is practical. Adding a new planet, scenario, or sponsor means writing data, not recompiling the game. The simulation reads what's in the content folder and builds the world from it, so the list of things a colony can encounter can grow without a rebuild.

The files are validated strictly on load, and every error is reported in one pass instead of one per restart. That sounds like a convenience, and it is, but it also means a content mistake can't slip into a running colony as a half-loaded building or a missing value.

Easy to add doesn't mean easy to change behind my back, though. The shipped content folder is fingerprinted, and the game won't load it if it's been edited. If the rules a save was played under could change silently, a replay wouldn't mean anything.

Saves are versioned and checked for damage on load. Older saves can be migrated forward. Each slot reports itself as good, damaged, incompatible, or in need of migration, so you know before you click Load.

The boundary between the simulation and Unity also has a cost, so I measure it. Publishing the snapshot Unity draws from averages about 0.006 milliseconds per tick for a typical colony.

My budget for it is 0.2.

What Milestone 3 Covers

I signed off on the third milestone on October 3, 2026, with 1,848 tests passing.

That milestone covers the worlds, the surveys, the expedition, and the first stretch of a colony's life.

Worlds that explain themselves

There are four landable worlds:

• A Mars-like planet with 13 landing sites
• Its icy moon
• An airless basalt world like Mercury
• A tilted world kept warm by tidal heating

Each world's physics turns into concrete consequences: how much sunlight reaches the ground, whether there's ice to mine, how bad the dust gets, and how hard the rock is to dig.

The game gives you straight answers about whether solar power, ice mining, or atmospheric processing will work there.

Axial tilt and orbit set the seasons, which shift solar output and storm frequency across the year.

And the physics is enforced, not just described. Try to build an atmosphere extractor on the airless world and it will be refused, because there's nothing to extract.

Surveys and uncertainty

I've written before that an estimate shouldn't look like a guarantee. The survey system is where that idea lives.

There are six stages: a briefing before launch, an orbital survey on arrival, survey drones, ground penetrators, test drilling, and a tomography rig.

A deposit is unknown, located, or graded, and you don't get a real number until it's graded.

The difficulty setting changes how much the surveys report. It never changes what's actually in the ground.

That distinction matters to me. A harder game should mean you know less, not that the planet quietly works against you.

Planning the expedition

You pick from three candidate star systems, then a world and a landing site. You choose a crew, their dependants, and a sponsor whose charter sets the terms.

Then you pack against a budget and a landing weight limit.

Cargo in orbit can be sent down, held, or stranded, and stranded cargo can be recovered at a price.

The first months on the ground

Every landing starts with the Seed, four starter units for power, smelting, robotics, and command.

They expire somewhere between sol 40 and sol 59, so replacing them is your first real deadline.

From there, the colony runs on systems that already work:

• Robots open mines on deposits you've actually found and work them until they're empty.
• Ice gets mined and processed into water.
• Solar output follows the day-night cycle, and batteries cover the dark.
• When demand outruns supply, loads shed in a fixed order, so you can see what went first.
• Dust storms are announced before they hit.
• Colonists are born, age, come of age at 18, and die, and morale gates growth.
• Buildings can be repaired, demolished, and kept running with spare parts.

A stalled mine or a starved factory raises an alert that names the cause.

That last point is the one I care about most. The alert isn't a separate system guessing at what went wrong. It comes from the simulation that made it go wrong.

What I'm Working On Now

The fourth milestone moves the colony off flat ground and down into the rock.

It's built, and the test count is past 2,000, but I haven't signed off on it yet.

Buildings need a level pad, and grading records the cut and fill.

There are three levels below the surface. Tunnels need roof support or they collapse. Lifts carry people and cargo between levels, and each one has a capacity.

Depth shields you from what's happening on the surface, but it gets hotter the deeper you go. And nothing underground is known until you dig into it or scan it.

Construction is staged now. Materials have to be delivered, the building goes up, and then it has to be commissioned before it runs. You can pause or cancel a job, and the game tells you up front what you'll get back.

Going underground is where the earlier decisions start paying off. Every one of those rules, from roof support to lift capacity, runs through the same tick order, the same refusal codes, and the same baseline check as everything before it.

What Isn't There Yet

There's a lot still ahead, and I'd rather be specific about it.

Research is an empty slot in the system order.

Power and water don't yet flow through routed networks you can trace back to a broken pipe or a cut line. That's the next milestone, and it's the one I care about most.

The dust storm is the only event.

There are no other settlements, no trade, and no endings.

The snapshot doesn't publish everything yet either. Vehicles, shipments, wear, and robot movement aren't in it, so some of what you see moving in a development build is the client filling in, not the simulation. I want to be clear about that line, because the whole point of this architecture is that the simulation is the source of truth.

Every number in the game is a placeholder until balancing.

So is the art.

The Game This Foundation Is For

None of this work makes for an exciting screenshot.

But it's the part of the game I can't fake.

When routed power and water arrive and your colony's water runs dry, the game will need to show you which pipe failed, why it failed, and what that failure did to everything downstream. That only works if the simulation knows the answer, can explain it, and produces the same answer every time.

That's the game I want people to play.

Not one where a colony collapses and you're left guessing.

One where you can see why it's struggling, understand what you could have done differently, and try again with a better plan.

Everything I've built so far exists to make that possible.

Far Reach Industries is a hard-science colony simulation I'm developing under Crown & Crabapple, my independent game studio. I'm documenting the development of the game, from the design decisions to the engineering underneath it.

Follow the development of Far Reach Industries, a science-fiction colony and industrial simulation game from Crown & Crabapple.