[MUD-Dev] common server design

[Chris Gray]

[Caliban:]

:> To a certain extent, yes. But, the facilities available in the server
:> will influence what make sense in designing the way in which things like
:> rooms, objects, commands, etc. are put together.
:
:However, this also results in the commands being fitted to the server
:instead of
:the user. 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.

:> 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, which is that no part of the program should rely upon any
:knowledge
:or assumptions regarding the rest of the program. If OOP is appropriate
:for a
:MUD server, then OOD should also be appropriate. You design each object
:within
:the four groups mentioned previously (user interface, command interface,
:network
:interface, and game system) as though anything whatsoever could be
:interacting
:with it.

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

:> If you
:> have a concept of separate "exits" (I don't), then any support in the
:> server for them should be considered, and vice versa.
:
:If you have no concept of anything, the server must by necessity support
:an
:intuitive and understandable method of describing in an effective
:fashion
:something that the developer would never in a million years have thought
:of.
:It's the 'intuitive and understandable' parts which bog down some
:servers.

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

:> You can't do the
:> two completely separately, since the base of the scenario is dependent
:> on the server and what it does well.
:
:I expect the server to have a very broad but well-defined goal, which is
:to run
:text-based multiplayer online games that are easy to interact with.
:Given that
:goal, certain types of games (Quake, chess, connect four, poker,
:scrabble, word
:search puzzles, crosswords, etc.) won't really be appropriate. Neither
:will some
:potential applications (operating systems, device drivers, compilers).
:While I
:am sure some weirdo somewhere is going to complain he can't use RPC in
:his
:mobprogs, I don't think that necessarily means we need that in the
:server.

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.

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). 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. Trying to exactly match any given set of requests from
inexperienced users sounds like a recipe for failure to me. Paying
attention to the requests is valuable, but following them exactly isn't.

:> Certainly, but I think it is unwise to equate "cool" with "useful". In
:> real life, the best way to do something may not be cool at all.
:
:If you're trying to create something cool, then the best way to do it is
:by
:definition something cool. QED. There will obviously be some limitations
:and
:restrictions the final server inherits -- try to be everything to
:everyone, and
:you end up nothing to nobody -- but I'm really hoping we can create
:something
:that will flatten the learning curve without overly diminishing the
:power. In
:my opinion, that's pretty cool *and* pretty useful. You may disagree, of
:course,
:since that's your prerogative.

I guess it depends on how you think of "cool". Achieving an affect that
appears cool to its users can be done by entirely non-cool internal
techniques. And vice-versa, unfortunately. Again, what is cool will
vary from user to user, too.

:Another point might be that there is a lot of useful crap out there,
:too. Think
:of the most horrendous misfeature of a server you have ever seen in your
:life
:(no, I don't have anything in mind, but I'm sure it's not hard for you
:to come up
:with one) and I can almost guarantee that someone out there is using it
:for something. If nothing else, *you're* using it as an example. ;)

Well, given my almost total lack of experience with other MUD systems,
some things I've seen so far that really didn't appeal are:

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

:The willingness of people to believe that my example of a pathologically
:bad
:command line for a game server was a *recommendation* pretty much
:demonstrates
:people's expectation that a game server's command syntax will be
:unusable and
:cryptic.

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

	This arises mainly from the lack of external input, I think;
:there are
:things I find intuitive, and things other people find intuitive. Since I
:am a
:longtime gamer, experienced programmer, and network administrator...
:chances are
:I would find something 'intuitive' where many other people would find it
:just
:plain confusing. I might, for example, think that a good syntax for
:making some
:object inherit another objects properties is by using a command like
:
:	create child uses parent
:
:But someone else could look at this and get confused. Obviously, the
:Java people
:among us will likely think this is perfectly logical, although an
:argument could
:certainly be made for 'extends' instead of 'uses'. Someone else might
:prefer to
:have the commands separated -- for example, 'create child' and 'link
:child parent'. Other people will of course have different ideas. But the
:problem with
:both approaches is that it isn't really descriptive of the parent/child
:relationship, and doesn't spring to mind instantly when trying to make
:one
:object the same as another object.

I wouldn't have any problem with that sort of distinction. My solution
would be to accept any of the keywords that people are likely to use
(or use none at all, and rely on position). The things I have problems
with are excess use of hard-to-type punctuation characters and escape
mechanisms. (Background: I also immensely dislike the syntax of things
like shell scripts, nroff/troff, some of the perl stuff, etc.)

:Which is why I like the idea of getting together in a sort of round
:table
:discussion about what makes a game server's command interface good or
:bad, and
:how it could be made better. That way, even if the discussion goes
:straight to hell and degenerates into flamage, we see some other
:people's opinions. We should
:all at least get one or two ideas from this sort of discussion, since
:even when
:someone just says 'a command like X sucks' you might think of a way to
:fix it or
:a new command that doesn't suck.

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.

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

Given that the builder commands in my MUD are part of the scenario and
not the server, I can likely throw together stuff to try them fairly
quickly (assuming I'm not deep in something else, of course!). The
problem is more likely to be in the basic concepts in building. As I
said, I have no such thing as "exits" as separate entities, and I also
have no concept of "objnums" or anything like that. The latter just
doesn't make any sense in my system. When you build a room via a command,
as in:

    build room new north indoors in Chris's new room

you get a new room that is linked to the north of the room you are
currently in. You can then move to it and decorate it, change its
connections to other places, add entry/exit restrictions, etc. You can
also give it a symbol in a symbol table, for later reference. Oh, the
above is parsed according to:

    <generic command: build, alias @>
    <build command: room, alias r>
    <room building command: new>
    <direction to build in: north, alias n>
    <room type: indoors>
    <room name: "in Chris's new room">

This isn't super user friendly, but after a bit of practice isn't bad -
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. 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

?

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