[DGD]DGD and Melville

[John West McKenna]

Nightlith writes:

>I think I've started doing the hard method. I have user.c inherit creation.c
>and login.c but something isn't working. I was looking through user.c and
>login.c for some ideas and I have a question: how do those two function
>access player.c functions?

I'm not sure what you're trying to do, but you say you're basing your code
on Melville, so that's what I've been looking at.  I've only had a quick
look, so I could be wrong.

It's confusing.  I'm not really sure why Melville does things the way it
does.  There are two objects: user.c is what I call the "connection
object".  That's the one that sits on the telnet port.  player.c is the
player's body.  That's the one that does all the work of being a player,
including parsing commands.

So far so good.  That's pretty much what I've been doing.  You might ask
why there are two separate objects.  I didn't bother at first, but as soon
as I came to the problem of trying to re-connect net-dead players, I
realised why.  The connection object only deals with the connection.  When
the connection is lost, you destroy it.  But you keep the player's body.
When they log back in, they get a new connection object.  It then finds the
player object and everything is good.

In my system (using Melville terminology), this is what happens:

* player connects.
* the driver object clones a user object.
* the user object asks the player for a name and password.
* if they match, it asks the user manager to find a player object for that
  name.
* the user manager finds an existing player object, or clones a new one and
  restores its variables from the appropriate file (if it exists - if it
  doesn't it asks the player object to complete the login process, asking
  for all the information required for a new character).

The only information that needs to be set from outside the player object is
the name and password.  There are set_name() and set_password() functions
(with the appropriate security checks) for doing this.

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.

But, to get to your point: user.c inherits login.c and player.c inherits
creation.c.  login.c simply handles the basics of getting a name and
password (and email address and real name, for reasons that escape me).
creation.c handles gender and race and attributes and whatever other
details your players need.  There's no reason for any object to be
inheriting both.

You might be doing things differently.  If that's the case, and you're
getting tied in knots with the inheritence, I suggest you re-design your
system.  The one I've describe here works quite well, once you've got your
head around the separate connection and player objects (my previous LPC
experience was on a MudOS system with lots of code stolen from Discworld.
Things are a bit different there.  I greatly prefer this system - exec() is
a truly evil thing that should never have been created).

John

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