Hundreds of multi-user games, ranging from simple Go servers to the more complex fantasy-based adventure games, populate the net in near obscurity in spite of its phenomenal growth over the past two years. The major impetus behind the explosion of the Internet into popular culture, the World Wide Web, has mostly been ignored by these games. Relying mostly on simple telnet as a client application by which you access them, these games have remained out of reach for users who see the Internet only through eyes of a browser.
The games originated in a time when dummy terminals were the most common method of accessing the Internet. Using telnet as the client application allowed these games to reach the least common denominator hardware and software combinations, thus preserving the potential user pool. As a result, while the servers of these games have evolved to perform complex natural language parsing and virtual environment modeling, the client side has been largely ignored.
Clients beyond telnet do exist for these games. In general, however, they tend to be small enhancements to the telnet interface with features such as command line history, mapping, triggers, and aliasing. In the final analysis, however, these clients are mostly ignorant about the server to which they are connected.
A recent attempt to move beyond this simple text interface is exemplified by Chaco Communications Pueblo client. This product makes use of Chaco's VRML plug-in with custom HTML tags to allow games to create 3D representations of their worlds. Games can make use of Pueblo enhancements while remaining backwards compatible with the telnet crowd with only minor server-end hacking. The Pueblo model, however, still requires end-users to download a piece of software that is not their browser.
At the most basic level, Java can clearly help to solve the client-end problems faced by multi-user games on the Internet. With Java, the game developer can create portable GUI clients accessible through a click on the appropriate web page. The greatest challenges posed by java are learning the Java socket library and hacking around bugs in java.awt.
Beyond the obvious mud-client revolution which Java has the potential of encouraging are more serious server-side implications. While using Java to build something a little more robust and friendly than telnet can help attract users to a game, it is only attracting users to the same old game. The Java paradigm, however, is much more powerful than that, as it has the power to change the way in which the games are written.
The Game Server Revisited
The most complex multi-user games servers are mud servers. This family of game, educational, and business virtual environments includes MUSH, MOO, LPMud, DikuMUD, and many other derivations. Complex command line interfaces, meshed with different ways of modeling virtual environments, are what they all share in common. The games tend to role-playing, most often, but not limited to, the fantasy sort.
Using its own proprietary method for creating an environment, each mud game stores area data and behaviour on the server machine. The only interaction with external machines are when players connect to the server using their client application.
Java presents the game developer with the opportunity to craft the server instead as a distributed gaming system. In a simple form, the server can store data and behavior about its virtual environment across the Internet. On a more complex scale, the game developer can abstract away from the client/server paradigm to truly distribute processing to the machines where that processing is relevant. Under this more complex scenario, the server becomes nothing more than an object broker passing along messages among clients.
The Distributed Server
Java empowers users by extending their world beyond their own machines. A simple distributed server can reverse this idea and extend development beyond a simple core with game host access. The following figure shows an object model for a simple distributed game server, outlining where on the network the classes lie.
Content dependent classes are built and stored across the Internet. The server implements a custom SecurityManager scheme that coordinates classes, loading them when needed and removing them when no longer needed. For example, if a player moves into an area known to be on a certain remote machine, the server attempts to load the relevant room class and create an instance of it. The server naturally needs to worry about such nasty things as an inability to connect to the remote server and load the class.
Security for such a system, however, would be much more complex. As with web browsers such as Netscape, you need to protect the server and the system on which it is running from rogue classes on remote systems. Unlike Netscape, however, a game server requires many shades of access that can seriously complicate the server. Though the need for browser-like file and network security is clear, the server SecurityManager also needs to provide robust mechanisms for preventing cheating. For example, on an insecure system, an unscrupulous player and builder could build the ultimate weapon, only accessible by that player.
The Fully Distributed Game
A fully distributed game contains all of the elements of a distributed server, except, instead of using the server to load classes, it simply retains smart pointers to actual objects instances being processed on remote machines. Whenever an object on one machine needs to send a message to an object on another machine, it routes it through the server.
Clearly, such a system would be immensely complex. At this time, however, only Java would make such an undertaking even remotely practical. And the benefits range from opening up multi-user games to a wider player-base, to creating a revolution in the way we actually play games. The challenge for developers, however, is to see beyond the traditional game architectures through to the new possibilities that Java provides.