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

[Bruce]

Good day,

I am a bit tired now, so I hope this makes sense and is coherent.

On Monday, October 26, 1998, Niklas Elmqvist wrote:
>On Sun, 25 Oct 1998, Bruce Mitchener, Jr. wrote:
>> Is there a reason that implementation must begin so soon?  Is there a
reason
>> that implementation must begin from scratch?  Why not take the time to
learn
>> about the existing projects, have people look into what has been done and
>> where it failed and where it succeeded?  Even more than having an
existing
>> base of code, it might be very profitable just to have a survey of the
field
>> like that done to assess what the real state of the art is and where the
>> real problems are to be solved.
>
>Duly noted. There are probably *lots* of lessons to be learned from all
>these projects, and others which were not mentioned. I also think we
>should try to talk with these people about mistakes, tips and other
>pointers. Why don't we start with you, Bruce? :)


I should've been afraid of that. :)

> - Which are the most important features DevMUD should support, judging
> from your background?
> - What are the key abstractions of the problem domain, in your opinion?
> (hmm, fuzzy question)
> - What to watch out for?
> - What did you do wrong?
> - What did you do right?
> - Any random wisdom you can share with us?

The Genesis source is fairly clean and well organized.  That said, there are
some really odd spots in it.  Currently, one of my big projects is going
back through the source and cleaning up the internal APIs and mentally
clarifying the boundaries of the modularized portions of the source
(although it is still a big monolithic piece).

Keeping things minimal in the driver and relatively policy free has proven
to be a large advantage when writing different applications on top of the
driver.  However, having the ability to replace softcode with native code
via the native method mechanism has also proven quite useful.

A big concern for these types of systems is in the security of the system in
the presence of untrusted programmers.  This seems to pretty much require
language-level support.  Provide enough information and capabilities at the
driver level, and the users of the system can implement their own security
system as it suits their environment.  I've seen 2 very, very different
security systems written in-DB in Cold, not counting any systems that
totally lacked security.

However, we currently have a large problem in that it is very easy for any
programmer to crash the system (as with other similar systems) if they write
code to create a large amount of data until the system runs out of memory.
This is really as easy as:

for x in [1 .. 100000000000000] {
        /* don't run out of ticks */
        refresh();
        y += "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
}

I'm working on some ideas in the area of resource accounting to handle this
issue, but this is largely unsolved as far as I know in the mud field.
Allowing free user-programming can be a pain.

I mentioned in another post the issue of upgrading databases for users of
the system, and the troubles of documentation.

>Don't get annoyed by these questions; I *know* Cold has a different design
>philosophy/purpose than our proposed DevMUD, but we are grateful for any
>help we can get. I am sure there are a lot of other questions which might
>beneficient to our cause, but I can't think of them right now... Please
>fill in with any information that you believe might aid us in our quest.


Note that through all of this, I did not design Cold.  I didn't originally
write Cold.  I've merely been working with it for a while over 2 years now
(including some commercial projects of my own and 2 others), and, since
July, I maintain the distribution and do development.  Now, I'm stuck making
a lot of changes. :)  However, I doubt that I'd be annoyed by questions. :)
I recognize that our philosophies differ, although I'm not sure that I've
seen any solid reasons for not doing a softcode system.  I'll be continuing
in that field for now.

>However, I am not sure we've ever said that implementation must start
>soon. What we're doing now can be characterized as analysis and possibly a
>bit of design. We probably need to formalize this in some way (i.e. write
>something down and make sure we can all agree on the specifics) and *then*
>enter the design phase. After we're sure we have a sound and solid design,
>we can move on to implementation. I know a lot of people are itching to
>get down and dirty with some code, but I personally believe we need to
>think and *then* code. And we'd better think good, seeing that this is
>a quite large project.


I suspect that a large part of my reaction is due to the overwhelming
presence of code and discussion of implementation details rather than
requirements, goals, etc.

 - Bruce