The tech behind Huemill
Huemill is an online automation game where your factory can become part of someone else's. That puts two demands on the simulation: the server has to be able to check every island, and it has to stay cheap enough to run hundreds of them. Here is some of what makes that work.
Fair trade: the server checks the math
Your PC sends the actions you take, not the results. The server keeps its own copy of your island, replays your actions on it with the same code, and settles every trade in its database. A modified client can't fake items, money, or time.
Old saves keep working after updates
When an update changes the save format, the server converts every island before it starts: not when each player next logs in, but all of them at once, including islands whose owners haven't been back in a long time, along with their blueprints. The conversion runs as a single database transaction, and the server won't start until every save is up to date. If something goes wrong, it shows up before the update goes live, not when someone comes back and finds their island won't load.
Nothing you were told is saved gets lost
When you do something, the server writes it to its database before it replies. If the server goes down, the only actions that can be lost are ones it hadn't yet confirmed.
Every machine gets the same numbers
For the server to replay your island, the simulation has to come out exactly the same on every machine. It doesn't use floating-point math. It works in integers, with fixed-point numbers where it needs fractions and its own random number generator, and it advances in fixed steps, 20 per second.
Belts: moving a whole line in one step
Belts of the same type that meet end to end are merged into a single line. Items on a line aren't moved one by one: the line is a ring buffer, and advancing it one cell is a matter of moving its ends. So the cost of moving a line doesn't grow with how many items it carries or how long it is.
Trains: plan once, then wait for the next event
Trains don't recalculate their position every tick. When a train enters a section of track, it works out its whole run through that section (accelerate, cruise, brake) once, in integer math. The next time the simulation looks at it is when the head reaches the end of the section or the tail clears it. The smooth motion you see on screen is drawn from the same formula.
There are no signals to place. Track is split into blocks automatically, and a train reserves the block ahead before it enters. I played OpenTTD for a thousand hours and ended up using nothing but path signals, so I left signals out.
Water: whole bodies, not cells
Water isn't simulated cell by cell. Connected water at the same level is one body, with one volume and one surface level. Springs feed rivers that run downhill to the sea or into sinkholes, and when you dig or fill, bodies split and merge on the spot. The work each tick depends on how many bodies there are and where water spills out of them, not on how many cells are wet.
Terrain: the ground comes from the seed
Islands are generated from a world seed using integer and fixed-point math only, so every machine produces the same terrain, rivers, and ore. That means the save doesn't have to record what's underground: only the columns you've dug into are stored, and untouched ground is recomputed from the seed when it's needed.