[MUD-Dev] Player Created Object System

[Richard]

> From: Bruce [mailto:bruce at puremagic.com]

> Could you just post it to MUD-Dev given the apparent general level
> of interest?

It turns out that the design document was the discussion we had on our
board system.  Its included at the end with its big heading.  Theres
not as much there as I remember. The guy who went ahead and coded the
prototype system pretty much found it sufficient.  How much use it
will be to others is debatable :) Unfortunately, most of our
discussion for most things we did at that stage was carried out online
and not logged.

Why is it a decomposition rather construction system?

Strangely enough, rather than the seemingly more logical goal of a
generic system that allows objects to created, the initial goal was
actually to allow objects to be taken apart.  Like the gem out of the
pommel of a sword and things like that.  This evolved into a system
where objects were composed of other objects and there was a template
which defined how they were put together.

Taking composite objects apart was a lot more achievable than the
reverse process.  Its all very well to say, making composite objects
involves manipulations, tools and ingredients - but chances are most
processes involving these are very different.  Not knowing a wide
range of these processes due to our extreme realisticity requirements
meant that we were of the opinion that we couldn't therefore design a
generic system to manage the processes.  On the other hand, a lot less
information needs to be known to allow an object to be taken apart.  A
sword for instance is just a blade, crossguard, grip and pommel.
Additional information is what each is made of, what each joins to and
how it is joined to it.  As our system is based around defining
objects and then including them in other objects, this allows for a
wide variety of swords.

If at a later stage we wanted to expand the decomposition system to
additionally be the basis for a construction system, then it naturally
lends itself to this defining the templates for objects.

Our prototype system works.  But for unknown reasons we moved onto the
next interesting idea and never actually added the easier stuff that
makes it usable and allows it to be integrated into the game.  We have
quite a few projects at this level :)

The "design document".


--<cut>--
                    O B J E C T    D E C O M P O S I T I O N
                    ----------------------------------------

Thu May  7 18:23:40 1998: (Galileo)
-----------------------------------

Okay, I've been contemplating basic object manipulation and structure
in an effort to come up with something practical, useable, and above
all else realistic.  This of course is *not* what we have ATM.  Here's
what I've come up with so far, your opinions as always are welcome and
encouraged.

We build for lack of a better term, a substance/material handler that
stores information on an assortment of common materials from iron, to
flesh.  For each of these basic materials, we store:

  state           (solid/liquid/gas/plasma)
  consistancy     (how thick or thin it is)
  texture
  opacity
  color
  strength        (how durable it is)
  density         (it's density, water is 1 remember)
  smell
  taste
  other           (anything that doesn't fit in one of the above)

Then when creating an object, let's say a sword you'ld have to set
what substances (or materials if your prefer), and in what porportions
were used to build it.  In our example:

  set_material( ({ STEAL, 90, GOLD, 10 }) );

This would give us a sword that's 90% steal but, also 10% gold,
probably the hilt.  This has a couple of advantages.  The biggest one
I see, of course is it makes standardizing weapons, armour, etc
painless.  The durability, sharpness, and what not would be calculated
for you and you wouldn't need to mess with getting approprite values,
and balancing it.  There would of course be support for setting your
own unqiue material for this particular item, and over riding the
default computed values if desired.  Also, this system has the perk of
saving a bit of memory, by consolidating all that repetative attack
information and what not that was scattered throughout all the
individual objects.

On top of this I'd like to change how weight is done, now I know the
stones system is what most muds use, but does anyone really like it?
Personally, I'd be inclined to convert it over to a grams.  The units
are nicer, a player can more readily digest how much he is actually
carrying, since 500 stones, doesn't mean as much to most people in my
opinion as 25 kg.

Also, as an odd thought, I never much liked the way bags worked
either.  It seems to me, they should be based more on volume rather
then mass.  Now we've stored the materials density, and we have it's
mass so we can easily calculate a volume for the object.  Now, this
isn't gonna always be acurate, for obvious reasons such as a sword may
have a smaller volume then a cinder block, yet be considerably larger.
However, it would in my opinion be slightly better then just basing it
on mass which is done now.

Finally, I've some ideas on potions and mixing of liquids and gases,
that's been outdated a bit by this, but the basic idea still applies.
The file is in /w/galileo/text/potions.txt, please take a look.

Anyway, this is already longer then I had hoped, but if you do read it
all please post an opinion on it.  I'm done now.

Thu May  7 19:41:14 1998: (Eggjon)
----------------------------------

I agree with you on most points.  Grams make more sense to me than
stones.....  I don't think we should have to stick to percentages,
i.e.

  set_material(({"steel",9,"gold",1})); 

should be as effective as

  set_material(({"steel",18,"gold",2})); 

since we already have the weight stored.

I don't think we can make materials totally calculate the effect of a
weapon...  But there's no reason they shouldn't calculate the effect
of a piece of armour...  Weapons can be pierce, blunt, whatever...  I
think a spear made 90% out of wood can do as much damage as a hammer
made 90% out of steel.  In the right hands, of course.

Thu May  7 22:09:51 1998: (Donky)
---------------------------------

I'm more inclined to the more thematically correct stones measurement
than the metric system.

  set_material(steel, gold) 

doesn't quite raise my flag, to me this infers that the metals are
mixed (I forget the word.. amalgam?)

Maybe objects could be composed out of parts, like:

  sword =3D hilt + blade + pommel.

the hilt might be made out of well, steel wrapped in leather (which
the player might be able to remove). The pommel might be gold with a
jewel of some kind which can be pried out by a player.

The blade, steel again perhaps engraved and inlaid with gold runes.

Ideally we would be able to have blacksmiths that could repair these,
and make them.  Players would be able to learn the same.

+++

> state           (solid/liquid/gas/plasma)
> consistancy     (how thick or thin it is)

Hmm, to me consistancy applies only to materials in the liquid state
and could easily come under the texture umbrella.  i.e. The liquid had
a thick texture.

> texture
> opacity

Hmm, opacity being how see through the material is could come under
colour possibly?

> color
> strength        (how durable it is)

Maybe strength should be renamed to durability?  How does this relate
to liquids, I can see the relevance for solids.  Perhaps this might be
part of a replacement for the condition of objects?  i.e. when they
need repair etc..

> density         (it's density, water is 1 remember)
> smell
> taste
> other           (anything that doesn't fit in one of the above)

Hmm, it occurs to me that secondary properties might be required
depending on the state of the material.

For instance, lets say you have 'water'.  It would have two potential
states, solid and liquid.  The default would of course be liquid.  So
lets see, from this, we might derive that we would want to keep a
range of properties representing a state of a material.  We would want
to specify whether a solid is consumable, you can taste a sword but
you can't eat it.  You can taste an apple, and also eat it.  If you
taste solid water 'frozen', then it might get stuck to your tongue.

> Then when creating an object, let's say a sword you'ld have to set
> what substances (or materials if your prefer), and in what
> porportions were used to build it.  In our example:

This is how, I see it.  Again, it is not 'how it is' but merely my
thoughts up for comment or use.

A sword would be specified as having three main parts, the blade, the
pommel and the hilt.  Each can be made out of a solid material, to
form the whole.  Lets say a you get some 'dirt', put it in a bowl. You
take out your waterskin and tip in some water and have mud in the
bowl. You get somw mud from the bowl and form a blade. You get some
more and form a pommel and a hilt. You join them all together. You
have a sword.  Yeah, sure that sword is going to be crap as dogshit
and a real sword is going to plow through it and slam into you making
you sick as dogshit.  But imagine if you are a wizard, you cast an
illusion on a dirt sword so that it looks like the most kick-ass sword
that was ever made, I think this makes for really good potential.

Ok, so we have 'objects' that can be requested which are created in a
specified way but not nescessarily with a given selection of
materials.  The object might have properties, lets say for instance
you carve a sword in its entirety out of stone.  A steel sword that
hits stone will soon blunt or even break.  That can be calculated from
the strength of the offense and the strength of the defense and the
properties of the connecting materials.

Ideally, this has much more potential than swords IMO.  Players might
learn how to make 'yarn' from 'wool', might learn how to make clothes
from 'yarn' and then could sell clothes.  This is just one example of
many possibilities.

I think it is essential we make this possible.

> Also, as an odd thought, I never much liked the way bags worked
> either.  It seems to me, they should be based more on volume rather
> then mass.  Now we've stored the materials density, and we have it's
> mass so we can easily calculate a volume for the object.  Now, this
> isn't gonna always be acurate, for obvious reasons such as a sword
> may have a smaller volume then a cinder block, yet be considerably
> larger.  However, it would in my opinion be slightly better then
> just basing it on mass which is done now.  >

I think mass should still be relevant in that the material of a bag
might not be able to support over a certain mass.  Thus the bottom
might fall out of a sack or backpack etc if too heavy things are put
in and it is lifted.

Fri May  8 15:16:20 1998: (Hogwash)
-----------------------------------

> I think a spear made 90% out of wood can do as much damage as a
> hammer made 90% out of steel.  In the right hands, of course.

However, a spear made out of wood would probably be more liable to
break, than a hammer made out of steel

+++

> that the metals are mixed (I forget the word.. amalgam?)

Alloy?

Fri May  8 15:40:22 1998: (Belgie)
----------------------------------

It's fun to dispute words but they're both right.

  Amalgam - An alloy of Mercury with another metal or metals.
          - A mixture of diverse elements.

  Alloy - A macroscopically homogeneous mixture of solid solution
        - Something added that lowers value or purity.

Too bad I sold back that material science book, might have come in
handy with all these new stuff.

Fri May  8 19:54:35 1998: (Galileo)
-----------------------------------

Okay, here's another track we might take.  Since it seems the
functionality everyone really wants is the ability to create objects
such as our sword example, from a set of pieces maybe we should persue
that primarily.  What I mean, is let's go ALL the way back, and change
what IS a standard object.

We'll assume for arguements sake that any instance of OBJECT_OBJ will
simply contain information pertaining to a specific part of a large
object.  For example, it might be the gold hilt of our sword.  Mind
you it's NOT the entire sword but just the hilt, and is composed of
only 1 material, (we'll allow alloys too).

Now since obviously, alot of things in the game are going to made from
multiple distinct parts, we'll set up base template inheritances.
These will contain basic information for what parts are
required/optional to build this object.  So when building a sword you
would inherit the SWORD_OBJ, and then either set each part with
specific information about it, or we could also set it up to pull the
info for an existing object if ya like.  Now we wouldn't want to store
an array of object pointers since they're unique to each clone, and
we'd like to get all the information localized in 1 object.  So, I'm
off the opinion that the standard object should be written to use
classes, and then a copy of the class that represents OBJECT_OBJ,
could just be stored in SWORD_OBJ.  This way, it's pretty painless to
remove and attach pieces to other peices, assuming they conform to one
of the available templates.

Of course, we'll set up a generic template to cover all the objects
that don't quite fall into a specific template type, or for other
reason don't require or desire this kind of functionality, the money
object for example.

Now what this does for us is a few things, people should be able to
smith weapons since we have a definite pattern, and proceedure define
to create certain things.  For example the sword, if you go out and
find a chunk of iron and bang it in to the shape of a blade, and a
hilt we'd easily be able to discover that assembled they're a sword
and should be treated as such.

It also sets up rough classification of item type for everything in
the game.  You'ld be able to tell if somethings a Tee-Shirt, or an
actual full suit of armour by checking it's type, in this case
CLOTHING_OBJ, and ARMOUR_OBJ.  This plays nicely into an economic
system suggested by Belgie.  I won't get into the details here, but
the jist of it is, each area would have slightly different values for
the materials, and the type of object.  In which case it'd be easy to
calculate a relative value of this object in various points around the
game.  Since, it seems we'll have multiple types of currency, this
might actually turn out to be nessisary where bartering is the only
means available.  But this is for another post...

+++

Also, some other little details things, I suppose durability does make
more sense as a name for the element.  Also I forgot to add 1 thing to
that list of elements, value.  Each substance will have to have a
specific value.

As for a few not applying, your right.  A few don't apply to every
phase of a substance, but it seemed to me id'd rather put a few extra
in, the set up complete different classes for each different phase.
Maybe, that wasn't a good idea, opinions?

As for stone, I can see why some people would want to keep it as it
is, it's quite a bit more romantic and in theme, but I don't find the
nussence worth the effect.

Fri May  8 20:08:49 1998: (Eggjon)
----------------------------------

I think we shouldn't bother with making objects a collection of small
subobjects.  I think we should try to make it something more like the
corpse object, i.e. you can get take objects apart to get two objects.
So, perhaps an array of parts?  We'd make up a part class for it, too?

Sat May  9 23:38:28 1998: (Donky)
---------------------------------

The method I had in mind was that everything that was possible to be
made was composed of parts.  A sword would be a part, but obviously
you can't build with it so it would be a part that no other parts
specify in their recipe.

Ok, let me make it a bit clearer how I see my vision of how this would
all work.  As Galileo and I have already considered, the best way to
handle all this would be to have a handler that you request such
objects from passing a list of specifications that fit the objects
design schema.  Ideally, we might want to consider passing any objects
that are parts used to create the object requested so the handler can
handle disposing of them at the same time.

On object requested might be a 'part'.  A part isn't nescessarily part
of another object the handler knows about, but is itself specified in
the handler, this allows us to have a sword as a part as mentioned
above.  Lets say you built the sword out of a hilt with attributes X
(that obviously fit into the hilt design schema) a blade with
attributes Y (same as for hilt) and ditto for the blade.  The
requested sword object would contain the specific hilt info which is
the information that could be used to recreate the hilt
separately. And the same for the blade and pommel.  (ok, so I meant
pommel in the instance of blade in the last paragraph).  Ideally in
the case of things that were made from raw materials, like the blade,
there would only be a need to keep a record of it's composition.  Same
for liquids.  Perhaps, liquids could also be 'parts'.  I think it
would be a good idea.

Anyway, thats how I see it, yes if every sword on the mud was
different it might get a bit memory intensive but we could share the
information for swords that are the same. etc, similarily for other
items.

--<cut>--_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev