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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  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
                     ` (3 more replies)
  2004-09-19 23:44 ` Coatings Eric McDonald
  1 sibling, 4 replies; 14+ messages in thread
From: mskala @ 2004-09-19 23:32 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

On Sun, 19 Sep 2004, Lincoln Peters wrote:
> 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.

Just a caution:  This is a game.  It's supposed to be fun.  Before adding
any new complication, I think it's important to ask "Will this make the
game more fun?"  There isn't only one right answer, since the answer
depends on who's answering, and on the context of the particular game in
which the feature will be used.  But I think the question should be asked.

My thinking is that as a player, I seldom if ever want to know (for
instance) how much potash is in the soil.  At most, I might want to know
"this is fertile soil; that is unfertile soil".  If there are more than
two or three levels of fertility, let alone more than one dimension of
fertility (nitrogen, potash, acidity...) then I'm just going to be
confused.  I'm usually quite happy to have details abstracted.  The level
of abstraction that's appropriate varies a lot depending on the individual
game.  Some games are "strategic", some are "operational", some are
"tactical", and in general you see more detail and more complication at
the tactical level and less at the strategic level.

That's one reason I said in one of my other messages that I think the
GIS/XConq translation process will need a lot of customization per map;
really, what it needs is customization *per game*.  Some games will want
some of the data to be really detailed; others will want less of the data
and less detail in it.  I think that in all cases the game's needs have to
come first, and they'll shape how the data is treated.

I have similar reservations about Cooper's plan to make every hex its own
unique terrain type.  I can see doing that as a work-around in order to
give every hex its own unique picture, but even that seems like a lot of
work and I think it would be a very special game that actually needed it.  
It would be nice to instead do something like the recent "specify a
picture for an individual unit" patch to allow specification of a picture
for an individual hex, while leaving the hexes grouped into just a few
terrain types.  Ideally, you could specify custom pictures for just a few
hexes, or for every hex, according to taste - that way you could deal with
a wide range of different game needs.

I also wonder about the user interface issues with extremely detailed
maps.  I'm not sure how coatings are currently handled, but I'm guessing
that dealing with them may be cumbersome.  Clouds and unit altitudes sure
seem to be so cumbersome in the current interfaces as to be almost
unusable (if, in fact, they are implemented at all).  Temperatures seem to
be at least partially implemented, but when I've played games that use
them I've always ended up turning off the temperature display because it's
just too confusing.  I'm not looking forward to what I'll have to do as a
player to stay on top of what's going on with four layers of coatings, if 
they're all game-play significant.

Anyway, if you can think of a game you'd like to build that would actually
use this level of weather simulation, then by all means go for it.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

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

* Re: Coatings
  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-19 23:44 ` Eric McDonald
  2004-09-20  0:45   ` Coatings Lincoln Peters
  1 sibling, 1 reply; 14+ messages in thread
