Re: Coatings

[Lincoln Peters <sampln at sbcglobal dot net>]

On Sun, 2004-09-19 at 16:31, Eric McDonald wrote:
> 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.

That is exactly what I'm saying.

> 
> > 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.

Interesting.  However, I wanted to be able to track vegetation
separately from physical topography, since I suspect that the data from
the GIS would contain so many different combinations of those two
properties (as well as others) that implementing each combination as a
separate cell terrain type would be even more work.

> 
> 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.

As far as I can tell, these semantics have little meaning right now,
since they only are used in one game, and that game only works because
of a hard-coded hack in the environmental code.

> 
> > 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.

Maybe it would instead be possible to make the cell terrain types land
and water, and the physical properties (sand, silt, clay) as Coating
Level 0.  Or it may turn out that the physical properties I mentioned
are meaningless for 99% of all situations and so could be omitted from
the planned terrain module entirely.

> 
> > 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))

That would probably work.

> 
> > 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'd have to further study how these models work, but I'd imagine that a
highly simplified model could be used in Xconq.  I've been trying to
track down the algorithms that  have been used for simulating weather. 
If I could find one of the models that was used on the supercomputers of
the 1970's or earlier, it would probably run on a modern PC with little
difficulty.  And the loss in accuracy would be unimportant, since, as
Matthew pointed out, this is a game.

> 
> > 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...).

I hadn't thought about that.

> 
> 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....

In most cases, such fantasy is also based on a assumption that the Earth
is flat and the suns revolves around the Earth.  This means that the
Earth would most likely *not* be rotating, in which case Coriolis force
is zero.

In games where flat maps are used, it might therefore revert to the
existing code to determine wind.  And for those rare games where one
might want Coriolis force to apply to a flat map, a separate weather
model would resolve this issue, sort of in the same way that Civ-style
combat was implemented by adding a second combat model.

> 
> > 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.

I just tried adding it to the proof-of-concept module I'm trying to
write for this kind of coating-based terrain model (actually, I
copy-and-pasted the clouds code from the Napoleon game).  It didn't
crash Xconq, but the clouds code in the kernel seems to be so incomplete
as to be useless.

---
Lincoln Peters
<sampln@sbcglobal.net>

Humpty Dumpty sat on the wall,
Humpty Dumpty had a great fall!
All the king's horses,
And all the king's men,
Had scrambled eggs for breakfast again!