Imaginary Realities Imaginary Realities About Search Glossary
What's new? Index :)
Select issue:
Join a discussion Resources
     

Designing God
- Scatter ///\oo/\\\
How Young is Too Young?
- Holly Fanelli
Why do a 3D mud?
- Tommi Leino
The World Does Not Need Another (Diku) mud
- Jeff Bennett
I Think, Therefore I Role play
- Sanvean
The WorldForge Gaming System
- Bryce Harrington

Letters to the editor

Enter your email to be informed when this site is updated.


Comment on articles

Letter 1
Contact editors

   

The WorldForge Gaming System

by Bryce Harrington

Ever since the earliest days of computers, there has been a dream of creating immersive, persistent role-playing worlds that are free to play, and free to change - and graphics rich. Many, many people have tried to achieve these goals, and many have conquered *some* of them, but as of today, no one has ever achieved all of these goals. WorldForge's objective is no less than to be the first to completely satisfy all six of these needs, and to empower you with the tools to profoundly change the landscape of online gaming.
Dancing Queen

Furry dancing mud?

First though, how to achieve these non-trivial goals? The mud community succeeded in meeting all save the last; graphical muds have been notoriously difficult to bring into the world, even though many good people have tried. The problem that has befouled this community is the room-based architecture of most muds. To represent items graphically, the knowledge of how items are spaced geographically is absolutely necessary, and this really cannot be done without vastly re-writing the core game engine.

There have likely been thousands of attempts at re-writing the mud game engine to support graphical play. As one would imagine, this is no small feat, and indeed it has proved to be beyond the means of most amateur game developers. Commercial groups have been more successful at creating graphical online game engines; indeed, their efforts have been so successful that they've put a good sized dent into the once-titanic mud community. These games range from the literal "mud clone with graphics" approach of Ultima Online, to the more innovative approaches of iD, Blizzard, and other companies. Most of these games are not free to change, or can only be changed in a limited fashion. Few are truly free to play (most require the purchase of a game license at the very least). And most are not persistent; they are still trapped in the antiquated single-session context style of the old arcade games.

WorldForge is shooting for not only _meeting_ all of the above goals, but far exceeding them. Since muds have so successfully achieved most of the objectives, we look to them for inspiration; while no source code is shared with any muds, WorldForge's spiritual heritage definitely lies there. Muds have been the beneficiaries of decades' worth of open source development, and WorldForge's server software, too, will be free and open, thus allowing anyone with a permanent Internet connection to administer a game world and allow anyone to inject interesting new features into the code. Game persistence will be achieved in much the same way that muds achieve persistence: automating the bulk of the administrative duties, and enlisting the aid of a few gamers to be the game "operators". We hope to push on a little further, and make possible distribution of the game server across multiple machines, to provide further administration-automation capabilities, and to make it possible to have different "levels" of administrators, with differing levels of responsibility and capability.

WorldForge will provide not one game implementation but a framework from which infinite varieties of games can be built. We'll give you a well designed game implementation, to be sure, but we want you to think of it as nothing more than a (really good!) example (1), from which you can create entertaining challenges for everyone else, and to go into the niches that consumerist games are unable to explore. Want to see a Middle Earth WorldForge? A Furry WorldForge? A Star Trek version? ShadowForge? CyberWorld? MarvelWF? JediForge? No problem, have right at it and roll your own, with our encouragement and help!

In allowing anyone to run a copy of the game, we will force WorldForge to always be free to play. While we are not going to put a restrictive license on the game preventing pay-to-play use of the game engine, we don't expect it to be very profitable (not without a good deal of value added, of one form or another), when any John Gamer can set up and run their very own copy of the server. This freedom is very important to us; this permits those of us who are rabid role-players to create worlds in which people are required to role-play, while allows others to take the opposite extreme with more socially-oriented venues to hang out with friends, and only tangentially be part of a game. And of course, it will provide a means for those gamers intent on "kill, Kill, KILL!" to do so as they wish. Game companies that think they are cleverly appropriating "something for nothing" by adopting WorldForge code will in actuality be inoculating themselves with the open source philosophy, thereby (hopefully) opening game code to proper peer review and the benefits it brings.

