[MUD-Dev] Re: DevMUD Objectives?

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

(I'm replying to this one because it was the last one in the thread)

"Koster, Raph" wrote:
>  Thandor wrote:

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

Yep.  Nobody wants to WORK for three months before getting any kind of
pleasure from what they are doing.  Besides, learning C/C++ could be useful
beyond mudding, internal languages are not...  (A great excuse for wasting
time "look, I'm not actually spending my life on a game, I am learning how
to program, could get me a job")

The DevMUD team might want to consider to make the internal language thing
optional, and rather focus on getting their modular vision clean and
efficient.  If the DevMUD blackbox is going to be SEXY (and it better be if
it is supposed to attract capable module programmers) then they really have
to spend a lot of time working on the interfacing and API.  A blackbox with
an obfuscated interface and lots of hidden interdependencies that surface
every now and then is a total waste...

An entirely different approach would be to build a MUDServer-generating
language. That is, modules are written or wrapped up in a special purpose
language. Then the whole thing is compiled down to an efficient monolithic
unit. It could allow different modules to have their own opinion about what
should go into an object... (magic properties and hooks for instance) Thus
it could be fast and modular at the same time. Sounds like a researchproject
though...

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

Hmm.  Are there any graphical Dikus out yet?  The advantage with having an
internal language is that programmers are _forced_ to use the API.  Voila,
full encapsulation. Thus you can change things, without breaking too much. 
Of course, this doesn't work if you have everything at the same level... 
Which is why I don't think the internal language should be a typical general
programming language. The MUD answer to SQL would be nice...

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

Well, you can recruit from math/physics dropouts :-)  Actually, the most
active builders on Regensis was quite capable of programming simpler things,
but that might be a special case as it's only attraction was graphics. As
you might have noticed, a lot of people who are capable of programming are
also interested in graphics... (Quite a few musicians are quite capable of
programming as well, the first computer music was created in the fifties!
And musicians were supposedly employed as programmers because they knew how
to deal with programminglike structures (scores)) I think graphics can make
programming more fun, moving things and animating stuff isn't too hard to
do, but it looks good...  Some people can combine simple programming with
some good graphical designs to provide STUNNING effects compared to the
tools they have available.  (Nowadays you would probably want to have those
programs run on the client side though)  How many muds give visual artists
and composers expressive power? NONE to my knowledge (except from ComicsChat
and Palace, possibly Alphaworld).
 
> 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.

LPC isn't too hard.  You inherit stuff that makes creating your first
objects quite easy in most mudlibs too.  The hard part is getting the
sourcecode onto the server, compiling it and understanding the errormessages
(at least on the older systems, dunno about the newer ones).  Then again,
this prevents the most clueless users from writing too much bad code.
--
Ola