Devblog 6 : Networking

I wanted my game to be multiplayer from the start.  Easier said than done.  This has made development considerably harder, as networking code is notoriously difficult to implement.  Never mind attempting good networking code.

There were two networking models I considered.  Client-Server or Peer-to-Peer.  They can both be implemented in a variety of ways, but for what I am doing the two options more specifically were an Authoritative Server, or Lockstep.

In a client-server model clients send messages to a server, which does something with them.  In an authoritative client-server more specifically the client only send requests to the server, which makes all the decisions, and then sends orders which the clients must obey.  This design is typical of FPS multiplayer, as it is usually faster.  It sends exact details, like the position of a soldier twenty times a second.

Peer-to-peer models require messages to be sent between all machines involved in a process.  This allows for more precision, but is slower, and harder to get it working properly.  A lockstep system more specifically requires all peers to have exchanged messages with each other, and checked them, before the game is allowed to continue.  Lockstep is a good friend; it will always wait for you.  Authoritative server is a mean girl;  it doesn’t care if you are lagging behind and will not wait.

In the old days all strategy games were lockstep.  This is because it was impossible to rapidly send the exact positions of hundreds of soldiers multiple times every second… given how little data could be transferred over a 56K modem.  Instead peers would send only the commands; select this person, tell them to move there, etc.  But this means that the game must run exactly the same way on every machine, with no tolerance for error.  Implementing a successful lockstep system that doesn’t constantly throw out of sync errors is very hard.

I simply didn’t have the time to do that.  I could however make some sort of authoritarian server.  So I did.  The clients only send player inputs to the server, and the server only sends outputs to the clients.  This clean separation of functionality ensures the server has the final say on every important decision in the game.

There are some exceptions to the rule.  If a player selects soldiers, for example, they expect their user interface to respond immediately.  In cases like this the client is afforded the rare opportunity to send an input and execute its outcome without waiting for the server’s approval.

So far I have implemented networking functionality for almost all of the game’s features.  I have also created a lobby system, allowing players to direct connect to games on their LAN or across the internet.  They can press a button to automatically find any LAN games too.  When in the lobby players can choose their colour, team, and say when they are ready.  Only when all players are ready can the host choose to start the game.  The game waits for all players to load the game scene, then begins play.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s