One of the most irritating manifestations of network latency is jitter, which occurs when latency is not constant, but fluctuating. In essence, jitter results from some—but not necessarily all—data being delayed. What’s more, the length of time by which the data is delayed will usually vary, meaning it cannot be accurately predicted. Jitter can also stem from packet loss (e.g., video jitter in UDP), which creates holes in the incoming data screen. If this is vital data that has a direct consequence in the game, the result will be more than just an uneven experience. Moreover, the causes of jitter will negatively affect attempts at packet serialization, where packets are given serial numbers in an attempt to thwart hackers (see Chapter 8). This is compounded when packets arrive out of order or if the system throws them out because of the effects of jitter.

Some symptoms of jitter are evident on the players’ side. For one, jitter prevents players from predicting movement accurately. If the movement data relating to other artifacts in the system is inconsistently delivered, the resulting movement will be similarly inconsistent. This will quite likely destroy an FPS, because players simply will not be able to exert the same amount of control over their in-game personae as before. Even if local movement is crisp and responsive, the game environment and other players’ avatars will seem to move in an entirely unpredictable fashion.

All this is to say that jitter poses serious problems for high-speed precision skill games, such as driving-based games (Burnout) and one-on-one fighting games (Street Fighter IV). The fact that both of these games have central network gaming components implies that the issues relating to jitter are not insurmountable. Note, however, that network jitter has next to no discernable effect on the playability of Web strategy games. It can be mildly annoying, however, in text-based MUDs, in that screen updates sometimes fly off the visible area of the screen. On the whole, though, this is not a big issue.

Lag, a term that was coined in the 1990s to describe a general slowdown of the entire game environment, is a symptom of more or less constant (within a given time frame) latency. Because it is constant, it is less annoying for both programmers and players than jitter. It can also be predicted to a certain extent—or at least recognized by the game engine and corrected for.

Although it is less annoying and more predictable than jitter, lag can render a game unplayable if many different players have different levels of lag—meaning something must be done to mitigate it. This book looks at some ways to minimize the impact of lag issue in the upcoming section titled “Solutions to Network Latency Problems,” but it is worth taking a moment here to explain the problem more fully.

What happens is this: The client on machine A updates in such a way that the player appears to be much farther away when his or her avatar starts moving as compared to the view of the same scene from the client on machine B. This is caused by the uneven reaction time. Luckily, in this simple case, the machines themselves can compensate quite easily through the clever use of status messages and minimization of data in transit, the aim of these measures being to enable fast updates when they’re needed. There will, however, be a point at which the system breaks down—specifically, when the machines must adjust to the slowest speed of the system connected.

This issue is the subject of research studies [NETGAMES01], which attempt to gauge the effect on playability when clients update at different times due to lag caused by latency. One such study notes that the point at which a game such as EverQuest2 becomes unplayable is when latency exists in excess of 1250ms. Up to this 1.25-second delay, however, there is quite a lot of room for machines to compensate locally for any network deficiencies. But of course, such maneuvering will involve a compromise between quality of experience versus security (see Chapter 8). That is, the more logic you put on the client side to enable it to make decisions on its own, the more scope there will be for foul play. For example, if a machine is tasked with relaying the result of any local decisions back to the server, the game is put at risk from the interception and subsequent alteration of status messages.

Game designers and developers program in a loop fashion, with the following types:

Each of these loops operates continuously. The input loop does so on an interrupt basis, waiting for feedback from the player via the man machine interface (MMI). The logic loop processes all the game logic, possibly on an interrupt basis, as well as performing a general monitoring function. The rendering loop ensures that those areas that need to be repainted are, and that the sound (spatial sound, background music, sound effects, etc.) is correctly overlaid with respect to the state of the immediate game environment. Normally, these three types of loops (although there may be more) are placed in separate threads, enabling the processor to try to farm out the processing in time slices in order to get everything done more efficiently and thereby improve the experience for the player.

Note

Chapter 10 looks at network programming in more detail.

