Re: Using terrain coatings and existing code to model topography,weather, and vegetation

[Lincoln Peters <sampln at sbcglobal dot net>]

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