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

[clawrenc at cup.hp.com]

In <33ad365e.412609 at relay.mnsinc.com>, on 06/21/97 
   at 07:16 PM, caliban at darklock.com (Caliban Tiresias Darklock) said:

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

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

Most of the original list members are server programmers: myself,
Nathan, AlexO, ChrisG, Wout, etc.  In fact almost the entire
concetration of the list prior to this year was on such low level
implementation details.  I consider it a field which has received far
too little attention --- the basics of MUD server design have not been
fully examined in years.  Technology has changed since then.

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

You missed out on a lot of early discussion on this area.  (I probably
out to archive the Megami and CC lists -- anybody really want copies? 
Demand will encourage action).  Part of what you missed out here is
that many of us went thru exactly that process of examination of bits
and arrived at the conclusion that the basic apporach of most of the
servers we looked at was so flawed (or so different from what we
considered optimal), that leveraging the model didn't make sense.  The
intent was to blow the doors wide open and take a look at both the
field and what was possible in a new unit of time, and from *there*
derive what could be done -- not as an extension of prior
implementations, but as an example of what was technically
possible/feasible given current data.

For example:  I'm a big proponent of event driven servers, as compared
to the standard polling loops seen in almost every current production
server.  Once you go to a purely event driven model, very little stays
the same any more.  I also went a little further to a multi-threaded
event driven model -- *EVERYTHING* got changed.  The whol internal
language changed character as of a necessity, and the entire method of
approaching the server to program a game feature bears almost no
relation to damn near anything else because of that single choice.

eg  Even my IO socket handling bears no relation to the similar code
used in LP, DIKU, etc -- I have a pool of threads which mutually
compete to satisfy IO.  As far as the event processing is concerned,
everything, from a player entering a command to an object changing
state is treated as an event which is processed by a centralised
"Dispatchor" which orchestrates the timing of events, and is executed
by the "Executor" which thows a mass of competing threads at it in
order to get it processed.  Events can log further events, and that
daisy chaining is what creates animation.

There's not a whole lot if anything I could even attempt to borrow
from most current server models beyond gross ideas.  Certainly the
code is unleveragable.

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

I see the value here in determining what characteristics are good
about a particular implementation, not what details of the
implementation.  What are the fundamental characteristics of XXX
server that cause it to be easily leant to YYY types of
games/features...?

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

The old model is that a MUD can be divided into three sections:

  Server  <->  Library <-> Customisations

The standard approach is to provide only the first two bits (server
and lib).  The Imms then hack their bits atop that.  (cf Nightmare,
LIMA, Merc, ROM, LP, etc).   The problem is that the library is then
irretreivably tied to a particular model.  You won't get a library
which suppots level based systems __AND__ level-less systems, classes
and class-less, skill tree and skill web, etc.  

As I've commented before, once you get to defining the behaviour to
that level of detail you have inextricably tied the code to the model. 
There's too much interdependancy to be able to tweak one bit and not
have it repercuss all the way thru the rest of the library.  Good OO
design can reduce this a lot.  It can't remove the problem. Depending
on the models (starting and target) chosen I'd argue that often it
can't even come close.

>>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 an implicit grouping in the "we" here which I don't see as
accurate.  The list isn't a single distributed project.  Instead we
have all of several dozen independant projects going on, many of which
with extremely different targets and goals, who are as a group using
the list as an ideas test and generation bed and the rest of the
members as unpaid devil's advocates.  

This is not to say that I'd be adverse to a group of members getting
together to create exactly such a concerted project as you mention. 
Heck, I'd love to see such, its just that you appear to be assuming
that such exists currently when it doesn't.

As list owner here I'm not trying to lead a single concerted charge to
advance the state of the MUD world.  I'm trying to catalyse an
explosion, a diaspora of new ideas, implementations, approaches,
servers, etc.  The idea is to get people together and talking
constructively so that they can then go away and do something a little
more adventurous than MUSH MkII or DIKE 2nd Edition.  Think "catalyst"
and "peer review" and you'll get the idea.  

Then again, I'm sure that many here don't quite view it this
way...which is fine by me.  My intent is as stated above, and I see
that happening and so am satisfied.

This is not to say that you don't have a point on the interface side. 
Very little discussion has gone on about interfaces and user
presentation.  About the only one I can think of was my proposed
nested prompts ala:

  > get bag
  Do you want the:
    1) Red bag
    2) Tattered paper bag
    3) Mouldy sack
    0) Cancel command
  >> 2
  You take the tattered paper bag.

Which got minor support and extension, and a lot of derision, but
generated a long thread on the general area of handling user commands
which invoke long actions (ie actions which may last several RL
minutes).

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

Agreed.  I would like to see threads being less general, and getting
into the nitty gritties more of exact details of implementation,
presentation, design etc.  We have a lot of high level "wouldn't it be
nice if," and "yes/no/yes/no," type threads now.

>It's been mentioned on this list before that the planning phase and
>the documentation phase just aren't fun. 

For me the planning phase is the *only* fun part.  Writing code is
grunt work -- you already know what you're going to do, its just a
matter of expressing it in code.  The fun enters in figuring out what
you are going to do and how.   

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

I'm far too ambivalent on the values of this so early in the
development of the field to add signal here.

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

Disagreed -- I see game world complexity as being one of the few
aspects of a game which hold continuous value.  Quests, puzzles, etc,
once you solve them you're done.  Internal complexity leaves a very
lengthy path of finding and fiddling with the internal details and
intricacies of the world -- good stuff.

>The
>more complicated the game gets, the harder it is to add a new feature
>or enhance an existing one. 

Design rules and determines here.  Consider a simple parallel case:

  What would happen to our good old familiar physical universe if we
just went out and changed something simple, like say making PI == 3.0,
or just removing the Earth's moon....Follow the implications thru and
you get into a heady mess, quickly.

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

There's been a long and variously broken project to create just such a
modularised LIB system for MOO for quite some time now.  I don't know
if it is still alive. 

Problem:  Different servers have different base operating principles. 
Those principles require that the game world implementation function
in compleatly different ways.  Example:

  MOO allows verbs to be written which execute over log (RL) periods
of time.  This is necessary to allow because MOO does internal time
slicing, essentially cooperatively multi-tasking its world and users. 
It allows this by cooperative tasking by having methods explicitly
yield their slice to other potential consumers/methods.

  This model is not an option for me.  I couldn't emulate this one if
I tried.  The base concepts behind that model just don't map at all to
my model (well, technically I probably could, but it would be an
incredible mess with events doing explicit context saves on a yield
and resumed events reloading their context etc which gets incredibly
messy given my absolute requirement for events to be atomic and
killable during execution, and reschedulable without any effect on the
rest of the system).  No thanks.  Ain't gonna happen -- the base
principle the two servers work on are just too incredibly different
for there to be almost any cross-over.

Nathan's server model is about as different from mine as mine is from
MOO.  ChrisG's and Jon L's are also similarly different from each
other and everybody elses.  We're exploding out in mutually oblique
angles...

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

I'd love to see it.  

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...