• Advertisement

Archived

This topic is now archived and is closed to further replies.

Issues in MMORPG programming

This topic is 6211 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
"trade secret" says it all

You can read up on how MUDs work, then you need to add quake-style position updates for the critters & players.

To distrbute the game across a couple of servers, you break the game world into areas, and run different areas on different servers.

Magmai Kai Holmlor
- The disgruntled & disillusioned

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • Advertisement