In the beginning, computers talked to each other over a modem connection, supported by the plain old telephone system (POTS). The term modem is short for modulator/demodulator and enables one computer to talk to another over a simple phone-line connection.

This works by taking the data (digital) and turning it into a sound-based signal (analog) that can be transmitted without loss over a standard copper telephone line. You might, for example, have heard a fax machine transmitting data to another fax machine using the same kind of protocol.

The whistles and crackles that represent the modulated data are created by the modem and transmitted as sound through the telephone system. They are then received at the other end by the modem of the receiving computer (or fax machine) and demodulated before being passed to the operating system for processing (or printed onto paper).

The data that is transmitted has to be standardized, and there is a certain amount of negotiation that happens between two modems (or fax machines), called the handshake, that allows them to settle on a specific mechanism for data exchange.

This basic model has remained with networking ever since. Data leaves the sending computer having been encoded by the operating system. The operating system (Windows, for example) then passes it to an external peripheral (the modem), whose sole function is to turn that data into something that can be transmitted over a network and make sure that it is done correctly.

For the most part, the mechanisms that can be used are transparent; that is, most development environments provide automatic protocol support, meaning that the developer has only to worry about the higher-level functions. So the work of actually performing the handshake, making sure that the data is received correctly and reporting that success correctly is usually handled by the device and operating system.

This basic premise of all networking technologies is shown in Figure 1.1, which illustrates the simplest approach—point-to-point networking.

Figure 1.1. Peer-to-peer modem networking schematic.

The term dial-up refers to the fact that the sending computer, depicted on the left side of Figure 1.1, dials a number to reach the other computer. This number is a regular phone number attached to the house (or office) where the computer on the right side of the diagram is located.

The computer forms a single connection over the phone network to a single point, and only that point. Each device can maintain only one connection at a time (think of a fax machine). This restriction is behind the meaning of the term Point-to-Point Protocol (PPP). Of course, from that point, other connections can be made to other computers, thereby connecting two networks by a single phone line. This internetworking is what gave rise to the Internet, and subsequently, the World Wide Web. However, we are getting ahead of ourselves slightly.

From a gaming perspective, despite the relative primitiveness of the hardware involved, PPP networking allowed some reasonably sophisticated gaming constructs. These were often made possible using bulletin board systems (BBS), which connected computers to a server capable of interacting and storing a persistent information state.

Initially, this information state was restricted to comments and communication via the BBS. People placed requests for software, which could be downloaded or just connected to share opinions, information, or chat. Over time, it became clear that the ability of the server to store persistent information and attach that information to a specific user, as well as allowing multiple simultaneous connections, could be used for multi-player online gaming. So, puzzle games like chess could be played in a two-player environment, with the server maintaining the game state and allowing for the conduit to be formed between the two players. Traditional single-player puzzle games could also be extended by storing the game levels on the server and allowing the player to play via his or her modem.

Play by e-mail also became possible thanks to the messaging systems—electronic mail—that made this exchange medium possible. Play by e-mail opened up some forms of complex social gaming (Dungeons & Dragons, for example) to wider audiences who would otherwise never have had the opportunity to play together.

There were, however, some limits on what could be achieved. For example, interactive single-player-versus-the-computer games were limited by the dial-up speed, which in turn limited the amount of data that could be exchanged in real time. In addition, the hardware limited the kinds of games that could be displayed; even if the computer were capable of graphics, early networked games could offer only a text interface.

Many games worked simply by the client computer displaying text-based graphics relayed back from the server. This was partly due to the fact that most of the systems involved were entirely dissimilar; the only common denominator was the fact that, because the computers connecting to the server could support BBS, the game developers could be sure that similar interactions were possible.

The obvious extension to this was to enable network support for specific games, allowing owners of these games to interact simultaneously, sharing game information directly (PPP) or through a server. Network gaming was born.

The local area network (LAN) is a step up from a PPP network; in a LAN, a collection of computers can be connected and can communicate with each other. Local means that the computers are connected directly together (usually by wires) and to a central server, but generally all within a very close distance.

The closer proximity of the LAN enables larger amounts of data to be exchanged, at higher speeds. The farther machines are apart, the more complex the actual data exchange becomes in order to maintain the same data integrity and throughput. This, in the early days of network gaming, understandably made LAN parties very popular.

