[DGD] Re: A simple lib
Stephen Schmidt
schmidsj at union.edu
Tue Jan 6 18:44:18 CET 2004
On Tue, 6 Jan 2004, Robert Forshaw wrote:
> That's basically what I had figured. Why is this feature not catered for
> better? It means having an additional object for every user. Seems a bit of
> a waste to me.
I'll field that, not so much as the Melville coder (Melville has
this feature too) but as one of the people who did the first
MudOS implementation of that system back around 1991.
Two reasons to have separate objects:
1) It allows you to switch the player's game representation from
one object to another. This has all sorts of uses. We used it to
handle death. When a player died, their human body object was
dested and they were transferred to a ghost body object. The
ghost body object could be completely different from the human
body object. For example, the ghost body object didn't check
for doors in movement, so a ghost body could pass through locked
doors when a human body could not. It can also be used to allow
wizards to take over NPCs, which has role-playing uses. It also
allows you to update the user object, clone a new one, and switch
the connection to the new one automatically. You can also do
dopplegangers this way. There are many cool uses for the ability
to switch control from one living object to another on the fly.
2) It's better design. There is a distinction (or should be) between
the real-world human playing the game, and their game character.
In the two-object system, the connection object is identified with
the real-world human and the user object is identified with the
game character. (Last I looked, maybe five years ago, the kernel
lib didn't strictly follow this distinction. Melville does.)
Keeping this design distinction in the fundamentals of the code
makes it easier to do good game design later on. I presume the
same point is true of non-game applications, but games is what
I've used MUDs for.
Steve
_________________________________________________________________
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list