[MUD-Dev] Virtual Chemistry

[Matt Chatterley]

On Mon, 11 Aug 1997 clawrenc at cup.hp.com wrote:

>    at 03:09 PM, Matt Chatterley <root at mpc.dyn.ml.org> said:
> 
> >On Wed, 30 Jul 1997 clawrenc at cup.hp.com wrote:
> 
> >> First thoughts on a representational model:
> >> 
> >>   Create a coordinate system.  
> >>   The axis of the coordinate system are the principles of your
> >>     alchemy system (yes, lotsa dimensions).
> >>   The purpose of the coordinate system is to define the 
> >>     behaviour of a substance.
> >>   Given a substance, a coordinate location can be computed from 
> >>     its components.
> >>   Given a coordinate location, the effect of the substabce can 
> >>     be derived.
> 
> >I was initially unsure about this, but the more I thought - the more
> >I liked it, and, for what I want to create, it makes perfect sense,
> >and seems to work nicely (at least theoretically).
> 
> FWIW I'd strongly recommend using a sparse array and interpolating the
> missing chunks at runtime.

Especially if you have a lot of coordinates. I'm probably going to set it
up so you can leave anything that counts as 'normal' undefined, and will
be set as 0+/- a small variance for magical flux (or somesuch). For
instance there is no need to implicitly declare neutral Ph, or Nil magical
capacitance in a substance.

There will also be basic defines that can be copied, for instance ({
"water" }) would be treated as the stored composition of water, rather
than each person having to actually enter the appropriate coordinates.
 
> >> Thus the leaves of the herb WaggaWagga might have a coodinate weight
> >> of (-5, 8, 3) presuming the simplistic case of only 3 principles.  The
> >> root of the UmbaUmba plant might have a value of (2, 9, -10).  Mix
> >> then together with GooGoo mud (0, 0, 2), and you get a substance (-3,
> >> 17, -5).  That location can be plotted in the coordinate system and a
> >> result computed:
> >> 
> >>   A minor weakening agent (-3) that also a *really* effective sleeping
> >> draught (17), and reduces physical dexterity (-5).
> 
> >Yup. Of course, you'd need many more properties tracked.. but still,
> >we have the basic spirit captured here. First things which came to
> >mind were properties to track reactivity of substances, acidity, and
> >magical capacitance. More general things with relevant to the mixing
> >of chemicals. A question rose subsequently here - what about by
> >products? How do we tell if a by product should be produced? I have
> >yet to answer that one.
> 
> Yeah, the above example is deliberately simplistic and trivial.  

Well, you can't explain something like this if you do it in a complex
fashion. Discussion of this idea (or something vaguely resembling it) on
my mud's development list quickly descended into some quite complicated
overlays - for instance set patterns in which rituals and other effects
can be applied to anything to modulate their behaviour. For instance,
contact with enchanted gold while solid may always increase acidity
slightly.
 
> By products are really a side effect of standard combinations.  Some
> sort of indexed reaction is needed.  If you further extend the array
> as follows, it can be done:

Yeah. This helps pave the way for easier multi-part mixes, too.
 
>   Each substance has a unique ID value in its array.
> 
>   Each substance array also encludes a member which is a list of
> arrays (maps really) which represents what quantities of what products
> are produced when the current substance is mixed with the named (by
> ID) substances.  

Heh, yeah. It might also be possible to use a simpler system, and say that
the byproduct is always a pre-set function of the combination (for
instance f(x)=x/2).
 
> >Incidentally, bringing in the concept of tracking state produces a
> >flaw in the design of many stock (LP) bases - you have a drink
> >inheritable, which all drinkable substances must include, defining
> >alchoholic properties etc (this is pretty standard accross LP,
> >excepting very different games). Of course, this is not going to
> >really work with liquids - in theory you can drink any liquid, but
> >you don't want to inherit drink into all of them!
> 
> The problem is a bad object model.  They should have a state base
> class from which a liquid class is descended (or is a base class). 

Yes. What is rather remarkable about the model is its apparent popularity
- probably because of the heavy and widespread influence of the Nightmare
libraries.

Regards,
	-Matt Chatterley
	http://user.itl.net/~neddy/index.html
"Speak softly and carry a big stick." -Theodore Roosevelt