New Feature: Overwatch

New Feature: Overwatch

[Eric McDonald]

Hello Xconq Game Designers,

   I have implemented a new feature to ring in the new year. (I managed 
to complete and test it just before local midnight.)

   The new feature is overwatch. An unit can now have a 
zone-of-overwatch (ZOO) that it maintains against other units of various 
types. The principle is very similar to ZOC (zone-of-control), except 
that ZOO's are inherently penetrable, whereas ZOC's are normally "hard". 
An unit entering into a ZOO of enemy unit will be immediately and 
automatically fired upon, provided the enemy unit has the necessary ACP 
and/or materials.
   Three new GDL tables are associated with this feature: 'zoo-range', 
'zoo-range-min', and 'acp-for-overwatch'. 'zoo-range' and 
'zoo-range-min' are TableUU, and specify range in cells. If 'zoo-range' 
exceeds the overwatcher's fire 'range' property, it will be clipped to 
that property. Likewise, if 'zoo-range-min' is less than the 
overwatcher's fire 'range-min' property it will be clipped to that 
property. 'acp-for-overwatch' (TableUU) is a mechanism for providing 
additional ACP so that an unit can respond to violations of its ZOO, 
even it would normally be out of ACP; the table tells how much extra ACP 
an overwatcher will get for the purpose of firing on another unit of a 
certain type.
   There is still room for improvement. A probability table would be a 
nice addition, as would doctrines controlling minimum materials needed 
to overwatch fire and maximum number of overwatch firing against an unit 
of a particular type per move of that unit. I also must ensure that it 
can work with acp-indep units.

   Enjoy, and happy [Gregorian] new year,
      Eric

Re: New Feature: Overwatch

[Lincoln Peters]

On Fri, 2004-12-31 at 23:59 -0700, Eric McDonald wrote:
>    The new feature is overwatch. An unit can now have a 
> zone-of-overwatch (ZOO) that it maintains against other units of various 
> types. The principle is very similar to ZOC (zone-of-control), except 
> that ZOO's are inherently penetrable, whereas ZOC's are normally "hard". 
> An unit entering into a ZOO of enemy unit will be immediately and 
> automatically fired upon, provided the enemy unit has the necessary ACP 
> and/or materials.

This sounds like exactly what I was looking for with towers in bolodd2.g
and bolodd3.g (I wanted them to automatically fire at any enemy unit
that came within their firing range).  And I imagine that this feature
will prove valuable in many more games.

What would happen if multiple enemy units are within the zone of
overwatch?

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

Confucius say too much.
		-- Recent Chinese Proverb

Re: New Feature: Overwatch

[Eric McDonald]

Lincoln Peters wrote:

> This sounds like exactly what I was looking for with towers in bolodd2.g
> and bolodd3.g (I wanted them to automatically fire at any enemy unit
> that came within their firing range).  And I imagine that this feature
> will prove valuable in many more games.

I anticipate that it will be showing up in some of Elijah's games, as he 
is the one who put in the feature request at Sourceforge.

Of course, any mods to the BoloDD family or the long-awaited Knightmare 
would be welcome too.

> What would happen if multiple enemy units are within the zone of
> overwatch?

Not to sound like Bill Clinton chatting with Ken Starr, but I would take 
issue with the word "are". An overwatch firing is triggered by movement. 
So, it is not a matter of an unit _being_ in a particular zone, but 
rather an issue of an unit _moving_ into or within a particular zone. In 
a hacked up version of 'vision.g', which is a derivative of Elijah's 
'conquest.g', there were many units in the zone of overwatch (though 
different cells) because the different sides started out within 
relatively close proximity to each other's heavy phasers (the units I 
setup to perform overwatch against ship types). The game proceeded 
somewhat slowly in Tkconq because sometimes as many as 6 different heavy 
phasers were responding to a ship's movement. But, it worked, and there 
was certainly more than one unit in most ZOO's.

Eric

Re: New Feature: Overwatch

[Lincoln Peters]

On Sat, 2005-01-01 at 09:31 -0700, Eric McDonald wrote:
> Lincoln Peters wrote:
> 
> > This sounds like exactly what I was looking for with towers in bolodd2.g
> > and bolodd3.g (I wanted them to automatically fire at any enemy unit
> > that came within their firing range).  And I imagine that this feature
> > will prove valuable in many more games.
> 
> I anticipate that it will be showing up in some of Elijah's games, as he 
> is the one who put in the feature request at Sourceforge.

Undoubtedly.

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.

