[MUD-Dev] Re: DevMUD Objectives?

[Koster]

> -----Original Message-----
> From: Thandor [mailto:thandor at donut.dhis.org]
> Sent: Friday, October 30, 1998 2:47 AM
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] DevMUD Objectives?

> Yet, diku is pretty low tech compared to some other codebases 
> out there. It
> has no internal language, everything is hard coded, the 
> "database" it uses is
> rudimentry, it's non-threaded, non-object oriented, etc. But 
> despite it's
> significant disadvantages, it's popular. I think it's 
> something that DevMUD
> needs to pay attention to.

There are a whole bunch of codebases which are of superior quality and
ought to be in widespread use. Cold immediately comes to mind. But there
are two audiences for a codebase--this is you intended "market" if you
will:

Mud wizards
Players who are thinking of becoming mud wizards

Now, among mud wizards themselves, there's a group that is savvy,
technically expert, desirous of moving on and expanding the horizon of
their game, etc. Among players, there's damn few. Is it any wonder they
stick with tried-and-true systems, ones with simplicity to them (and
mind you, even the SIMPLEST mud has a hugely high barrier of entry for
expansion & modification--something we tend not to appreciate)...

New mud code bases tend to fail because they are not easier to use than
the current ones, and because they do things too differently for people
migrating to be able to make a quick and easy transition.

> I'll tell you why I think it's popular - it's simple. The 
> design is simple
> enough to quickly understand. The code is simple enough to 
> skip to pretty much
> any place in any source file and quickly grasp what is 
> happening. Heck, you
> can get some sort of understanding as to how diku works 
> without really knowing
> C. The simple design makes it easy to understand, and easy to 
> modify - which
> encourages people to modify it. 

cf my long-ago post on Diku vs LP muds available at
http://mud.sig.net/raph/lpvdiku.html. This is spot-on: im my experience,
Dikus tend to be both more popular and, ironically, more innovative than
LPs. And I think it is because LPs daunt people trying to modify them.
Dikus have a simple "template" style architecture for building, and a
simple code structure. There's no concept of a mudlib. And I honestly
think that those concepts are some of the main reasons why Dikus are
perenially popular.

Also, I always shudder with horror when I see the amount of data folks
wanna track here. :) Legend ran for a very very long time on a 100 MHz
486. It also ran for a very very long time in a 10 meg space on a
University of Texas account. Dikus are small in both footprint and CPU,
in a way that more advanced muds tend not to be.

> I think that should be the number one thing to keep in mind 
> when designing and
> coding DevMUD - make it easy for someone to come along later 
> and change it to
> their liking.

The barrier to entry to change a Diku, however, is coding ability. Which
frankly, the best people to be doing mud design generally don't have.
(You badly need writers and visionaries and dreamers and social
butterflies to make a mud--and most of them tend not to come equipped
with CS degrees). Hence the fact that most Dikus are heavily modified
and still indistinguishable from one another.

> Next point, and maybe my opinion is tainted here from my 
> heavily diku-based
> background, but what is the aim of the internal mud language? 

It is the single thing that is the biggest add to a Diku-derived mud.
Trust me, I speak from experience. :)

> I can think of a
> few reasons to want it, but only one that is really compelling:
> - It makes things modifiable on the fly. This is something 
> the diku world
>   doesn't have, but I can't see the big deal anyway. So you 
> have to reboot
>   every few days to add changes, it takes 30 seconds and many 
> muds these days
>   have copy-over which means players don't even have to relog.

This is not actually the main attraction. The main attraction is that it
allows the builders greater rein to make what they want to happen
happen. Most mud builders on Dikus have to settle for whatever stock
special behaviors exist already, or wheedle a coder into making them
happen. With a well-designed internal language, you can make it all
happen yourself.

> - You can give "non-techies" the capability to "code". This 
> sounds great in
>   theory, but all reports I've heard of how it works in 
> practice is that
>   nearly all the code gets writen by people who would have 
> been writing the
>   code anyway. So you've now forced them to learn a new 
> language, and then
>   write code that runs slower, and gained nothing.

If you are going off the how it goes with MOBProgs (a pale imitation of
a real mud language, and not even as robust as the original Diku
internal language it is modelled on) then that's a bas place to get such
an impression from. A good internal mud language can indeed be simple
enough to allow non-techies to write in it.

If you're going off of robust softcode systems such as LPC or MUSH, then
I agree with you--the reason for this is that the systems are not easy
to use.

[snip comments on modularization & on graphical vs text]

If we ever release Legend's code, it will be an unabashedly Diku-derived
mud, with area files and the works. But it will hopefully be able to
parse area files for all the stock Diku muds; provide customization and
access to Legend-specific features via config files read at runtime, or
by adding additional sections to the classic Diku-style area file (eg,
you add a #WEATHER section to start getting weather effects, so you can
quickly upgrade stock areas); and have all of the "new" things it offers
be fully optional.

-Raph