[MUD-Dev] Re: Missing the point: OpenMUD, Gamora, Casbah, etc.

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

"Bruce Mitchener, Jr." wrote:
>=20
> On Monday, October 26, 1998, Ola Fosheim Gr=F8stad wrote:

> >Yes, and that leads to another question, why did it take years?
>=20
> Well, a good server and the associated things like documentation, code
> running on top of it to make it useful and so on do take time.

I didn't intend to imply that you can break new ground with a mud project
and do it in less than a year.  All (from scratch) mud projects will
probably take years, which makes the question even more important... It
could indicate areas in which one should be extremely careful with design=
,
or use existing code (at least in the first version), or "reverse enginee=
r"
an existing implementation...

> I appreciate a lot since I don't know Win32 stuff at all (yet?)).   My =
list
> of projects that I want to accomplish, when viewed with the amount of t=
ime
> that I have available, is probably something on the order of a year or =
so of
> work.

Heh, I've got a list of fun projects which would take several lives to
complete, if they are possible at all... :/

> >> base of code, it might be very profitable just to have a survey of t=
he
> field
> >> like that done to assess what the real state of the art is and where=
 the
> >> real problems are to be solved.
> >
> >Uhu, but that is a big job.  Although there is nothing wrong with thro=
wing
>=20
> Writing an excellent server framework is a huge job.

Yes, but doing a real survey (which should cover areas beyond the textmud
community) is more work than you want for a thesis... I'm not sure if any=
one
want to do that without even getting a _degree_?  Unless they already hav=
e
one of course.. (Bartle? :^)

> >fail to do a good job at it...  The basic goal for a commercially orie=
nted
> >mud server development project is obviously to create a foundation whi=
ch
> >allows for the creation of enjoyable user experiences, with the additi=
onal
> >requirement of minimizing cost (time spent on building, maintenance an=
d
> >money spent on infrastructure).  The goal doesn't help implementation =
much
>=20
> Well, there are lots of assumptions in here.  What is the difference be=
tween
> a 'mud server' and an 'application server'?  What about a general serve=
r
> framework (where things seemed to be headed anyway)?  How does an 'enjo=
yable
> user experience' fit in at this level?  Minimizing costs via reducing t=
he
> time spent on building and maintenance is great.  How will you improve =
on
> the current systems?  What problems do the current systems face?

I don't want to improve on them.  I doubt that they will ever do what I w=
ant
to do.  I will most likely have to adapt my own design to the low-level
bottlenecks of the server. I have to learn yet-another-not-really-excelle=
nt
language (I have had enough trouble separating the differences between LP=
C,
C, C++ and Perl).  I have to trust the server to be mostly bug-free.  If =
the
volunteers quit the project then I have to port all my code to a new
platform, or read and understand those 100K lines of code.

The difference between a "mud server" and an "application server" should =
be
that it is extremely real-time focused, that it support the dynamics of
muds.  If you look at the API then you should get a good picture of how a
mud could be implemented using it.

I looked at MudOS 2.5 years ago, and decided not to use it, not because i=
t
doesn't handle persistence well (you have to save the objects yourself, o=
r
rather...tell them to save themselves), but:

- It doesn't support 8 bit chars (I don't think standard YACC does either=
)
  which is vital to us scandinavians (=C6=D8=C5).
- I want some intelligent server/client distribution and I don't want spe=
nd
  too much time ripping out code and rewriting. Just to find out that it
  doesn't cut it anyway...
- It had a new dialect which I wasn't familiar with, and I am not all tha=
t
  happy with LPC anyway.
- There was no really useful no-bullshit basic functionality softlib
  available. And I guess the mudlib level debugging facilities were
  scarce. A development tool with no debugger is useless, especially if I
  am dependant on having a correct understanding of the underlying system
  written by somebody else.. :(
- The only reason for having an internal language from my POV is to eithe=
r
  support the problem domain (as with SQL etc.) or to  allow for safe
  userprogramming at a later stage. LPC doesn't support the domain better
  than C++ does, and security is done in the softlib (and looked like a
  major effort, I don't want to spend time on something  as boring as
  this...)

Maybe this is the right question to ask:=20

** What mud servers have you considered to use, and what made you refrain
from using them and rather start on the slow and painful process of
implementing your mud from scratch? **

Involving the users in the process is always a good idea. :^)

> current ColdCore lacks the modularization and documented (and enforced
> interfaces), which is one of the reasons behind my designing a new core=
 from