A LAN party is essentially a game-playing extravaganza in which hundreds of gamers come together under one roof, connect their machines on a vast local area network, and play multi-player network games. These can be free events (sponsored) or events backed by an entry fee. Of course, LAN parties can also exist on a much more personal level, sometimes just between a small group of friends. Social gaming in this vein is growing in popularity with platforms that support both networking and non-networking components.

Contrary to what people might have predicted, LAN gaming has not been killed off by the rise of the Internet. For social reasons as much as anything else, LAN parties are still very popular amongst gamers.

The very first clutch of multi-player extensions to existing single-player games like Quake were played using a LAN. A LAN was the only way it was possible to allow large numbers of players to participate in such a complex game environment. The real-time nature, coupled with reasonably complex data sets, meant that the LAN was really the only solution.

Local area networking also provides the basic configuration for wide area networking. The protocol, TCP/IP (Transfer Control Protocol/Internet Protocol), that allows local networking also permits wide area networking with the addition of a modem. In the previous discussion of PPP, you saw how a server can provide this. The very first Internet service providers (ISPs) did exactly that—they provided a dial-in location, allowing users to connect to the server, and hence the wider worldwide network that was the fledgling Internet.

Once line speeds began to pick up, both at the dial-in level and the main networking backbone, Internet gaming—or at least multi-player network gaming over TCP/IP and wide area networks (WANs)—became a reality, opening the field to many more potentially simultaneous players than ever before.

I’m going to oversimplify this a little bit, since the underlying protocol is so similar. The Internet and World Wide Web (WWW) can be seen as an extension of LAN models, to connect multiple LANs together.

So, the extension of LAN gaming to include the Internet as a WAN is made possible by the fact that much of the same technology is used. LAN and Internet gaming can also co-exist, although it is clear that LAN users would have a theoretical performance advantage in any hybrid network model used for multi-player gaming.

This potential advantage might manifest itself through higher connection speeds leading to a reaction-time advantage, as well as advantages relating to the stability of the networking connection. The Internet is not renowned for being either particularly fast or reliable, although it is improving steadily.

Usually when we think of network gaming, it is with the real-time multi-player market in mind. We should not forget that there are many other potential gaming models made possible by network gaming. Some of these will take on a new impetus when the Internet and World Wide Web are brought into play.

The Magic: The Gathering card-based game is a good example of this. It can be played over a network and revolves around using cards wisely in a kind of statistics-oriented role-playing game (RPG). It really comes into its own, however, when the only method of communication with other players is through the game itself.

Although WWW and Internet networking technology can be looked at as just the LAN protocol TCP/IP writ large, it also comes with its own set of issues to resolve. These are various, but include unintentional disconnect and lag.

Unintentional disconnect occurs when the Internet backbone breaks down, forcing the connection between the client and server to be interrupted—sometimes for several minutes. The TCP/IP protocol is essentially connectionless. In other words, once the request is made and a response returned, the protocol goes into a dormant state.

This might work for Web pages, but is a little bit of a problem for fast-paced action games where a split-second delay can mean the difference between in-game life and death. The nature of the Internet protocol is that routes for the data are often decided dynamically, and so an alternative is usually found in time, but there are no guarantees.

Lag is a different, but connected, issue. It occurs less and less often, but is defined by the delay between the player requesting an in-game action and the action manifesting itself in the game environment. Quite often it is impossible to tell whether this is because the request has not reached the server or because the updated state of the game environment has not (yet) been received by the client.

Quite an issue for game designers.

There is another unique aspect of Internet gaming, and that is the fact that the user is largely on his or her own in the ether. Now, this aspect isn’t unique because players are alone; single-player gamers were, after all, always on their own. It is unique because players are on their own and yet are connected to other players through an abstract game universe.

If players try to cheat or have a genuine problem, it is that much more difficult to interact with them. In single-player games this difficulty wouldn’t matter much; it’s only the player against the machine. But in multi-player games, this kind of issue has consequences for other players.

Of course, this issue is then compounded by the fact that there will be a potentially much larger collection of heterogeneous platforms to support than with other classical single–player gaming or LAN-gaming models. This is true not just from a machine-specification point of view, but from an ISP point of view also.

Different ISPs will have different configurations, allow different uses of their inter-network connections, and respond differently to technical problems—all of which is outside the control of the people running the game server and gives more margin for problems that will potentially affect sales of the game.

For example, connection speeds (bandwidth) vary between providers. Connections with a 2- to 3-megabit (Mb) bandwidth might be common for Internet access using broadband technology, but clearly the designer can’t count on everyone having the best connection.

Ideally, the design needs to take into account the lowest common denominator. This might even be the humble 56Kbps modem over a plain old telephone line. The lowest common denominator will affect the gaming model; it will not matter for games that are played through the browser with text and minimal graphics, but it might restrict the gaming environment for a multi-player first-person shooting action extravaganza.

So, a design balance must be struck between complexity of the game and capability of the platform, including, for the purposes of this book, the network connection—over which, it is worth repeating, the designer has no control.

At the heterogeneous extreme, if a game designer wants to create games for the wider Internet market, then this will bring its own complications. Some people, for example, will be using cellular technology to access the Internet with a handset and not a computer. This will have an effect on bandwidth, platform technology, and so forth, which dictate the networking and game complexity. In effect, the more platforms, and the more diverse they are, the more the design of the game is going to be complicated. While we look only at the networking component in this book, it has a direct effect on the game design as a whole, and so we will be touching on most areas of traditional game design.

Wireless LAN (also known as WiFi) connects devices via radio technology, providing large-bandwidth, high-speed connectivity. Again, the protocol is basically TCP/IP, allowing any device with a driver to enable an application to use the technology.

Special hardware is used, which must be supported at the operating-system level—just like any other networking component. This insulates the designer and programmer from having to explicitly design for WiFi connectivity.

WiFi is not as fast as regular LAN, but public-access speeds of 1–2 Mbps are common at the time of this writing. It is worth pointing out that wired LANs typically offer 100Mb bandwidth, with gigabit (Gb) connectivity around the corner.

Over WiFi, machines can connect via a PPP to each other (and many others simultaneously) or they can connect to network points that provide services. These services include printing, file sharing, and Internet access. So, apart from the wireless aspect, WiFi is much the same as regular LAN.

Where WiFi is potentially special is in the fact that, given the right security access control protocol (proprietary to the game or using accepted security standards like WPA or WEP) and sharing of security information between trusted parties, anyone with wireless LAN can connect to anyone else with wireless LAN.

Since it is all based on open standards, special networking can be built into the game to allow these peer-to-peer relationships to take place. In this case, peer-to-peer means that one machine is connecting directly to another, for the purpose of information sharing. They could be ad-hoc relationships (discovered on the fly) or pre-arranged relationships. One obvious example is a temporary relationship with an Internet access point. Another might be the connection of two machines to play a game without a network being established to facilitate this communication.

Of course, there are also security concerns. For example, WiFi might be open to snooping technology because data goes out as radio waves. Partly because it might be poorly understood by the gamer, this could lead to possible security loopholes. In the worst-case scenario, this might extend to turning off security altogether.

This may or may not have an effect on the game design directly. However, the game is just another application that exists on the gaming platform, and as such provides a potential Trojan horse for malicious software to take over the player’s system. It is the responsibility of the game developer to

Clearly this list could be relevant to any kind of network gaming, but the nature of wireless networking means that the game developer and gamer both should be doubly careful. Since it is relatively difficult for the player to actually determine that an unexpected connection has taken place, it is a rich seam of hacking potential for those with malicious aims.

Along with WiFi networking, Bluetooth networking is also possible, but typically allows only for pairing with another device (be it temporarily) to share data. This means that the gaming model that will be most likely to make use of this technology will involve sharing of in-game artifacts (characters, prizes, etc.) for connectionless play. Bluetooth is a technology that uses low-power radio connectivity to replace cables between devices. WiFi differs from Bluetooth in both the speed of the connection and the fact that it is designed for true networking—i.e., replacing a LAN connection. In contrast, Bluetooth connections are point to point and typically, once a pairing has been created between a computer and device, that is the only pairing that can exist for that device. To use a different pair of devices, at least one of them will have to create a new relationship.

For example, a player might spend time in-game on his or her own machine (console or handheld, for example) building a character that can then be sent via Bluetooth to another device and interact with another player’s character. The result can then be returned, again via Bluetooth, at some later moment in time. The time between the sharing of the character and the result could be measured in seconds, hours, or even days, depending on the gaming model.

