[DGD]DGD and Melville

[Stephen Schmidt]

On Sun, 14 Jan 2001, John West McKenna wrote:
> It's confusing.  I'm not really sure why Melville does things the way it
> does.

For Deeply Philosophical Reasons. :)

The idea is that you should distinguish between the person
playing the game, and their character in the game world.
Those ought to be, in most reasonable game designs,
separate concepts. user.c is the former and player.c
(normally) is the latter. It has a number of advantages.
If you want a player to change his game identity, you
can change his body without having to change anything
about his connection or identity. For instance, this
can permit wizards to assume NPC identities in a very
seamless way - just have their user object point at
the NPC body (and put their wizard body on ice in
the interim). TMI-2 mudlib has commands to do that.
This is also how TMI-2 handles death; destroy the
player's body (it's dead now, so you replace it with
a corpse object), clone a ghost object, and point the
user object at the ghost. Melville is a barebones lib,
so it doesn't do that sort of thing, but the capacity
is there.
You can also do possession (two users both pointing
at the same body), and dopplegangers (two users
pointing at separate but identical bodies) and a
host of other Fun Stuff this way.

If you wanted to, you could also have different bodies
for different races; thus, elf.c, dwarf.c, orge.c,
pixie.c, vampire.c. Then each race could have totally
different code. The only thing I ever knew that used
that ability was TMI-2's ghost object - the move_player()
code in ghost.c didn't include the check for doors,
so that ghosts could move through doors even if they
were closed and locked. You can imagine doing that
in a vastly more differentiated way to make real
serious differences between races. Doing that, you
could ultimately start to break down the PC vs. NPC,
player.c vs. monster.c distinction, which I thought
then (and still do) is important from a game-design
perspective.

Of course, there are practical advantages, such as handling
net-dead players (and this method would be even more
important, I think, in a persistent game).

> Melville seems to follow a similar path, but with a few little differences
> (for reasons that I don't understand).  It has the user object handling
> the player's email address and real name.  To me, that belongs in the
> player object.

It's because different users might, conceivably, run the
same game world character (and conversely, one user might
have several game world characters - certainly a wizard
might do that). The email and real name are part of the
real player, not the game character.
 
I think John's system and mine are essentially the same,
and I agree that, unless you want to switch to a single
user/player joint object, that's the method to follow.
I think one should have the two-object system for
theoretical reasons, but in practice there certainly
is some convenience to the single-object way.

Steve 

"Bill Gates' biggest fear is not that some kid is brewing up the next killer
app in his garage in Kenosha. His biggest fear is that some kid will brew up
the next killer app in his garage in Kenosha and Microsoft won't own it."
	Seattle Times, 4/1-7 2000






List config page:  http://list.imaginary.com/mailman/listinfo/dgd