[MUD-Dev] Virtual Chemistry

Matt Chatterley root at mpc.dyn.ml.org
Fri Aug 1 23:02:14 CEST 1997


On Wed, 30 Jul 1997 clawrenc at cup.hp.com wrote:

[Snip my original post]

> 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).
 
> 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.
 
> Or some such similar whatever.  You can then add other weightings,
> such taht the WaggaWagga(-5, 8, 3) gets an added (-2, 1, -8) value
> added if it is prepared by grinding in a special stone bowl while
> chanting the desiderata backwards.  

It's easy to add in special cases once you have an established system,
almost trivial (some sort of basic db format seems in order, loaded at
runtime). Also, consider the states of compouds - mixing two solids
(powders) is hard. Or rather, you can mix them easily, but not chemically
combine them (unless they *really*really* react!). Of course, its not the
same with two liquids, and/or a liquid and a powder. Gases are pretty
tricky to react, too (without appropriate equipment).

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!

Simple solution: Ditch the lame idea of a drink inheritable, and simply
make drinks chemicals with appropriate properties. This also allows the
use of common drinks (eg: water) in such reactions as formation of
solutions from powders, and dilution of solutions (and also brings in the
notion of concentration of solution). Excellent.
 
> The reason for doing a coordinate system rather than a flat expression
> for each axis is tht it allows you to put in break values.  Simple
> things like values on this axis smaller than X have this effect, and
> larger than Y have this totally other effect.  Compound that across
> multiple axis, and you can get a result which is far removed from the
> intial components.

Definitely. You can literally simulate the change in properties of
alchohols as you increase the length of the carbon chain (aka, add CH2 to
go up from Methanol to Ethanol, to Propanol and then Butanol, etc). The
effects are fairly subtle(ish), but mappable in this way. Woo.
 
> Next up would be to then special case certain combinations (reflective
> alchemy), such that components A (which normally has a very simple
> effect), and B (similarly simple), in combination do something else
> entirely (ie mutate into a totally different coordinate.

You could do special cases both by mutation of one or more properties, or
just by taking an effect 'out of the hat' and assigning it, so to speak
(for instance, a binary liquid, which is harmless on its own, but explodes
without explanation on contact with another similar liquid).
 
> This special casing can be handled without undue difficulty by
> building it into the base system.  Again, going back to the simplistic
> 3 principles above, just add various other "fake" principles after
> that.  Thus WuggaWugga could be (-5, 8, 3, 0, 12, 2) and UmbaUmba (2,
> 9, -10, -5, 9, -10).  Then when they're mixed the result is (-3, 17,
> -2, -5, 21, -8).  Now you can do your special casing on the fake
> values (-5, 21, -8).  Say things like if the first fake value is less
> than -5 it was apply (X,Y,Z) to the base matrix, it its over +5 apply
> (Q,R,S) etc.  This results in a really simple way to codify the
> exceptions and and special cases while allowing new compnents to be
> added which have their own unique behaviours.

Yup.
 
> >Has anyone actually attempted anything of this nature, or
> >contemplated it?
> 
> Nope.

Well - that answer is changing now. The above reflect a few of my
considerations as I put pen to paper to map this out properly.

Another random one that just flew past:

We can represent loose solids in a room easily. Liquids fairly easily
(pools that can be manipulated with some difficulty, and that evaporate
over time based on their volitality), but what about gases? Should we
begin measuring the atmospheric compositions of a room/area/whatever, and
allowing for temporary changes?

Regards,
	-Matt Chatterley
	http://user.itl.net/~neddy/index.html
"Doublethink means the power of holding two contradictory beliefs in one's
	mind simultaneously, and accepting both of them." -George Orwell




More information about the mud-dev-archive mailing list