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

[Jon A. Lambert]

On  9 Sep 97 at 7:43, Ola Fosheim Grostad wrote:
> Jon A. Lambert wrote:
>
> 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.
>

Through iterative specification and analysis comes understanding of
the domain.  I don't see how one can proceed to implementation and 
testing without significant understanding of the problem domain. 

I'm not entirely sure what the problem domain of a D&D type mud is.
I would be hard pressed to define it close enough that others on this 
list would find satisfactory. The waterfall approach makes sense in 
common business problems where domains are well-understood.  In muds, 
if one is redesigning or rewriting an existing code base then yes, a 
waterfall approach seems productive.  Keeping in mind, that many 
existing codebases lack the specification typically required in an OO 
design.  

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

I'm puzzled by this question.  The process of analysis is building 
models of your proposed "world" whether it's real, fictitious or a 
combination of both.  Methinks you are taking the OO methodology
too literally.  Your virtual world concept is the real world you are 
modelling.  If there is _nothing_ in your virtual world that you
can model with a real world metaphor then you are in some difficulty.

> > > 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 :)

The scenario you present is far-fetched but nevertheless can be 
handled.  If sensor/detector subsystems exist external to the mud, 
the unprocessed collected data can certainly be fed into the server 
at startup, mud time can be advanced to the current time with no 
data lapse.  This type of setup is currently done in many commercial 
and scientific applications.  

If you are not talking about THIS kind of realtime information (in 
your example), what sort of realtime information are you really 
interested in?

In my design, when the server goes down mudtime stops. When the 
server begins mudtime begins again exactly where it left off.  
I don't believe I could do this without transactional processing.
A transaction forms the wrapper around application dependencies and
is atomically independent of any other transactions.

--
Jon A. Lambert