Implementing network lag compensation is hard, how to avoid it?

Maybe it's possible to use tricks and build game mechanics in such a way that lag would be percieved as a non critical or even as a natural part of game?

What are those technics and is there any existing games (MMORPG, Strategies, ...) that uses such technics?


Turn based games don't require lag compensation, but it would be interesting to see approaches for real-time (or just an impression of real-time, the important part - user shouldn't be blocked and forced to wait).

The main reason for me to avoid lag compensation is simplicity.

  • 1
    \$\begingroup\$ This link could help: developer.valvesoftware.com/wiki/Source_Multiplayer_Networking \$\endgroup\$ Feb 6, 2013 at 20:44
  • 6
    \$\begingroup\$ If you're looking to build a game where latency is a non-issue; consider building something that is turn based where a few seconds is acceptable. \$\endgroup\$ Feb 6, 2013 at 20:46
  • 3
    \$\begingroup\$ That Valve link is all about the fairly complex ways in which network lag compensation is implemented - so, it's the opposite of what the question asks about. \$\endgroup\$
    – Kylotan
    Feb 6, 2013 at 20:47
  • \$\begingroup\$ @JohnMcDonald Yep, I know about that article from Valve, and as it mentioned - it's the opposite of what I'm asking :). \$\endgroup\$
    – Alex Craft
    Feb 6, 2013 at 22:43
  • \$\begingroup\$ You might want to take a look at GGPO as well: ggpo.net \$\endgroup\$
    – Decency
    Feb 11, 2013 at 17:16

5 Answers 5


It's common for the client to implement some sort of feedback to let the player know immediately that their chosen action has been registered, eg.:

  • interface sound (eg. button click)
  • in-world sound (eg. a character saying, "At once, commander")
  • animation (eg. begin swinging a sword)

These can take place while the information is travelling to the server so the player doesn't realise that their action has not started yet. As long as the server replies promptly and the action does begin soon, the player may not notice the delay.

These tricks work in games where player inputs are fairly infrequent and therefore the amount of time you spend waiting for an input to take effect is a relatively small proportion of the total time spent playing. Therefore, you would want to find ways to structure the game so that the player makes fewer inputs. This probably means making player actions more abstract and having the game implement the low level behaviour. Examples:

  • replace steering mechanics with pathing mechanics
  • replace aiming mechanics with target selection mechanics
  • replace round-by-round combat instructions with more tactical or strategic plans
  • replace real time/continuous gameplay with discrete/turn-based systems
  • 1
    \$\begingroup\$ Thanks, You formalize what I'm asked about - use infrequent, deferred inputs from player. Would be interesting to see the actual games that use that. \$\endgroup\$
    – Alex Craft
    Feb 6, 2013 at 22:58
  • 2
    \$\begingroup\$ Hundreds of games use things like this in some way, but most likely it was done for other reasons with lag-hiding a beneficial side-effect. \$\endgroup\$
    – Kylotan
    Feb 6, 2013 at 23:18

Random thoughts:

  1. cheat: use rockets. Rockets explode in a radius, hiding any weirdness.
  2. cheat: predetermine the outcome and force the condition to happen visually
  3. cheat: attacks take time, hide latency in the atk+anim+result discontinuity
  4. cheat: disconnect local feedback from the networking stuff
  5. cheat: lots of VFX or screen activity that covers any weirdness.
  6. use an action-reaction design that requires resolution before continuing

So yeah, cheat a lot.


The answer is quite simple - just build games that don't have time critical sections. You're looking to avoid implementing these types of interpolations for a specific reason I take it, which means you're not concerned about twitchy and fast gameplay. This is perfectly accetpable for a lot of games, including Civilization (which is a strategy game). However, understand this is NOT acceptable for a REAL TIME strategy game where you need to be passing a lot of data over the network at variable timings. If you'd like to design a game around a very high latency network, consider the following:

  1. Build turn based games. In these types of games, real-time input of the state isn't needed and the other player can simply push the state of the game into their client when it's their turn. This reduces pressure on the network and allows delays upwards of even a few seconds if one so desires. Civilization is a turned based game which is very popular, and in the strategy vein.
  2. Keep the other players decisions impact to a minimum. If your game is strategic and can't play turn based, consider reducing the impact of delayed packets. Can the client does most of the simulation? An example is a strategy game that is played alone for a while and then after say, 16 minutes, is simulated against another player (perhaps a combat game where players send in troops every x interval and report back every y interval.

I hope this helps at least a bit; without knowing your exact game ideas it's difficult. I assume you have your reasons for wanting to create your game around such a pattern (simplicity, saving on bandwidth, reduced network complexity)


You could also make lag be part of your gameplay for "realism" sake. Say your players are meant to control some robots from a distance, you could force the lag to be at least 500ms or 1s (you'd have to implement some dynamic lag padding system).

  • \$\begingroup\$ This is a nice twist \$\endgroup\$
    – o0'.
    Feb 11, 2013 at 18:18

It is also a nice trick to simply hide the actions of players. A lot of FPS games do exactly this. They do not show any visuals of most of the bullets only sounds are played and you get the outcome in the form of damage dealt to players.

I have played some FPS games where high accuracy weapons (snipers and such) had very clear visual effects, and you could actually see that the other player shot behind you, but because of lag compensation you were killed.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .