I'm currently working on a multiplayer game with top-down camera view and WASD player control, similar to Bloodline Champions. Projectiles, spawned by players are relatively slow and clearly visible, e.g. a fireball. The most difficult part so far - designing an appropriate networking model. The main goal is to find a fair balance between state consistency and player input lag.
Three alternatives I've came with so far are as follows:

Plain Authoritative server
Clients simply send user input to server, which advances the world according to the input provided, and then sends the latest state to all clients. Clients interpolate between two last received states to provide smooth movement.
This variant provides perfect consistency, since all clients see the same world state, but user's input feedback time suffers a lot, because total lag sums from the following parts:

  1. Sample lag = T(client sends sampled command) - T(command was sampled)
  2. Client-Server lag = T(packet was received by server) - T(packet was sent by client)
  3. Simulation lag = T(command was simulated by server) - T(command was received by server)
  4. Replication lag = T(state was sent by server) - T(command was simulated by server)
  5. Server-Client lag = T(state was received by client) - T(state was sent by server)
  6. Interpolation lag = time interval between two states: the last received and the one received before that, so that client can interpolate between them ~ server send interval

Authoritative server with Prediction
To minimize player feedback lag, client code has to use some prediction, i.e. execute sampled commands before updated state is received from server. The drawback here is that it creates state inconsistency between entity controlled by the player and the rest of the world, since the former is in the present and the later is in the past.
First person games with instant-hit weapons can use some lag compensation algorithms, since the player sees only some portion of his or her surrounding and most of the time does not sees bullets. But in top-down viewed games with slowly moving visible projectiles, those correction can be considered as unfair and buggy.

Thus, with authoritative server we have to choose between better state consistency and smaller input lag.

Peer-to-peer with server
The only other solution I can come with is where client broadcasts sampled commands to other clients and server, but instead of immediately executing them, client delays them at a constant amount of time, e.g. 150ms.
Other peers (including server) do not execute received commands immediately either. Each peer computes time, that is left until 150ms and waits that time:

time_to_wait = 150 - (peer_received_time - client_sent_time)  

Thus, every command is, theoretically, executed simultaneously on every peer, which provides good state consistency and moderate input lag. To address possible unsync, server periodically sends its state to all clients.
Problems with this solutions include:

  • much more complicated code base.
  • much more cheating-prone client, since it contains the same logic as the server.
  • all players' IPs are exposed to all others.

I tried to find any info about BLC or LoL net models, but all I've found so far is that they use client-server architecture without any P2P communications.
I personally prefer the Auth-with-prediction variant, but have to stick with P2P one for now, since I have no idea how to solve inconsistency caused by prediction. Is there any way to compensate this inconsistency without increasing input lag too much, or I have to use P2P solution?


closed as unclear what you're asking by Anko, Trevor Powell, Kromster, Josh Jan 6 '15 at 18:17

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ The only question I can see is at the end and it seems to be essentially "how do I implement client-side prediction". Is that your question? \$\endgroup\$ – Anko Jan 4 '15 at 2:38