[MUD-Dev] MUD Design Fundamentals (Was: Looking for
Jon A. Lambert
jlsysinc at ix.netcom.com
Sat Sep 6 01:02:58 New Zealand Standard Time 1997
On 2 Sep 97 at 21:40, Ola Fosheim Grostad wrote:
> >explain what you mean by "splitting objects". As someone who isn't at
> That's what changing the object-system was intended to mean. To change,
> add and remove classes. To do major restructuring.
I haven't heard of the term "splitting objects" either. Nevertheless
I willingly accept ANY terminology as long as we are able to share
conceptual understanding. This sounds like a specific task of
iterative design or development that I have done often. I have no
terminology for it though.
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.
> I wasn't talking
> about transforming instances, but in a pesistent system you would have
> to transform all instances of that class.
Surely. And this can be automated in a persistent system. It may
well be an expensive process. But one must remember this is a
development process. I do not see this activity as occuring very
often in a live and running mud. You may well have significant
concerns with a highly active user-base in a commercial environment.
This wouldn't be a major concern in my environment.
> I'm not used to discuss OO
> outside my university, except for a whort while on a oo newsgroup which
> ended in some kind of flamewar between those that only viewed oo as a way
> of extending a programminglanguage, and those that viewed it as a
> way to build a conceptual model of the problem space (the part of the
> world that your program cares about).
I wouldn't flame you over this. :)
> According to my OOA book
> "object system" is supposed to mean: The coming users perception of what
> the computersystem is used to admin, control or supervise. This
> wouldn't make sense in a MUD system however. When I talk OOP I take it
> to mean what concepts are present, and how they relate. But I use it on
> a conceptual level, not on an instance level.
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.
> >Diku's where zone files are parsed and loaded. We mean something where
> >stuff can be written back to the disk representation when it is no longer
> >needed (e.g. the caching mechanisms have decided to punt it to make
> >space for something else).
> OK. I figured quite a few LP's threw things back on disk, though not by
> caching. I'm probably wrong then. Of course most of the stuff in LPs
> are generated and not stored, though objects get compiled and cloned
> when needed.
Sure. I can't comment on what LPMuds are doing. But many of us are
doing "disk-based" systems and I think we all recognize the value of
cheap memory. I am using a configurable cache which can use all
available memory if I desire. I am also taking advantage of
multi-threading especially in the area of network and disk I/O. You
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.
> >There is more to persistence than saving the state of the entire system?
> >Huh? Please elucidate.
> 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
Jon A. Lambert
More information about the MUD-Dev