Technologies and Techniques for

Network Game Play

or

The biggest theme of this year’s Computer Game Developer’s Conference was gaming on the Internet. From the conference, it was apparent that there are as many ideas of how to do this successfully as people presenting them. This paper describes some of the ideas on gaming on the Internet as well as some of the different technologies and business models.

Before looking at the gaming over networks, it is important to understand the environment that game companies work in. Expect a shake-out soon in the game and especially multimedia CDROM industry. The top 20 titles received 80% of the revenue. This economic reality propagates its effects throughout the industry: Retailers have to allocate tight shelf space between a few hit titles; publishers need to choose their titles carefully and from a handful of promising companies; and small game houses are largely overlooked. The working professionals are largely a loose collection of free-lance artists, designers, and producers. Good software developers are extremely valuable and highly sought. Most workers have to put up with moving from company to company and not getting paid on occasion.

To make a block-buster requires a budget that few companies can afford to gamble on one product, and if they do and it doesn’t turn out to be a best-selling game, they will fold. This is one of the reasons you see so many sequels or knock-offs of the best selling and successful titles such as Doom.

The answer to how these companies who spend millions making a game and give it away over the net has always eluded me. but to fully understand who gets paid what, some distinctions are necessary.

Everyone defended their business plan by analogizing it to other successful industries. For example, MPath, who is a big supporter of providing the service for free and making money on advertising likens their business to TV and Radio. Others liken their business to a traditional service like a telephone where you pay-per-play or pay a flat fee. Probably what will happen is a mixture of subscription and advertising like a newspaper or magazine. And others, like the AMOA, will send two guys to break your legs if you don’t give them money.

The few who are currently profitable are ImagiNation (the game service on AOL), and Kesmai. Both are mainly software companies, have been in the network gaming business years before the Internet, and had a base of customers who paid monthly subscription rates. They both do classic puzzle games like chess and poker, action arcade games like flight combat simulators, and have extensive lobby and chat services.

The reason why these two companies in particular are because they have provided the mantras which I have heard reiterated in one form or another by every on-line company but was best summed up by ImagiNation:

1. Content --- The games, of course
2. Community --- The social interaction and communication
3. Commerce --- The financial transactions as an on-line activity

This is important, so I’ll repeat it.

1. Content
2. Community
3. Commerce

While character dungeon games evolved from mainframes with terminals, many action arcade games evolved from direct null-modem connections, then to LANs. Because there wasn’t a game "server", the game writers used peer-to-peer communication between the different players. There are many drawbacks to this model which will be discussed as advantages of Client/Server below. Perhaps the most non-obvious is the fact that peer-to-peer forces the game into the so-called lock/step communication architecture.

Not to be confused with turn-based games like chess, the idea of lock/step communication is to update the game state on each peer within a certain frame of time. Until each peer received an updated state from all others, no peer can move ahead. This is the model of games like Diablo, Duke Nukem 3D, and Command and Conquer which are still considered "real-time" games because they allow multiple players to move simultaneously. Another problem with the lock/step approach is that it forces the game play to the lowest common denominator (either machine or network connection speed).

One of the more obvious disadvantages of peer-to-peer which became a huge problem recently was the fact that players can hack the client and cheat. This was the problem with Diablo. This problem has always been under-rated, but it only takes one person to post the patch to the web and the rest is history. The game play is usually destroyed because it becomes a battle to get the best hacks on your system.

Both of these problems, and many more, are solved by the Client/Server architecture. Here are some of the main reasons why:

• Security
  The server is secure and can keep the game state integrity intact. This is especially important when money or prizes are involved.
• Scalability
  Peer-to-peer communication requires (N-1)² messages per frame for N clients. Client/Server requires 2N (N input messages to server for moves and N output messages to update client game state). Usually, the input messages to the server are small and technique described below will reduce the amount of information back to the client.
• Encryption
  Servers can provide secure encryption of messages.
• Billing
  The server can support advertising or billing models.
