Bug reports, feature requests, and dilemmas [was: Re: New Feature:Overwatch]

[Lincoln Peters <sampln at sbcglobal dot net>]

On Sat, 2005-01-01 at 14:37 -0700, Eric McDonald wrote:
> Lincoln Peters wrote:
> 
> > I suppose I should also copy the various unfulfilled feature requests
> > I've made on this list to the Sourceforge page, so that they'll be
> > easier to keep track of.
> 
> Yes. That would be of much help.

I've finished submitting 4 bug reports and 5 feature requests.

Looking back at some of the messages I've posted, I noticed the
following issues that were discussed, but we never decided what to do
about them:

1. Adapting GIS data to Xconq: The NLCD system used by the USGS treats
developed areas as part of the terrain, whereas Xconq would usually
treat them as units.  As I think about this, the solution would
ultimately depend on the scale of the game and the resolution of the
NCLD data.  Since I'm not familiar with all of the military lingo
involved, I've listed my ideas based on what existing game modules use
the scale in question:

Beirut: Depends on the resolution of the data provided by the GIS.  It
might be possible to use some of Xconq's existing synthesis methods to
randomly generate units and terrain if the scale of the game is too
small for the data provided by the GIS.  This would involve populating
developed areas with units representing buildings, and maybe
synthesizing roads if the GIS doesn't provide such information or it
only provides major roads.

Panzer: Probably no adjustments required other than placing units
representing cities over terrain marked as "developed".  The only issue
I can immediately foresee here is that a unit would have to occupy
multiple cells simultaneously, depending on the size of the developed
area relative to the scale of the game.

WWII, Advanced: There may be scaling issues if a "developed" area is
smaller than a single cell on the map (is it small enough that it's
strategically insignificant and can be omitted, or should it be left on
the map?).  Perhaps this issue can be resolved automatically; I'm not
sure.  As before, the "developed" areas would likely need to be
populated with units representing cities before they would be useful.

Still no clear course of action, but I hope that these ideas bring us a
little closer.


2. Handling rivers from GIS data: Should they be cell terrain, border
terrain, or connection terrain?  The answer would depend on several
factors, including the scale at which the game is played and the
presence (or absence) of ships capable of sailing along them.  In a game
like Advances, Ancient Greece, or Ancient Rome, you'd probably want to
set up rivers so that they would simultaneously impede movement of land
units and allow movement of certain naval units.  As far as I can tell,
this would be awkward regardless of whether you went with borders or
connections.


3. Weather simulations: If you wanted to write a game module based on
Napoleon's invasion of Russia, which ultimately proved disastrous due to
a cold Russian winter, you would present an interesting challenge for
the French army because, although they have superior weapons and
training, they must move very quickly or suffer the effects of an
extremely cold winter:

a. If the French can capture Moscow and either return to France or
fortify in Moscow before winter, they win.

b. If the French cannot capture Moscow before winter, but they are able
to capture another town, city, or fort that they could use to wait for
the end of winter, their food and fuel consumption will not change, but
they might run out before spring.  (Note that the Russians retreated and
burned every town and city to the ground before the French could capture
them.)

c. If the French are caught out in the open during the winter, their
food and fuel consumption skyrockets (not sure exactly how much it would
increase).

If the French run out of food or fuel, they suffer attrition as would be
expected.  If they are within a Russian winter at the time, the
attrition skyrockets, just as their food and fuel consumption did.  The
effects of running out of food *and* fuel would be cumulative.

This illustrates how weather simulations would be required to implement
certain historical simulations.  I've been trying to find one of the
weather models used in the 1970's and earlier, in the hopes that it
could be imported into Xconq (a mainframe of that era was about as
powerful as a 386 PC, so I doubt the CPU/memory requirements would be
prohibitive).  So far, I'm still searching.

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

BOFH excuse #52:

Smell from unhygienic janitorial staff wrecked the tape heads