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

[coder at ibm.net]

On 28/08/97 at 03:19 PM, Ola Fosheim Gr stad <olag at ifi.uio.no> said:
>coder at ibm.net wrote:
>> On 19/08/97 at 09:55 PM, Ola Fosheim Gr stad <olag at ifi.uio.no> said:

>> Many, not all, of us here are discussing creating full worlds with no
>> concept of object or world resets.  As such persistance of objects,
>> and object changes are implicit to the world design.  The base
>> assumption thus changes from "save what we have to" to "everything is
>> saved by default, explicitly not-save what we don't want".

>Uh, well, in my opinion, persistence support
>(compiler/language/library) is great for rapid prototyping,
>especially if you have a graph-like object system, but there are some
>downs:

>1. even minor changes in datastructure may require a wipe, or some
>extra coding effort

No, this is a question of design, either of the system being modified,
or of the persistance implementation.  If either is insufficiently
robust, you are going to have troubles.

I won't posit that it is possible to create systems which there is
never a problem, merely that I've never run into a case with my system
such that this was a concern.  Most of my approach on this score has
been to make the representation layer free to rebuild anything it
wishes, whenever it wishes, and the storage layer free to (re-)locate
any object at any time for any reason (rebuilt or not).  Add a little
collusion between the two, and I haven't found anything to date which
required special handling.

>2. reloading may not give you what you want, it is easy to make
>blunders 

Who says that you have to reload text?  Why not make it orthogonal? 
Text, code, data, read, write, its all the same really.

3. fixing a bug in the code may not be enough if the bug is >present
in the stored structure.

Then make the code and the stored structure one and the same.  I fail
to see a reason for the persistance mechanisim to distinguish between
code and data.

>I only have some experience with persistence, maybe there are
>approaches that are better, but I know for sure that I wouldn't rely
>on persistence alone in any long term project.

???  I don't understand.  How could one rely on persistance alone for
a project?  Persistance is merely a feature of an implementation or
language which allows greater lifespans for structures and systems. 
Its a tool.  It doesn't actually do anything in itself.

Implementation can be either hoary or implicit.  My old system had a
fairly heavily exposed DB layer with implicit transactions and an
exposed cache and contention resolution.  The new system has hidden
the whole persistance aspect significantly, and the DB almost in its
entirety.  The cache is now utterly hidden, and the contention
resolution is only exposed to the extent of pass/fail.    Transaction
requirements however are more exposed -- there are always trade-offs.

>Well, actually, the guy with the original post seemed to ask for
>information on A LOT of fields,and quite specialized ones, and was
>still talking about "hobby" projects.  

I think what was missing here is that you came in late on the process
which engendered that post.  Many of the areas that Greg asked about
had frequently been discussed here, and I assume, were areas that Greg
has little familiarity with.

>...More advanced approaches
>usually results in increased codesize, more bugs, more
>interdependencies, longer compiletimes, longer development times,
>difficulties when making major changes etc.

While I agree in general, I think there is a limit to its
applicability.  On occassion the base approach decision for a design
affects and reflects into the entirely to the rest of the design. 
Occassionally that base approach is also complex.

Sure, it is, or should be, fairly easy to swap out a a list for a hash
table for a BTree or whatever.  However moving a base design from a
weighted tree or web to a neural net is a sufficient paradigm shift
that its rarely that easy.  In cases like that, if the principles can
withstand it, I recommend taking the big design and implementation
leaps early.  

>BUT I do believe, with the help of whatever libraries being
>available, some general programming knowledge and the major reference
>books, that "hobby" projects will be able to provide running systems
>exploring new concepts, provided that the designteam is able to focus
>on a few concepts.  I don't believe it is lack of specialized
>knowledge (such as NLP design) that prevents them from surfacing.

Agreed.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...