In addition to these, we must also create a network loop—both on the client and server sides—that operates on an interrupt basis for incoming connections and data, but on a regular basis for outgoing data. In addition, this loop is as important—if not more so—than regular player interaction, so this must be worked into the time-slicing algorithm that farms out work to the processor.

Note

There are different algorithms for devoting time to various tasks based on their importance, available time slices, and other dynamic factors. All in all, the scheduling operates to make sure that everything gets done in such a way as to provide a consistent gaming experience.

The emphasis is slightly different for the client and server implementations (assuming that you are eschewing the capability to allow clients to contact each other directly). For the client, there is communication with only a single entity—the server—in the client/server topography being used. This enables you to incorporate into the network layer design a blocking socket call—which blocks until there is data to be read, and is ignored by the system until data is available—thereby releasing CPU cycles back to the system. (The alternative is to have the thread waste cycles in a busy-waiting loop, awaiting data. Even if the system operates on a time-slicing basis, it would still mean that for the whole time-slice, the network thread would effectively be doing nothing.)

In contrast, this would precipitate a disaster on the server side; the system cannot afford to block a socket when there might be data coming in from another socket. Because clients might be trying to send data to the server, it needs to have a thread that can poll multiple sockets but not block on any of them. This is the fundamental difference (with respect to network communications) between the client and the server.

This, then, is the first rule in improving network communications: Never waste time on a socket that has no incoming data—but do not use blocking sockets where multiple sockets are to be used.

Note

This is also the case for replicated models, where each client has to multicast data to all other points in the game network. In such cases, each client is also a server, as it has to be in a position to both send data to multiple points and receive data from multiple points.

The interplay between the client input, network input and output, and game logic threads is the determining factor in overall system latency, manifested though the perceived reaction time of the game to the player’s input, other players’ actions, and the network component. Other game-development books cover these issues more completely; here, we are concerned only with the latter part—the network component. Experimentation and testing are the only ways that the developer can determine the best way to hook all the processing points together and facilitate communication between them at the game-code level.

Improving network communications begins with choosing the best protocol—TCP or UDP—for the tasks that need to be carried out. As mentioned, different data-exchange requirements can take advantage of the different mechanisms used by TCP and UDP with respect to data delivery. That said, these protocols also share some key similarities—most notably the need to reduce bandwidth usage to the extent that it is possible. After all, both use the same underlying physical technology—a wire—to transfer data. And clearly, the less data you need to push around the network, the better.

Data comes in two flavors:

One approach is to blend the use of UDP and TCP to make good use of available bandwidth—but care should be taken to ensure that the appropriate data is put in the appropriate protocol. On the one hand, vital data that would introduce latency into the system if it were lacking should be delivered via TCP, but the volume should be reduced. Data that is not so critical can be delivered via UDP—but if it has to be synchronized, then it is better to reduce the volume as much as possible in order to use less bandwidth and reduce processing overhead in correcting the transmission errors.

In addition to reducing bandwidth, it’s a good idea to cache large data repositories such as level files and images. This is rather like a Web browser storing image files for later use; resources that are loaded frequently and do not change often are ideal targets for caching in networked video games. This can be done either as needed or at the start of the game session. In the first instance, the resources are delivered in-line via spare capacity in the data exchange so that they are available when needed. In the second, the user must actively download them (as was the mechanism used in Unreal Tournament) in order to have the correct shapes, sounds, level files, and graphics available at the start of the play session.

Another way to reduce bandwidth is to allow clients to take responsibility for some of the processing. In this way, they relay only the result of that processing, rather than every possible state change, back to the server.

Because state changes result from interactions between the player and the game—as well as other players and artifacts within the game environment—the processing of the game rules is outsourced to the collective clients. Earlier, this chapter covered an extreme example of this in its discussion of the distributed homogeneous topography. That model was deemed too high risk, but if each client is (separately) also calculating cause and effect, then the server could validate the decisions by comparison. This would be far quicker than calculating cause and effect itself, would reduce data transmission, and would offer a more robust solution with respect to possible cheating than the alternative.

One easy example is the aforementioned bullet fired within the game environment, provided by Jason Leigh [LEIGH01]. The message sent to update the clients simply relays the state change of the bullet. It is up to the clients to figure out for themselves who has been hit. In addition, they should play a role in computing how the bullet should fly and then relaying to everyone else the end effect—not the state changes, nor the position at a given time in their local rendering of the game environment, but the end result: hit or miss. In this way, we a) don’t have to relay more data than is necessary, and b) don’t have to wait for the data before showing the action to the player. This avoids the flooding of the network by state messages and also helps mitigate any natural latency or jitter in the system.

You should be aware, however, that this approach opens up possibilities for people to interfere with the game-client processing. For example, they might claim that the bullet hasn’t hit anyone—when in fact it has—by intercepting the message and changing the status information. Feasibly, this could be achieved without other players being aware of it, as their system will simply render the data that has been provided to them. Until the bullet disappears in thin air, nobody will notice that there is something amiss.

All this is just another way of saying that as a game developer, you must find a balance between security and performance.

To understand how you can avoid latency, you need also to understand that network processing often employs buffers. A buffer is simply a place where data is stored before it is processed (either somewhere over the network or by the gaming client).

Systems generally have input buffers, where data is stored before processing, and output buffers, which need to be filled before the data is sent. The output buffer is also used to queue data in the event that the network beyond becomes saturated. In times of low traffic, the buffer can then be emptied, allowing the system to catch up.

Ideally, the interplay between these two buffers enables the system in the middle (be it a network or a processor) to be balanced such that it is always operating at maximum saturation when there is data to be processed. That means filling and emptying the buffers in an organized fashion, allowing just enough slack to be robust. (The slack is used to stock the buffer in the event the processor or network becomes saturated and has to take a brief time-out.) If an input buffer is not emptied quickly enough (i.e., the client is slow to process), then data will be lost. In essence, because the buffer is full, there is nowhere to put incoming packets, and as a result they will be dropped, causing data loss. If, on the other hand, the output transmission fails for some reason, preventing packets from being sent quickly enough (at the server), then the output buffers will also fill up. In this case, packets will be dropped unless you provide a solution for this on the server (see the section “Rate Adjustment Strategies” later in this chapter)—namely, backing up the system and making sure that no additional data is generated. This will potentially cause the gaming system to visibly pause—one of the worst effects of latency.

A network is also composed of various routers, firewalls, bridges, and so forth that deal with ongoing network transmission—commonly network transmission that you can’t control. Worse still, you have no interfaces at your disposal that would allow you to adapt to the situation. Moreover, these devices also use buffers—and these buffers have the same limitations as described above. Packets are dropped because flow is interrupted by poor performance, either locally or remotely. Quite often, simply being in the middle of the flow is what causes packets to be dropped as buffers fill up.

This has a feedback effect in TCP networks because on the one hand, they try to retransmit to guarantee delivery, and on the other, devices using the TCP protocol will reduce transmission rates to try to reduce congestion. The net effect is that latency increases artificially—in addition to the natural network latency that exists. In contrast, in a situation involving high latency—with buffers filling up and packets dropping everywhere—UDP will not attempt to correct for it. It simply allows the data to drop into the ether, expecting the software application using the protocol to correct for missing data.

Note

In these cases, TCP is almost too smart; such occurrences of packet loss and latency can actually be a good argument for not using it as a network protocol. Indeed, most video-transmission packages use UDP and live with the data loss rather than use TCP and experience high levels of latency.

With large volumes of data, this might be a viable approach—as long as there is (as with some video transmissions) a high level of redundancy. If, however, there is a relatively low level of redundancy, and a high quantity of significant data, then this approach may not work.

Either way, a good solution is to control the rate of sending to try to minimize—or at least learn to live with—the effects of latency and packet loss on the network game infrastructure. This can be done at the client and on the server.

