Contents  Introduction  Conclusion  Printable version  Discuss this article  in the forums

Disclaimer: I am writing this article under the assumption that no one else has written one like it; I certainly have not found one. With all the people writing games today, I'm certain the wheel has been re-invented many times over, so please e-mail me if you find another article exactly like this.

Anyone who develops real-time network games understands the importance of keeping them in apparent synchronization without sacrificing game play. I knew this even before starting my own, at which time I looked around programming forums on the 'net for ways to do this. I was not satisfied with any existing methods. I sat down and stared at the screen for a few hours, on and off, until I came up with a method which I call Targeting.

Targeting is a variation of dead reckoning where a remote player moves about a local player's game instance through persistent interpolation toward an uninterpolating and dynamic position.

In English, this means that another player on your screen will constantly move closer and closer to where that player really claims to be at all times. We don't keep any historic information about where the player has been; nonetheless, the remote player and any projectile he launches can appear to travel in a smooth, unbroken path.

Before we go any further, let's put a picture on the blackboard so you understand why we're doing this. There are three entities in client/server based network games: You, the server, and other players.

Figure 1: The reality of network games; what everyone sees

In this example, you are moving your ship back and forth, left to right. If you watch closely enough, you'll see that the server is a bit lagged behind you, and that the other player is lagged behind the server. If this isn't the case, then you need to refresh the page and/or upgrade your browser :). This is the current reality of network games. The lag is caused by latency, which is the time it takes game data to get from your computer to everyone elses. The server won't know you moved until a short period of time after you really did move. I tend to think of the game as existing in three different "time zones."

Big deal you say? Well, not when you're trying to shoot the alien!

Figure 2: Latency causes the game to go in different directions for each player

According to your instance of the game, you shot the alien right when you were directly in front of it. The thing is, the server can be a thousand miles away, so he won't know you fired until up to several milliseconds later. In some cases, it could be hundreds of milliseconds! By then, the alien will have moved past your ship on his computer! Look above and see what happens.

Ok, so let's force your laser to appear in front of the alien on the server's machine by magically telling him that is where the laser should be. Thats fine, but now look at the game:

Figure 3: Overly compensating for latency makes the game look bad.

The player on the server is thinking: "Uhhhh, where did that laser come from!?," and will then proceed to throw your game away and go play Half-Life Counterstrike.

Next : Conclusion