WorldForge Community

Proposed zone based visibility system.
Mmo worlds can take huge proportions and trying to send all entities, all terrain data and all updates to every client connected to it would be folly. There needs to be some selection to decide what is visible to a client and what is invisible and irrelevant to a client. A system like this should be in place sooner rather than lather as it has hooks in a lot of subsystems mostly on the server but on the client as well.

Let's look at the problem in more detail. Ideally a client should only be able to see and receive updates from what is immediately visible to him so is in it's visual range. It is however not feasable for the server to check for every entity if any entity it is within visual range every time he moves or needs to send an update. Even if you would remember which entities are visible, the server would have to check the distance from every entity to every other entity on a regular time interval to update this information which is far from optimal.

To overcome this obstacle an mmo server needs some sort of spatial awareness so entities can be grouped together geographically in relation to others. For this subdivision I suggest a closed square zone grid.

It is easy to see that if we put every entity in a zone that it can only be seen by entities in the same or nearby zones and should only provide updates to those entities and no other.

This is the theory, now follows a more in detail proposal of how I intend to handle this.

First of all the zone system will consist of a zone manager on the server (cyphesis) which keeps track of the zone grid generated at server startup or potentially loaded from file in the future. Every entity in the world is assigned a zone by the zone manager based on it's location and every zone keeps a list of connected entities. Zones also keep track of a list of clients (in the broadest sense of the word) which are interested in what is happening in this zone from here on referenced as listeners.

Now if an entity wishes to announce an update it will send this update to his zone which will in turn transmit it to every listener. Listeners can be connected to multiple zones.

This is best explained by an example. Let's take a player as a typical example of a listener. We attach the player to a zone and the 8 zones surrounding that zone, then he will receive updates from everything in it's immediate surrounding and no more. Now while the player moves about, it occasionally checks with the zone manager if it is still in the same zone. He is unregistered from the zones it has strayed too far from and is registered with the zones he is now closer to. These checks do need to happen at regular time intervals (+-every 3s) determine if comeone is in a square zone is as simple as checking if the x and y coordinate are within the lower bounds and the higher bounds of the xy coordinate of the left upper and down right corner which has very little overhead.

This system can be further refined by making the zones smaller but connecting to more than the 9 zone grid I've used in the example here.

Possible optimizations:
When dealing with heavily crowded areas it would be good behaviour performance wise to reduce the size of the zone dynamically. Smaller zones mean less network and server overhead in general but a smaler area of visibility.

Other potential uses for this zone grid:
The zone system is not limited to entities it can be used for landscape aswell.

Extending the zone system to client as well will allow it use zones to determine which entities and which landscape it can completely unload.

Modern mmo content apart from resources such as models, etc is partly static (not retransmitted every time) and partly dynamic. Usually to update the static content, regular patches are used. But what if you could have the best of both worlds. Create a list of static entities in the zone, and assign the zone a version number that is incremented whenever the static contents changes. When a client enters a zone it will receive the version number from the server and compare it with the version number of the same zone the client has stored locally. If it doesn't match send the version number of the client's version of the zone back to client. Based on that version number the server can determine which static content the player is missing and transmit it. This way you have static contents you can update dynamically with a minimum in overhead.

It seems like a lot of work but I've already implemented something comparable on cycli.sourceforge.net which experience in the area and code could help me get along in this project quicker than projected. I'm also very familiar with development on *nix operating systems so that wouldn't be an issua.
I'm confident I can get this quite far and even implement some/all of the other uses or optimizations I've mentiod. In addition to that, worldforge can really benefit from this. Limiting visibility is definitely needed and currently missing. I know this is largely a server based issue and not part of ember but it lies in my area of expertise which is more server based. If you rather would have something more in line with the idea list let me know. And as always suggestions are always welcome.

The AI can determine proximity based on the same zone system

Thank you for reading and considering my Application.

Karel