Rate adjustment simply involves changing the rate at which data is sent or received (or even requested). This can be a dynamic operation, with the rate being changed as the network components sense shifts in the state of their communications conduits, or it can be a set-and-forget option at the start of the transmission session. Clearly, the latter approach could lead to issues with latency and buffer overflow during the session, while dynamically changing the transfer rates can help to provide a more even experience.

Note

Rate adjustment is common in many streaming applications; these enjoy the most benefits from rate adjustment because they tend to use the most bandwidth.

Rate adjustment occurs on two fronts:

Rate adjustment may also be necessary at the client side in cases where the server-side buffers are filling up too quickly. This can happen because the server has too much to do (too many clients) or because the onward transmission is much slower than the incoming rate of data reception. In such cases, communication between clients and server is vital to synchronize the data-exchange rate as well as to make sure that every client cuts its data-transfer rate as required. The result is a network-wide agreed (or negotiated) data-transfer rate that keeps all parties in sync without exposing the player to latency, lag, or jitter.

As a last resort, you can always send less data, less often. The result is not faster data transfer, as is the case with non–stream based data exchanges like status information, but actually transferring less data. While it means different things to different applications, this approach can lead to holes in the transmission. For example, in a streamed application, a lower data-transmission rate usually means a lower-quality result. This can mean something relatively benign, such as lower-quality sound or video, or something quite profound, such as jittery in-game movement. It really is a last resort, and is to be avoided as much as possible.

That said, because this approach is desirable due to its speed and efficiency, to improve on both, you could try to make sure that each piece of data to be transferred is smaller. One approach is to strip out all the extraneous data and make for a more efficient exchange of information—hopefully without any loss of quality or integrity. That’s what the next section is all about.

As useful as prediction is, it does pose certain problems, such as, What happens if the player does something unexpected? If, for example, the player is moving in a given direction but suddenly stops moving and starts hacking away with a sword at another in-game entity, you need to make sure that this new behavioral trajectory is correctly relayed.

There are two sides to this. One, the player has stopped moving. Two, the entity at which the player is hacking away probably also stopped moving. If the other system reacts too slowly, then the observed player may no longer be in the correct place at the correct time to effect the new actions.

So how does the system (as a whole) catch up with this sequence of events? Obviously, the first thing is to make sure that the game environment views never diverge too much from each other. That means reeling in the freedom that clients have to maintain their own world view a little bit. This, however, has serious implications with respect to security. For example, if you give too much decision-making power to distributed clients, that decision making might become susceptible to tampering.

For Web games, this not a problem, as no decisions are made in browser. Rather, all decisions are made on the server; the client simply renders them. So even if you need to smooth out the data flow in some way with local (JavaScript) logic to combat lag or jitter, you can’t affect the outcome of the game. The same goes for other client/server games based on dumb clients (i.e., MUDs). That means the only thing you need to worry about here is reflex based. That is, there is the possibility that an automated player could be made to play faster than a human. (We’ll deal with in Chapter 8.) If, however, a smart client is introduced, where some of the logic is implemented on the local system (for example, a shrink-wrapped MMORPG like Everquest), then you start to encounter serious problems. In resolving issues relating to jitter (and/or lag), you run the risk of introducing a security loophole that makes it possible for players to circumvent game rules.

The scenario runs something like this: In trying to ensure that jitter is almost undetectable by players, you let the gameplay out on several clients simultaneously. That means local clients take input from their human player and pass the status and consequences of that input back to the main server. (This was the approach taken in many multi-player strategy games, such as Age of Empires.) Any unexpected in-game moves can be priority-posted along with the consequences, and each copy of the game environment can be checkpointed using a variety of methods (explored in a moment) to make sure that they stay in sync. But what happens if a rogue player intervenes to relay false or augmented information to the main server? Examples might include a sword doing 10 times more damage than it ought to or a strategy game posting inflated resource figures after a certain period of time has elapsed. Once the inflated resources have been passed to the other game clients, the player will be able to do things that he or she ought not to be able to do—things that will allow him or her to overtake the other players in an unfair manner. This makes proper synchronization with respect to the server and other game clients an absolute necessity.