By its very nature WorldForge will be extremely open to customization, on several levels. First, like with all GPL'd software, the source code will be openly distributed and users will be encouraged to dive into it, tweaking it for their own purposes. Ease of modification is an important design requirement we are placing on ourselves; the code we believe people will wish to modify the most will be kept in code modules we call "Toolboxes", external from the heart of the server, enabling administrators to dig in and add new features or customize as they see fit. (2)

For example, WorldForge is not dependent on any one particular combat system. It will know the basics of "attack", "defend", and "resist", and know the types of effects each of these can have on a character, but the exact mechanics are left modularized, allowing a rules developer to fold in their own notions of how combat should work all in one place, without needing to wade through the complicated server internals.

Toolboxes will be vital for economic system modeling. In order to get a stable, interesting, and believable economy it will be necessary to tweak this code little by little as play-testing reveals its intricacies. By exposing this code this capability will be easily reached.

But we imagine that few people want to spend much time hacking code, so are architecting it to be externally configurable via config files, scripts, and administration tools. (3) Indeed, it is our goal that, like in many of the more advanced muds, 90% of game customization and administration can be performed while the game is still running.

Thirdly, we wish to permit player-level game world customization. This is a feature found in most advanced muds, as well as a few commercial games. Players are allowed to "build" the game world themselves, house-by-house, wall-by-wall, and city-by-city. We would like to permit gamers to even invent new *types* of objects. We can model many of the low level object interactions (inventing a new spell from fundamentals, building a house brick by brick, or designing a new style of shirt by drawing a pattern and choosing fabric colors and textures). The player is then able to identify the object that they created as a new Entity Type, upload new graphics, descriptions, sounds, and so forth for it to a centrally accessible Media Server, and systematize the pattern they followed into a "Recipe" others can use to create copies of the new type of object.

Furthermore, in the hope of rekindling the interactive, story-oriented traditions of paper and pencil role-playing games, we will be including facilities and tools needed to set up and administer elaborate and engaging plots. After all, consumerist games seem to have perfected the hack and slash aspects of muds, we need something else to distinguish ourselves (wink!)

A fourth way in which WorldForge will be open to customization is via player-developed scripts. This is one of the consequences of a design decision made earlier on, that in the design of the server we would ignore all differences between a human-run character, and a computer- run character. (The implications of this decision have been widespread and quite exciting and beyond the scope of this article!) Many of us find enjoyment in designing programs to automate characters; others wish to write 'macros' to streamline the annoying chores; still others want to write slick tactical programs to give a distinct edge in combat. Rather than taking the fun out of the game, scripting will instead take the _drudgery_ out of the game, making it even more enjoyable. At the extreme, a character that is fully scripted is akin to a 'mobile', only better because it has a human watching over it, enhancing it, and in effect doing the AI development for the game administration, for free. In fact, we are actively engaged in the development of an application called Cyphesis, which provides the facilities for developing AI's in a high level scripting language. (4)

Finally, the whole notion of customization is taken to its logical extreme: the entire game system: client / protocol / server, is being abstracted to allow "mix and match" of clients and servers, even going so far as to using the architecture for a completely different type of game. To do this, we are developing a standard, generic protocol called 'Atlas' that will permit independently developed clients and servers to establish communication, even though they have never 'met' before. (5) Initially, this decision was made to permit us to have several clients under development: 2D iso, 3D first person, and text-based. But a protocol that abstracts clients can also be extended to abstract servers, and this has proved to be a major boon: Several independent game development projects have joined the WorldForge family, hoping to use the Atlas protocol so that they can focus on server development, and take advantage of the excellent client applications under development.