Again, the technology used is wireless, but the lower range and pairing restriction tends to mitigate possible security threats. There are, obviously, security issues to bear in mind, but the closer physical proximity of possible threats reduces these considerably.

Wireless communication in general also limits its application in multi-player network gaming, however, because of the fact that it is restricted by proximity. So, handheld consoles such as the Nintendo DS are therefore most likely to take immediate advantage of wireless gaming.

Naturally, as cell phones also become endowed with WiFi (most already have Bluetooth) or other wireless-networking and inter-networking capabilities, they will also become very capable network gaming devices.

More and more cell phones are being equipped with networking capabilities—from Bluetooth to WiFi and beyond. In addition, many can also access to the Internet via the cell phone operator at varying speeds. The standards involved are various—GSM, GPRS, UMTS, etc.—as are the capabilities of the phones themselves.

Despite the ubiquity of the cell phone as a life accessory, they remain heterogeneous in their implementation. There are many variables to contend with when considering using a cell phone as a network-enabled gaming device:

While not all of the above are unique to network gaming, they all have an effect on the kinds of network games that can be realistically implemented to achieve wide enough acceptance to be financially viable. Whether sales are from direct sources (off the shelf or virtual purchase) or indirect sources, it never makes sense to isolate any corner of the market. This is especially important for cell phones, as it is a very fast-moving, high-replacement market, with exceptionally high lifestyle penetration.

All the possible networking issues also come together in cellular networking technology—everything from varying protocols and access possibilities to screen size and memory capacity. This makes it one of the most difficult platforms for which to create network games. There is, however, middleware available to help target specific platforms and technologies, making the process easier.

The market is potentially so big that the trials and tribulations will be worthwhile if such a broad worldwide user base can be catered to. This can include everything from PPP gaming using temporary connections to full network Internet gaming.

There is also plenty of scope for hybrid models where cell-phone gamers and console gamers can live side by side, or where taking a Web-based PC game on the go by having a cell-phone client keep track of the game environment gives the same gamer two interfaces to the game.

The simplest kind of multi-player gaming model to appreciate, and the one that we are most familiar with, is called the client/server model. It is also the networking model used for static data sharing. It is called client/server because there is a one-to-many relationship between the client machines and the central point (server), which is the master of the data exchange. Figure 1.2 shows the client PCs, which can be on a LAN or connected via the Internet, all communicating via a central point: the server.

Figure 1.2. Client/server network schematic.

The role of the server is to run the game environment and manage all the in-game objects within it. This generally occurs at an abstract level; it is the role of the client systems to depict the unfolding state of the part of the game environment that each player can “see.”

This realization of the abstract game state is based on data that comes to each connected gaming system from the server. Of course, player (or user) interaction is also relayed back to the server where it calculates the net effect of all the incoming data on the game universe.

This can be seen as a kind of default networking model for most data-sharing paradigms over a network. We should not forget that online gaming, network gaming, and multi-player gaming in general, be it over a LAN, WiFi, Internet, or dial-up PPP connection, is often just an exercise in data sharing.

In browser-based Web gaming, a Web page is delivered to the browser using a client/server model. More precisely, a request and response (from client to server) mechanism is used—nothing happens unless the client is ready to receive data and actually requests it. This is an example of the most basic kind of multi-player network gaming, and one of the easiest to actually implement.

Other client/server mechanisms allow the client to indicate that it is ready to receive data (listening), which is then pushed to it. The data push happens when the server is ready to relay an update to the client, whether the client wants it or not. This model is entirely necessary in most online multi-player gaming models. The simple reason for this is that there is no way to predict what other players are going to do, nor how the game environment will react over time. Therefore, the server must inform the client of updates as they happen, in as close to real time as possible.

Of course, there will be some gaming logic in the client, too, but that will not necessarily allow it to predict with any certainty how the game environment will evolve over time. Most of the logic will just be there to maintain the illusion of the gaming environment and interface, as well as manage the connection and user interaction.

So, the data-push model is very important, as is the request/response model, depending on the kind of game the designer has in mind. The latter, for example, will mainly be used for games in which there is a turn-based mechanism at work.

In addition, there are all kinds of games (play by e-mail, browser-based games etc.) that make use of the client/server network model in a transparent fashion. In other words, the players do not necessarily use the same protocol, client, or software to access the game; the networking component is just another data-exchange service.

For these kinds of games, it is often not necessary to have any more than a very high-level view of how the underlying mechanisms work. However, for most network gaming, and especially real-time multi-player online action or simulation games, the designers need to appreciate what kind of underlying mechanisms are available at a reasonably low level.

To summarize this section, then, client/server is a network model in which there is a central repository of data and a centrally controlling entity. This entity is responsible for storing the game environment. It is a fundamental part of the vast majority of other network-gaming paradigms in the same way that TCP/IP is fundamental to network gaming in general.

Many, if not the majority of, network games fall into this category, even if they are turn-based games and not real-time interactive gaming experiences. An example of a real-time multi-player Internet game might be Eve Online, or multi-player variants of Quake, which also supports LAN gaming.

Some games are not strictly real time in the sense that the action takes place as request and response, but where the game environment is still updated in real time. Subsequently, the consequences of decisions taken by players in the game are immediate.

The fact that, in this kind of model, the action unfolds at a less frenetic pace as in-game commands are carried out does not detract from the fact that they are still games that take place in a dynamic environment (hence the distinction between real time and dynamic). The game environment, objects in it, and other players evolve as the interactions take place in the virtual consciousness of the server.

Naturally, no multi-player network game is ever really static in nature; the game environment is, by default, fluid. There are, however, games where the environment remains in the same state for an extended period of time. This can be a period during which the users make their in-game decisions (covered in the next section “Connectionless Network Gaming,”) and interact with the front-end interface of the system. This is a similar, yet different, model, and comes with its own set of issues, which is why it is dealt with separately.

The most basic example of a real-time multi-player network game is a multi-user dungeon (or MUD) game. These games have a text-mode interface and illustrate some of the key challenges of network gaming, being at once a real-time chat system and an online game.

One of the issues that rears its head in this particular model is the problem of network disconnects—both accidental and otherwise. An accidental disconnect is an irritation, both for the player, and the game designer. An intentional disconnect—often in an attempt to escape when things start to go wrong in the heat of battle—is really only an irritation for the designer. There is, as we shall see later on, a kind of balance to be struck between coming down hard on intentional disconnects and accepting that some kind of in-game mechanism is required to ensure continuity in case of genuine network problems.

This is all quite complex, and the connectionless network gaming model provides a slightly easier way to embrace multi-player network gaming for those just starting out.

As an example of a connectionless networking protocol, think of Hypertext Transfer Protocol (HTTP). This is the protocol that sits on top of TCP/IP and allows the programmer to request information (often Web pages or files) over the Internet. Once the response has been processed and all the data received, the connection is broken.

Unlike a dynamic or real-time dynamic network-gaming model, a connectionless network-gaming model allows the game universe to remain static for a given length of time during the play session. This might be brief or extended, depending on the way that the game is designed.

The purpose of this static period is to allow the players to make their moves—simultaneously, in some cases, before the environment is updated to take into account all the various requests of the players.

The game environment is updated periodically—overnight, for example—and the effects of all the players taken into account. Crucially, however, the interface between the player and the part of the game environment that they are responsible for (or interact with) can also be either dynamic or static.

A static relationship would mean that the player just sets up a series of commands (state changes, requests, etc.) and then logs off. When the player logs back on, provided that the environmental regeneration has taken place, his or her own little piece of the game environment will also have been updated.

The dynamic relationship at this level means that much of the impact of the player’s own decisions is directly reflected in the player’s own part of the game environment. The result of these changes drives the evolution of the game as a whole. The difference is that the player knows the local effect—the effect on his or her own part of the game environment—but not the emergent effect that this will have on the system as a whole.

For example, Project Rockstar is essentially a turn-based, daily-update gaming model. the basic premise being that the player can hire musicians and either let them loose as solo artists or create a band from them. Each musician has strengths, weaknesses, and other RPG-style attributes such as charisma.

Some attributes can be trained, and others cannot. It is the responsibility of the player to try to get a hit record by playing gigs, practicing, and recording music in virtual studios. Interestingly, although the result of the training, gigging, recording, and releasing of music is known only after each update, spending money is done using a dynamic model.