Synchronization involves checkpointing game-environment representations in order to keep all copies of the game environment in sync, even as updates based on decisions made in a distributed fashion are being posted. The checkpointing approach is designed simply to make sure that, at a discrete moment in time, all clients have the same snapshot of the game environment. This allows the clients to be sure that their predictions are true or at least that they can be corrected with real data so that they do not stray too far from reality.

Of course, one thing you need to be sure of is that no one has interfered with the data—which is very tricky. You can avoid packet insertion by following the guidelines in Chapter 8 in general. But what happens when you’ve just lost the plot and want to update?

Let’s look at these in turn. Packet insertion occurs when a client has been modified—or augmented with additional software—to introduce data that should not be there. That data is then forwarded to all clients, thereby changing the way they perceive the game environment and the status of the sending client. Once replicated through the system, it becomes the “truth.”

Checkpointing helps to stymie this cheat attempt. Its power is limited on its own, but when combined with other techniques on the server, all can help minimize the impact of packet insertion by offering a kind of centralized analysis of all client data and a decision as to who is correct (the majority carries the vote). That means if there is a client that has lost the plot and needs a quick refresh, rather than going to potentially corrupted clients, they now have the option of going to the server.

There’s another reason for this too—especially for those who choose UDP for data transmission. Protocols like UDP have no mechanism for ordering data reception. That means each packet must be synchronized using a number that indicates the age of the packet so that older ones can be thrown away if they arrive out of sequence.

So, if you’re trying to correct prediction on the fly, and the packets arrive in the wrong sequence, it will likely make a bad situation worse, unless these steps are taken to rearrange the data as it is received.

You should also implement synchronization detection by the server and other clients. This is as much to enable them to get back into sync as it is to make sure that the data stream still has integrity. It is the server that bears the ultimate responsibility, as it is the only entity that has overall control—not to mention the fact that it is the only part of the system that is more or less guaranteed not to have been tampered with.

Queuing events—a technique frequently used by MMORPGs (such as Everquest)—can help solve a few issues relating to efficiency (and jitter), security, and prediction (although it is, of course, not appropriate for all kinds of games). The phrase “queuing events” doesn’t mean holding up events before relaying them to the client, but rather refers to players being able to queue up events that take a certain length of time to play out. These events are queued on the server, probably one by one, and then passed, as a queue, to the client software. If you assume that the efficiency by which packets are to be transferred does not depend on their size, this approach makes sense, in that it sends as much data as possible at once. With respect to resolving issues relating to prediction, queuing events helps because the discrete wishes of the players can be relayed to the clients ahead of time—like a kind of action buffer that removes the necessity to try to keep up with fast-paced action. The result is that each client can play out the actions in its own time, as long as these buffers are kept fresh—and since they likely contain much less data than a complete environment update or sequence of discrete actions, this shouldn’t be a problem.

This mechanism can be taken to another level by enabling the game system to also queue up events—as long as there is a way to take them out if the AI controlling the queuing changes its mind. This might even be used as a mechanism to return some of the logic processing to the server by allowing it some breathing space as the clients execute the queues of events attached to system-controlled in-game entities.

Of course, the client must make sure that the queue is invisible to the opposing player; otherwise, he or she might be able to cheat by knowing what is coming next. Also, if the data in the queue is delayed for any reason, the other clients will run into problems.

With TCP/IP, if one packet is dropped, the whole connection tends to time-out—which is why, on occasion, a Web page will fail to load initially but, when refreshed, loads correctly. This same refresh mechanism can be used to re-establish connections and data streams in a networked video game using TCP/IP. In that case, however, the data will be lost forever because, unlike a Web page, the game environment is in a constant state of flux. UDP, on the other hand, is connectionless—in other words, each collection of packets is sent in isolation, and there is no need to even keep the connection alive between the sending of data. Furthermore, there is no guarantee for data delivery; therefore, the application itself is responsible for detecting dropped packets, which then become a fact of life.

