Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Internet Game Design
View All     RSS
May 24, 2019
arrowPress Releases
May 24, 2019
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Internet Game Design

August 7, 1997 Article Start Page 1 of 2 Next

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.



When What Varies Is:
A Game is Categorized As:
The number of players a game can support
  • Small scale (1 to 16 players)
  • Large scale (16 to 200 players)
  • Super-large-scale (over 200 players)
The network communications model
  • Client/server (in which the server has knowledge about the game)
  • Peer-to-peer (in which there is no server or, if there is one, it has no game knowledge, but simply rebroadcasts any messages it receives)
  • Hybrid (where the game has a small server component but performs most of its communications in a peer-to-peer fashion
How a game handles new players
  • Drop-in (where new players can enter at any time)
  • Session-oriented (where new players can only enter at game startup)
The lifespan of a game server
  • Persistent/eternal
  • Short-duration

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.

Article Start Page 1 of 2 Next

Related Jobs

Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

System Designer (Player Progression)
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Lead Game Designer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Animator
Intrepid Studios
Intrepid Studios — San Diego, California, United States

UX Designer

Loading Comments

loader image