[MUD-Dev] Re: Spell components, chemistry, and the like...

[Nathan F Yospe]

On Mon, 9 Nov 1998, quzah [sotfhome] wrote:

:Greetings all. I'm working on a spell component system
:for MERC, which is quickly becoming a physics engine.
:Or perhaps I should say, chemistry engine. Now then,
:since I didn't take chemistry in high school I have a
:few questions relating to my spell component system.

Ooh, fun! I'm replying to the original, otherwise I'd be correcting just
about all of the replies. The problem is, you've all had "matter has the
three states: solid, liquid, gas" drilled into your heads, and some have
even heard about plasma... but you're trying to model stuff that is much
more complex than that simplified statement. Now, as far as forms of any
elemental substance, some definitions:

Plasma - stripped ions and electrons in a high energy hot gas
Gas    - non ionized free state, only stable in rare cases (nobles, etc)
Doubled gas - covalently bonded pairs of the element, free state
Liquid - loosely bonded non ionized partial free state
Doubled liquid - covalently bonded pairs of the element, partially free
Amorphous solid - non crystaline solid form, rare in elementals
Crystaline solid - one of many stable crystaline forms; each will have a
                   number of unique properties, eg. diamond, graphite
Pure solute - ion in water or oil solution

As you can see, that's an awful lot of states, without even getting into
non elemental compounds. How to handle? I have a table of substances, in
which some are elemental, some are compounds, and all are single states.
Each substance has a list of "transform functions", with the values of a
set of "transform variables", and a link to the "product substance". The
transform functions include "Transubstantiation" - dependant on variable
temperature, pressure, and the two part curve fitting transform variable
previously mentioned - look in a chemistry book for the three part curve
with a substances triple point, and note how water has one line going in
the wrong direction - ice expands, and all that - and you'll know what I
mean. Transubstantiation only applies for simple solid to liquid to gas.
Complex solids usually require a much more complex transform function. I
also have functions for "Reaction", which include burning... These are a
much more complicated calculation than I want to make regularly (every 3
or 4 seconds, or when a condition changes instantly), so I store the bit
of the calculation that is constant. When pressure remains constant over
a second calculation, to a given accuracy, the transform function sets a
threshold on pressure, then begins to check temperature regularly, which
is a much simpler calculation. (Local execution of function has a little
bit of memory, these functions are in the execution layer, not the basic
C++ layer.) If both temperature and pressure are constant, there is only
a threshold check every conditional cycle. Likewise with other transform
functions. The ultimate result is a huge library of substances, and some
ten or twenty transforms for each... and a number of those will check an
optional "variable like" and produce one of many products, depending. If
a substance hits a threshold temperature, for example, the variable like
oxidant will be checked, and if there is an oxidant present, a check for
that oxidant's reaction temperature will result in a new threshold for a
reaction. Oxygen is not the only possible oxidant...

For you, it becomes much simpler. You don't have nearly as many elements
or compound substances... you don't have variable pressures in air, with
the only other conditions being under water and maybe under oil? You can
ignore the exotic reactions and focus on the simple ones... the system I
have implemented should be pretty easy to apply to a Diku.

:{
:"molten gold", COTYPE_METAL_GOLD, COFORM_LIQUID,
:COTEMP_HOT_HD, COSIZE_MODERATE, (volume), (weight/volume),
:(heat_to), (cool_to), (found where), ...
:},
:
:{
:"gold dust" ...
:},
:
:{
:"gold nugget" ...
:}

:Ah. Problem. Do I really want to list every form of gold?
:For that matter, is gold ever a gas? If so, would anyone
:ever be able to use it? Is this just a pain in the butt?

:So, I have decided to redo it, (not sure exactally how) and
:just have something like:

:{
:"%sgold%s", (solid info)(liquid info)(gas info)
:}

:ideas on handling the three forms of an element (compound/item/
:whatever) that won't fill an encyclopedia volume? I already
:have COFORM_ to handle things like "powered"/"liquid"/"shavings"
:and so on, as well as COTEMP_ (temperature), COSIZE_ (measurement)
:but I'm not sure what to do with elements, since I'm also allowing
:for plants, blood, mud, swords, whatever to be a spell component.
:(Room->vnum, obj->vnum, and mob->vnum are also allowed for spell
:components: "You need to be in the temple, with a silver staff,
:and a priest to cast resurection.")

:I really don't feel like making every form of every element/item,
:and so I'm looking for a different view on the subject. 

It's a good idea to have every form of every element/item *that you want
to appear in your game*. In other words, you won't encounter a gold gas,
at least not at temperatures likely in a medeival setting, but molten or
solid gold are present. Gold liquid follows one of the basic liquids. It
is a nonpolar liquid, with a high viscosity... Gold solid is conductive,
which might mean nothing to you, but it is also glittery yellowish, with
the liquid being more a red-gold color. Remember also that there is more
than one appearance to a single form of a substance. Solid powders are a
lot ligher than the non powdered form, and don't pass light, which makes
snow, for example, opaque...

Of course, it also depends on your objective. I intend to have snow melt
when it gets too hot, to have sugar (and poisons) disolve in a drink, or
percipitate out when a new material is added... that's a lot deeper than
you probably need.
--

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
University of Hawaii at Manoa, Dept of Physics, second year senior (joy)
(On Call) Associate Algorithm Developer, Textron Systems Corp, Maui Ops.
yospe#hawaii.edu http://www2.hawaii.edu/~yospe Non commercial email only