From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4969 invoked by alias); 19 Sep 2004 22:19:13 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 4960 invoked from network); 19 Sep 2004 22:19:11 -0000 Received: from unknown (HELO smtp812.mail.sc5.yahoo.com) (66.163.170.82) by sourceware.org with SMTP; 19 Sep 2004 22:19:11 -0000 Received: from unknown (HELO ?192.168.1.101?) (sampln@sbcglobal.net@67.121.168.201 with plain) by smtp812.mail.sc5.yahoo.com with SMTP; 19 Sep 2004 22:19:10 -0000 Subject: Using terrain coatings and existing code to model topography, weather, and vegetation From: Lincoln Peters To: Xconq list Content-Type: text/plain; charset=UTF-8 Message-Id: <1095632486.15989.24818.camel@localhost> Mime-Version: 1.0 Date: Sun, 19 Sep 2004 23:17:00 -0000 Content-Transfer-Encoding: 8bit X-SW-Source: 2004/txt/msg01187.txt.bz2 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 To err is human, to forgive, beyond the scope of the Operating System.