After reading a few articles on MMOG architecture, there is still one point on which I cannot find much information: it has to do with how you keep in sync server data on the client, when you join, and while you play. A pretty vague question, I agree. Let me refine it:

Let's say we have an MMOG virtual world subdivided into geographical cells. A player in a cell is mostly interested in what happens in the cell itself, and all the surrounding cells, not more. When joining the game for the first time, the only thing we can do is send some sort of "database dump" of the interesting cells to the client.

When playing, I guess it would be very inefficient to do the same thing regularly. I imagine the best thing to do is to send "deltas" to the client, which would allow keeping the local database in sync.

Now let's say the player moves, and arrives in another cell. Surrounding cells change, and for all the new cells the player subscribes, the same technique as used when joining the game has to be used: some sort of "database dump".

This mechanic of joining/moving in a cell-based MMOG virtual world interests me, and I was wondering if there were tried and tested techniques in this domain.



1 Answer 1


The phrase that you're looking for is relevancy sets. Each player has their own list of objects that they care about (That are relevant to them.) As objects are removed from this list, a message is sent down to remove it from the client. As objects get added to this list, a creation message is sent down to the object. During the course of game play as an object state changes, messages are created to update that state on all clients that consider it relevant to them.

This is a bit of a simplification as some systems use multiple messages for create. (IE: Block out a model here, details will be coming, or here's the model and textures but no RPG mechanics are sent yet.)

I probably linked it a few times before, but a paper that discusses this is Distributed Object Views and was used on an MMO I worked on awhile ago.

Rereading what you asked, one thing to note is that commonly a cell can be subdivided per client. IE: The cell may be the entire portion of the world that the process owns, but for cheat-prevention and bandwidth issues the cell may only consider objects that are within 20-40 meters to be relevant to the player. The real tricky part is what happens when the player is within 20-40 meters of a cell boundary? At that point they are seeing objects from multiple cells that are relevant to them and those other cells need to proxy their data through the cell the player is in.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .