[DGD]Inherit and include

[Stephen Schmidt]

On Sat, 26 May 2001, mtaylor wrote:
> We have a player.c
> which holds all the information for the Players Character (name, stats etc)
> and also the functions that deal with the connection stuff. Is this a bad
> idea?

Probably not. It simplifies things a little bit. There are two
reasons to have two separate objects, one practical, one aesthetic.
The practical one - you may want a user to be able to change the
player (or perhaps monster) object that he/she is controlling.
For instance, you might want a wizard to take over an NPC body.
Or you might want to have a player switch from a regular body
to a ghost body when he/she dies. (That avoids the problems
involved with a death shadow. You can also implement different
functionality in the two. For instance, the TMI-2 mudlib has
different move_player() functions; the ghost body bypasses the
check for a door, so that ghosts can walk through doors.)
The aesthetic one is that, conceptually, the real person who
is playing the game, and their game alter ego, are separate
entities; they should be represented by two different objects.
The Melville system of user.c and player.c conforms to this
aesthetic issue - all information about the real person (name,
email address, password) is in user.c, and all information
about the game alter ego (description, location in the game
world, stats if you add them) are in player.c. The kernel
mudlib does not quite conform to it - specifically, the
kernel's user.c (which is analagous to Melville's player.c)
contains some information about the real person playing the
game which, according to the aesthetic principle, should be
in connection.c (which is analagous to Melville's user.c).

But if you are not planning to do body swapping, and if you
are not concerned about the aesthetic design issue, then having
them as a single object is fine.

> Now if I have a close function in the player.c I have two big problems. One
> is that if I call destruct_object(this_object()) then it says Too many
> arguments for function close.

Wherever close() is being invoked, your are sending more arguments
than your close() function is planning to receive. Should be an
easy fix - just add the required argument to your close() function.
(If you are using the kernel lib, it is Considered Harmful to
alter the kernel lib, so if the close() function is being called
from within the kernel, don't change the call; change your function.)

On the other questions I defer to those more knowledgeable.

Steve



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