Out-of-sequence packets are the first indicator of data loss. This is not to say that the packets arrive out of order (which, too, might also be an indication); it’s more that there is a visible gap in the packets that arrive. This will be noted, however, only if the detection mechanism is built in to the network-processing logic of the game. Other indicators of data loss can be built into the protocol, such as detection of smaller-than-anticipated packets—for example, where the data header says that there should be 128 bytes, but only 64 are received.

Using some kind of serialization or numbering scheme to validate the stream of incoming data packets is a necessary precaution for UDP, but technically not required for TCP (at least as far as data reception is concerned). That said, serializing the packet streams for TCP is one way to make sure that the data stream maintains integrity, guaranteeing that the data is received as the sending client intended. By extension, you can therefore detect whether there is any data missing in the stream over and above any of the support for this that is built into the protocol. This is important because the client might send the data out in good faith, only for it to be tampered with by the network portion of the system (either inadvertently or maliciously). The underlying protocol might not be able to tell the difference, but the game should be able to detect this and take action.

Note

Dealing with data loss goes hand in hand with detecting data injection, as the two are sides of the same coin. Data injection is at the core of many of the examples of cheating that you will read about in Chapter 8.

If you think back to the example of the car traveling in a straight line, you’ll remember that everything works right up until the player does something unexpected. This action (or the result of it) is first shown on their screen, after which it is supposed to be relayed to the server. If, for some reason, it is not relayed to the server, the result is that other players do not see the cause—just the effect. The data loss makes the action invisible, because the systems have synchronized to prevent the game-environment views from deviating from each other. The end result is that it just looks bad—in the worst case, as if the other player is cheating—which does not reflect well on the game.

Let’s assume, for example, that the car is racing along, but takes a small diversion to pick up a power-up present on the road (like the power-ups in Mario Cart or WipeOut). From his own point of view, the local player jigs to one side and picks up the power-up. If this is not relayed to the server because of data loss, however, then a strange phenomenon will occur, the effect being that on the player’s system, the object is no longer there, but for the other systems, it is. It is as if the player hasn’t taken the object. This may result in one of the following (as viewed by remote player’s systems):

Unfortunately, having chosen an update model that farms out the logic to the remote systems, the game designer can do nothing to prevent the object from disappearing or being duplicated. All he or she can do is make sure that the third outcome never happens, as it represents the worst-case scenario. Systems should never need to be reset because they are unable to sync themselves.

Note

Of course, the worst hit will be action games. That’s because in action games, maintaining the flow of action is usually crucial. This is also critical in strategy games that use data in the same way as an action game would.

In the most basic case, missing data can be treated as infinitely delayed data—that is, you can simply hope that the problem will resolve itself. This approach will work for non-action games—but at what point does the game decide that the data is really lost, and that the game has to take action? Some turn-based games, for example, use a counter to count down the rest of the players’ moves based on the first to move (this is the Civilization approach). They also need an internal counter to make sure the connection is still alive, and that the connections can be polled to ensure that every client is still alive.

This polling approach helps in two ways: First, it helps prevent data loss. Second, it makes sure that the players are all still connected, even when they fall silent and no longer actively post actions. This might, at first glance, seem to violate the principles of keeping the data in transit as light as possible and avoiding noisy network communications layers. But it is actually vital in games where there may be substantial gaps in the natural communication between clients and the server. It is also vital for managing games that need to combat dropped connections.

An unintentional dropped connection occurs when, through no fault of the user, the connection becomes temporarily unusable. Once a connection is lost—hopefully unintentionally—the server has several choices, depending on the authorization architecture. The general idea is to re-establish the connection as transparently as possible, depending on the level at which the connection was dropped.

Note

