Internet Game Design

Author: by Yu-Shen Ng

Imagine a place where gamers throng. Where, every day of the week, every hour of the day, hundreds or even thousands go head-to-head. Imagine these online revelers proudly unveiling their custom-created levels, synergistically sharing techniques and game secrets, and uncontrollably increasing their game-addiction. Imagine the previews of your sequel that they'll see and the shopping galleries where they can purchase new levels, new titles, t-shirts, and other goodies directly from you. These are some of the possibilities of bringing video games online.

While the potential rewards of Internet gaming are great, the technical issues are also significant--but surmountable. In spite of the inherent unreliability of the Internet, in spite of the high latencies (also know as lag times or time delays) of message transmission in the Internet, and in spite of the bandwidth limitations of 14.4k baud modems, it is possible to write fast action and even large-scale multiplayer games for the Internet.

This article addresses issues in Internet game design. I will provide a framework for asking design-level questions about your game's ability to be played over the Internet and offer a cookbook of tips, techniques, and issues. In the second article, I will focus more specifically on fast action and real time games and what techniques or optimizations you can use to make such games playable over the Internet.

Assume Nothing

Let's start by stating a few assumptions. I assume you are writing a game to be played (either primarily or secondarily) on the Internet. I also assume you or your company have no plans (or at least are not in a position) to maintain and operate game server software 24 hours a day, 7 days a week. Therefore, you plan to either deploy games that can run over the Internet without any support services or deploy your game with the aid of one of the online game companies and rely on that company to manage deployment and infrastructure issues such as supporting customers online, billing customers, managing game servers, keeping the network running all the time, managing the performance of the network, providing mechanisms for gamers to find each other and enter games together, and so on.

With these assumptions in mind, let's first outline a skeletal taxonomy of online games. In addition to the usual key attributes of a game concept (for example, real time or turn-based, and action, strategy, or adventure), several other game characteristics particularly affect online games. Together with the standard game categorizations, these other characteristics set the backdrop for any discussion of online games. Table 1 shows some key determining characteristics of an online game.

One of the first questions to ask is where, along each of these axes of comparison, does your game fit in? In the first two categories, number of players and communications model, you often have technical design choices to make. For the other two categories, player drop-in and game server lifespan, you have game concept choices to make. Let's examine tradeoffs in these choices in more detail.

How Many Can Play?

As a general rule, the more players you allow, the more complex your architecture must be. Small-scale games are often implemented using a very simple peer-to-peer communications model in which everyone broadcasts his or her game data (for example, position changes) to everyone else.

In contrast, large scale games are more complex. Large scale games have, by definition, so many players that modems provide insufficient bandwidth to allow all players to communicate with each other simultaneously. To conserve bandwidth in such a game, only a subset of all game information is delivered to each player's computer. Typically, this is accomplished by subdividing or partitioning the game world cleverly in ways that limit the number of people in close proximity to each other.

For example, in a space game, you might allow only players in the same quadrant to see, hear, and track each other. In a racing game, perhaps only players who can see each other or are within a certain distance of each other can communicate with each other. Although it is possible to statically prepartition the game space, more typically a large-scale game requires a server to manage dynamic partitioning of the game space. In this case, either a client/server or hybrid network communications model is usually the architecture of choice.

Super-large scale games are so large that, in addition to individual players' modems limiting scalability, server CPU processing power also limits scalability. In super large-scale games, a single server CPU is insufficient to service all the players. To enable a single instance of the game to be played using multiple server CPUs, such games must be architected in a strongly multithreaded or fully distributed fashion. Thus, super large-scale games are even more complex than large-scale games.

Choose an Architecture

Client/server games require that you write server and client code, which has the drawback of having two sets of code to maintain and possibly two separate platforms to develop in. For example, your server deployment architecture might require that you develop servers to run on UNIX systems. Along with the cross-platform issues, you'll run into other disadvantages of writing client/server games.

For example, if you're using a distributed gaming network, someone else has to run your server software. There are training issues, installation issues, integration issues, security issues, CPU efficiency issues, server administration issues, and possibly pricing issues. Almost always, if you plan to deploy your servers on an online gaming network, you should implement your servers as independent, UI-less .EXEs.

