[MUD-Dev] MUD Design Fundamentals (Was: Looking for

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

Jon A. Lambert wrote:
> I might suggest that major restructuring can be avoided through
> intensive OO design work ahead of time.  And this depends on how
> much time you've invested into your mud's specifications.
> 
> I'm a big proponent of an 80/20 rule in effort in Analysis/Design as
> opposed to coding.  It takes a bit of patience to spec' a brainstorm
> rather than immediately code it.

Absolutely true, but this depends on the understanding you have of the
domain you are working with.  If you are working within a well-known
domain, then you can go on and use a waterfall approach, that is:
design, implement, test, maintain.. If you are designing in a domain
with a lot of uncertainty, you would be better off with an evolutionary
approach: analysis, design, implement, test, analysis etc.

Hence, if you are doing a D&D type MUD design, you probably can go with
the waterfall model of the development process.

> Hmm, it may be more productive to use OOP or OOPL when discussing
> implementation concerns and OO, OOA, or OOD when discussing
> conceptual concerns.  At least I think(?) many OOers on the list may
> concur with this.

Yeah, except there is crossovers.  Besides what good is OOA/OOD going to
do you, when you don't have a real world to model?  Has anyone learned
something from OOA/OOD that they find invaluable when working with MUDs?
(I could come up with a few, but it would be interesting to hear what
others have to say)

> mentioned in another post the ease of editting flat textual
> information.  I think the editting information in "popular" database
> formats can even be more convenient or productive.  That depends on
> your toolset to a good degree.

I think I wrote easily-parsable.

> > You have to deal with realtime information, that changes between runs or
> > which is invalid between runs, either by not saving, cleaning up before
> > saving, cleaning up after saving or avoiding.  In a dedicated system, you
> > may of course hide that stuff.
> 
> Transaction based recovery and restart.  Look to database theory for
> solutions here.

I don't think this will help much..  Imagine this: you design a mud that
is partially based on the real world. That is, you place
sensors/detectors in the realworld, and those measures are reflected in
your virtual world.  Hence, if it is raining outdoors, it will rain in
your mud etc..  When your system saves state and reloads that state, you
somehow have to take care of whatever has happend in the meantime
outside the computer.  (Or avoid any dependencies)  The example is
intentionally far-fetched :)

--
* Ola Fosheim Groestad  (http://www.ifi.uio.no/~olag) *