[MUD-Dev] Architecture (Cell Rebalancing)

[Daniel.Harman at barclayscapital.com]

From: Rossmann Peter [mailto:peter.rossmann at siemens.com]
> On Tue, 01 Jul 2003 06:38:23 -0700
> Daniel.Harman at barclayscapital.com wrote:

>> I'd argue that this approach is over engineered. If player density

> It was overengeneered.  I have tried to draw new design here:

>  http://w1.860.telia.com/~u86015984/MMO-Grid-Cluster-v2.jpg

> all elements are actually arrays of the same elements.

> I am not sure about the AI manager. Should it interact with
> everything thru World Manager? Or should it be able to run it's
> own queries on spatial database and modify the Object database
> directly?

I know it will sound like I'm plugging this book as I mentioned it
in another thread, but it does discuss architecture issues like this
so you may be interested ['Massively Multi-player Game Programming',
Thor Alexander,
http://www.amazon.co.uk/exec/obidos/ASIN/1584502436/202-4712135-1906243].
I'm not connected with it before you ask ;) Did get a reply from the
author on an error I spotted though!

Anyway, I'm not sure from your componentisation what will be the
controlling process? Where is the main loop that controls game time?
Presumably it would be the Spatial Manager as that's the only part
that has sufficient knowledge of what is within interactive range of
other objects? Except that your world manager handles object
interaction...

That distinction between world manager and spatial manager strikes
me as likely to cause problems. Your game is likely to be making an
awful lot of spatial queries, so you don't really want it being in a
different process to the world manager.

Furthermore it looks like you are discarding with the idea of zones
here?  Not sure that is a direction I'd choose to pursue as it makes
your spatial queries potentially much more expensive?

Are you discarding with the idea of zones because I suggested they
were overly complex? Zones per-se aren't actually hard to implement,
its only if you want seemless transition that you get an issue as
you have players and AI potentially able to see/interact with
objects in neighbouring zones.  That's where the problems start to
occur. One solution proposed in the aforementioned book is to have a
border area that exists in both zones - pretty ugly and hard to
syncronise etc. An option I've considered is to have very small
zones, smaller than the visual/weapons range of the players, and to
have them updated with information for the surrounding area. E.g.

  P=Player Zone
  V=Zone player can see/interact with objects in
  .=Zone that contains objects that cannot be seen/interact with player.

  .............
  .............
  ....VVV......
  ....VPV......
  ....VVV......
  .............

This solves the problem of having players partially in zones or zone
borders, as the player zone is entirely explicit. The server would
send them relevant data from all the P and V zones.

The other nice affect of this approach is that it solves another
problem with transitional border areas. What happens if an object is
larger than the zone border? i.e. a wopping great dragon, which zone
is it officially in if it could be said to be in either. With the
micro zone approach, its only in one zone, and it makes no odds if
it slops over as it will still be in the working set for the player.

Anyway hope I've made some sense ;)

Dan
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev