Quote:Original post by hplus0603
The size and shape of our zones is set by the operations staff, and can vary from one 100,000,000 square kilometers down to 25x25 meters or so. (Could be smaller, but then the quad tree starts becoming cumbersomely large :-)

If you have sparse players, Bob's your uncle -- you only need to instantiate (or page in) the parts where players actually are. Also, spatial culling will work wonders, giving collision tests only against a small subset of your world in any one step.

Those distances arent significant unless I then knew what the NPCs/Players sensor distances are (ie- 1km range with the 25x25m means alot of zones to subscribe to...). I would expect that you use smaller zones for interiors and extra dense areas of activity, but do you allow variable zone dimensions (and possibly irregular sections, tho still Axis Aligned..) or simple rectangles.


AAAAAAAAAAA
AAAAAABBBAA
AAAAAABBBAA ... B being a high content 'detail' zone
AAAAAABBBAA ... surrounded by an mostly empty A zone
AAAAAAAAAAA
AAAAAAAAAAA
AAAAAAAAAAA



I can use a sparse system (with rollout and creation/expansion on the fly) and even within the zones there is partitioning (I so far have a budget of 2000 'dumb' objects each). Each zone is a fixed data structure (65k at this point) with a local heap to simplify the rollin/out. Intelligent 'significant' objects
live in their own data space (and can rollin and out if needed).

There are actually 3 types of 'zone' -- one being a regular heightmap terrain 'chunk', another being 'structures' (an irregular navmesh) that sits ontop of the heightmap terrain which is also used for vehicles (and I suppose for terrain the heightmap cant handle) and a 'tunnel' type used for interiors (also a navmesh based).

Quote:The system design (client cannot change connections to cluster mid-session) is given and something that cannot be changed.

That seems to argue for a permanent proxy system, doesn't it :-)

Quote:Original post by Antheus
Just to clarify this. The system design (client cannot change connections to cluster mid-session) is given and something that cannot be changed.

In addition, the clients are unaware of any kind of clustering, so this aspects needs to be completely transparent. They also assume that any zone is available at any time and they can switch between zones freely and instantly without restrictions. The only physical separation that exists is between individual zones, but the transitions between cluster nodes within individual zone must be transparent.

So this is not about designing the latest greates MMO server. It's just a technical issue of retro-fitting an existing system.

You already made clear that the proxy server does the event marshaling and handles whatever routing is needed on the server side.


'Instantly' is something different when dealing with bubble worlds (teleport in and out, losing all dependancies with the old location, versus a transparent boundry system where the handoff needs to be as fast as possible and the player can still be effected by things on both sides of the boundry after the transition takes place.)


'latest greatest' is irrelevant. Im designing a system that ISNT a MMORPG and has significantly different specifications from a MMORPG (like really high powered AI that will eat most of the clusters processing capacity). BTW, some of the latest are still bubble-worlds because of the major problems (complexity, transition delays, complications, processing load) doing transparent boundries.


Im still not sure how your mechanism works with having multiple peer servers per zone. I would think that it would need centralized bookkeeping of some kind (for each zone) as well as for message dispatch within the zone's set of servers. If you have dynamic load leveling (within the zone) then even more overhead....