Re: Coatings

[Eric McDonald <mcdonald@phy.cmich.edu>]

Lincoln Peters wrote:

> I've been re-examining the ww2-eur-42.g module (the only one that uses
> terrain coatings) to try to figure out the exact level of functionality
> in the terrain coating code.  I discovered that the run_environment
> function contains a few lines of code that look specifically for
> temperature and terrain coating types called "mud" and "snow", then
> applies the coatings as appropriate.  It works in ww2-eur-42.g, but it
> obviously lacks the flexibility to be used elsewhere.

If you're saying that you discovered some hardcoded hacks, then that is 
not a good thing.

> What I want to be able to do is use coatings to represent aspects of
> terrain that normally are glossed over in a game (even though many such
> aspects have played major roles in countless historical battles).  I'm
> thinking that I'd implement a model where different kinds of terrain
> coatings would be grouped into levels, each level representing a
> different aspect of the terrain.  This would probably break down as:

I think this is just another way of trying to put terrain in multiple 
categories:
   (define moist-0-t* (desert tundra))
   (define moist-1-t* (semi-arid))
   ...
   (define alt-0-t* (swamp plain))
   (define alt-1-t* (highland))
   (define alt-2-t* (plateau))
   ...
I do something similar (though somewhat more verbose) in Wreckreation. 
Actually, I have some other categorizations as well, such as how rugged 
the terrain is, because that is applicable to movement rules.

The question of whether it is better to categorize by overlaying 
coatings on "bare" cells or by categorizing terrain into multiple groups 
is an interesting one. I would have to think some more before I could 
determine which one might be better.

One thing to think about is that a coating is intended to be something 
that dissipates and has inherit characteristics such as depth. Trying to 
use them in the manner you prescibe changes their semantics somewhat, as 
they then become "terrain attribute layers", if you will.

> Coating Level 0:	Bodies of water.  They might do well to be implemented
> as coatings since all other terrain properties I describe here,
> including vegetation, apply to bodies of water as well as dry land.  The
> only distinctions required within this level would be for fresh water,
> salt water, and glaciers.

A problem is that liquid terrain is special to Xconq in several ways. 
One of these is that the AI relies on a land-sea regions layer to 
determine whether a body of water is large enough to consider building 
naval units. If everything is a bare cell underneath, then the ability 
to make [designer-guided] intelligent naval construction decisions is 
impaired.

> Coating Level 2:	Soil composition.  For most games, it would be adequate
> to measure nitrogen, ammonia, and potash, since they have the largest
> impact on what can and cannot grow in certain soil.

(define nitrate-lvl-0-t* (ice-field sheet-rock))
...
(define nitrate-lvl-5-t* (fertile-plain tropical-forest))
(define nitrate-lvl-6-t* (fertilizer-depot))

> Coating Level 3:	Transient weather, mostly precipitation (normal rain,

Weather and climate modeling are how most of my employer's 
supercomputing cycles are spent. To do any sort of detailed work on the 
subject is non-trivial.

> I've also re-examined the existing code for wind, temperature, and
> clouds, and found them to be just as inadequate. 

I would agree, from what I've seen. But, I have no plans to work on them 
anytime soon.

> Wind:		Xconq needs a mechanism to model the two fundamental weather
> phenomena that control all wind: Coriolis force 

Xconq maps can be rectangular or cylindrical, but not spherical. If the 
map is considered to be moving on a rotating frame, you should still be 
able to calculate a Coriolis force, but it might not be behave the same 
way you would expect on Earth or in the Sun. One would have to assume a 
sphere, or oblate spheroid, as the case may be, in order to get 
something closer to what one might expect (trade winds on Earth, etc...).

For a fantasy game, someone might wish to assume a world that truly is 
flat, and has spirits with chubby faces blowing across the face of the 
world, __you know, Boreus, Zephyrus, and that bunch....

> I remember that Xconq's existing code for modeling clouds
> was meant specifically to allow weather to obstruct a unit's vision,
> depending on the elevation of the clouds and the elevation of the unit.

There may be a bug in this code, as Elijah pointed out to me a while 
back ago. I think it crashes the Napoleon game.

> To err is human, to forgive, beyond the scope of the Operating System.

:-)

Eric