[MUD-Dev] common server design

[Caliban Tiresias Darklock]

Chris Gray wrote:
> 
> [Caliban:]
> 
> :I think the command set is
> :something that really ought to be defined by someone other than the guy
> :writing all the internals of the code.
> 
> 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.

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

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

> 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 also like to think that a significant number of us are pretty tired of
> :crap and would rather write something really cool.
> 
> 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.

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. ;)
 
> :I often see a sentiment expressed on this list...
> 
> The fact that someone doesn't intend to be totally driven by the demands
> of "users" doesn't mean that person isn't interested in what users and
> other implementors have to say. Quite the contrary, I would say.

I usually see that sentiment expressed when someone says "I don't like
the way 
you did that and I would rather see it done differently". (Of course, if
the 
disagreement is expressed by saying "That sucks, you moron, do this
instead", 
then I can see a little outrage being perfectly appropriate.) When
someone says
they don't like what you're doing, particularly if they have a
well-reasoned and 
logical alternative, it generally indicates at least the *possibility*
that you 
really are doing it wrong.

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

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.