[MUD-Dev] TECH: Distributed Muds

John Buehler johnbue at msn.com
Sat Apr 28 23:24:10 New Zealand Standard Time 2001


Eli Stevens writes:
> From: "J C Lawrence" <claw at 2wire.com>

>> Why design your model so that the incremental unit in the working
>> set definition is so large as a zone?  What if the bas (world)
>> incremental unit was smaller, perhaps even at the individual object
>> level?

> ...

> I had been wondering about this myself.  Unfortunately, my relative
> inexperience with large scale systems make my ponderings less useful
> than they might be.  Still, what I had been thinking seems to match
> your question somewhat.  :)

> So...  Am I an idiot?  Would this work well?  At all?

> Suppose that the world is divided up into tiles that are a
> significant fraction of the average character's perception distance
> to some level of detail (perhaps at 300 feet avatars can recognize
> faces, so the tiles are 300 square feet).

The thing that seems so incredibly odd to me is the insistence that the
world be partitioned for processing along geographic boundaries.  I
mentioned it in an earlier post and have been holding my tongue here,
but I'll just quickly mention it again.

Partition the world along skill lines, or perception lines, etc.  Look
at the processing schema of the world that you're providing and see
what data and algorithms can be partitioned away.  Even those data and
algorithms that can't be *completely* partitioned may be related to
others along just a few, infrequently-touched schema connections.  In
that case, transferring data between those partitions would be
performed on an as-needed basis.

There's no question that some elements of processing will have to be
done on a geographic basis.  But I see no reason why processing power
shouldn't be applied to the different processing problems on a
partition basis.  This lets you design your blacksmithing system to
run on a certain class of machine, with as much customization as you
care to apply to the vagaries of blacksmithing.  Blacksmithing might
run on a small machine, while your collision detection machines might
be big, multiprocessor machines that have extremely customized code
and data structures that serve the single purpose of dealing with
collision detection.

The primary objection that was presented to this scheme is the
inter-machine communication problem.  The theory was that data flying
around between machines would simply be too much.  It was pretty much
left there.

I think that architectures like this will be more and more necessary
as a broader and broader range of entertainment is presented in the
same game world.  In a world where killing stuff is pretty much the
only entertainment, I can see how a geographic division makes sense.
In a world with many different kinds of entertainment, it would seem
that partitioning along new lines has promise.

Oh, one last mention.  As many forms of entertainment are introduced,
that much more data is going to have to be managed.  Scaling a game
over time by adding machines to deal with a partitionable set of data
and algorithms sounds pretty desireable.  The hitch is in determining
the viable partitions...

JB

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



More information about the MUD-Dev mailing list