From: Eric McDonald @ 2004-09-19 23:44 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

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



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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  2004-09-19 23:32 ` mskala
@ 2004-09-20  0:24   ` Eric McDonald
  2004-09-20  0:30   ` Andreas Bringedal
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 14+ messages in thread
From: Eric McDonald @ 2004-09-20  0:24 UTC (permalink / raw)
  To: mskala; +Cc: Lincoln Peters, Xconq list

mskala@ansuz.sooke.bc.ca wrote:

> Just a caution:  This is a game.  It's supposed to be fun.  Before adding
> any new complication, I think it's important to ask "Will this make the
> game more fun?"  There isn't only one right answer, since the answer
> depends on who's answering, and on the context of the particular game in
> which the feature will be used.  But I think the question should be asked.

Agreed.

> That's one reason I said in one of my other messages that I think the
> GIS/XConq translation process will need a lot of customization per map;
> really, what it needs is customization *per game*.  Some games will want
> some of the data to be really detailed; others will want less of the data
> and less detail in it.  I think that in all cases the game's needs have to
> come first, and they'll shape how the data is treated.

Again, I agree. I think much of this can be controlled by predetermining 
how many bins someone wants in each categories, and which categories are 
even desired. Fewer bins -> coarser binning -> lesser detail -> more 
easily manageable from game design perspective.

> I have similar reservations about Cooper's plan to make every hex its own
> unique terrain type.  I can see doing that as a work-around in order to
> give every hex its own unique picture, but even that seems like a lot of
> work and I think it would be a very special game that actually needed it.  
> It would be nice to instead do something like the recent "specify a
> picture for an individual unit" patch to allow specification of a picture
> for an individual hex, while leaving the hexes grouped into just a few
> terrain types.  

This is reasonable. However, there is still the advantage that one 
terrain type per hex can be binned in multiple categories, which gives 
the ultimate in variety. But, again, you are right in that we should 
stop to ask how much matters to the player.

> Clouds and unit altitudes sure
> seem to be so cumbersome in the current interfaces as to be almost
> unusable (if, in fact, they are implemented at all).  

Unit altitudes are currently ignored.

Eric

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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  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  0:32   ` Using terrain coatings and existing code to model topography, weather, and vegetation Lincoln Peters
  2004-09-20  0:45   ` D. Cooper Stevenson
  3 siblings, 1 reply; 14+ messages in thread
From: Andreas Bringedal @ 2004-09-20  0:30 UTC (permalink / raw)
  To: xconq7


> On Sun, 19 Sep 2004, Lincoln Peters wrote:
> > 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.
>
> Just a caution:  This is a game.  It's supposed to be fun.  Before adding
> any new complication, I think it's important to ask "Will this make the
> game more fun?"  There isn't only one right answer, since the answer
> depends on who's answering, and on the context of the particular game in
> which the feature will be used.  But I think the question should be asked.

Yes making a funcionally weather system does seems like overkill. What about making a simplified weather system which is just based
on lontitude and time of year(and if implemented altitude) in a semi random manner.  Certain areas are prone to certain weathers in
certain periods of the year where only a handful of weather types has an impact. Rain/mud, Snow, Frozen, Fog, Storm and Blizzard.
Rain, fog, storm and blizzard affect visibility and thereby the 'to hit'-ability of units as well as speed, while snow, frozen,
blizzard and mud affect terrain (im)passability and speed.  I would think these 'areas' could be made mobile without too much
problem simulating the movement of a raincloud or a storm across the map. You could then get storm effects like Terrible Ivan that
just went rampant and the players would anxiously try to avoid them. Fly a plane into it and watch it crash, force move a troop of
infantry through it and see the attrition skyrocket.  It would be nifty to have a strenght 5 storm move semirandomly across the map
by spesific scenario design or by a very low random chance.

With such weather areas moving across the game you could give them different speeds and different sizes where the largest would be
covering the whole map and the smalles just a handful of provinces.  They could be tailored made for specific scenarios which
varying degrees of randomness which would help people create (historical) scenarios or they could be randomly created. A weather
area could for instance appear withing 1-5 turns before or after one specified turn, appear at province x,y or near it or it can
have a random size within given minimums and maximums etc.

The mobile weather areas could have parameters like size, start area, speed, direction, change of direction point, end area.  The
non mobile temperature areas (above or below zero mainly), would decide if the mobile weather area creates rain or snow.  You could
have a lingering mud area after a mobile rain area passed and the same lingering mud area when a frozen area thaw.  The non mobile
weather areas would have parameters like size, start(randomly within span of turns or a specific turn), end.  If you wanted to make
it even more relistic you could expand the temperature areas to the whole map and give extreme temperatures attrition effects on
units.  The heat of Sahara or the cold of the Alps could then be simulated.

If these weather areas had weak graphic representation that overlaid the GIS map that is suggested created now(great project btw!),
like rain drops, snow flakes, slight graying of the area for fog and faster moving and more rain drops/snow flakes for
storm/blizzard, you would have a very nice effect without what seems to me to be overwhelming work(?) and without cluttering up the
map with 4 types of overlay. Rain and snow shouldn't obscure a hex to any degree(just enough so that the player can see that it
rains/snows) but with a blizzard you should have trouble identifying what's in the hex even if you are in the hex next to it.

Just some thoughts from a player and non programmer though.

-Andreas



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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  2004-09-19 23:32 ` mskala
  2004-09-20  0:24   ` Eric McDonald
  2004-09-20  0:30   ` Andreas Bringedal