So, the player can hire a new musician and put that musician to work immediately, which is part of the dynamic aspect of the connectionless model. The result of the work, and the effect of that work on the wider game environment, is then part of the static aspect of the connectionless model. It is not known until after the static instance of the game environment has been generated.

Remember, however, that connectionless game models are not necessarily equal to turn-based gaming. Project Rockstar, for example is not turn based; players do not have to wait their turn before they can play. Dungeons & Dragons (D&D), the RPG/board game, however, is. As such, it lends itself to connectionless gaming, provided that the correct model is established.

It is perfectly possible, for example, to have a D&D game in which players must take turns, in a given order, in a connectionless gaming environment with daily updates. A play-by-e-mail system with strict, order-based, turn-by-turn gameplay would be an example of an extreme application of this gaming model.

Such a model might prove laborious to some; a single game would take many days (even weeks/months/years) to unfold. However, play-by-e-mail and other connectionless gaming systems based on platforms like HTML have an advantage. Since they are played through the browser or a standard e-mail client, they have the advantage that any Internet-connected device can be used to play. This also makes them a good target for casual gamers, which is an interesting emerging market that can be tapped with a clever combination of game, platform, and community.

As a brief side note, we have discussed the play-by-e-mail turn-based connectionless model, but not the browser-based equivalent. In this kind of model, updates happen in real time; as players finish their moves, the environment is updated, and play moves to the next player in a round-robin fashion.

Note that with the move toward a dynamic real-time gaming model, we will again be confronted with the design issue that there is a possibility of disconnection, accidental or otherwise, which must be dealt with appropriately.

One of the most important aspects to consider is the security of the data exchange—not so much because in-flight data can be intercepted and tampered with by unknown third parties, but because the players themselves might try to defraud the system in some way. The two most likely security threats are probably

The way that the information is used in game will have a severe effect on the amount of security that needs to be put in place. Primarily, we are concerned with adding security to prevent cheating. Other attacks might happen, but if we take steps to prevent active cheating, then we automatically reduce the dangers associated with attacks in general. In addition, there are non–game specific things we can do to reduce the chance of hacking attacks, denial of service or otherwise, which will not affect the game design so much as the way that the whole system is implemented and run.

However, it remains the responsibility of the game designer to make sure that the opportunities for foul play are eliminated. To the extent that it is possible, this should be done in the logic of the game itself, so that a technical solution is not required.

A technical solution in this case would likely be some kind of secure encryption algorithm, which will be computationally expensive for both client and server. Naturally, we would like to avoid any additional stress on either system, but if encryption proves necessary, it should be performed on as few pieces of data as possible.

The first key point, then, is this: In the design, try to minimize data exchange as much as you can. This has two advantages—the additional data-reduction effort also helps to sustain network performance, and not just improve the performance of any additional security measures.

The second point is to make any sensitive data non-obvious so that a casual interception (and eventual altering or augmentation) cannot yield any quick results. The aim is to make sure that only a concerted effort to monitor data exchanges over an extended period of time will yield any information at all, let alone useful data.

Finally, the third point is to make any data, as far as possible, non-consequential, reducing the gaming logic that the client system implements. This is a slightly different take on the data-security model that will need to be implemented. We assume, from the outset, that none (as far as is practical) of the data stored locally with respect to the client can be used to further the player’s progress in the game without data exchange between client and server.

This is another balancing act of data exchange versus security versus gameplay. For example, it may seem to be a good split of the gaming workload (see the next section, “Split-Information Model”) to allow clients some leeway in deciding how certain aspects of the game environment evolve during the play session. In other words, the client system helps the server out by providing some of the game environment update processing muscle.

Be it in a real-time gaming model or a connectionless one, this might seem like a good idea. After all, the less work the server has to do, the richer the environment can be, and the better the game will be—as well as being able to support more artifacts, more players, and more interaction.

The dangers in taking this approach should be obvious—namely, there is a transfer of control away from the one part of the system we can control (hopefully, completely): the server.

At one logical extreme (with only the absolute minimum data exchange), in a real-time gaming model, the client system is just an extension of the server. That is, it exists only to show the player what the current game environment looks like (and sounds like), and to capture any input from the player for eventual communication back to the server.

Thus, the data exchange that occurs is merely to send movement commands to the server and receive the current state of play (immediate vicinity only) from the server. The server maintains the state of the game environment and everything in it.

