[MUD-Dev] common server design

[Caliban Tiresias Darklock]

On Sun, 22 Jun 1997 11:14:27 PST8PDT, cg at ami-cg.GraySage.Edmonton.AB.CA
(Chris Gray) wrote:

>I agree with your end goals, but I don't think your method would work, in
>practice. I think a better approach would be to look over the existing
>servers (and scenarios/worlds/mudlibs) to determine what is deemed to be
>good in them, and use that infomation to guide the building of new servers
>and scenarios. Actual code re-use isn't likely to work very well. 

Allow me to restate: '...rather than looking around and going "Let's use
the socket code from Diku and the builder code from Mordor and the
commands from TinyMUX and the database structure from Cold" ... let's
look at what *makes* these things good'.

In other words, the better approach you recommend is exactly what I was
proposing. I apologise if I was unclear; I am not suggesting that we
take snippets of this and that, post it to the list, and glue it
together. The end result of that would, well, to put it bluntly, it
would really suck. And your points about coding styles are correct; I
have my own coding standards as well. I'm more interested in defining
what the code should *support* than what the code should actually look
like. When you get down to that level, it just turns into a holy war
about things as ridiculous as where the opening brace of the code block
goes. (BSD style. Definitely.)

>The basic representations and standards are going to vary a lot between
>servers, so it would be difficult to convert anything other than the most
>basic of properties. 

Which is exactly why I don't want to waste ANY time at all on trying to
do it... like I said, if we don't concern ourselves with that sort of
thing and leave it to the people who have a need for it, we don't end up
supporting some hopelessly backward way of doing things. A lot of crap
survives in modern servers for compatibility reasons, just like in
modern operating systems. 

>I was quite concerned with the commands that would be available.

Then I'm sure you have some opinions and thoughts on the matter which
would be helpful. Not anything like a full grammar, but just
observations on what makes a good command set and what doesn't; for
example, someone mentioned recently that "dig" was a really bad metaphor
for creating a room. (Other people are saying that the room/exit concept
is totally wrong and should be discarded completely. I hear you. I don't
agree. I haven't heard a compelling argument on it yet.) There are a lot
of theoretical issues that really shouldn't be defined by a programmer,
but by the public; and since all of us here are gamers, we might easily
be considered a sample of that public. 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.

>when people are writing servers for fun, they are more
>likely to *want* to spend time on what they consider interesting. Making
>their system into a real live usable system for the masses may not be of
>much interest. It so happens it is for me, and (hopefully!) for the
>commercial folks on the list, but I doubt it is for all.

I don't begrudge people their God-given ability to write crap <GDR>, but
I also like to think that a significant number of us are pretty tired of
crap and would rather write something really cool.

I often see a sentiment expressed on this list (and others) that goes
something like "I am writing a server for ME to run MY game on, and I
could give a flying leap if you like the way I do it or not". If you
take a step back from that, you might wonder why someone with that
attitude even bothers to discuss their server on a mailing list in the
first place. 

>:I think complexity is something we should be trying to minimise. The
>:more complicated the game gets, the harder it is to add a new feature or
>:enhance an existing one.
>
>>From what I've seen on this list, some folks, as players, *want* complexity
>in the game they play. 

Allow me to clarify that complexity in the game *world* does not
necessarily imply complexity in the game *system* which does not in turn
imply complexity in the game *server*. What I'm really saying here is
that a complex command structure is not really something that enhances
the game; for example, you can have eight thousand skills, but a single
command to use skills. You could do thirty thousand calculations to
determine the efficiency of a sword thrust, but it all comes down to
'kill guard with sword' in the end. I don't have any problem at all with
complex worlds, systems, or servers; I have a problem with overly
complex interfaces. I would have a problem with an interface that
required commands like 'Draw sword. Lift sword. Swing sword. Parry left.
Block up. Lower sword. Thrust high. Lift sword...' or something
similarly complicated. If all eight thousand skills in your game had a
separate associated command (or worse, several), that would be a
problem.

-+[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/]+-