@ 2004-09-20  0:32   ` Lincoln Peters
  2004-09-20  0:45   ` D. Cooper Stevenson
  3 siblings, 0 replies; 14+ messages in thread
From: Lincoln Peters @ 2004-09-20  0:32 UTC (permalink / raw)
  To: mskala; +Cc: Xconq list

On Sun, 2004-09-19 at 16:13, mskala@ansuz.sooke.bc.ca wrote:
> On Sun, 19 Sep 2004, Lincoln Peters wrote:
> > 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.
> 
> Just a caution:  This is a game.  It's supposed to be fun.  Before adding
> any new complication, I think it's important to ask "Will this make the
> game more fun?"  There isn't only one right answer, since the answer
> depends on who's answering, and on the context of the particular game in
> which the feature will be used.  But I think the question should be asked.

I would imagine that some of these details could be disabled in a
particular game if necessary.  I know that there are more than a few
historical battles that were affected to a significant extent by
weather.

I also seem to recall that, in an old post I found in the archive,
someone mentioned that voyages.g (and modules based on it, such as
magellan.g) would be a lot more interesting if it could make the trip
across the Atlantic as difficult as it was in real life.  A better
weather model would be an important first step toward that goal.

> 
> My thinking is that as a player, I seldom if ever want to know (for
> instance) how much potash is in the soil.  At most, I might want to know
> "this is fertile soil; that is unfertile soil".  If there are more than
> two or three levels of fertility, let alone more than one dimension of
> fertility (nitrogen, potash, acidity...) then I'm just going to be
> confused.  I'm usually quite happy to have details abstracted.  The level
> of abstraction that's appropriate varies a lot depending on the individual
> game.  Some games are "strategic", some are "operational", some are
> "tactical", and in general you see more detail and more complication at
> the tactical level and less at the strategic level.

In most cases, this kind of detail would be handled in the background. 
Perhaps no game would ever want to implement multiple dimensions of soil
fertility in a game, but if nothing else, I could see it being used to
build a more realistic system for creating random maps.

> 
> That's one reason I said in one of my other messages that I think the
> GIS/XConq translation process will need a lot of customization per map;
> really, what it needs is customization *per game*.  Some games will want
> some of the data to be really detailed; others will want less of the data
> and less detail in it.  I think that in all cases the game's needs have to
> come first, and they'll shape how the data is treated.

This could probably be handled by using variants in the terrain module,
although it may be necessary to add a GDL method to enable or disable
variants when including a module.

> 
> I have similar reservations about Cooper's plan to make every hex its own
> unique terrain type.  I can see doing that as a work-around in order to
> give every hex its own unique picture, but even that seems like a lot of
> work and I think it would be a very special game that actually needed it.  
> It would be nice to instead do something like the recent "specify a
> picture for an individual unit" patch to allow specification of a picture
> for an individual hex, while leaving the hexes grouped into just a few
> terrain types.  Ideally, you could specify custom pictures for just a few
> hexes, or for every hex, according to taste - that way you could deal with
> a wide range of different game needs.

I was hoping that a terrain/weather mechanism like the one I described
would allow for enough detail that one would not have to make each cell
have a unique terrain-type.  And, as you said, it should be possible to
allow different cells with the same terrain-type to have different
images, since the same thing can now be done with units.

> 
> I also wonder about the user interface issues with extremely detailed
> maps.  I'm not sure how coatings are currently handled, but I'm guessing
> that dealing with them may be cumbersome.  Clouds and unit altitudes sure
> seem to be so cumbersome in the current interfaces as to be almost
> unusable (if, in fact, they are implemented at all).  Temperatures seem to
> be at least partially implemented, but when I've played games that use
> them I've always ended up turning off the temperature display because it's
> just too confusing.  I'm not looking forward to what I'll have to do as a
> player to stay on top of what's going on with four layers of coatings, if 
> they're all game-play significant.

Weather maps are notorious for being cumbersome and difficult to read,
but they *are* easier to read than the information given on the Xconq
map.

I can easily see temperature being displayed in isotherms (i.e. areas of
a particular temperature would be shown in the same manner as
elevations) as a way to clean up the interface significantly.  Winds are
trickier; wind in Xconq is not based on air pressure (as it is in real
life), so you couldn't handle it by drawing isobars unless we were to
re-write the wind code.  As for clouds, I think that it would be easiest
to represent them using the isometric code (or a variant thereof) to
show them in some sort of 3D space.

> 
> Anyway, if you can think of a game you'd like to build that would actually
> use this level of weather simulation, then by all means go for it.

My goal with this terrain/weather model is to provide a framework for
the GIS data (which apparently includes weather statistics) so that it
could be added to Xconq in as much exquisite detail as possible.  I
could see myself using it in knightmare.g, and I kind of suspect that
Elijah could find a use for it as well.

Even if the weather stuff I describe doesn't get implemented, some of
the terrain coating things, such as implementing vegetation as one or
more coating types, would add a lot of flexibility to Xconq.

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

OKAY!!  Turn on the sound ONLY for TRYNEL CARPETING, FULLY-EQUIPPED
R.V.'S and FLOATATION SYSTEMS!!

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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  2004-09-19 23:32 ` mskala
                     ` (2 preceding siblings ...)
  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
  3 siblings, 0 replies; 14+ messages in thread
From: D. Cooper Stevenson @ 2004-09-20  0:45 UTC (permalink / raw)
  To: mskala; +Cc: Lincoln Peters, Xconq Mailing List

On Sun, 2004-09-19 at 16:13, mskala@ansuz.sooke.bc.ca wrote:
[snip]
>  I'm usually quite happy to have details abstracted.  The level
> of abstraction that's appropriate varies a lot depending on the individual
> game.  Some games are "strategic", some are "operational", some are
> "tactical", and in general you see more detail and more complication at
> the tactical level and less at the strategic level.

I don't want to lose the tactical aspect of the game: that's critical.
For me, thinking about how movements should be made in the macro sense
is a primary draw to the fun of the game.

> 
> That's one reason I said in one of my other messages that I think the
> GIS/XConq translation process will need a lot of customization per map;
> really, what it needs is customization *per game*.  Some games will want
> some of the data to be really detailed; others will want less of the data
> and less detail in it.  I think that in all cases the game's needs have to
> come first, and they'll shape how the data is treated.

You're right. I overlooked this. I'm going to do Antarctica first, then
look for an, "operations" level theater to do (Normandy Beach?). I hope
that I then have the experience to give the satellite view of a tactical
theater without getting in the way. Think: a "toned down" satellite look
with only the relevant features making it through the filters.
 
> 
> I have similar reservations about Cooper's plan to make every hex its own
> unique terrain type. 

Me too. I thought as I drafted my plan, "wouldn't it be nice if I could
say, okay, Xconq, here's your world view image divided into hexes. Now,
0,0 is border, 0,1 is sea, 0,2 is plains, 0,3 is mountains, and so on."

>  I can see doing that as a work-around in order to
> give every hex its own unique picture, but even that seems like a lot of
> work and I think it would be a very special game that actually needed it.

Exactly.

>   
> It would be nice to instead do something like the recent "specify a
> picture for an individual unit" patch to allow specification of a picture
> for an individual hex, while leaving the hexes grouped into just a few
> terrain types.

Exactly! Also, if a designer later wishes to design new terrain types to
match their design goals, we haven't gotten in their way to do so!

>  Ideally, you could specify custom pictures for just a few
> hexes, or for every hex, according to taste - that way you could deal with
> a wide range of different game needs.

Right. This feeds full circle back to the type of game. If it's a
tactical game you're after, just have a few different tiles for each
terrain type. If it's an operations level game you're after, have each
tile accurately reflect the actual topography. The key is to display
tiles and display them well without getting in the way of the games
native functionality or the designers goals.

I think this is the way to go. I will look deeper into the patch and try
to emulate it from the first go.

My primary focus is to bringing nice-looking satellite imagery to Xconq.
This way, the game designer gets the opportunity to use (and modify) the
imagery while at the same time giving them the freedom to implement
whatever attributes the designer wishes.

