[MUD-Dev] distributed objects

[Kevin Littlejohn]

Hey all,

I'm reposting this from something I sent to our own development lists (for
Moebius) the other day - it's a musing on my behalf over the concept of
distributed objects, and how they fit in with general mud requirements - in
particular, things like fight systems, where certain behaviour is required
of an object.  I'm reposting it because I'm still thinking about this stuff,
and am hoping other, more knowledgeable types on here might have some comments
about this all, and whether I've gone seriously off the tracks or not ;)

  ------------------------------------------------------------------------

(Ramble about caps and object trustworthiness)

Ok, we were discussing the other day the whole 'objects interrelating' thing.
My original thought was that each object was an entity unto itself - the "pure"
object view, where nothing is changed in an object except by asking the
object to change it, and each object itself is master of it's own domain.
Interestingly enough, that's the first precept of the writings at
www.erights.org, regarding caps systems over distributed objects.

Phil's comment on that was that it's impossible to construct a decent fight
system, for instance, under that setup, because you can never guarantee that
an object has actually decremented it's hit points when it's been asked to.
The solution he had to this was a 'mediator' setup, tied into the caps system,
which I kinda like.  Basically as follows:

1) We have caps over various ops on various attributes of objects.  In the caps
world, this means we make a 'key', that says 'whoever holds this key can change
my hit points'.

2) We have objects talking to each other, if they want to let others change
their hit points, they hand them the key.  All well and good to here.  The
degenerate case is that every object has the 'set' keys to it's own attributes,
and 'get' keys for all other object's attributes.

3) Now we introduce mediators.  These would define a context of 'being' -
to join that context, you'd have to satisfy the mediator's conditions.  Those
conditions would be expressed in terms of keys - the mediator would say 'to
participate in this context, you're going to have to give me the key to set
your hitpoints, and drop it yourself.'  If an object chooses not to participate,
it's effectively ignored, and cannot use the facilities provided by that
mediator/context.  If it chooses to participate, it hands over the keys to
its hitpoints, and can no longer set them itself.

This seems like a neat idea - it allows us to move the world mechanics
completely into the world itself (no comments about defining a system
within the system being impossible, please ;).

I was thinking further about this today, after running across
http://home.devlocus.org/psion/prog/manifesto.html - someone's 3D distributed
object engine.  The major flaw in the above is that this all relies on some
way of verifying that the object is actually telling the truth about having
reliquished the keys.  We can guarantee that's so in our current case,
because we control the object data, but should we be paying some thought to
the idea of distributing the objects themselves - data and all?  How would you
guarantee that a remote object is behaving the way it claims to be behaving?
Is this the same problem EverQuest et al face with clients that have too
much information, and is there a solution?  If there isn't, does that mean
that multi-user games are ever and anon going to have to store all data
server-side, and perform all manipulations there likewise?

One alternative would be to enforce the keys thing above by migrating
object data to the server where the object relinquishes control over it - so
in the degenerate case, all objects carry their own data, but when they
choose to participate in a context, they relinquish control of their data
not only by handing the keys over, but by handing the data over as well.  This
has synchronisation issues, especially if the object is being used on
multiple different services (thinks sideways toward the idea of a single
avatar for multiple games, grins, carries on), but that might be an easier
to address issue than trust of remote objects...

Rambling,
KevinL

--------------- qnevhf at obsu.arg.nh ---------------
Kevin Littlejohn, Technical Architect, Connect.com.au
Don't let the Govt censor our access to the 'net -
http://www.efa.org.au/Campaigns/stop.html
---------- telnet mud.bofh.net.au 5000 -----------



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