This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Coatings


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]