A game scenario about trying to take Russia in the winter, for example,
definitely has a weather factor. I don't want to interfere with the
designer's freedom to do that.


-Coop


-- 
--------------------------------------------------------------
| Cooper Stevenson        | Em:  cooper@gencom.us            |
| GenCom                  | Ph:  541.924.9434                |
| "Working For IT"        | Www: http://www.gencom.us        |
--------------------------------------------------------------

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

* Re: Coatings
  2004-09-19 23:44 ` Coatings Eric McDonald
@ 2004-09-20  0:45   ` Lincoln Peters
  2004-09-20  0:58     ` Coatings Elijah Meeks
  2004-09-21  2:09     ` Coatings Eric McDonald
  0 siblings, 2 replies; 14+ messages in thread
From: Lincoln Peters @ 2004-09-20  0:45 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

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!

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

* Re: Coatings
  2004-09-20  0:45   ` Coatings Lincoln Peters
@ 2004-09-20  0:58     ` Elijah Meeks
  2004-09-21  2:09     ` Coatings Eric McDonald
  1 sibling, 0 replies; 14+ messages in thread
From: Elijah Meeks @ 2004-09-20  0:58 UTC (permalink / raw)
  To: Lincoln Peters, Eric McDonald; +Cc: Xconq list

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

I think that making the coating system work better
would prove advantageous in the long run.  Certain
unit actions, like clearing or irrigating terrain,
would make more sense and therefore be easier to
program if the action more resembles the actual,
physical act (i.e. removing the 'deciduous-forest'
coating instead of changing the terrain from
'deciduous-forest' to 'plains').

The first major change I'd recommend for coating,
though, is that it accept real images, and not the
(ugly) transparent effect it has now.  It would look
about ten thousand times better.

And in regard to napoleon.g, it seemed like the
problem was with some unit images and not the weather
code.  Well, unit images and the incredibly ugly cloud
effect that XConq uses...  Okay, I admit it, I'm a
graphics snob.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  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
  0 siblings, 2 replies; 14+ messages in thread
From: mskala @ 2004-09-20  1:33 UTC (permalink / raw)
  To: Andreas Bringedal; +Cc: xconq7

On Mon, 20 Sep 2004, Andreas Bringedal wrote:
> infantry through it and see the attrition skyrocket.  It would be
> nifty to have a strenght 5 storm move semirandomly across the map by
> spesific scenario design or by a very low random chance.

I think if I wanted to model a hurricane, I might do it by having the
storm be a unit that detonates on every turn but doesn't destroy itself
when it detonates.  Then the detonation effect could cause damage to
nearby units and potentially even modify terrain.  I'm not sure how I'd go
about making it move in a storm-like way, although I think maybe it could
be made to be blown around by the existing "wind" code.

I was actually already thinking of something very similar to model Project
Pluto - that's a remote-controlled supersonic airplane powered by an
unshielded fission reactor, so that it kills anything it flies near.  It
was a real-life design (thankfully never built) but used to good advantage
in fiction here:  http://www.infinityplus.co.uk/stories/colderwar.htm
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  2004-09-20  1:33     ` mskala
@ 2004-09-20  2:35       ` Lincoln Peters
  2004-09-21  0:43       ` Eric McDonald
  1 sibling, 0 replies; 14+ messages in thread
From: Lincoln Peters @ 2004-09-20  2:35 UTC (permalink / raw)
  To: mskala; +Cc: Xconq list

On Sun, 2004-09-19 at 18:02, mskala@ansuz.sooke.bc.ca wrote:
> I think if I wanted to model a hurricane, I might do it by having the
> storm be a unit that detonates on every turn but doesn't destroy itself
> when it detonates.  Then the detonation effect could cause damage to
> nearby units and potentially even modify terrain.  I'm not sure how I'd go
> about making it move in a storm-like way, although I think maybe it could
> be made to be blown around by the existing "wind" code.

I assume that the hurricane would be an independent unit, and the
independent side would have an AI (and thus could do things).  It would
get especially tricky to move the hurricane in a storm-like way, since
the iplayer would try to use it like a normal unit.  Of course, since it
doesn't understand detonating units, it might behave in amusing (?)
ways, but it would not behave like a hurricane.

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