With all of these lofty goals, one could justifiably ask, "What is our current status?" We've been at it for a year now, and have much to show. An equivalent system would take a professional game development company several years to complete; as we're mostly volunteers and amateurs we expect to be at this a while longer. But we've got the luxury of being free to release interim developmental versions. ;-)

A few months back we buckled down and produced a prototype demo. It didn't do much, but it did demonstrate client/server communication, 2D movement, and chatting with other players. Since then we've been focusing on rewriting the prototyped bits properly, turning the 2D movement into 3D, and crafting an AI scripting application called Cyphesis. Client-side, we've added a 3D CrystalSpace client called XClient to the SDL-employing UClient and our other 2D clients. Make sure to check out the screenshots. (6)

As stated in the opening of this article, the key to success is _graphics_, without which the project could not succeed. Yet not only have we succeeded at garnering nice visual and auditory talent, it is the very sparkle of our crown jewels. We have nearly as many active graphic artists and musicians as active programmers (a rare position for an open source project to be in!) Our media archive grew to such volume that we had to break it out of the main CVS archive, and set up its own tree on the CVS server. In browsing the website, one can get a hint of the good work stored away in CVS; terrain tiles, vegetation, buildings, character artwork, animations, and beautiful rendered objects have been created and provide a stunningly solid foundation for future graphics development. We've got 2D tiles and sprites, 3D models and animated figures, MIDI and MP3 music, and much more. Our intent, though, is not to create all the graphics ever needed, but to instead assemble a media system into which new art and music can be added after release of the game, thereby harnessing the inspiration and talent of the players themselves. (7)

We're currently focused on a series of milestones leading up to the production of our next release target, a working game called "Acorn". This will be built using our AI engine Cyphesis, and will provide a true, playable game. We're keeping it simple and limited so that it is easy to implement; indeed, we've got most of the graphics generated already, and the server and client codes just need a touch of customization. We've also defined the area of our game world where Acorn will be set, and have mapped out the town and its people. Expect to be helping us beta test Acorn over the holidays and playing the released version at spring break. (8)

After that, we'll be diving into STAGE, the first implementation of our production server design. Right now we're putting the finish on the STAGE architecture and completing the prototypes we've been pounding on. We'll next be entering into a long design phase, and some time next year will be able to implement and then test the server in great detail.

We have a great deal of faith in our chances for success. The project is still going strong, a year since it started, and we have much to show for our efforts. As we peer down the road ahead of us, we realize that it is long indeed, but with each passing step another soul joins our column, and with each new ally our pace grows. If you'd like to directly help us in making this system real, please come on by our website at www.worldforge.org, hop onto one of our mailing lists (9) or stop in on irc.worldforge.org / #forge and chat.

Footnotes

  1. Our game world is Dural, a place to where Celtic immigrants seek to establish a new home in an exotic and ancient desertland. More on Dural can be found at http://www.worldforge.org/website/worlds/dural/ or join the Duralian discussion by emailing world-subscribe@worldforge.org.
  2. More information on our new server design architecture is available from http://www.worldforge.org/website/servers/stage/.
  3. The configuration capabilities of STAGE are discussed in the design docs for the Thor module: http://www.worldforge.org/website/servers/stage/thor/
  4. Cyphesis is documented at http://cyphesis.worldforge.org/
  5. You can learn more about our standardized protocol layer at our Atlas site: http://www.worldforge.org/website/protocols/atlas/. Also be sure to check the libatlas implementation in our CVS repository.
  6. Demo1 is obtained at http://www.worldforge.org/website/archives/downloads.html Our screenshots are at http://www.worldforge.org/website/media/screenshots/
  7. Our media page is at http://www.worldforge.org/website/media/ and is well worth a browse. ;-)
  8. A description of Acorn can be seen at http://www.worldforge.org/website/rules/acorn/
  9. A listing of mailing lists to be subscribed to is available at http://www.worldforge.org/website/tools/comm-tools.html