Profile Treeform's Blog

Don’t use Lockstep in RTS games

Oct 1, 2016

Lockstep has lost! The Client-Server network model has won and has become the standard for pretty much all games. RTS games were the last holdouts, yet there it also falling. Lockstep is simply used less and less. Let's figure out why, but first what is Lockstep?

So in games we have multiple players playing the game on a client. How do you make sure they are playing the same game? With Lockstep the clients all run the exact same code, with exact same parameters and inputs. If one player orders an army forward that command is issued to every other client and they issue the command to move that army forward. Even the random numbers must be agreed upon and is usually done in form of passing the first seed and executing everything in same order. This is very efficient for networking because only the player inputs must be sent. Things such as orders and build commands take up very little space in the network packet.

Lockstep is an extremely efficient network model, but is hard to code for with desyncs and compiler/multi platform issues. Lockstep was used in the past because network bandwidth was very low. It worked very well for that. Conceptually its is very easy to add to an existing game.

Take DOOM for example the game was already written and everything worked. To add networking all John Carmack had to do was to replay commands on every computer. This sounded very easy in theory, and it worked for DOOM, But as soon as network latency or different architectures come into play everything breaks down. In practice it's hard to code for.

The Programmer must make sure that all actions happen in exact order on every client. What if someone did not receive the command in time? Well, the player who issued the command has to wait for all of the other clients to agree. What happens if someone drops and reconnects? Well most likely they have to re-simulate the entire game from the beginning, which might take a lot of time. See this defining paper on Lockstep in RTS games: 1500 Archers on a 288 Network.

With Lockstep one must make sure that the compiler they use does not optimize the float operation away, because CPUs architectures have slight differences on how the float point unit behaves. This is even worse if you are going to synchronize between say PC and iPad. Different architectures create a nightmare for lockstep. If you are coding with HTML5 — Javascript JIT can optimize your float points paths very differently introducing small errors into the calculations that could lead to huge changes later on. Lockstep programming is like balancing a heavy weight on a knife edge.

If that was not enough, Lockstep has peer to peer connection problems as well. If you are using TCP there is almost nothing you can do to connect two random computer over the internet because of firewalls, NATs, proxies, VPNs … etc. With UDP you can do what is called hole punching. Thankfully the browser has a new system called webRTC that works over UDP and has hole punching built into the protocol through a STUN server that is required. Yay! At least this part can be done with HTML5.

So what is Client-Server? Well it's very simple you connect to the server and it sends you updates. Done. It is how the web works. It is how email works. It is pretty much how everything except BitTorrent and BitCoin work. The server and the client can run totally different code, even written in different languages, different platforms. The server has full authority over the game. There is no knife edge balancing going on. The problem is that it requires more updates to be sent. Because every single unit’s move, bullet fired, health bar change needs to be synced. But thankfully bandwidth for people is increasing, bandwidth is cheaper than programmer time.

The reason why the RTS genre held onto Lockstep for so long was bandwidth. In FPS games moving 32 people around is very easy. In RTS games moving 1000 units around is very bandwidth heavy, but even so bandwidth got better and cheaper phasing out the need for Lockstep.

Server-Client is also more hacker resistant. With Lockstep you can do maphacks — where you basically disable fog of war — because fog of war is client side (client must know about everything to sync up) and also network hacks where the other client knows your IP address and can try to send a bunch of network traffic your way like a min DDOS so that you get extreme lag disconnect or lose. In the Client-Server model you can’t do map hacks (server does not need send you updates on stuff in the fog of war) and you don’t know the players IP address (only the server does). I guess you can DDOS the server, but then everyone gets lag and servers can deal with it better. The server can also be on the lookout for strange client activity.

http://photos.imgix.com/racking-mac-pros Another disadvantage of servers is that they cost money. Running game servers can be quite expensive, while with Lockstep there are no servers — it’s all peer-to-peer. Thankfully cloud providers make it easier to buy, spin up or spin down servers. But if that's still too much for you can run a server locally on one of the clients … it looks almost like Lockstep then … except there is still one authoritative source, and that player pays for bandwidth.

Ease of programming and the falling cost of computers and bandwidth just tip the favor into the Client-Server direction so much, you will see Lockstep used less and less.

See also: