[MUD-Dev] Re: regulating player-created objects

[s001gmu at nova.wright.edu]

On Fri, 1 May 1998, Adam Wiggins wrote:

> On Fri, 1 May 1998, Dan Shiovitz wrote:
> > On Thu, 30 Apr 1998, Adam Wiggins wrote:

[... objects as composites of components ...]

> > [..]
> > 
> > Hmm. I've been chewing on this for a while. It's pretty clear that the
> > latter isn't feasible. It occurred to me, though that you could get
> > some sort of in-the-middle compromise by not hard-coding all the
> > classes of objects that can be created. I guess you might want to have
> > some base ones defined, but beyond that you could let the admins
> > create "patterns" that players can learn and create. For instance, say
> > someone knows the "chest of drawers" pattern. This would be something
> > that an admin wrote in some sort of in-game coding language. According
> > to the pattern, say, the chest of drawers is composed of 3 large
> > boards, some nails, and three drawers. "drawer" is another pattern. A
> > drawer consists of 4 small boards and one medium board, plus some
> > nails. So eventually all patterns are decomposed into sub-patterns
> > which get decomposed into atoms. Atoms are things that don't have to
> > be specified how to make: "carve large board from log" will give you a
> > large board if the log is large enough. 

The first thing I thought of when I read this was 'wow.. what an
interesting application of OOD.'  Seems like a no-brainer in an OO
implementation, neh?
 
> > The advantage of this system is in the use of sub-patterns. For
> > instance, you could have the "arrow" pattern be made of up "shaft",
> > "arrowhead", and "fletching". Anything that fits into these categories
> > can be used to make an arrow; so you could make arrows with steel
> > heads, or flint heads, or diamond heads if you can find a way to chip
> > them, and so on. 

Isn't Inheritance beautifull?

> > This doesn't let players create anything they want. If I want to make
> > a cuckoo clock with a secret compartment in the bottom, there has to
> > be a cuckoo clock pattern already existing (and presumably made up of
> > a gear pattern, a carving of an animal pattern (usually animal=bird),
> > a bell pattern, and a small base pattern). But if there's already a
> > base-with-secret-compartment pattern created, I can make my cuckoo
> > clocks come with secret compartments even if that wasn't the intent of
> > the original pattern creators. 

I don't think it would be too difficult to extend the system so that
people could create something very similar to something else...
esentially, add attributes to an inherited class.  But then, you get into
some interesting areas there... in a C+ implemenation, dynamic linking is
probably your friend here.

> > (Of course, the downside to this is every game object needs to be
> > deconstructible now. Oh bother.)

heh... Actually, this system will fit beautifully well with what I have in
mind for I/O decoupling... Why have the object even know or care what it
looks like to the user?  The client will have to have a representation for
all the primitives, but from there all it needs is a list of the
configuration of primitves, and it then handles all the displaying.

> > Anyway, am I reinventing a known wheel here?  

aside from OOD, nope.  :)
 
> Long quote, but I think all of it is relevant.
> 
> Actually, now that you mention, Orion and I tossed around this idea a few
> years back.  The idea was that the basic object types are only shapes.
> These basic types can only ever be made of one material.  Thus you can
> determine the number of sub-objects something should have by the number of
> distinct forms, and the number of distinct materials.  Thus your average
> axe has two objects: an axehead made of steel, and a shaft made of oak.
> 'shaft' and 'axehead' are both primitive object forms; oak and steel are
> two possible materials one can extract from the game world.  We originally
> came up with this because we wanted an easy way to damage objects in a
> specific way.  I wanted to be able to burn the axe and have a pile of ash
> plus a charred axehead.  All objects in the world are defined this way,
> including creatures.  No object can exist that is not a primitive - all
> non-primitive objects are just containers for their primitives.  A human
> would contain a whole bunch of limbs, for example.  A specific limb would
> contain primitives in the form of a bone, some muscle, and some skin.
> This makes things like damage a no-brainer.  It also makes it easy to add
> cool effects like a 'turn bones to adamantite' spell.  Now you get all the
> bonuses you'd expect from adamantite bones.

A lovely perk that I hadn't thought of..  *kudos*
 
> I see this as being very feasible in a text-based environment, but it
> would require a pretty serious amount of attention to creating basic
> objects.  Just getting the thing to a playable point would be a serious
> chore, but at that point you'd have an incredible amount of freedom with
> how your objects interact.

Why limit it to text?  As I said above, just remove the I/O from the
server, and foist if off on the client, and then your mud becomes easily
extendable as new interface technology arises.

Yes, it will require a large amount of initial time invested.
But hey, what else am I going to do with my weekends? :)

-Greg


--
MUD-Dev: Advancing an unrealised future.