Synchronization

It takes time for information to travel between the client and the server. It takes time for the server to execute commands. During this time, the client has to maintain its display of the virtual world. What it shows may not, therefore, be a true representation of what the server defines to be the current world state: The two aren’t synchronized. In the real world, the sun might have spontaneously exploded 19 seconds ago, but you’re not going to find out for another eight minutes. In a virtual world, someone may have quit four seconds before you loosed an arrow at him.

Lag due to server load can be addressed by buying in faster hardware and by optimizing code. There’s little that can be done about lag due to communications, though. Even with a perfect connection, the speed of light through glass ¹ is such that someone in Sydney playing in a virtual world with servers in San Diego ² would experience a delay of over 0.06 seconds in each direction with a direct cable connection. The fact that their communication has to go through routers and isn’t in a straight line brings it up to more like a third of a second. Throw in an analogue modem and you can add another third of a second. Lag happens.

Designers have to account for this by making nothing too time-sensitive. In a regular computer game, players can be expected to make timed runs through windmill sails or giant steam pistons or pendulum scythes, but in a virtual world there’s no guarantee that when the player sees a gap on their client the server is actually implementing one. For this reason, players can never be called on to make reflex actions (although their characters can be), which means virtual worlds have little or no twitch.

Timed actions are possible, but the window for success needs to be at least four seconds in duration or some players are going to miss it while believing they hit it. Nevertheless, improvements in Internet reliability have led to attempts to bring the kind of response times common in first-person shooters to virtual worlds: Planetside ³ is the best-known pioneer.

Precise timing issues aside, virtual worlds are fairly robust in the face of lag. The exact moment that a player initiates an action is rarely important; when players agree to do something “at the same time,” they know it’s a fuzzy concept. As long as designers avoid doing anything deliberately that requires speed, there’s rarely a problem.

Although most of the lag that players endure is fairly constant across a connection, not all of it is. Sometimes, lag can be intermittent: Things can work fine then suddenly halt for no apparent reason. This kind of lag is actually due to bandwidth issues that cause a service provider to invoke some kind of resource allocation scheme. It doesn’t matter how good your broadband connection is, if your ISP isn’t sending you the packets, then you’re not going to see them. This kind of lag can last several seconds, whereupon all the packets that are buffered up are dispatched at once and service resumes as normal.

Clients expect regular packets of data from the server to update their local state. Most of the time, these arrive in a timely manner. However, it only takes someone using the same router as you to start downloading copious quantities of pornography and packets will inevitably be delayed. What does the client do in such circumstances?

The easiest solution is to do nothing. Just sit and wait until packets arrive, then update them in sequence. The problem with this is that the virtual world effectively freezes for the player until the updates arrive. The player can try to do things, but gets no response until the packets start flowing again. This isn’t always a problem in textual worlds, but it looks very disturbing in graphical ones.

Most graphical clients therefore use a predictive model, whereby they continue moving objects along whatever course they were taking the last time information was available. If a character is running east, the chances are that when an update packet finally arrives it will still have the client running east, so the screen will be right without ever having frozen. Predictive models work well when their predictions are correct, which (fortunately) is most of the time. However, there are problems when they’re wrong. If the character who was running east had stopped and turned north, there could be a serious discrepancy between their actual position and the position the delayed client is displaying them at.

To correct failed predictions, there are two approaches. The traditional way is to use the new information and just forget about the predictions. This results in an effect called warping, which originated in Air Warrior. Players would be on the tail of an enemy plane when suddenly it would disappear from their sights to rematerialize instantly a short distance away like it had made a hyperspace jump. Players even found ways to induce it, so they could plan the reappearance to gain a tactically superior position.

More modern clients apply gradual translations to the displayed position of an object so that it moves to its correct position smoothly (if a little more slowly and still looking highly suspicious).

For designers, this means that not only can’t they use relative time (in three seconds) but they can’t use relative space (dead ahead) either. The client might think a particular co-ordinate is slightly to the left of the player whereas the server knows it’s slightly to the right. Commands that need co-ordinates therefore have to use absolute ones rather than relative ones. Again, when designers are aware of the problem and don’t call for players to follow complex instructions in mazes or anything, virtual worlds are usually sturdy enough to cope; a little error in absolute positioning is fine. They do have to be aware first, though.

There is a special case, however, in that sometimes players want to do things to other players at a distance, for example, shoot an arrow at them. In this situation, not only might the archer’s position be at odds with the server’s definitive version, but so might the target’s. The client knows that the player wants to shoot an arrow at a character, but doesn’t know for sure that character’s co-ordinates. The designer must decide whether the command is “shoot at a target” or “shoot at a location” (which hopefully contains the target). If the arrow has a timed flight (and if it’s modeling a real arrow it certainly ought to), the potential for error increases even more.

Bleah!

Graphical virtual worlds are presented as being continuous. Although characters might actually occupy integral co-ordinates, they are animated such that they move smoothly between them, thereby giving the impression that they at times occupy the spaces “between” the co-ordinates.

Textual worlds can be continuous too, but they are usually contiguous. Locations can represent an area rather than a point, and several characters can occupy such locations ⁴ without causing an anomaly. Restricting horizontal movement to eight compass points means that using relative direction in such virtual worlds is a definite possibility. True to form, there are textual worlds that allow players to use both absolute (north, northeast, east, and so on) and relative (forward, ahead right, right, and so on) directions for movement, with the room description format (absolute or relative) also under player control. Graphical games can take relative co-ordinates from a client, but they have to transmit them as absolute ones.

A common mistake among inexperienced client authors is to take all this with a grain of salt. So what if the client and server have slightly different ideas as to what is where pointing in whatever direction? There isn’t going to be that much divergence. Okay, so maybe occasionally you see someone run through a solid windmill sail because there is a gap on their client, but that’s hardly a show-stopper. Let the client decide if an arrow hits, rather than putting the burden on the server. There might be a few hits that should be misses and misses that should be hits, but it’ll all even out over time.

This brings us neatly to the issue of security.