Client/Server Interaction in the WorldForge Project
WorldForge developer John R. Sheets talks about the interaction between client and server applications in the WorldForge gaming system.
Client/Server Interaction in the WorldForge Project
The Altima Project started back in October 1998 with the ambitious goal of creating an open source version of the Massively Multiplayer Online Role-Playing Game (MMORPG) Ultima Online. People from around the world would connect across the Internet to an imaginary game world, and create fabricated characters to roam around that world gathering treasures, fighting monsters, and building up a virtual society of their own. The project soon outgrew this narrow scope, and after renaming itself The WorldForge Project broadened its ambition to include all types of networked games, in the Ultima spirit and otherwise. Where Altima was to be an online fantasy role-playing game, WorldForge was a generic online game-playing system for fantasy, sci-fi, and any other genre, with potential for role-playing scenarios, real-time strategy games, board games, text-based dungeon games, and whatever other online games people might like to develop.
The grand theory that breathes life into the WorldForge gaming system is the specialized interaction between client and server applications. In the WorldForge (WF) model, any WF client can connect to any WF server, negotiate a common set of assumptions, and begin playing whatever game the server is offering. If the game involves a role-playing world like Ultima, the client application might activate a graphical user interface (GUI) for creating and viewing imaginary player characters. If the game was a turn-based strategic game like StarCraft, the same client application might activate an entirely different interface. If the game server supported both 2D (third-person overhead) and 3D (first-person Doom-style) views, the client might allow the player to choose which style to use.
Such a flexible, universal connection scheme is no easy goal to achieve, and in all honesty has proven more complicated than we originally guessed. Early on, we began designing a generic protocol, code-named Atlas, which would act as the bridge between client and server.
The Atlas protocol is a specification of the language a WorldForge client and server must use to communicate. Regardless of what architecture and data structures they use on the inside, the clients and servers must translate their actions and data streams into the Atlas protocol before sending it across the wire. Although Atlas started out as an XML-based protocol, it has, in the spirit of WorldForge, broadened into a more generic specification that can take the form of XML for easier human consumption, or a compact binary form for more efficient transmission, or other forms as necessary. For convenience, all of this can be encapsulated by a wrapper library. The Atlas-C++[4] library provides a C++ implementation of this; other bindings in different programming languages may appear in the future.
In the two years since the WorldForge project began, we have produced a rich assortment of tools and applications, and a positively huge collection of quality graphics, music, and artwork, all of which resides in publicly accessible CVS archives. Quite a few client applications have surfaced, although only three are still actively maintained. UClient is the shining star against which the other clients are measured. Written with the Simple DirectMedia Layer (SDL) graphics library, it is by far the most mature client, and has been featured in all three WorldForge demo releases. UClient is the only client to date that can connect to WF game servers. The other two major clients are XClient, a very nice-looking 3D client, and Anvil, a GNOME client that is still quite rough around the edges. (Anvil is one of my pet projects; unfortunately, development on it ground to a halt while I worked on my book.) In the future, Anvil will likely become more of a game editor than a client.
WorldForge has spawned a potluck of server projects, too. Each of the three official demos has employed a different server. The first demo used a rough-hewn Java prototype server, quadas, to provide simple chat and movement. The second demo sported qserver2, an enhanced version of quadas ported to C++, which added rudimentary support for animations and more sophisticated movement. The third and most current demo, Acorn, introduced a storyline and multiple characters, and Cyphesis, a server written in Python with strong Artificial Intelligence support. The next major step in server development is STAGE, an extensively designed server model that builds on the successes of the previous servers and is theoretically capable of handling a full-blooded game world. STAGE will make full use of the Atlas protocol, as will all clients who attempt to connect to it.
WorldForge still has a long way to go in order to fulfill its lofty goals. The first year of development was somewhat chaotic and didn't produce as many tangible fruits as hoped; however, the time spent building and throwing away prototypes is now starting to pay off, as the lessons we learned help guide us to create better server models than we could otherwise. With the dawning of its third year of life, WorldForge is poised to make some serious waves in the online gaming community.
See also:
http://www.devolution.com/~slouken/SDL/
http://www.blizzard.com/starcraft/
About the Author
John R. Sheets has been following the GNOME project on a day-to-day basis for more than two years, since GNOME was only six months old. He is a software developer for CodeWeavers, Inc., where he works on Wine and GNOME. In his free time, he is helping the WorldForge Project to create a free online multiplayer gaming environment. John is the author of Writing GNOME Applications (Addison-Wesley, 2001), and the maintainer of the OpenBooks Web site.