This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]