* New Feature: Overwatch @ 2005-01-01 6:59 Eric McDonald 2005-01-01 7:19 ` Lincoln Peters 0 siblings, 1 reply; 8+ messages in thread From: Eric McDonald @ 2005-01-01 6:59 UTC (permalink / raw) To: xconq-developers, xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New Feature: Overwatch 2005-01-01 6:59 New Feature: Overwatch Eric McDonald @ 2005-01-01 7:19 ` Lincoln Peters 2005-01-01 16:31 ` Eric McDonald 0 siblings, 1 reply; 8+ messages in thread From: Lincoln Peters @ 2005-01-01 7:19 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq-developers, xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New Feature: Overwatch 2005-01-01 7:19 ` Lincoln Peters @ 2005-01-01 16:31 ` Eric McDonald 2005-01-01 21:09 ` Lincoln Peters 0 siblings, 1 reply; 8+ messages in thread From: Eric McDonald @ 2005-01-01 16:31 UTC (permalink / raw) To: Lincoln Peters; +Cc: xconq-developers, xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New Feature: Overwatch 2005-01-01 16:31 ` Eric McDonald @ 2005-01-01 21:09 ` Lincoln Peters 2005-01-01 21:38 ` Eric McDonald 0 siblings, 1 reply; 8+ messages in thread From: Lincoln Peters @ 2005-01-01 21:09 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq-developers, xconq7 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: New Feature: Overwatch 2005-01-01 21:09 ` Lincoln Peters @ 2005-01-01 21:38 ` Eric McDonald 2005-01-02 2:43 ` Bug reports, feature requests, and dilemmas [was: Re: New Feature: Overwatch] Lincoln Peters 0 siblings, 1 reply; 8+ messages in thread From: Eric McDonald @ 2005-01-01 21:38 UTC (permalink / raw) To: Lincoln Peters; +Cc: xconq-developers, xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Bug reports, feature requests, and dilemmas [was: Re: New Feature: Overwatch] 2005-01-01 21:38 ` Eric McDonald @ 2005-01-02 2:43 ` Lincoln Peters 2005-01-04 17:24 ` GIS and navigable rivers mskala 0 siblings, 1 reply; 8+ messages in thread From: Lincoln Peters @ 2005-01-02 2:43 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq-developers, xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* GIS and navigable rivers 2005-01-02 2:43 ` Bug reports, feature requests, and dilemmas [was: Re: New Feature: Overwatch] Lincoln Peters @ 2005-01-04 17:24 ` mskala 2005-01-04 21:27 ` Lincoln Peters 0 siblings, 1 reply; 8+ messages in thread From: mskala @ 2005-01-04 17:24 UTC (permalink / raw) To: Lincoln Peters; +Cc: xconq-developers, xconq7 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GIS and navigable rivers 2005-01-04 17:24 ` GIS and navigable rivers mskala @ 2005-01-04 21:27 ` Lincoln Peters 0 siblings, 0 replies; 8+ messages in thread From: Lincoln Peters @ 2005-01-04 21:27 UTC (permalink / raw) To: mskala; +Cc: Xconq developers mailing list, xconq7 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-01-04 21:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-01 6:59 New Feature: Overwatch Eric McDonald 2005-01-01 7:19 ` Lincoln Peters 2005-01-01 16:31 ` Eric McDonald 2005-01-01 21:09 ` Lincoln Peters 2005-01-01 21:38 ` Eric McDonald 2005-01-02 2:43 ` Bug reports, feature requests, and dilemmas [was: Re: New Feature: Overwatch] Lincoln Peters 2005-01-04 17:24 ` GIS and navigable rivers mskala 2005-01-04 21:27 ` Lincoln Peters
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).