Battle PathLATEST NEWSNov 8, 2026
⌕ Search

Building a deterministic space auto-battler

What the report saysThis was not part of the plan. When I made Gratuitous Space Battles, it was not a deterministic sim. Multiple runs of a battle could lead to slightly different results. It was not ideal. And I was not…

Building a deterministic space auto-battler

What the report says

This was not part of the plan. When I made Gratuitous Space Battles, it was not a deterministic sim. Multiple runs of a battle could lead to slightly different results. It was not ideal. And I was not even thinking about it with Ridiculous Space Battles, until I started to do balance testing and started designing campaign levels. And in that testing I started to really appreciate how infuriating a lack of determinism was. That was more than a week ago. Maybe two weeks…To explain: Ideally if you do two battles in RSB with the exact same deployments, you should get the same result.

Not just victory or defeat, but the exact same score. This is is the whole core of the game. The smaller the fleet you win with, the more points you score. So running the whole battle again with just ONE less squadron, is definitely worth it for the meta-game (and bragging rights). But that might mean fielding 99 squads instead of 100. In other words, the game has to be accurate down to that 1%, and actually that means 100% deterministic.Here is the problem. A missile fired from a frigate drifts 0.0001 units to the left compared to the previous run-through.

That means it actually hits its target VERY slightly later, but that ‘later’ means just *after* its target fires its massive mega-gun that takes out a crucial enemy cruiser. Without that cruiser, the fleet will narrowly lose. With it, the fleet will narrowly win. So that missile MUST hit its target in the exact same frame, every time……and its worse. That missile might even be a dummy missile. It might even miss! it does not matter. Because in theory that 0.0001 units means its the nearest target for a point defense laser, or not.

Building a deterministic space auto-battler

Key details

That could still lead to a chain of events that results in the whole outcome of the battle being changed. In practice, if you want the outcome of a big battle to be predictable, and repeatable you need a 100% deterministic simulation. Thats not 99.99999% deterministic. Its absolutely 100%. And that is… hard.I’m not a n00b coder. I know this problem is hard, AND I know in theory how to avoid it. Have a constant simulation rate, and detach the frame rate from the sim rate. Do not use any truly random numbers, but precalculated ones based on a fixed random seed.

You can use true randoms for UI, but never for the sim. The sim is the sim. The UI is the UI. They never get confused. Simple right? And I am sure coders who haven’t worked on it before already think its an afternoon’s work. It is not!It would have been WAY easier if I had worried about this right at the start of coding the game, but I did not, and so I had to take a huge existing game and MAKE it deterministic, and its taken weeks and I’m not yet 100% sure I’ve cracked it.

I have definitely made it much better, but am I at 99.99999% or 100%? Lots of testing tomorrow will answer that for me. But briefly, this is what was involved:Step 1 was to move from a variable frame rate (capped at 60 fps) to a dual system where the sim runs at a constant interval, but the frame rate is independent. This is complicated by the fact that the game has 5 speeds, from 1/4 speed to 4x speed. Actually to be fair this part of the work was quick and easy.

More from the announcement

I still have a ton of macros in the code referring to SIMTIME that actually should now just be ‘4.0f’, but thats the beauty of macros. There was a fair bit of find/replace to change a lot of calls in the code to either use SIMTIME or FRAMETIME, but that was simple. Now every tick assumes 4ms has passed, and the ratio of ticks to frames simply depends on the current game speed. This does mean I have kind of lost the ‘frame-smoothing’ for when the GPU is under more or less strain, but TBH the game runs so fast its ludicrous anyway, and for super low spec GPUs the game has a ton of graphics detail settings.So that sim/graphics decouple was a big step, and an easy step, but after that the real problems began.

Basically there were mistakes somewhere in the code. There were circumstances where things drifted out of synch, and it took a ton of detective work to find them all.