Distribution schemes (was Re: [MUD-Dev] Languages for MUD drivers)

[Ian Macintosh]

    > Bruce Mitchener, Jr. wrote:
    > Sent: Thursday, 18 November 1999 13:03
    >
    > Ian Macintosh wrote:
    > >    > I've always thought this was an extraordinarily poor
    > >    > way to handle it...
    > >    > Unless you have a truly enormous number of players,
    > >    > don't you end up
    > >    > shifting areas from server to server as players and
    > >    > groups move, in
    > >    > order to achieve load balancing? Wouldn't event-based
    > >    > distribution work
    > >    > much more cleanly?
    > >
    > >I'd agree with that Greg.  But that is really
    > dependant on how you
    > >design your software.  In the first place, I am, as
    > you say, trying to
    > >load balance, but not to the nth degree.  Rather, I
    > want to find
    > >logical breakpoints where I can split the 'world', and
    > thereby achieve
    > >a fairly equitable load sharing.  Of course, what this
    > means in the
    > >normal Aber/Diku derivatives that we all seem to run,
    > is that you
    > >would put different zones/areas on different servers.
    >
    >
    > This would fall victim to the phenomenon of 'flash
    > crowds' or 'stampeding
    > herds' or whatever it should be called.  With this type
    > of static
    > distribution scheme, you can run into some trouble if a
    > large number of
    > users (or objects, or whatever) decide to go visit some
    > area on a single
    > server.

Can't fault your logic there Bruce.  I've run enough quests to see the
stampede they cause, and watched the old 'top' display move my task
impressively high on the list.  I only mentioned that because I don't
see any other way of doing a split on Aber/Diku systems.  Personally,
I'd consider it crazy to actually try and implement it that way.  If
you're gonna do that much work, bite the big one and start from
scratch.

    > >You could of course split those tasks any way you like, but the
    > >concept should be clear from the example.  What you
    > really want to do
    > >is ensure that any particular part of the project can
    > be handled by
    > >one or more servers in your server farm.  If you do
    > that right, you
    > >don't need to concern yourself too much about where
    > the right place to
    > >split would be.  If you find you allocated too few
    > servers for the mob
    > >AI for example, you just add another server and split
    > them into 3
    > >groups instead of 2.
    >
    >
    > Why does AI get treated any different from any other
    > client connected to the
    > game?  (Making a lot of assumptions: clients aren't
    > accessing world via flat
    > text that they just display, like telnet; that there
    > are clients; etc).

Heh.  You clicked onto that one fast enough.  You're quite right.  I
don't treat mobs any differently to normal players.  What the AI
server actually does is log on *as* the mob, and then plays it just
like a player would.  The code I'm fiddling with now tries to do a lot
of clever stuff, and I've spent a few months studying up on ALife (try
www.google.com and type 'ALife'.  There's too many excellent
references there for me to spam you with it all).  Despite the
facination with the whole concept, and some really nice and nifty
things you can do with it, I eventually decided it simply wasn't
feasible.  Testing it out showed that I would only get around 4 active
mob's per server if I was going to do it that way.  No can do.

I've been fiddling with some of the more basic ALife ideas.  Dunno if
it really classifies under that banner though.  Here's a simple
example.

You have a few properties on mobs.  Thirst, Hunger, Fear.  Now each
mob will only obey one 'drive' at a time.  Each drive gets a chance to
calculate it's importance, and the one with the highest value wins.
That way, the thirstier an antelope gets, the closer and closer it
gets to the waterhole, even though it can see the lions.  Finally, the
lions nail one of the antelope, and the rest get to drink.

Even with that kind of simplification, I'm still biting deeping into
the CPU.  Also, I'm on very early days with the AI system.  I'm
getting all kinds of 'strange' behaviour from the AI code that I need
to get to the bottom of before I can say if it's even feasible.

It was because of my AI requirements that I started looking at
distributed processing.  There was no way to do it on one CPU that I
could see.

Regards,

Ian Macintosh.




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev