[MUD-Dev] DevMUD Objectives?

[Thandor]

I've been following the DevMUD thread closely and it's been interesting enough
to make me want to post. Keep in mind this is a somewhat loose collection of
thoughs, so bear with me if it seems to wander aimlessly in parts...

I'm just wondering what people are hoping to achieve with DevMUD. As I see it,
everyone thus far has had different objectives. Some just want to do something
that is extensible and flexible, some want to do something that's a nifty
piece of code, others want to make the mud platform to kill all mud platforms.
Frankly, I don't see these objectives as being compatible. I also don't see
the real point in doing either of the first two - there are already extensible
mud platforms, and there is plenty of muds that have nifty code. So my
interest certainly is only in the third - I see no point in doing DevMUD
unless it is to make it the best mud platform, so that's what I'm going to
give my thoughts on.

If we look at what has been done and been popular, one name imediately comes
to mind - diku. There is no doubt that diku derivatives make up the majority
of muds out there. They're also popular with players: I can think of several
for whom a online count of 100 is considered low. And finally, diku can be
moulded into a whole lot of things - hack and slash, roleplay, fantasy theme,
sci-fi theme, you name it, someone has done it with a diku based mud.

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.

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. 

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. I think it's a far more important thing that say, wiz bang
features, or brilliant code, or pure speed. Mere mortal programmers like
myself would like to be able to use it too - if you don't have that you end up
with something that is useless to the mudding community as a whole. Sure, it
might be the most modular, fastest, most advanaced mud ever dreamed of, but
what good does that do anyone if everyone sticks to their diku muds that they
can understand?

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? 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.
- 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.
- The real potential advantage I can see: It may be faster to write code in a
  well designed, purpose built language. However, I think this goes pretty
  much against the design goal some people are advocating of maximising the
  flexibility of the system. After all, the more you target the language at a
  particular style of mud, the faster it is to work with, but the less
  flexibility you have, no?

Which brings me to the whole modularity and flexibility concept. Some people
have been advocating a very pure sort of approach, with very generic modules.
While I agree in theory that is a good thing, but in practice I think it's
counter productive to be too generic. At least, don't go to the extent that
some people have been talking about - I don't think you should be able to use
a module from DevMUD in a thoroughly unrelated system. A mud has some
specialised requirements, and I think it would be better off keeping those in
mind when designing the modules, rather than just making generic
parser/telnet/bootstrap/config/etc modules and putting all the mud specific
burdon in the game module(s). Yes, it's probably not as pure an approach, but
I think it would keep things simpler and more usable in the context we expect
them to be used - running a mud.

Finally, graphical vs text based. I'm yet to be convinced that making a mud
that can be either graphical or text based is the way to go. Even assuming
that someone designs the "all encompasing graphical mud module" that means
everyone can work with only one graphics module in mind, wont allowing for
both the text based and graphical clients mean that everything needs to be
done twice, with regards to output? To me, that doesn't sound like much of a
fun environment to be creating a mud in, having to do twice the work
everywhere. I think deciding on a text based or a graphics based system would
again keep things simpler, especially given that most muds will probably only
want one or the other. I guess this comes back to flexibility - making DevMUD
all encompasing sounds great, but is that an achievable or even desirable
goal?

Maybe I'm missing something, but DevMUD is sounding more like a cool geektoy
filled with as many neat coding tricks as possible than something that anyone
is going to be able to use. The number of times people on this list who seem
to be very knowledgable when it comes to mud design have replied that they've
been unable to understand something, even at the very sketchy design level
being worked on at the moment sounds like a warning to me.

I hope I'm proved wrong though. With all the talent on this list maybe I just
need to have faith and not question the wisdom being thrown about. ;)

- Shane King/Thandor.