Furthermore, the server decides everything that it knows for each coded client, at each moment in time:

This is the only information that the server passes on to the clients. Each client knows only what it has been told. It has no idea what else might be going on in the game environment and is not allowed to make any decisions based on the data that it receives whatsoever. Of course, it can decide how to render it and allow interaction, and so on, but the data that passes between the two is minimally useful.

Tampering with this kind of data should a) be difficult, and b) fail to yield any obvious benefits to the player. Even if players were inclined to do so, they would need to read and interpret the incoming information before acting upon it. This should require quite some programming skills—and it is the responsibility of the developer to make sure that it does.

This means that, at this logical extreme, the client is just a window on the game space. It cannot render (be it a real-time action game, rendering graphics in real time, or a text adventure) things that it is not told are explicitly within the player’s sphere of influence within the game space.

The other side to this issue is straight hacking and cyber terrorist attacks. These are cases where third parties infiltrate the data layer and cause denial of service or disruption of the gaming model. Denial of service is usually nonpermanent, albeit irritating for the players concerned, as they are unable to get service from the overloaded server. Beyond the lack of revenue and loss of face, there should be no lasting damage. Disruption to the gaming model, however, might not be so benign. Parts of the gaming environment might become disturbed temporarily or, in the worst case, permanently. It is important, though, to note a difference here between hacking and exploitations of holes in the design that ought to have been plugged by the developer. Players cannot be faulted for these kinds of exploitations.

The example in the last section shows a data model that is biased toward the server. This might seem, at first glance, to be a sensible precaution, given that I’ve spent a good amount of time making you paranoid with respect to security and performance. On the other hand, it can also make good sense to store static data on the client and use a split-information model in which the client layers information that it receives on top of information received by the server.

In the split-information model, gameplay data is stored on the server, with some of the data required to render the game state stored on the client. The litmus test is that information can be held on the client as long as it does not include any data that directly influences the gameplay.

This litmus test is the safety net against the aforementioned security, but also introduces an added strength of the network-gaming model: downloadable content. In turn, designers wishing to build this into the game design need also to think about how best (and most securely and efficiently) to cater for these downloads.

A good example is a game model in which the game environment (without in-game artifacts or players) is stored on the client. Whether the client is a handheld gaming device with lower-end processing power, a top-end PC, or a console with Internet access, it will be responsible for rendering the immediate game environment.

Here is the crux of the matter: It may only render that which the game server tells it to. There should be very little logic, no decisions taken as to what the player might be able to see, and no data downloaded that is not part of the immediately visible game environment.

This model is something like the original Unreal Tournament network-game model. Players had to download a map to their PC (actually, the map is part of the game download) and then find a server to play it on. As long as the two were synchronized correctly, possibly through further downloads, everyone was happy. Players could then select from a variety of game modes (from Capture the Flag to all-out Team Tag–style warfare) and play over the Internet against other players, be they real or virtual (bots).

The point is that the game model that splits the information in an intelligent way—such that the downloadable client provides only the rendering—has the potential to expand the audience. Since only data that pertains to the environmental game session is ever actually communicated, security is maximized, and data transfer is minimized.

This is a popular model of information split, but it has some consequences. For example, the environment can only be expanded by downloading new portions of it upon demand (for games not based on single maps), which could cause issues relating to timing.

A dynamically unfolding environment must therefore be downloaded in layers of virtual zoom. If we take a space-based game like Eve Online as an analogy, this is the same as saying that we first download the abstraction of a galaxy (and all the stars within it), and then the system that the player chooses to visit (star + planets), and finally the exact planetary system in which the player finds himself or herself (planets + moons + game artifacts).

There is another technique that will be discussed in the book—procedural rendering of the game environment. This is an interesting and useful technique that splits the information exchange again. In short, the client downloads coded information, which allows it to create the game environment based on logic contained within the client and the local data it is shipped with. The key to this technique is that, if a new piece of the game environment is created, there is nothing downloaded beyond the codes required to create the new environment upon demand.

We should also dig down a little more deeply into the data split where all the information resides on the server. We have mentioned the model in which environmental information is downloaded inline, but there is also the possibility to take an extreme client/server approach whereby the actual rendering information is passed to the client, which is just drawing what it is told to. (Readers might remember the X Windows client/server model, or recent thin client computing, which achieves this. Also, the Microsoft Windows Remote Access Client works in this way.)

