Does anyone know where you can find good technical documentation on how MMORPG''s are built -- MMORPHs on the scale of Ultima Online and Everquest. What I''m specifically looking for is issues in distributing the game over many servers and how clients interact with these servers; this would include all the general networking and management issues. If there aren''t any good documentation, can a knowledgable someone fill me in on this topic?

To get started on the distribution of the load without having to invest in multiple machines, make each separate database type operation a different program. User accounts, map changes, container inventory, NPC control, Tactical AI, and shop management are the ones we''ve started with. You may also need a main gatekeeper to help with the distribution. In our instance, we need it to facilitate adding more servers and distributing the load without exposing things to the client. Alternatively, the user accounts program could handle this as well, but I do not suggest it.

Use an abstracted communication class to communicate amongst the different programs. DO NOT HARDCODE ANY INTERPROCESS COMMUNICATION. If you end up needing this later, derive a new commnication class. Get it working on one machine, then move to two. Make sure it doesn''t matter where you put each piece.

Later, you can profile each program to see which programs might need to be on the same machine (for performance) or see if there are any critical optimizations that need to be done.

For more information, you may want to check out some of the books on distributed systems or large scale design. Since your servers will most likely be databases of one sort or another, you should probably study up on database design.

Our goals might be too lofty for this semester, but as of now, we only want to lay down the framework so that in future work, we can build on this.

Basically, we are writing a MMORPG game that''s not really RPG. Perhaps there''s a name for it, but I don''t know. The game will play like Quake or a third-person shooter. The key word is fast. Unlike Quake or UT, the levels will be massive and allow many people. Perhaps it will end up inheriting traits of traditional RPGs, but we are first aiming for speed.

We''ve only started talking about design, but we realize we require many servers across the country. That shouldn''t be a problem, as our professor has access to many servers around the country we can run applications on. The main hurdle we are trying to solve is how to effectively load-balance the servers to reduce lag. We will be dividing up the levels into areas manageable by many servers. However, in cases where a player from the West Coast and a player from the East Coast end up in the same area, the two servers (each located in its own local geographic area) must be able to replicate the data efficiently so that both players can interact with minimal lag. But what''s the best way to replicate the data between the east and west coast servers, and how should each server talk to their respective clients? I suppose you can simple wait for the two servers to communicate all the data before updating the clients, but that may introduce too much lag.

There''s also the issue of when servers should offload its management to other servers, especially when one server is suddenly bombarded with a high density of players. But that might become hairy, especially when you have two different players on two different servers that suddenly meet up. Then both servers (or at least one) must be aware that the players have crossed the "boundary" into another server.

I''m sure there are tons of issues I''ve missed. Platypus, thanks for the tips. I''m not sure, but I might have heard at least one company attempting (or maybe even completed) a distributed quake-like game. That''s something I would like to see.