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

[Eric McDonald <mcdonald@phy.cmich.edu>]

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