[MUD-Dev] common server design

[Chris Gray]

[Arrrghhh. On my second try to reply, 'sendmail' froze - but I was smart
enough to grab a copy of my reply from ramdisk before rebooting.]

This second attempt to reply to this message is likely going to be shorter
(everyone sighs with relief) than the first one. The first one got eaten
when a lightning bolt struck just across the river and made a power bump.
Whine, whine, whine...

:So who do you design your command syntax for, if not the users? And what
:in God's name are you thinking?

Mostly I design what seems reasonable to me. My goal has been to accept
a reasonable fascimile of natural English for standard commands, while
still having the expected shortcuts. In short, I aim for what I consider
to be a "good" parser. Please try it (see later post) and tell me what
you think. Be as specific as possible.

:What the server is like internally should not be reflected in the
:commands. What the people playing the game are expected to be like
:should be reflected in the commands.

I'd be less positive about it and say: what the server is like internally
should be reflected as little as is reasonable in the commands.

:Deliberate development implies a large amount of research and thought.
:Another word for this process is 'deliberation'. The parallel is
:evident.

Let me rephrase. I think the kind of stuff a lot of us seem to be doing
here is more related to "academic research" than to "commerical research".
The difference is that academic research is often more interested in
the exploration of "what if..." than in reaching any given goal.

:I see a lot of people going 'I use something unlike any other server!',
:and people that can't even spell are expecting me to believe that fifty
:years of computer programming theory has never produced anything as good
:as what they've written. I'm sorry, I just don't see it. Great men stand
:taller because they stand on the shoulders of those who came before
:them. To ignore the past, the history of the field, is to doom yourself
:to the same mistakes. That's why we have lists like this: to sanity
:check ideas. Evidently this one's totally whacked, nobody likes it.

Hmm. I had some nice reply here before... I don't want you to abandon
your MUD desires, or even this list. However, before any of us can
say much that is substantive, I think you have to give us something
substantive to work with. Give us some explicit suggestions to play
around with. Don't worry about many of us not agreeing with you - this
set of folks seems to be very positive-looking and agreeable, asside
from the occasional wars about certain topics...

:If it doesn't benefit (and look cool to) the user, why are you working
:on it?

Because I want to. "Cool" has never been one of my driving forces.
Certainly not "cool" as other people may define it. I much prefer
"fun" and "useful", and the much harder to agree on "nicely done".

:>    Don't use 	page <who> '=' '"' message
:>    Instead, use	page <who> <message>
:>	where <message> is the rest of the input line
:
:I made this exact same observation earlier in the discussion, along with
:the associated mention that this precludes the use of spaces in names.
:No response was ever made on the matter.

Sorry, I must have missed it. The volume on this list is getting pretty
large, so I have to skim a lot of it, else I wouldn't get any work done
on my MUD system! [It was about here that lightning struck...] Do people
find it important to allow spaces in user names? I thought about that
a fair amount, and internally my server doesn't care, but because of
practical reasons, it (and the scenario) don't allow spaces or punctuation
in names. I couldn't think of any reasonable (by my views) way of
handling them, and still have easy-to-use and English-like commands.
For example, how is a machine ('bot) supposed to parse spoken output
and find the part that is the user name and the part that is what was
spoken? Do you allow spaces in names but not allow certain words to
be used in names (such as "says")? Since this kind of scanning can be
used a lot in the system, I weighed the expense of some kind of general
matching and name-lookup against what I perceived as the benefit, and
decided to ignore the issue of such names. If enough real users complain,
I might rethink the issue.

:>This isn't super user friendly, but after a bit of practice isn't bad -
:
:It's the user friendliness that I think we need to QUIT IGNORING. We've
:done it far too long.

OK, what is your suggestion for a replacement form?

:What happens if you mix up the parameters? The more parms you have, the
:greater the chance that someone can inadvertantly do something they
:didn't want to do.

It's unlikely you will do something wrong, and if you manage to do so,
it isn't hard to undo. If you mix up the parameters, you will most likely
get a complaint, since there are a fixed (by the scenario) set of
"room types" and a fixed set of "directions", and a determinable set of
tables that you can define symbols in.

:>    @r new type indoors dir n
:>
:>or, if you like typing punctuation:
:>
:>    @r new type=indoors dir=n
:
:I see some problems here. What about when a direction isn't appropriate?
:What if a room type just isn't appropriate to the game system? Something
:I'd prefer to see is a series of atomic commands rather than batches;
:batches can generally be done using the programming language, after all.
:While it may seem tedious, building is something that is prone to the
:worst kind of creeping complexity; I would love to offer some examples,
:but I am incredibly tired. I'll post something more specific tomorrow,
:most likely.

Within my scenario, directions are the only think that *is* appropriate.
Out of curiosity, what other things would you want to use? Remember, this
set of building commands is part of the scenario, not part of the server,
so for some other scenario, the command would be changed if there were
no room types (or some other concept).

You want to do the simple room creation with a series of commands instead
of just one? If you really want to, you can get programmer status from
the administrator and do things the hard way - the point of the added
build commands is to make it easier to do the common stuff.

[Since my system has a full graphic client with sort-of GUI stuff,
the actual way I would build a room would involve a short series of
mouse clicks, plus some typing for the room's symbol and name. These
text commands were done before I realized I could use the mouse stuff,
and I've kept them for players who don't have Amiga's and so cannot use
the current client.]

I look forward to what you have to say on this tomorrow.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA