What I find interesting about the lockstep approach described here is it seems a lot of modern RTS games still use the same approach, even though the bandwidth calculations have changed radically. When developing my own RTS game I was able to fairly straightforwardly get 1000 units in combat to live stream using about 50 KiB/s bandwidth, which is nothing these days: https://www.construct.net/en/blogs/ashleys-blog-2/rts-devlog...
So as much as this is a fascinating piece of history and an impressive technical solution to the constraints of the time, I think modern games ought to move past it.
> So as much as this is a fascinating piece of history and an impressive technical solution to the constraints of the time, I think modern games ought to move past it.
But why? As far as I know mega-hits like Warcraft III and it's new, updated, version, "Warcraft III: Reforged" which came out 20 years later still use that technique.
The benefits do go well beyond being able to "send" hundreds of units across the wire: a deterministic game engine allows to create tiny replay files and, very importantly, allows to find and smash bugs way quicker.
Having the next game state being a deterministic function of the current game state + player inputs is great.
What would RTS games win by "moving past" that? To do what instead? How would you then implement the replay functionality? You'd also invariably run into a class of bugs which would be hard to reproduce but which would be trivial to reproduce using a deterministic engine.
From a latency point of view you're not gaining anything either: you need to receive the other player's units position anyway. So what's the difference between receiving the hundreds of unit's position or receiving the player input that created these unit's position? Just compute them, deterministically, as soon as you get the player's input.
Everything I've read about the lock-step approach is that it is a total nightmare to develop - keeping games deterministic is really hard and a de-sync bug that happens out the blue after 1 hour of 4-player multiplayer is the kind of thing that is extremely difficult to get to the bottom of. Streaming everything is by comparison much easier to develop in my view since that class of problems disappears. It also allows late-joining, including spectators, as it syncs the full state of the game periodically, and it makes it resistant to brief network outages, such as going through a tunnel on a train while on cell data.
I think it's also worth sometimes revisiting the assumptions made for the current algorithms and approaches in use. The original design was for dial-up modems. The networking landscape is completely different now. Maybe some of the original assumptions are no longer valid and a different set of tradeoffs is worthwhile.
Did those units shoot? What happens when there is a few thousand projectiles in the air, fired by those 1000 units? What about map deformations? What about map wide physic simulations, like springs tsunami water sim or the lava flows of a volcano, changing directions?
None of this should matter as long as the algorithm determining randomness is deterministic.
The bottleneck is player input which is the most overestimated bandwidth stat in gaming. It's mouse movements and a couple of keys strokes per second. Top Starcraft players are in the 300 actions per minute range, that's still just 5 per second.
You don't need to track every projectile, you just need to know that player 1's unit 33 started shooting at player 2's unit 45.
You can encode that very compactly. 2 bytes for each unit ID, source and destination. So 1000 units would be just around 4K, if they all start shooting at the same time.
After that, you can rely on that in most RTS games how units shoot is deterministic.
So as much as this is a fascinating piece of history and an impressive technical solution to the constraints of the time, I think modern games ought to move past it.