[MUD-Dev] RP=MUSH/PG=MUD

[Caliban Tiresias Darklock]

On Fri, 20 Jun 1997 20:18:49 PST8PDT, Adam Wiggins
<nightfall at inficad.com> wrote:

>[Caliban:]
>> 'here we have a group of servers that does this part well, and here we
>> have a group that does that part well, so why not look at the
>> possibility of doing something that combines the natural strengths of
>> the two types, a sort of hybrid server?'
>
>*nod*..this is what I desire, and I think most folks think that this
>is a Good Thing(tm) too.  However, there seem to be large disagreements
>of what the 'good' parts of any given server (or, more signifigantly,
>game type) are.

A lot of effort appears to be directed at locating the good algorithms
and internal representations of the object model, rather than the
high-level things which make a good game. What I'm looking at here is
the general idea that people prefer certain things; we never seem to
discuss the actual end-result, but the idea of how to represent a
specific effect. I think in any system, there are several things that
need to be handled, but 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" -- which of
course would be like using all the leftovers you have that aren't moldy
to make a casserole -- let's look at what *makes* these things good (and
I'm not saying any of the above are necessarily the best examples
available), and see if we can't come up with something that would be as
good or better.

>We're always talking about this _sort_ of thing, I think, but it's
>usually in very general terms rather than in terms of actual
>functionality you want to lift wholesale from a certain server.  

No, no, no, that's not what I'm proposing! I'm proposing that we look at
what works, and use it as a guide -- with the aim being to take the good
parts, see why they're good, and try to put them together into something
better. There will of course be modifications, because there's nothing
out there that's *perfect*; more to the point, what I'm looking at is
the possibility that if we assume the people using the server know
absolutely nothing about anything, how can we best provide them with
something intuitive and easy to use? This means that none of the admins,
imms, imps, gods, wizards, or whatever you call them have any
preconception about how the MUD ought to work; let's assume they would
spend a lot of time posting messages to mailing lists asking how to do
very very simple things, and try to answer those questions in the
documentation and help. Let's try to make a server that takes next to no
effort to install, run, and use, and free up these people to actually
improve the game itself by adding new spells and classes and races and
let them do all of it without having to recompile or reimplement
anything at all.

>As you've said, any hybrid worth its beans would have to be from-scratch,
>forgoing a lot of the assumptions and setup things that have kept
>existing servers from heading this way.

If we operate from the assumption that no one is going to need to bring
a database or area in from any other server, and leave any desired
conversion utilities to standalone programs designed by people who need
to do that sort of thing... that could free up our ability to define
what really needs to be in the server. If we work from the idea of
making the player happy, rather than the builder and the programmer,
then we could possibly come out of this with something really great
that's long overdue.

>> There's a lot of talk here about internals, and next to no talk about
>> what finally ends up on the screen when a user logs on. The user is
>
>It depends.  I recall Wout's list being a lot less technical, but maybe
>I just wasn't paying very close attention.  About 6 months ago the
>list went *very* technical and I didn't post for quite a while; it's
>actually gotten quite a bit better with the recent influx of so many new
>people.

It's not the question of technical versus nontechnical; it's more a
question of directed effort. The server developer is obviously concerned
more with the code that runs the server than he is with the command set
it results in. We end up with an interface and command structure that
happens almost as a side effect.

>Depends.  I'm not interested in making my game accessable to a wide number
>of users.  I *am* interested in making it more playable, fun, and enthralling
>for the users that I am targeting (namely, those who like to play the same
>kinds of games I do).  One thing my parter and I have always paid very
>close attention to is making sure everything works in an intuative way.

But the question is whether you're allowing new people who WOULD like to
play these same kinds of games an appropriate opportunity to learn the
game. No game is going to make *everyone* happy, but to create an
interface targeted at people with a specific area of knowledge can
unfairly lock out some very promising players. A related problem area is
the all-too-common lack of documentation in servers; as should be
evident in this post, I have four major problems with the majority of
servers available.

	1. Lack of documentation.
	2. Nonintuitive command structure.
	3. Complex and difficult building interface.
	4. Lack of system flexibility.

What all of this comes down to, in my opinion, is a lack of proper
planning and design. I think what happens is that the developer has a
really cool idea, and just jumps in and starts writing code. (I've been
guilty of this myself.) When he hits a snag, he ducks and weaves around
the problem. At the end of the process, there's this huge mess of code
that could have been a lot better; and it's so tightly integrated, the
problems are now difficult if not impossible to fix.

It's been mentioned on this list before that the planning phase and the
documentation phase just aren't fun. I think that's a good point, but I
also think that we have a large enough community that we could possibly
get the planning done in a sort of open forum, even before the code is
actually being written. If we create something that has clear and
compelling advantages, then people will *want* to write to the standard,
and it won't be a question of my project and his project. If we build a
set of 'desirable' server qualities, and put forth a little work here
and there toward implementing those qualities, we can end up with a
project that really doesn't *belong* to anyone. It would be something
that is a property of the community, like it should be. It would reflect
the wants, needs, and opinions of the people who are actually expected
to use it.

>Even the most intelligent and experienced gamer will be turned away if he
>can't figure out how to interact with the game.  Ours is particularly
>bad since the game world is so open-ended (no easy-to-define goals from
>the moment you start playing) and so complex (no simple list of special-case
>rules as with a pen and paper RPG).

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. Tight integration for speed and power is a good
thing until you want to build on it; there's no place to slot your
changes and concepts in, and when you try to shift things around, you
break things that you thought weren't even related. One of the things
I've been looking at is trying to separate the four sections of the
server I mentioned previously on this list; basically, setting them up
so there is a very simple API in between them and anything that conforms
to that API can replace a section. Sort of like FOSSIL drivers for
serial interfaces; a FOSSIL driver abstracted the serial communications
required for a program into a simple interrupt-driven API which nearly
anyone could support. Any DOS programmer could learn the API in a matter
of minutes, and add serial support to an application with a few hours of
work. 

I think we could do the same general thing with a MUD, allowing someone
to easily plug a new command set or builder interface or programming
language or server core into the game. In other words, we could make it
modular, with any and all of the modules interchangeable within their
own function set. Working to this sort of standard would allow us to
write whatever weird and wonderful things we want, with the assurance
that as long as it conforms to the API it's going to work well with
other pieces. 

Furthermore, if someone has a great plan for a new command structure, he
wouldn't have to go reinvent the wheel by building the server core that
handles network communications. He could build just the module he has a
great idea for, and be confident that it's going to be linked to a
working additional set of interfaces. 

This separation of function would also allow a programmer to quickly
isolate any problems to a specific module, improving debugging. If
someone keeps getting booted form the server, the problem could not
possibly be in the command structure or programming language, it must be
somewhere in the server core. If we provide an effective debugging
model, we could make even the location and repair of bugs effectively a
no-brainer. 

If we could cooperate on a project of this type, and set aside the 'X
sucks Y rules' sort of thing, I don't really see that it would hurt
anything. It may help; there are probably a lot of people out there who
could improve their own designs just by watching the thread. Even if we
don't actually build a server, we can still have an impact on server
buillders, whether it might be the design of a full server based on what
we come up with, or just a few modifications to a design in progress to
reflect something we said that was considered a Good Idea. I certainly
don't see that a discussion of the matter could have any detrimental
effect.

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