[MUD-Dev] Object and class heirarchies -- are they really nec essary?

[Nathan F Yospe]

On Tue, 21 Mar 2000, Koster, Raph wrote:

:> My favourite benefit of this approach is the same one that e.g. Diku
:> has over most LPMuds... that you nail down in the implementation of
:> the single physical class the entireity of the feature set... and as
:> a consequence, all physical objects are guaranteed to respond sanely
:> to a known set of actions.

:This is what I referred to as the great strength of Dikus--they are
:template-based muds. The template constrains, but only insofar as the data
:set that the template provides. If you can expand the template and supply
:default values to objects that have not been manually updated with new data,
:then your constraints pretty much go away without having to subclass new
:object types, etc.

Funny thing - the first version of Physmud - the one I had running as a text
mud - was actually a port of a set of worlds written for a modified Diku to
a more flexible custom engine with a file interpreter that read Dike format.
I've still got the last version - which I still play with from time to time,
and still plan on finishing eventually - but occasionally I start to get
fed up by the limits currently present.  I never thought I'd say this, but I
miss the quick-feature-add of putting another field or two into a text file,
giving it a default, and editing in the value on a test object/thing.  Now,
I do the same thing, but I have to work in the global physics of the feature
before I can activate it, and test it for consistancy...  Dikus are nice,
because Dikus are simplistic.

Still...

I use a global base for all physical objects, one for processes, and one for
relationships.  Inheritance from these is dynamic; the source code doesn't
have a clue what the object heirarchy is.

Processes cover verbs, continuous behaviors, triggered/scheduled actions,
etc...

There is inheritance for processes.  All inheritance is potentially MI, but
some MI will not lead to results - inheriting from two complex objects will
not create a hybrid mutant - no chair-dogs that try to be both - because a
complex object is instantiatable, and objects derived from multiple
instantiatable objects are considered bad and not loadable.

Objects can be *assembled* from multiple complex objects, by linking them
using relationships.

An object must be made complex to be instantiated or used in an assembly.

Processes are also complex/basic and can be assembled using relationships.

Relationships specify dimensional, temporal, or complex connectivity, and
can be coded...

This means that, if I wanted to create a new attribute for all physical
objects, I could easilly do so... but a builder could not.

Fortunately, attributes for physical objects are very narrow in focus.
They include parametizable things like mass, energy, material, state,
temperature, life (sorry, I know, but that's how I did it), shape,
dimensions, density, density gradient, velocity, position, orientation...

All of which are interdependent, and some of which are complex themselves.
A new material is a bitch to design, having hundreds of parameters, quite
a few of which are variable by state.  Materials can contain binding to a
process, but not to a spacial relationship.  Life no longer does anything
significant, as there is a subclass of physical called "alive", bound to
processes like replication, reaction, and proaction... all of which have
subprocesses implementing specific behaviors.

If I wanted to add a new physical attribute, I could... and I could make
the base processes take it into account... but I can't control the exact
results of this change... and I certainly can't test it in a limited
scope.

And that's just for behavior.  Interface is a whole different can of
worms.  How do I describe the attribute to a player, if at all?  There's
a client - theoretically - that needs to be able to interpret direct (as
opposed to consequential) manifestations of the new attribute.

I remember adding a new set of fields describing locomotive behaviour for
objects - if an object moved under its own power, it could describe that
behavior, or use a default - and I can't think how I'd do this now.  I'd
say the current design is better - the client describes the locomotive
behaviour out of a lexical database it has updated from the server when
the new process in question is added - but you can't make a tigger
bounce and flounce and pounce, unless you derive a special version of
a hopping locomotion process (one exists for pogo sticks, or things of
that nature, already) with those descriptions... which would really
mess with the NLP neural net's lexicon.

And building objects is a pain.  I'm using a skeletal gui based assembler.

:> So though in theory, with competent and _disciplined_ developers, the
:> LPMud can be everything a Diku can and then some, in practice there's
:> no question which code base I prefer to be a player in. Since Skotos
:> uses DGD, an LP driver, we must attempt to conjure up this discipline
:> largely through our world implementation (and developer interface).

:cf my LP vs Diku posting from ages ago, it's in the archives and also on my
:website. Key point is near the end, and is equally applicable to your
:approach: "The name of the game in Dikus really has to be making the
:templates they load more flexible"... in other words, for your approach,
:providing an architecture to your superclass so that your methods can easily
:be added to, expanded on, and customized in greater detail...

:http://www.legendmud.org/raph/gaming/index.html

As I said, I did that once... the end result was a form of SGML that
had a separate program for converting Diku files to a subset... and
mobprogs to a different file, to be updated by hand.

Now the question is, if I turned my codebase and development environment
loose, would it hold up against the undisciplined builders' efforts?  If
someone tries to write a process that behaves in a way out of keeping
with the existing resources and process attributes, it won't work - but
I imagine some abuses will, and where there's something hackable...

--

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
http://www2.hawaii.edu/~yospe  nathan.yospe at isearch.com yospe at hawaii.edu
Don't mind me, I'm just insane... there's someone else here in my brain.




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev