public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* Using terrain coatings and existing code to model topography, weather, and vegetation
@ 2004-09-19 23:17 Lincoln Peters
  2004-09-19 23:32 ` mskala
  2004-09-19 23:44 ` Coatings Eric McDonald
  0 siblings, 2 replies; 14+ messages in thread
From: Lincoln Peters @ 2004-09-19 23:17 UTC (permalink / raw)
  To: Xconq list

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.

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:

Cell terrain:	Solidity of the terrain, ranging from solid rock to silt. 
Elevation *must* be implemented in order to properly handle any of the
coating levels, even if the entire map is pre-generated.

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.

Coating Level 1:	Climate, probably using the Köppen system of climate
classification.  These types are:

a. Moist tropical climates: tropical rain forest, tropical monsoon,
tropical wet-and-dry.

b. Dry climates: arid desert, semi-arid/steppe.

c. Moist climates with mild winters: humid subtropical, marine,
Mediterranean, dry winter.

d. Most climates with severe winters: humid continental, subpolar, dry
winter.

e. Polar climates: polar tundra, polar ice cap.

f. Highland.

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.

Coating Level 3:	Transient weather, mostly precipitation (normal rain,
normal snow, sleet, freezing rain, snow grains, snow pellets, and hail
would be implemented as distinct coatings).  This would also require
code to determine how water moves along a surface, in order to produce a
working water cycle (where precipitation is formed by evaporation from a
body of water, then returns in the form of precipitation to a body of
water).

Coating Level 4:	Vegetation, such as grasslands, shrubberies, forests,
and algae.  The number of individual coatings required here would depend
on how much detail one wants (or needs) the vegetation to have.  In the
case of forests, in most games, it would probably be sufficient to
differentiate between evergreen forests and deciduous forests: in winter
situations, evergreen forests would obstruct vision to a greater extent
than deciduous forests (which lost their leaves in autumn), whereas
there would be no difference worth noting in the summer.


Obviously, all of these levels are interdependent in various ways.  All
coating levels would be affected by coatings of lower levels (e.g. no
vegetation on glaciers), and some are affected by coatings of higher
levels (e.g. vegetation might affect soil composition over time,
depending on how much detail you're looking for).

I've also re-examined the existing code for wind, temperature, and
clouds, and found them to be just as inadequate.  As for changes that
would need to be made to the existing weather code:

Wind:		Xconq needs a mechanism to model the two fundamental weather
phenomena that control all wind: Coriolis force and pressure gradient
force.  It might be necessary to implement additional terrain coatings
at Level 3 to represent high and low pressure cells at different general
elevations, although a solution that is directly integrated into the
existing wind code would certainly work better.

Temperature:	Temperatures on Earth vary with latitude because places at
high latitudes receive less direct solar energy (i.e. the sunlight that
they do get travels through a larger part of the atmosphere, due to the
angle at which it approaches the Earth).  As solar energy passes through
the atmosphere, it scatters, and thus places with less direct sunlight
are not as warm as places such as the equator that receive more direct
sunlight (that travels through less of the atmosphere).  While Xconq
does not need to model all of the laws of physics that cause such
temperature differences at different latitudes, it does need to model
their end results.  Xconq should also be able to model differences in
temperature due to elevation, without depending on elevations
corresponding to specific cell terrain.  Additionally, in the
aforementioned model of terrain coatings, temperature (actually heat
energy) would control the conversion of bodies of water (Level 0) to
clouds, then clouds to precipitation (Level 3), and then precipitation
to bodies of water (Level 0) again.  And, of course, there should be
changes in temperature due to day/night cycles; such changes would be
based primarily on humidity (since water tends to moderate temperature
change) and wind (since wind causes air to move around, thus moving any
heat energy that was absorbed by that air).

Clouds:		Clouds are one of the trickiest aspects of weather to model
correctly.  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. 
To build an even remotely realistic weather model, you would also need
clouds to be interdependent with bodies of water, precipitation, and
wind.  For our purposes, it might be adequate if the weather model
handled clouds as being directly related to bodies of water and
precipitation *without* making any effort to handle the shapes of those
clouds, as long as there is some mechanism for those clouds to have a
defined density (not just volume).


The more I think about this, the more I can see that, while writing the
terrain module itself might not be such a difficult task (albeit a
time-consuming one), re-writing the code for terrain coatings, as well
as the existing weather code, will be a lot of work.  On the other hand,
when you consider the benefits that such a weather model could have on
any existing or future game, I think that the return on such an
investment would be enormous.

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2005-01-04 19:30 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-19 23:17 Using terrain coatings and existing code to model topography, weather, and vegetation Lincoln Peters
2004-09-19 23:32 ` mskala
2004-09-20  0:24   ` Eric McDonald
2004-09-20  0:30   ` Andreas Bringedal
2004-09-20  1:33     ` mskala
2004-09-20  2:35       ` Lincoln Peters
2004-09-21  0:43       ` Eric McDonald
2005-01-04 19:30         ` Weather tidbit mskala
2004-09-20  0:32   ` Using terrain coatings and existing code to model topography, weather, and vegetation Lincoln Peters
2004-09-20  0:45   ` D. Cooper Stevenson
2004-09-19 23:44 ` Coatings Eric McDonald
2004-09-20  0:45   ` Coatings Lincoln Peters
2004-09-20  0:58     ` Coatings Elijah Meeks
2004-09-21  2:09     ` Coatings Eric McDonald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).