The primary advantage of client/server games is that you simplify some aspects of the game programming because a single computer has access to all the game state. Moreover, a server computer typically has a high bandwidth network connection, a reliable network connection, and is itself running on a reliable computer system (you can't assume any of these with a client machine). Together with the centrally located game state, these properties of a server make it very easy and natural to perform certain kinds of operations in custom game server code.

Peer to peer games require you to write only client code. This is a much simpler model than writing both client and server code. For peer-to-peer games, the complete game state is replicated on all client machines. Unfortunately, due to bandwidth limitations of modems, this model can support only up to 8, 16, or possibly 32 players, depending on how much data you send.

Hybrid games involve both client and server code. In hybrid games, clients communicate to each other as well as to a central server. Unlike fully client/server games, however, the server consists of only a small amount of coordination code and does not have full knowledge of the game state. Using this approach gives you the power and flexibility of a client/server model while at the same time achieving the CPU and network load-balancing of a peer-to-peer model.

Although the hybrid model sounds more complicated than a fully client/server model, it may actually be simpler. In particular, since most online game companies generally offer simple, sophisticated facilities for supporting peer to peer communications via a multicast messaging server, you can take advantage of those services in the hybrid model and not have to reimplement them.

Multicast messaging basically means that, if one client wants to broadcast a message to everyone, he or she sends it once to a multicast server and the server forwards it to everyone else. In short, the sender need only send the message once, and not n - 1 times, where n is the number of players. This whole scheme conserves outbound modem bandwidth. You could implement this yourself, but you'd have to deal with queuing, failure recovery, and maintenance issues that, hopefully, an online game service-provider will have already resolved for you.

Drop-In Play

If your game concept can handle it, definitely consider support for drop-in players. Drop-in games allow a player to enter a game already in progress. These types of games are well suited to the Internet because, since players enter cyberspace at random, uncoordinated times, drop-in games eliminate any waiting before joining a game. To support drop-in play, new players must be somehow informed of the current game state. For action games with little game state, this is easy; for games with a significant amount of game state, the most effective solution is to have a server process communicate the current game state to the player.

By contrast, session-oriented games require that all players enter the game at the same time and require some sort of pregame player rendezvous and coordination procedure. Although most online game services will manage this game startup coordination for you, players will nevertheless have to wait some amount of time to get into their game. This waiting time--the antithesis of immediate gratification--may frustrate users. Despite their drawbacks, session-oriented games do allow for better plot development because they have a definite start and finish as well as a committed and constant group of participants.

In short, there are trade-offs. If your game concept can allow for drop-in play, then consider it. If not, then take advantage of the benefits of session-oriented games.

The Lifespan of Your Game Server Process

Eternal and persistent games, by definition, have a game server CPU process that never dies but instead continually maintains and updates game state information. Even if all players have left a game, the game server in an eternal game keeps running. Internet MUDs are typical examples of eternal/persistent games. Conversely, short-duration games (for example, Doom) describe most current-day off-the-shelf games in which all CPU processes start and finish when the game session begins and ends.

You probably decided at a very early stage whether your game will be a short-duration game or an eternal/persistent game. However, keep in mind that eternal/persistent games may require more maintenance (in particular, server maintenance) than short-duration games and have the additional requirement of coping gracefully with power failures, crashes, or other interruptions of service. At the same time, eternal/persistent games offer a certain continuity that can make the game feel very alive, organic, dynamic, and, most importantly, very online.

We've now introduced most of the important characteristics of online games. Together with standard distinctions such as action, adventure, or strategy, and realtime or turn-based, we now have a solid foundation for a discussion of specific issues and tips.

What follows is something of a cookbook of tips, techniques, and issues relevant to writing effective online games. By no means is this list complete. It is mostly just a list of various issues I've seen come up and mistakes I've seen made in the past. Some of the topics discussed apply to all categories of online games, while other topics affect only specific categories.

Allow Interactions at All Times

After initial contact is made with any other player, interactions should never be unexpectedly blocked. In particular, be careful not to allow a special options screen or a particular mode of the game to interrupt a player's ability to send or receive messages. At the very least, if you do block messages in certain game states, you should notify others of the player's temporary unavailability.

Although disallowing interactions may have been acceptable in the days of LAN multiplayer gaming, the physical separation of players on the Internet really requires that players be kept fully aware of each other's actions.

Providing interactions throughout the game also enables users to teach or guide each other, facilitates spectatorship, and gives continuity to the entire interactive experience. Keep the communication channels open, and you will achieve a more rewarding, more interactive game.

Integrate Voice and Other Communications

Another way to make your game more interactive is to use effectively the various communication channels available to you: for example, live speech, text chat, precanned or user-prerecorded audio, precanned or user-prerecorded video, and so on. Integrate some or all communications into your game. Make them a central activity in your game. Interactivity can amplify players' enjoyment and can add a whole new dimension to the game. With just a little bit of communication support, all of a sudden, you enable players to laugh, jibe, ridicule, insult, holler, and joke with each other.

If you do decide to support voice communications, be sensitive to the fact that some players may be too shy to talk. At the same time, players that are slow typists may not be willing to type. Precanned audio or video messages might be one way to help resolve some of these social and UI issues. Also, consider distorting voice messages to mask player identities and thus help shy players. Speech distortion effects may also be used to garble enemy messages or aid players in assuming game-specific roles.

I ought to address the technical viability of speech data over the modem phone lines. With proper compression, speech data is definitely viable at modem bandwidths. You can design with the expectation that each channel of streamed audio will require roughly 300 bytes per second. We'll address the bandwidth allocation issue in more depth in the next article, but I just want to assure you that speech, if properly compressed and scheduled alongside game data, is viable. Here's one other tidbit of information: compression of speech today typically uses about 15% to 25% of a Pentium 100 CPU, and decompression uses 10% to 15%.

Player and Server Drop-Outs

Although speech handling is an optional feature, graceful handling of players losing their connections is an absolute requirement. This rule has implications at the game-play level (does AI take over if a player drops out?), at the UI level (what does a player see if another drops out?), and at the network communications level (if I don't receive a response to the message I sent, how can I recover gracefully?).

Since player drop-outs might occur under unmanaged circumstances (someone picked up the telephone line) or under managed circumstances (player hits abort game), player drop-out notification and management should come from a centralized game server. Client/server game models can easily use the server to detect a player drop-out and inform all clients of the drop-out in a timely and efficient manner. Peer-to-peer game models that use intelligent multicasting servers can also efficiently send player drop-out notifications if the multicasting servers are intelligent enough. Detecting unmanaged player drop-outs with serverless peer-to-peer communications is a bit more inefficient and error-prone.

Just as you should handle player drop-outs, you should also handle server drop-outs. Actually, your game server is pretty unlikely to lose its network connectivity; however, the more likely situation is that the network connectivity between a client and a server might go down. To a particular game client, this will appear as though the server dropped out. Should this happen, be sure to recover gracefully.

Consider Allowing Drop-in Spectators

On the flip side of drop-out players or drop-out servers are drop-in players and drop-in spectators. If you have drop-in support in your game, or if you are writing a client/server game, you might give some consideration to allowing spectators. Spectatorship is a nice, albeit nonessential, feature. It's great for tournaments and can also help novices learn to play the game. Within the context of your game, be sure to consider whether and how you limit a spectator's purview and ability to communicate with players. In a game of battleship, for example, you might limit a spectator's view of the game or ability to communicate. Otherwise, a spectator might pass enemy secrets to help one of the actual players cheat.

Also keep in mind the social relationships between players and spectators: a spectator might be an anonymous onlooker, a friend, a trainer, a customer service representative, or someone else; this relationship may have some impact on the nature of the interaction. Accessing information about a spectator really touches upon the issue of accessing an online game service provider's database services. The database service, among other things, is one area where you might want to investigate integrating more closely with a particular online game service provider.

Online Game Service Providers

Although you might like to make your game as service-provider independent as possible, there are certain areas where it is really just not possible today. As a first step, build abstraction layers into your software in areas in which you expect variation among service-provider APIs. Most commonly, this will be the communication and voice compression (or, more generally, sound handling and sound mixing) areas. Specifically, instead of calling the vendor's SendData API function directly, call your own generic MySendData function and have that function call the service-provider's function. Ideally, your abstraction layer for each area should be in a separate DLL so that, just by swapping DLLs, you can convert to another online game service provider.

A second integration step is to integrate seamlessly the service provider's user-interface (which provides player rendezvous, chat, billing, accounting, login, and password functionality) with your game's user-interface. There are two approaches to this: integrate essential software components from the service into your game or integrate small parts of your game into the service.

Mpath prefers the latter method; developers provide essential bitmaps and either server configuration characteristics (is the game uses peer-to- peer multicast servers) or a custom game server executable. Optional game DLLs may also be necessary for game-specific configuration screens.

A couple of final points regarding integration deserve to be mentioned, even though they are beyond the scope of this discussion. There are integration issues in providing customer service, online testing, running of beta programs, and running of pilot programs. Also, depending on your game's needs, there may be issues in accessing a service provider's tournament or player ranking and billing services. And if you are planning to release a shareware or freeware demo version of your game, you may want to make sure that, on the online service, it interoperates with the production version. And finally, you might want to access an online game service vendor's custom database services. Database services might be used, for example, for saving games or saving player characteristics.

Saved Games and Saved Player Characteristics

Although saving games is possible, I don't believe that saved games will play a very large role in session-oriented online, multiplayer gaming. In ad hoc session-oriented games, it is just too difficult to get the same group of people back together again to continue a saved game. Although saving games is discouraged, saving player characteristics to be restored in later game sessions is encouraged. Persistent/eternal games like MUDs do this all the time; they save a player's characteristics such as strength, intelligence, or items owned and restore them the next time that the player logs on.

If you want to consider supporting saved games or saved player characteristics, this game data really ought to be saved on the server. Saving data on the server will prevent game tampering and allow the same user to play from either home or work. Also, in the case of saved games, it will allow saved games to be played by replacement players; in the case of saved player characteristics, it will allow other players to view characteristics of a player who is not even logged in. You may want to examine an online service provider's persistent data or database API if you plan to save player information or save games.

Try to Keep Game Durations Short

One way of avoiding saved games is to keep game durations short. For games with three or more players, try to, if possible, enable a game to be played in less than one or two hours. Too much longer than that, and the probability of any one player leaving the game (for dinner, because the modem misbehaves and drops the connection, or for some other reason) increases.

Of course, this does not apply to drop-in and drop-out games or games that support a saving game state. For turn-based games, which are the games most likely to suffer from taking too long to complete, one simple and effective technique to make game play move faster is to place time limits on each turn.

Production Cycles

Just as there will be a spectrum of short, time-limited games to long, eternal games, the cycle times of game production projects will diversify too. In time, on one extreme, we can expect to see some games evolving into a hybrid between a game and a TV show. Imagine a game that changes every week and is serialized and published weekly online. Other games will change less frequently, but will still change dramatically quarter to quarter. Some games might have actual celebrities appearing online. Yet other games might have movie-like production cycles, with time allocated for pilot programs and reediting. And still other games will abide by the current game-software production model.

No matter what production model you move to, be aware of these possibilities, and try to always allow time in the development schedule for play-testing online and refinements after the play-testing.

Also, in this hybridized media, the issue of how to manage game scenarios comes up. In brief, they need to be managed carefully. Game companies have a lot to learn from Hollywood about managing of such production cycles. Having too many game scenarios, levels, or plots with too few players will make a gamescape feel lonely. On the other hand, steady well-managed releases of new scenarios, levels, and plots may keep the gaming public engaged.

Outlook

It's clear that change is underway in the gaming industry. We are seeing the emergence of a variety of new games (eternal games, serialized games, large-scale games, and client/server games), and we are seeing new opportunities for current categories of games (primarily in the area of live-speech-enabled games and more interactive games).

In this article, I've examined some of the issues and techniques relevant to developing such games for the Internet. Hopefully, with these techniques in hand, you'll be equipped to analyze the needs of your upcoming Internet game.

Yu-Shen Ng develops tools and services for game developers at Mpath Interactive, a company running Mplayer, an online service for Internet videogaming. He can be reached at [email protected], http://www.mpath.com, or http://www.mplayer.com