public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Skeezics Boondoggle <skeezics@q7.com>
To: xconq7@sources.redhat.com
Subject: Re: fighters fighting without ammo
Date: Sun, 07 Dec 2003 18:13:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0312070811360.19370-100000@q7.q7.com> (raw)
In-Reply-To: <200312071607.hB7G7Ld08163@panix5.panix.com>

On Sun, 7 Dec 2003, Jim Kingdon wrote:

> > i play the modern game regularly. using fighters is becoming a
> > pia. If a fighter with ammo 2 attacks a cell with about 15
> > occupants, it fires 15 times even though the ammo is exhausted after
> > the first two shots.
> 
> The workaround is to use the "a" (attack) command which also lets you
> pick which of the 15 occupants you want to attack.

Geez, I never knew that.  That would come in handy if you have fighters 
attempting to pick out a bomber mixed in with a series of ground troops... 

> But yeah, getting the default (overrun) behavior to work better would
> make sense.  I suppose going through the library and setting
> material-to-attack along with consumption-per-attack might be one
> choice.  The standard game is another game which sets
> consumption-per-attack and not material-to-attack.

Well, consider that bombers have the same behavior too - bomb a city full
of units and it does hit/miss calculations for everything in the hex.  In 
that case, it might make more sense, since bombs could damage more than 
one unit, but for consistency you'd probably want the "three bombs, three 
hits max" behavior to apply there as well.

In fact, what is the "ammo" supposed to represent for fighters?  Certainly 
not bullets. :-)  Three passes or strafing runs?  Three 100-round bursts?  
Three volleys of rockets?  It could be argued that a fighter attacking a 
heavily occupied hex would have just as much likelihood at inflicting 
at least partial damage on more than n units per attack in that case...

Perhaps the calculations for both bomber and fighter attacks could reflect
a proportional damage assessment based on how many defenders are present?  
Choose one target with the "a" command and you inflict full damage on that
one target; click on a full hex otherwise and you potentially inflict
minor damage on multiple units.  (But the HP granularity probably wouldn't
allow for that level of precision, and could reduce the effectiveness of
air attacks too much.  Hmmm.)

The AIs don't use air power very effectively, which I must admit is one
easy way to defeat them.  In some games I've mounted such intense air and
naval bombardment campaigns that the AIs have resigned with 4 or 5 cities
left (whatever I hadn't flattened entirely) before my convoy of transports
has even reached shore.  Park a couple of destroyers off a coastal town
and lazily lob a few shells in there and you can eventually draw off
defenders to open up easy landing areas, and if you throw enough naval
units off the coast the AI will shift to building massive numbers of
bombers to try to eliminate them - which, at 16 turns to build, means you
have plenty of time to roll in an armored column and start picking off
towns and take away big chunks of manufacturing capability.  It's pretty
rare that I have to follow up with even a second transport load of armor
if the navy has peppered the coast, the fighters have cleared away the
enemy bombers, and paratroopers have taken at least one outlying town to
sow confusion in the poor AI's little brain. :-)  Very few games (with 3-5
AI opponents) go beyond 100 rounds...

I'm looking forward to some of the AI improvements, but y'know, most times
I like to just take a break and "go conquer the world" so it's kind of
relaxing to just swarm over the map and blast everything to bits.  :-)

But improving the AI's ability to use a more balanced approach to air, sea
and land power would probably improve its chances quite a bit.  It tends
to go nuts and build lots of one thing, then build lots of the next thing,
rarely seems to put up air patrols, never has destroyer screens to defend
coastal cities, and too often sends out waves of transports completely
undefended, where they're almost always picked up (first by fighters, then
by destroyers, as bombers are brought in to blow them away) way before
they reach landfall.  And losing full transports is expensive, obviously.

I guess if the AIs start to get smarter I'll have to work a little harder.
:-)

-- Chris

  reply	other threads:[~2003-12-07 16:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-07 16:07 Kenneth Gonsalves
2003-12-07 16:54 ` Lincoln Peters
2003-12-07 17:36 ` Jim Kingdon
2003-12-07 18:13   ` Skeezics Boondoggle [this message]
2003-12-07 23:54     ` Bruno Boettcher
2003-12-13  5:11       ` Eric McDonald
2003-12-13 10:57         ` Bruno Boettcher
2003-12-13 12:02           ` Hans Ronne
2003-12-13 19:55             ` Eric McDonald
2003-12-13 20:02             ` Jim Kingdon
2003-12-14  4:33               ` Hans Ronne
2003-12-08  8:19     ` Kenneth Gonsalves
2003-12-13  4:59     ` Eric McDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0312070811360.19370-100000@q7.q7.com \
    --to=skeezics@q7.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).