There's a bunch of different ways of mitigating the effects of latency in online games. Everyone who has tried to make a networked game knows how it feels to be testing and running your game locally, where everything is smooth and crisp and instant, only to be tremendously disappointed when you go to play that inaugural multiplayer match and your enemy is skipping so fast you can't even follow him. With the Invasion Engine being built from the ground up as a networked game (even single player matches are actually connections to a local server) solving the issue of lag is very, very important. Having just finished the first successful test of our system for doing so, I'd like to talk a little about it. If you've ever been interested in how games like Half-life 2 (and all the Source engine games) counter lag, or if you're struggling with this same problem in your own project, read on.

Lag, as any gamer knows it, is the effect of objects randomly altering positions, orientations, or velocity during a game where the latency (travel time for packets) is high. This effect is caused because the server's simulation cannot be instantly and entirely replicated on the clients. The information must be sent piece by piece, and those pieces are slow, sometime arriving out of order or not at all.

So, games have mechanisms for dealing with latency. These usually involve having the client attempt to predict what will happen in response to user input, so it can be displayed instantly. These simulations work most of the time, but inevitably something that the clients can't predict (say, another player suddenly hitting the local player) will occur and the simulation will be invalid. As soon as that packet arrives, the simulation will snap to the "correct" configuration. That can be both disorienting and ugly. The solution that the Invasion Engine is using, in the company of other great engines (like Source, as I said above) is called Trailing State Synchronization (TSS). This is a bit of a hard concept to understand, so I'll go ahead and draw it out:

Allow me to explain. On this graph, time advances horizontally to the right, with each vertical bar representing a single "tick." The vertical axis represents some parameter that needs to be smoothly synchronized over the network - say, the position of an object.

The thick green line represents the position of the object in question at the given time. As you can see, it's moving back and forward in a somewhat unpredictable manner. Every tick, the server looks at the position of this object and sends it to the client. Some time later, that packet (indicating both position and direction, in this case) arrives at the client as indicated by the bright, thick red dashes. If we were to stop here, and attempt to predict the position of this object based on simple physics and snap to the correct configuration upon the arrival of the next packet, we would get a movement on the client that looks like the thin dark blue line. Hardly a realistic impression of the dark green line.

This is where Trailing State Synchronization comes in. Instead of immediately adjusting the position, the client waits a short amount of time, enough to get another packet or two. Now that we have two or three packets in a buffer (the darker red dashes), we generate a smooth connection between them and use that smoothed line (the teal/cyan line) to position the object. As you can see, since the client's display is intentionally slightly behind the server's, we know just enough about the "future" to plot a smooth path that matches the original almost exactly.

Of course, there are still a few problems, like how you account for objects like the player that needs to be very responsive or what happens when there's so much lag (either latency or dropped packets) that the buffer is empty. Unfortunately, there's no magic bullet for this sort of thing, and even in our engine I foresee a lot of tweaking of the tick rate and the trail time, along with handling of special exceptions.

Different games will be able to take advantage of different kinds of prediction. It all depends on how much you can trust your clients and what kind of data you need to exchange. A first person shooter has much more data to send than, say, a real time strategy game. They also have to do things like account for player's actions themselves being delayed on their trip to the server. TSS is a great solution for problems that warrant it, and I haven't been able to find much about it for independent developers online; I hope this article helps someone. If you have any questions, feel free to reply to this post or shoot me an email.

~Karantza