Q:	"What is the burning question on the mind of every dyslexic
	existentialist?"
A:	"Is there a dog?"

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

* Re: Using terrain coatings and existing code to model topography, weather, and vegetation
  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
  1 sibling, 1 reply; 14+ messages in thread
From: Eric McDonald @ 2004-09-21  0:43 UTC (permalink / raw)
  To: mskala; +Cc: xconq7

mskala@ansuz.sooke.bc.ca wrote:

> On Mon, 20 Sep 2004, Andreas Bringedal wrote:
> 
>>infantry through it and see the attrition skyrocket.  It would be
>>nifty to have a strenght 5 storm move semirandomly across the map by
>>spesific scenario design or by a very low random chance.
> 
> 
> I think if I wanted to model a hurricane, I might do it by having the
> storm be a unit that detonates on every turn but doesn't destroy itself
> when it detonates.  Then the detonation effect could cause damage to
> nearby units and potentially even modify terrain.  I'm not sure how I'd go
> about making it move in a storm-like way, although I think maybe it could
> be made to be blown around by the existing "wind" code.

To the best of my knowledge, the wind code acts as an impediment to 
movement and not a driver for it. But, it would be interesting to extend 
so that it could be a motivator as well. Some of the restructuring of 
the ACP computations that I did a while back ago should help in this regard.

> I was actually already thinking of something very similar to model Project
> Pluto - that's a remote-controlled supersonic airplane powered by an
> unshielded fission reactor, so that it kills anything it flies near.  It
> was a real-life design (thankfully never built) but used to good advantage
> in fiction here:  http://www.infinityplus.co.uk/stories/colderwar.htm

Neat little story. I see the author borrowed from Lovecraft in places.
Of course, one problem I have with nuclear-powered aircraft and 
spacecraft is the cooling aspect. If you're dumping 60% to 70% of the 
energy due to the efficiency of your "engine", all that energy has got 
to go somewhere. But, I digress.... Now that I took the time to read the 
story, I probably won't be able to get a new Windows installer and 
source tarball for Xconq ready this evening. Oh well, it was a fun 
little read.

Eric

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

* Re: Coatings
  2004-09-20  0:45   ` Coatings Lincoln Peters
  2004-09-20  0:58     ` Coatings Elijah Meeks
@ 2004-09-21  2:09     ` Eric McDonald
  1 sibling, 0 replies; 14+ messages in thread
From: Eric McDonald @ 2004-09-21  2:09 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

Lincoln Peters wrote:

> 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 whole point of binning the same cell into multiple categories is so 
that various aspects of that cell can be tracked separately. Assuming 
that the topographical data and the vegetation data can be aligned and 
scaled the same, then each cell cut out with a "hex cookie cutter" would 
have both of those layers, each of which could be used to bin the 
separately in the relevant category.

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

This could be a reasonable modification to address the liquid terrain 
concern.

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

That was my point.

Eric

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

* Weather tidbit
  2004-09-21  0:43       ` Eric McDonald
@ 2005-01-04 19:30         ` mskala
  0 siblings, 0 replies; 14+ messages in thread
From: mskala @ 2005-01-04 19:30 UTC (permalink / raw)
  To: Eric McDonald; +Cc: xconq7, xconq-developers

On Sun, 19 Sep 2004, Eric McDonald wrote:
> > I think if I wanted to model a hurricane, I might do it by having the
> > storm be a unit that detonates on every turn but doesn't destroy itself

> To the best of my knowledge, the wind code acts as an impediment to
> movement and not a driver for it. But, it would be interesting to extend

Digging through my mail to see what messages from my vacation I could
delete, I found the above very old message and thought of another
game-design idea that seems worth mentioning for the archives:  what could
be done would be to make the "hurricane" unit be controlled by iplayer,
and make it move more or less at random.  I think that could be done by
making it blind and invulnerable, and probably also unable to attack
except with its detonation.  Then I think iplayer will tend to move it
randomly.  If it's also set up so that it only *can* move in the direction
the wind is blowing, then we have a unit that moves where the wind
carries it.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

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