Multi-Player Games

By Bret Barker


  • The Revolution in Java's I/O Libraries
  • ChatterBox, A Basic Multi-Player app
  • Multi-Player Game Server Framework
  • A Sample Game: RPS (Rock, Paper, Scissors)
  • Complete the Look: Building on the Framework
  • Server Administration
  • Advanced Topics
  • Summary

Multi-player computer games have been around for decades. Long ago, in the distant computing world of the 1970s, hackers wrote primitive network games on DEC VAXs and other minicomputers running early versions of UNIX, VMS, and other operating systems. By the 1980s, multi-user dungeons (MUDs) were gaining popularity, and every major online service of the time (CompuServe, Prodigy, and GEnie) had its own offering of online games. In those days before the Internet boom, the audience was still very small because most homes were without Internet connections or even computers. All that changed in 1993 when Id Software released its first network-enabled first-person shooter (FPS), Doom. Doom allowed up to fourplayers to shoot at each over a local area network (LAN), or two players to play via modem. The introduction of Doom brought about a new genre of high-speed multi-player games. Doom was followed by Quake, which gave rise to LAN parties and a new crop of companies (mostly defunct now) dedicated to providing dedicated, low-latency game server networks. As more people swarmed to the Internet, an opportunity arose to provide games to a wider audience than the traditional hard-core gamers. The casual games genre was born, consisting of web-based or downloadable games that were a bit slower in pace. A number of companies sprung up in the late 1990s to serve this demographic, offering basic parlor games (chess, checkers, solitaire, blackjack, and so on), word and puzzle-style games, as well as some original games. Although these games are turn-based and relatively slow compared to FPS games, sites such as Pogo, Yahoo! Games, and MSN Gaming Zone serve a large player base and often have thousands of simultaneous players. The other major genre addition of the 1990s was the massively multi-player online role-playing game (MMORPG), started by 3DO with its release of Meridian 59 in 1996, but quickly eclipsed by EA's Ultima Online and Sony's Everquest. These games broke new ground with the number of simultaneous users supported and the vastness of their virtual worlds. Each of these genres has come with its own set of design challenges. In this chapter, we explore the design of a generic multi-player game server and client. We discuss the use of the JDK 1.4 NIO packages through a simple client/server example, show you how to build a flexible multi-player game server framework, and discuss some advanced topics. In the end, you will have a good base of knowledge and code to serve as a starting point for building your own multi-player game server. This chapter is a bit of a departure from those presented earlier. You won't be doing anything sexy here—no flashy graphics, no dazzling sound effects. Nope, the most exciting thing you'll see here is a message in the server log file that reads:

New connection from, 483 users online.

So, if sockets, logging, thread pool wraps, and remote admin consoles sound like fun to you, let's get to it!

Prerequisite Knowledge

It is assumed that you have working knowledge of a command shell, whether bash, tcsh, or the Windows shell (cmd). Note that if you are working on Windows, Cygwin (available at will make life much easier because it provides a bash shell and a set of standard command-line utilities. Server apps are meant to be run headless and to provide their output via log files. Headless refers to the lack of a GUI (the head) for the app. You'll want to become familiar with how to browse and search the logs using tools such as grep and tail. For example, to view the last 50 lines of a log file, enter the following:

tail –n 50 server.log

To continuously watch an active log file, use the –f (follow) switch:

tail –f server.log

More recent versions of the GNU tail command have a –F switch that follows the same log filename even when the underlying file is replaced. This is valuable for watching logs that rotate often. grep is a tool used to find lines in text files that match a given pattern. By combining tail with grep using a pipe (|), you suddenly have a very powerful tool for analyzing your log files. Let's say you want to see only log messages that refer to client disconnections. The following command gives you just those lines from a running log:

tail –F server.log | grep disconnect

If you are analyzing old logs, you might want to combine grep with a pager command, such as less:

grep disconnect server.log | less

The man pages for these commands provide full details on their usage and options. Additionally, familiarity with network diagnostic tools such as netstat and packet sniffers such as ethereal will aid immensely in debugging server operation and client/server communications.