> scratch.  Sure, this can be solved, but it requires planning.

You are probably talking about regular structuring, but there has been a =
lot
of talk about modules and such and I really don't understand the need for
dynamic binding. I would prefer a static executable and migration of
serverstate (syncing the updated server with the old while running in
parallel) if downtime is undesirable.  I am not so sure if slicing the
system into executable modules by functionality as discussed is such a go=
od
idea, unless  it really reflects the dynamics, it is at least not OOP to
split objects this way. Then again, maybe OOP isn't the way to go (as
opposed to OOA/OOD)?

If one doesn't get anything else right in the analysis stage then one sho=
uld
at least have determined the dynamics of the system which is going to be
"simulated".  You can't do that without knowing something about what come=
s
on top of this bottom layer.  The most workable approach for most systems=
 is
probably to not only go bottom-up, but iterate over going bottom-up and
top-down. This implies that the more abstract layers (those closer to the
running mud) should be, at least roughly, designed in parallell with the
basic layer (core).

> >though, so you basically have to come up with something more amenable =
to
> >analysis. One possibility is to come up with a set of relatively detai=
led
> >descriptions of desired example systems, then try to find common
> >requirements that these systems imply. One will probably have to exclu=
de
> >some of these systems from the problem space in order to reach a base =
which
> >allows for the efficient creation of MUDs.
>=20
> So what is your desired system?

I am only considering inherently graphical muds.  User building should
either be visual, implicit or extremely simple and foolproof. I have
basically two interests. The first will not fit any existing development
system.  It is focusing at adaptivity and more organic physics oriented
systems thinking.  Meaning, spatial relationships rather than logic:
collision detection, density and sensing.  The basic problems are speed, =
the
client/server split (caching, updating etc), graphics engine and lag.. :(=
  I
don't really think the ?async? event model or threading will work well.  =
I
am thinking more about "pipelining" and running things in stages (makes f=
or
faster collision detection, sorting, change-notification etc).

The second interest is more typical, and is basically about prototyping m=
ore
"simple" graphical worlds where users can draw rooms and build things usi=
ng
simple mechanisms. Less simulation, and more atmosphere
(roleplaying/chatting).  What I want from this system is a system that is
adaptive under the hood. That is, I don't want to think about efficiency =
at
all, I want to think about changing and extending the system: a rapidly
evolving prototype if you like.  It should be easy to add constraints
without conserning oneself with implementation details, a simple example =
"in
area 2 : forall say_event E(from userX to userY) : distance(userX,userY) =
>=3D
5 : kill E".  The underlying system should profile usage and optimize
automagically (search-indexes etc). I wouldn't be unhappy if spatial
considerations and heuristics have been accounted for and are optimized t=
he
same way. (What is the closest object which smells like honey, etc)

More exotic is perhaps the desire for a entity-relation (state is recorde=
d
events?) oriented system where there are no real structure, but where you
instead define views and classes of relationships: "select all entities w=
ho
opened a bank account before 1996 (by event?) which are hairy (by relatio=
n?)
have lots of money (sum of events?)".  By "view" I simply mean transformi=
ng
some part of the database into something specified by a "client"
read-interface.  The "view" is notified of changes and will be recalculat=
ed
when needed (lazy).  This could be close to JCL's mud, but I'm not quite
sure... The basic idea is anyway to define object classes by properties
rather than by instance.

I am not sure if the softcode-oriented projects will be able to support t=
he
hidden profiling, adaptivity and general optimization which is needed if =
you
want to enable flexible and rapid development of the end product.

Anyone know something about the aspect-oriented programming paradigm whic=
h
Xerox Parc supposedly are working on??

> >An important observation: a smaller, more coherent and well defined pr=
oblem
> >space simplifies all development stages and makes a more useful result=
 more
> >likely. Nobody will use OpenMUD if it doesn't bring them _substantiall=
y_
> >closer to running a mud than using plain C++ and Unix...
>=20
> Don't forget really good documentation, FAQs, constant support, etc.  F=
or a
> long time, the complaint of those visiting the Cold Dark was that the
> documentation was inadequate.  Now, there are docs, but we still end up
> answering most of the same questions.  Now, we need tutorials, etc.  I'=
m not
> convinced that it ever will end. :)
>=20
>  - Bruce
>=20
> --
> MUD-Dev: Advancing an unrealised future.


--
Ola Fosheim Groestad,Norway      http://www.stud.ifi.uio.no/~olag/worlds/