Slashdot Mirror


IGDA Persistent Worlds White Paper Released

Elonka writes "The Online Games SIG of the IGDA has released the latest in a series of White Papers on the online computer gaming industry. The 2004 Persistent Worlds White Paper (80-page, 457K pdf) had several contributors from across the industry, and gives general "developer to developer" advice, covering everything from a quick overview of major products, to design considerations on multiplayer gameplay and dealing with online communities, to technical considerations, to some stats about the international marketplace, including the rapidly-growing Asian market. Editors included Daniel James of Three Rings Design, makers of Yohoho! Puzzle Pirates, and Gordon Walton, VP and Executive Producer at Sony Online and presenter of the Ten Reasons You Don't Want to Make a Massively Multiplayer Game talk at the 2003 Game Developers Conference."

2 of 72 comments (clear)

  1. Argh by daeg · · Score: 3, Interesting

    I am bloody sick of the MMOGs as of late. I want some decent single player games that don't suck. I have enough FPS games to last until the draft of WWIII, where are the cool RPGs and innovative games?

    I would consider playing an MMOG if it had a "single-ish" mode. I don't want to be disturbed by others, 90% of them are children anyway. Unfortuantely, they are necessary to support MMOGs as the primary clientelle.

    Skimming that paper made me dislike MMOGs even more. Bravo, if that was the intent.

  2. thesis project from 1999 by hin72 · · Score: 3, Interesting

    My undergrad thesis with a colleague of mine, back in 1999, was essentially a very, very simple realisation of persistent worlds. We created a three-dimensional version of Pong where all activity in one-half of the arena (in our case it was a cube) was handled by one machine. The other half was, obviously, processed on the second machine. The communication between hosts only consisted of periodic heartbeats and the movement deltas of the paddles. Rendering, I/O, physics and the predictive calculations were all done locally (i.e., the machine on which the person was controlling his/her paddle). When we took one machine offline, the user on the still-active machine was notified but was permitted to simply bounce the sphere against the interior of the cube until he/she got bored.

    Our game was written in C using Mesa (a 3D graphics library with an API which is very similar to that of OpenGL). Our development machines were IBM boxes running RedHat Linux 5.x. We got the rendering code all working on Solaris machines too. For networking we used UDP and referred to the Stevens book alot.

    The ultimate goal of our humble project was to split our arena into octants. Once all eight (8) machines were online we would remove N < 8 machines from the cluster and see how the remaining machines handled the loss of nodes. Because the network is no longer receiving heartbeats from a given machine, another machine would take responsibility and inherit all the process duties thereafter. Ideally, this transfer of duties is totally transparent to all who are watching and/or playing the game.

    What drove our desire investigate persistent worlds back in 1999 was my interest in Quake 2 CTF and deathmatch. To hop from one server to the next the user had to explicity exit the server and reconnect to another. I would have preferred if I could seemlessly "walk through a doorway in the game world" and find myself in a different environment. In the background, of course, all network traffic came from a totally different host running a Quake 2 CTF / deathmatch server.