[MUD-Dev] Re: MUD-Dev's DevMUD: a word of caution

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

"Adam J. Thornton" wrote:
> It's basically Forth, isn't it?
> 
> Whether that is a good or a bad thing is open to debate.

Yeah well, I could care less about how it calculates expressions.  It is fun
though. Postscript does what it is supposed to do, it is flexible, easy to
generate, tailor and extend.

> A waterfall model, rigidly hierarchical, works reasonably well for projects
> which have full time staff and does not have a changing target to
> implement.  It is the latter that has caused most of the problems in recent

I haven't argued for any model or method.  I've argued for getting a common
understanding of the domain, what the main goals are, what the main
conflicts and trade-offs are etc..  I've also argued for not messing up
analysis and design with descriptions of implementation concerns.  Then I
have argued for making sure that there is a clear link to the end product:
muds with users on 'em.

> The first reason is more important for us: we *have* to go with a bazaar
> development style, because none of us are going to be putting in 40 hours a
> week for a year on this thing.  It will be a labor of love, done in our
> spare time, for the most part, and therefore will need to be done in small
> chunks.

A bazaar is as good a metaphor as a jazz group, soccer team and a bunch of
other metaphors :-) BUT you probably need to know the location where the
bazaar is going to be built, or the concert hall where the jazz group is
going to perform, or the field on which the soccer team is going to play... 
A common vision which is well received by the public is of course good. :)

(I like working with metaphors)

> We also need to consider our audience.  Is it the MUD community at large?
> Is it people writing new MUD engines?  Is it people developing commercial
> MUDs who don't want to reinvent the wheel?  I'm thinking it's either the
> second or the third.  And a lot of *those* communities are already on the
> list.  And we need to consider our ambitions: is the DevMUD (or whatever)
> successful if it's used in 2 systems?  20?  200?  2000?  20000?  The
> consensus answers to these ought to largely determine the direction
> development takes, because it strongly influences many of the fundamental
> design choices.

Quite right. You still miss the dynamic aspects of the system though.
(structure and content)  Although I would say it is at least partially
successful if you can easily and efficiently implement existing systems on
it.  I don't like typical DIKUs much, but if it is as small as people say
then making a better DIKU test implementation on top could serve as both a
teaser and as a QA guinea pig... (Read: it wouldn't be a total waste and it
would attract attention, and Diku is probably the bottom limit? After the
claims made so far, not being able to support a DIKU experience would be
plain embarrassing.)
--
Ola