> 
> Of course, any mods to the BoloDD family or the long-awaited Knightmare 
> would be welcome too.

I finally got some time to work on Knightmare last night, and I may be
able to work on it some more over the next few days.  It has grown to
over 3,000 lines (and still growing!), so it's proving to take a while
to debug.

> 
> > What would happen if multiple enemy units are within the zone of
> > overwatch?
> 
> Not to sound like Bill Clinton chatting with Ken Starr, but I would take 
> issue with the word "are". An overwatch firing is triggered by movement. 
> So, it is not a matter of an unit _being_ in a particular zone, but 
> rather an issue of an unit _moving_ into or within a particular zone. In 
> a hacked up version of 'vision.g', which is a derivative of Elijah's 
> 'conquest.g', there were many units in the zone of overwatch (though 
> different cells) because the different sides started out within 
> relatively close proximity to each other's heavy phasers (the units I 
> setup to perform overwatch against ship types). The game proceeded 
> somewhat slowly in Tkconq because sometimes as many as 6 different heavy 
> phasers were responding to a ship's movement. But, it worked, and there 
> was certainly more than one unit in most ZOO's.

Now it makes sense.  Although it sounds like in one of the BoloDD games,
a tank could move to within 4 cells of a tower, start firing on it, and
only be automatically attacked once.

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

Academicians care, that's who.

Re: New Feature: Overwatch

[Eric McDonald]

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.

> Now it makes sense.  Although it sounds like in one of the BoloDD games,
> a tank could move to within 4 cells of a tower, start firing on it, and
> only be automatically attacked once.

Correct, __until the tank moves again. I think you may be looking for 
another feature that Elijah requested about the same time as overwatch, 
namely "counterfire". I have not attempted to implement this, but I 
envision it being the firing analog to "counterattack". Of course, 
things need to be set up so that an attack can be responded to by 
counterfire, and vice versa. In the case where both counterattack and 
counterfire are available, then probably a 'preferred-hit-method' table 
will be needed to decide between them. Such a table would also be useful 
for disambiguating the two options in the case of an overrun action, 
when both are available.

Eric

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

[Lincoln Peters]

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

GIS and navigable rivers

[mskala]

On Sat, 1 Jan 2005, Lincoln Peters wrote:
> 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

> 2. Handling rivers from GIS data: Should they be cell terrain, border

I think both these issues illustrate my point that GIS->game conversion
really depends on the game.  If we're going to do it automatically, I
think we should give the designer a lot of control to specify just what
conversions should be done.

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

There's some discussion of the navigable-rivers issue in the designer's
manual; if you make them borders so that they can impede land movement,
then it's tricky for ships to travel along them, and if you make them
connections so that ships can travel along them, they won't impede land
movement.  The documentation suggests making a chain of alternating lake
hexes and river borders, and using the special "border slide" movement
mode.

Another thing one could do, although it's something of a hack, is to
represent a river by a connection type *and* a border type, going in lines
parallel to each other; the graphics could be designed either to make one
of those invisible, or to make the two of them together look like a single
river.  That's actually quite an attractive idea; I think I'll try to find
some time to design a sample game illustrating it.

I think it would be worth researching what the old-style tabletop hex-grid
games did about this issue, since they would have faced it too.  The ones
I'm familiar with did it in a makeshift way by having rivers be what XConq
calls connections, and having the land within a cell containing a river be
split into two chunks, with players required to keep track of which bank a
given unit is on.  I think that would be prohibitively difficult for XConq
because it means changing the topology of the grid entirely.  But there've
got to be games that handled it in a more computer-friendly way.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: GIS and navigable rivers

[Lincoln Peters]

On Tue, 2005-01-04 at 12:32 -0500, mskala@ansuz.sooke.bc.ca wrote:
> There's some discussion of the navigable-rivers issue in the designer's
> manual; if you make them borders so that they can impede land movement,
> then it's tricky for ships to travel along them, and if you make them
> connections so that ships can travel along them, they won't impede land
> movement.  The documentation suggests making a chain of alternating lake
> hexes and river borders, and using the special "border slide" movement
> mode.

The more I think about this, the more I think that the solution would be
to make mp-to-leave-terrain work for connections, so that one can cause
a unit to spend one or two extra MP's to leave a cell with a certain
type of connection, preferably without penalizing them if they simply
traverse the connection (unless mp-to-traverse is used for that purpose)
or cross it by means of another connection (i.e. a bridge).

I'll add this to the feature request tracker on SourceForge as soon as I
get a chance.

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

BOFH excuse #134:

because of network lag due to too many people playing deathmatch