[MUD-Dev] common server design

[Caliban Tiresias Darklock]

On Wed, 25 Jun 1997 19:25:38 PST8PDT, cg at ami-cg.GraySage.Edmonton.AB.CA
(Chris Gray) wrote:

>[Caliban:]
>
>:The user has to use the commands, so the user should be the
>:primary concern in designing a command structure.
>
>I have to disagree. User input is important, yes, but you cannot ignore
>the realities of implementation. Some ideas are just plain not workable,
>regardless of what uninformed users might think.

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

>:> Doing that stuff while ignoring what the server is like is bound to run into
>:> troubles.
>:
>:That viewpoint basically hammers a fundamental theory of object-oriented
>:programming, 

[snip]

>Sorry, I don't see your point here. Can you rephase?

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. 

>"Intuitive and understandable" are so subjective that they can easily
>lose all value as evaluators. As you say below, the concensus (hah!) of
>a group of people is generally of more value, so long as that group has
>enough background to be aware of most of the issues. The opinion of a
>large group of uninformed/inexperienced people is often not worth much.

Which is why I'm trying to discuss this here instead of on rgma or
something.

>I think you have to have a more strongly defined goal than that. What
>appears to happen a lot, at least from what I've gathered from folks on
>this list, is that people with lots of experience with MUDs (I'm not
>counting myself here, since I have almost no experience with MUDs outside
>of my own) have thought about what they find wrong with current servers,
>and have set out to try alternative stuff in the hopes that it will
>serve better. This is much more like research than it is like deliberate
>commercial development.

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

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.

>I think a lot of input from the user point of view would be valuable, but
>not directly applicable to the core of a server (I always tend to think
>of a server as being fully programmable, so that the distance from its
>core to user commands is quite large). 

Exactly. Which is why they do not need to depend on each other at all.

>The value of all of that user input
>is in how to build upon the core to attain the selected portion of the
>user goals. 

This is the way we've always done things. You design something that has
nothing to do with your end result, and then work toward the goal. But
let's try working inward -- start from the user, and say what does he
need? What does he want? And how can I get it to him? 

>Trying to exactly match any given set of requests from
>inexperienced users sounds like a recipe for failure to me. 

It is, which is why I wanted to discuss a variety of options and
viewpoints with experienced users and developers instead of taking a
survey.

>Paying attention to the requests is valuable, but following them exactly isn't.

Yes, that's true, which is why I wouldn't do that.

>Achieving an affect that
>appears cool to its users can be done by entirely non-cool internal
>techniques. 

But the end result is cool. QED.

>And vice-versa, unfortunately. Again, what is cool will
>vary from user to user, too.

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

>    - silly inheritance in LP that results in sillyness like 3K rooms
>	that are minimally different from one another
>    - ridiculous scripts in Mush that look like line noise victims
>    - poor command parsing in many MUDs (it isn't hard to add a little
>	bit of support for extras words, punctuation, etc.!)
>    - whatever...

All of these things are being used for cool purposes on the net. Except
maybe 'whatever', which I don't think is being used in a cool way
anywhere at all.

>In my case it arises from my belief there are a lot of hackers out there
>who will implement whatever seems easiest at the time, with little or
>no thought of future expansion. 

That's what I want to get away from.

>To me, such systems seem to be things
>that have mutated and sprouted cancers, rather than things that have
>grown properly with adequate resources. A good designer has to step
>back from time to time and ask if what is happening is good, and then
>be willing to redo stuff if it isn't good. Too many people hacking on
>MUD servers do not do that, and it shows. (Not that I'm claiming that
>I would never resist change!)

Yes, exactly. Which is why I think sitting down and talking about it and
planning things based on the *need* before the *implementation* will be
helpful.

>Question: are we talking about the user input in general to MUDs, or are
>we just talking about some building commands and ignoring the more common
>stuff? I've been assuming we're talking about everything.

We are. I generally use builder commands as examples, because they tend
to suffer from HUA syndrome more than the usual front-line commands. I
don't think much improvement can be added to look, get, drop, go, etc. I
did mention that 'give' could use some work.

>Got any specific suggestions you'd like to start the discussion process
>with?
>
>Here is one from me: (using pseudo-BNF type stuff)
>
>    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.

>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. 

>most people will have more trouble remembering the various room types
>(which just controls what generic room they inherit from), than in
>remembering the pieces of the command. 

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.

>Would it be more user friendly
>to have keywords for all the pieces, and default values, so that users
>could use, e.g.:
>
>    @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.

-+[caliban at darklock.com]+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 I am here to grind your eyes harder into the miasmic bile of life; to 
 show you the truth and the beauty in the whisper of steel on silk and 
 the crimson scent of blood as it rises to meet the caress of a blade. 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+[http://www.darklock.com/]+-