Moving house
The game moved to a new server today. What changed underneath, and a few things we tightened on the way.
Eras runs as one small server: one Node process plays the game, sends out the client, and keeps the whole world in a single SQLite file. Today it moved to a new machine. The world came across with everything in it, and once the address changed over, players landed on the new machine exactly where they'd left off. Moving it made a good excuse to look at what happens between a commit and a player.
Every push ships itself
Every change now runs the same path. A push to the main branch runs the tests. If they pass, the new server builds that exact commit once, starts it on a staging copy of the world, and waits for it to answer as healthy. Only then does it back up the real world and switch it over. The last five releases are kept, so going back is one step. If staging doesn't come up, the real world is never touched.
The tests got faster too. They drive real game clients against a real server: they found settlements, fight battles, tame and ride horses, and carry supplies along roads. They used to walk the bots everywhere at walking speed. Now they jump straight to where they're going, and all seven run at once, each against its own fresh world. A full check takes about a minute and a half on a laptop, where it took nine and a half.
Smaller downloads
The game's script and its 3D models went out uncompressed. Turning on compression was a one-line change: the script dropped from 1.4 MB to 0.4, and the models file from 3 MB to 1.5. A first visit now downloads about 2 MB less, on a day when the models gained ten new hairstyles and a dozen new animations for villagers.
One world, one room
A world holds 32 people at once. When a 33rd arrived, the server quietly opened a second copy of the same world for them. Both copies ran, both saved every 30 seconds, and each one undid the other's saves. Nobody had hit it yet, but a busy evening would have. Now the 33rd person is told the world is full, and there is only ever one copy of each world.
Keeping score
To tune battles we need to know how they actually go: how long they last, how they end, how many lives are left. The server wrote one line per battle to its log, but the log only kept the last few minutes. Now every battle's summary is kept as well, so after an evening of real play we can see whether battles run too long, end too early, or favor one side.
None of this shows on screen, but it all decides whether the game is there when you want to play it.