Of course, this creates a much higher processing workload on the server, produces very heavy Internet traffic per client, and is not an efficient information split for some game models. That said, simple text-based games (MUDs, for example) use this model very effectively, but do suffer from occasional lag (which is not as bad as it used to be, but can still be irritating).

It is highly unlikely to work well in an Internet gaming model, but there is potential for this kind of information split to work for LAN games. The closer proximity of the machines and the higher data-exchange rate means that it might be feasible. It also has the advantage that the client does not need to store any information about the game, and can therefore be adapted to multiple games by just changing servers.

Naturally, a hybrid approach is also possible, where game-world data can be downloaded and stored, to be used later on. This might suggest that additional security needs to be introduced to protect the downloaded data from prying eyes—an issue for an adventure or quest-oriented game, for example. For pure multi-player combat, however, where advance knowledge of the game map is not necessarily an advantage, this protection is not generally necessary. Due to the fact that play occurs against other players, at speed, and there are no hidden things to discover, the additional protection is not generally necessary. This last, simple model brings us full circle to the highest form of information split toward the client. That is, the map lives on the client system, and only positional and action information is relayed to the clients as the game unfolds.

All the preceding discussion has been about extremes. But these are not binary decisions—it is not a matter of choosing one or the other. Each extreme in a decision process can, indeed must, be applied in a balanced fashion to try to design the most appropriate data-exchange model for the game, clients, and network protocol.

As we noted, data exchange is a balance between compression, security, and connection speed. The exchange of data between client and server needs also to be correctly balanced in order to yield a reasonable playing experience.

This is of course dictated in part by the split of the information model used—higher client content may imply lower data-exchange requirements, and higher server content may imply larger quantities of data flowing from the server to the client. The issues relating to compression and encryption (for example) are also applicable to the data that is actually exchanged, as well as stored on the client.

Depending on the capacity of the devices and networking protocols used (remembering that we have to cater to the lowest capacities being supported), the principles of size and security will come into play. Less-capable devices might not be able to (de)compress quickly enough or be able to decrypt or encrypt data at sufficiently high speeds to enable players to take part alongside others with more-powerful client machines.

Then again, data can flow in both directions. This naturally means that if there is any processing performed by the client beyond simple interaction with the user, the result of that processing needs to be passed up to the server. Typically, this upstream data has to follow the same principles of size and security as for downstream data; although the server will have higher processing capacities, it also needs to deal with more entities, so there is again a balance to be struck.

There is an additional point to make which may seem obvious, at first. If the client is doing any game-related processing (not advisable), then security comes into play. The data that results from client-side processing, and that must be sent to the server, must be secured adequately. If the data generated by the client and shared with the server is a result of an interaction in the game space, then it will have an impact in the game environment as a whole. This being the case, there is a risk that local security issues could lead to undesirable consequences and global security issues.

Now, this might feel a bit abstract, so let’s look at a concrete example. Imagine that the server presents a puzzle (encrypted) to the client. This puzzle might represent a challenge that must be solved by the player, on the client machine, before the player can continue in the game. The actual updated position of the player’s avatar in the game environment should be decided and monitored by the server. This is just an added safeguard against unintentional or intentional side effects. If the result of the puzzle solving is just a simple yes/no, the data needing to be exchanged is minimized. While this is good, it would allow the player to intercept the data and just send a “yes” answer rather than actually solving the puzzle. The player would then be permitted to proceed to the next stage of the game, which is clearly not desirable. What is needed is some way to package the network data and then encrypt it such that the player is not able to easily defraud the system.

Even worse, the result of the client-side processing might actually be something that is uploaded to the server and stored there. In a game revolving around city building, for example, this might call for the player to create a city using resources awarded by the server based on online performance. Then, the player could feasibly upload that city, which would then become part of the online gaming environment for interaction with other players (city builders, or some other gaming class supported by the system). If such a data exchange is not secured, then the data that is sent back to the server might well be tampered with to the detriment of the game for all players.

Getting the data exchange, network model, and information models lined up correctly in the game design, based on the networking platform (PPP, LAN, Internet, Web, etc.) is clearly very important. It is an integral part of designing a network game, or the networking portion of an otherwise stand-alone game, which we will uncover step by step through the rest of this book.