• Ownership
  Users have a single point of contact about problems or content questions.
• Upgrades
  The server software can be upgraded and the clients can download the new version if necessary.
• Copyright
  Since you cannot copy the server code, you do not have to worry about piracy.

It is also easier to build a sense of community where all people can go to one place. This doesn’t have to be a low-latency network for most people. When the players go to a lobby and find a game session open, then can then be switched to the low-latency networks. Also, a fair amount (roughly 1MB of text/hour on AOL) is created from "chat rooms". As we move toward real-time video conferencing, I suspect that these will be moved to low-latency networks as well.

All network games, even those made for a LAN with low-latency, are moving to Client/Server architectures. This may require one of the clients to act as the host, or that the host be dynamically moved from server to server.

All fast-action games use unreliable delivery for updating object positions. Usually, this is in the form of UDP if using IP. Service providers must also implement a reliable protocol which is used for actions that cannot be dropped such as score updates or whether or not you are killed. Encryption and digital signing may also be used on such packets.

Latency over a LAN is not as much of an issue as the bandwidth because fast twitch games update a frame on the order of every 33ms and an average RTT time of a packet is 1ms. The bigger problem is latency and RTT for Internet game play.

Some people quote unbelievable best-case times and others are honest when they say "could be seconds" over the Internet. Basically, it comes down to this: if your game doesn’t have low-latency requirements, for example, chess, scrabble, and poker. The Internet is currently fine. For real-time games like Quake and Command and Conquer, these can be placed on a low-latency gaming service provider like Dwango or Concentric Networks. With these types of providers, the best-case latency is often quoted around 200ms for regional games. First, there is the time between the home computer on a modem and the low-latency service provider, then the actual time on the service provider network. Both the service providers and their technologies are described below. Here is the breakdown of the 200ms estimate:

Outbound latency 20ms

Transmission over 28.8k (RTT) 100ms

Transmission over service provider network (RTT) 80ms

The low-latency network providers use ATM switching in their networks. Concentric Networks, the largest network, uses a dial-up hub and Setel ATM switches.

With server-processing time and some load taken into account, the estimate goes to between 250ms and 400ms for these services. Latency hiding techniques, described below, are therefore necessary for games which require real-time output.

However, even with latencies around 200ms, fast-twitch games are noticeably different than their LAN versions. So different, in fact, that Romero was beaten 30-0 in T.E.N.’s version of Quake.

Since modems connecting to networks will probably not get down below 200ms, the next obvious choice is to reduce the amount of information which needs to be sent from the server to the client to update game state. This is done in two ways: first, packing and quantizing the information into as few of bits as possible; and second, having the server figure out the minimal amount of data to send for each client.

Usually, objects have a 32-bit identifier on the server which is aliased (or tagged) with fewer bits to transmit it to the client. For example, an opponent’s tank, the mines, and bullets could be tagged in an 8-bit field. Also, object closer to the view pyramid of the client can be given more data bits then those farther away.

The server maintains a list of all objects of the game and can do quick calculations from the viewpoint of any client. One technique is to only send objects that the client can currently see (and how well they can see it) by a quick transform without using a BSP-tree. The server can also maintain a measure of perceived error of the client. For example, the server only updates object on the client when the last update to that object pushes the perceived error over a threshold.

Even with reduced latency and data size, there will be times when the client must use a technique called Dead Reckoning where it interpolates what the world looks like and makes a best guess to where the other object are. The server not only sends object positions, but parameters of a difference equation to describe and predict where they will be since it cannot rely upon a message updating the information.

Usually, the client sends a packet with a timestamp so that the server can respond. The client keeps an average of RTT as a parameter in the Dead Reckoning algorithm.

This is brief because I think the conclusion is still unknown. It seems that everyone is moving in the direction of network gaming including both LANs and the Internet. There are many companies providing services for this. Which model will be successful over time is hard to tell, but many agree that providing a community feeling, good content, and easy purchasing of service and merchandise are necessary.