Clearly, if a hardware failure that could lead to security issues caused the dropped connection, then re-establishing the connection is not going to be possible.

Some games store authorization data and can automatically re–log on the player. Indeed, the player might not even notice that the connection was dropped. This is probably the best form of auto-recovery after a dropped connection; the end result might appear similar to, for example, a jittery connection. (Note that this solution would usually be used with console games, but not for PC games, where the machine might be used by multiple people.)

If auto-recovery is not possible and the player needs to re–log on manually, then the server must remove the player from the game environment in a timely fashion. That’s because there is no guarantee that the player will return right away (if at all); he or she might be faced with a long-term or permanent network-connection loss. This action will naturally have a profound effect on the game session in progress.

The following actions, which vary by game type, are likely to be the most appropriate from the point of view of the players:

If the connection is lost but can be re-established, the game developer might indicate this in-game by briefly shimmering the graphical representation of the player to let other players know what has happened. This is purely an aesthetic nicety, but it does serve to inform players about the general network environment. Text-based MUD games from the early 1990s had a similar solution:

[character name] shimmers briefly as <he/she/it> reconnects.

In the game, of course, some form of prediction will be needed at the server or distributed client level. In principle, prediction should make sure that both the local player and the other, remote players notice as little deviation in the gameplay as possible. This is the same as the approach we took for data loss and jitter caused by irregular network latency. It is, in fact, more solid, because you know the reason for the lack of data—i.e., the connection has gone down—which means you can more accurately compensate for the problem.

In cases where the connection cannot be re-established, of course, the player’s in-game representation must be replaced by an AI-controlled one (if the game requires that a certain number of players be present) or removed completely. The decision as to when to remove the player—and what to do with the in-game state—is left up to the game designer. At one extreme, the player can simply be returned to a known safe point in the system, and pick up from where he or she left off at some point in the future. At the other, the player loses everything that he or she had built up in the play session immediately prior to the connection failure.

Unintentional dropped connections should be dealt with sympathetically, without penalizing the player. Some players, however, might choose to manually disconnect—either physically or logically—in order to save their place in the game during an exchange that might lead to their in-game position being compromised. (We’ll deal with this more concretely in Chapter 8.) That, as you probably know, requires a less sympathetic approach.

An intentional dropped connection occurs in its simplest form when the player unplugs the network cable to fake a network connection issue. This can be seen as akin to cheating, as you shall discover in the next chapter; in fact, it is hard to see it any other way.

The only reason that a player would disconnect his or her network cable would be to forcibly remove himself or herself from the game. It’s not something that could happen by accident. Consequently, it ought to be possible to detect it at the physical and logical levels. On the physical side (assuming you categorize data synchronization as physical), you ought to be able to tell whether the client has disconnected manually by intervening at the operating system level (for example). If the connection is closed above the hardware level, you could reasonably infer that the disconnection was intentional and address the issue accordingly. (This relies, however, on that information being available to the server.)

If the cable was just pulled out, there would likely be no warning, so you can assume that it was either intentional or unintentional. You can then perform a few logic operations to try to ascertain the likelihood of the disconnection being intentional. These operations take place on the server, but could also infer the intervention of the client at the start of the next play session—kind of like a post-mortem of the connection failure. The server and client could then come to a decision together as to whether the connection was dropped intentionally.

A scoring system should be established to rapidly grade the disconnect in order to assess the chances of the disconnection being intentional. The aim is to use in-game and network-layer information to determine the likelihood of cheating. Although this is not a guaranteed method of weeding out those who seek to cheat by forcing their machine to disconnect from the server, it is as close as we are likely to come. (Scoring is covered in more detail in Chapter 8.)

This leads to the game developer’s decision as to whether the player should be punished or whether to just let it go—that is, to live with the consequences of intentional disconnection, or try to continue playing using AI techniques so as not to disrupt the game from the point of view of the other players.

Most importantly, the trick is not to confuse the two—intentional and unintentional—forms of network disconnection, as this will alienate and confuse players.