[MUD-Dev] Re: MUD Design doc (long)

[Emil Eifrem]

At 04:06 AM 1/2/99 , Travis Casey wrote:
>[Emil Eifrem:]
>> I have a distinction between player and character that I think helps; where
>> player is an actual rl person connecting to the mud, while a character is
>> one of possibly many in-game entities that that player may control.
>
>My own thought is that they should be separate where it makes sense
>for them to be separate, and the same where it makes sense for them to
>be the same.

I have to agree here! :)

>When I was working on Psyber Age, I set things up like this:
>
> - The "in-game" portions of all characters were represented by
>   "bodies."
>
> - The "control" portion of a character was either a shell (for PCs)
>   or a "mind" object (for NPCs).
>
>Thus, PCs and NPCs had bodies that were exactly the same, but the
>things controlling those bodies were different.  All the shell logic
>(alias expansion, etc.) was in the shell object -- and since NPCs
>didn't use a shell object, their commands didn't go through that
>logic.

Definitely. Sounds much the same as my player/character separation. Our
'Player' is an account associated with one rl human being. We intend to
impose severe penalties on using someone else's account in order to
restrict things like multi-playing, character sharing, etc. 

On that subject, how many of you guys have required e-mail authorization on
your player accounts (or whatever you may call them)? What are your
experiences? I would love to have that, but I'm afraid that it may scare
away new players. My current plan is to allow anyone to create a player
account without e-mail authorization but to limit their characters in some
ways. May not exceed level X or use the public mail system, etc.

>A couple of things I never got around to, but which should have been
>fairly easy:
>
> - Having one "mind" control multiple "bodies."  This could be useful
>   for implementing NPCs with group minds (Psyber Age was to be an SF
>   mud, so this was a consideration).

Yes, killer bees sharing the same mind and other stuff like that come to
mind. Pretty cool thing.

>> I use single inheritance for my world object hierarchy so multiple base
>> objects and other issues associated with multiple inheritance (I didn't
>> include the multiple-inheritance quote from your mail) won't be any
>> problem. The only immediate drawback I see about a global grammar is the
>> requirement to recompile your server in order to add a verb or command
>> instead of shoving that responsibility to the world scripting language.
>
>You could have a global grammar and still have verbs/commands be
>implemented in the world scripting language.  Lima does this -- verbs
>are LPC programs in the mud, but the driver handles parsing (verbs
>have to register themselves with the driver).

That's true. Unfortunately, my server is not that far to the soft side of
things that the above would be possible. Our scripting lang is designed
specifically for world manipulation and would be quite unsuitable for
commands programming. 

I have had thoughts of having major parts of the game logic in a scripting
language, but then I'd probably want to replace my old world scripting
language with one intended for commands (I don't *have* to do that, but it
feels overly complicated to have *two* completely different scripting
languages in a relatively small server project like mine) and that would
mean throwing out all the hard work I've invested in my existing language.


>> That inflexibility may end up being tedious and restraining on the
>> builders, such as when JoeBuilder wants 8 new small commands for his new
>> cool area, but will have to wait for lazy coders and the next code update
>> instead of just adding it dynamically by script. It may or may not be a
>> problem, depending on the length of one's code-update cycle and how
>> soft-coded one's server is.
>
>It can also help quality control, though... some of the eight commands
>that JoeBuilder wants to add may be synonyms for existing commands
>that he doesn't know about.

Very true. Which counts high at least with me. The above may be the
solution I choose after all.

-EE [emil at prophecy.lu]