Sign in to follow this  
Oogst

Article on core network structures for games

Recommended Posts

I have written an article on the core network structures that are used in games today (as far as I know) and which we use in our game Awesomenauts. I figured this might be interesting to people. smile.png
 
Here's a short summary:
-Client/server: one player decides everything, the other players send him their actions and he updates them on the gamestate. Lots of work to keep controls from getting laggy.
-Dedicated server: same as above, but the server is not a player but a company-owned computer. Benefit is that the server always has good internet and cannot be hacked. Downside is that it is expensive and requires pro server architecture if you are expecting lots of players.
-Peer to peer: each player manages part of the simulation. No input lag if each player manages his own character, but everyone needs to communicate with everyone causing lots of traffic (Awesomenauts uses this).
-Deterministic peer to peer lockstep: each player simulates the game in exactly the same way. Only need to send player actions (extremely small) but controls are laggy. This requires complex coding tricks to keep the simulation exactly the same. RTS games use this since it allows enormous unit counts with hardly any bandwidth usage.
 
Here's the complete article:
 
 
Network%20architecture%20-%20Structure.g

Share this post


Link to post
Share on other sites
Note that "deterministic lockstep" can be used with any of the above suggested topologies.
In fact, well-known deterministic-based games like Starcraft generally use client/server rather than peer-to-peer.
You may also want to break out the two different phases: "Setup / matchmaking" and "actual game."
It's often the case that you need a hosted server of some sort for the matchmaking (and NAT punch-through) part, even if you then let the players run the game servers.

Share this post


Link to post
Share on other sites

Would deterministic lockstep in combination with client/server not add additional latency? Each client needs to know the inputs of all clients to perform a step, so doing this client/server means sending to the server and then having the server send to the other clients.

 

By the way, how do games handle determinism in combination with hiding the complete gamestate from cheaters? Do they synch units that come into view and then lockstep those, and only send the commands needed for what each user can actually see?

 

I was only talking about the gameplay synching here. Matchmaking is indeed a completely different topic, having completely different requirements. I intend to write about matchmaking as well in the future, as we have gone through several implementations on a bunch of different platforms now. :)

Share this post


Link to post
Share on other sites

Would deterministic lockstep in combination with client/server not add additional latency


Yes, Client/Server adds one additional hop of latency compared to peer-to-peer. This is true no matter what the game simulation approach. For most games, it turns out that this additional step is not actually as important as everything else that goes into a networked game, though.

how do games handle determinism in combination with hiding the complete gamestate from cheaters? Do they synch units that come into view and then lockstep those, and only send the commands needed for what each user can actually see?


There are many cases where "partial lockstep" ends up failing. (In fact, I helped build such as system, with client simulate-ahead to hide latency, in the very early 2000's.) Typical games do not only do partial lock-step, but instead use other mechanisms to catch cheaters.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this