Re: Consumption-per-fire?

[Eric McDonald <mcdonald@phy.cmich.edu>]

On Sat, 2004-06-05 at 02:08, Hans Ronne wrote:
> >>   I'd think if a designer was defining
> >> this table, you'd think the hit-by would default to
> >> true (Or 1 or whatever).  Why would anyone go through
> >> the trouble of defining a consumption-per-fire table
> >> and then not want it to apply?
> >
> >I have thought that 1 would probably be a better default as well.
> >However, I did not touch that table when applying the 'hit-by'
> >multiplier logic; so, whatever was put in as the default, by whoever
> >added that table, is what is still there.
> 
> Defaulting to 1 is OK provided that game designers are aware of the
> consequences. You would then have to explicitly disable hit-by for any
> units that you don't want to be hit by a particular ammo. I'm not sure if
> this is more logical (or less work) than enabling hit-by for units that can
> be hit.

I guess it comes down to a matter of how often someone is going to work
on a game with more than 1 ammo type. In games where only 1 ammo type is
available, I think the default of 1 makes much sense, since the designer
(particularly a newbie) is probably not going to want to selectively
disable it.

Only in the (exceptional?) cases where multiple ammo types are used,
would a designer generally want to selectively enable ammo on a per
target type basis.

One thing that I have noticed from working on a simple game (to test
wrecking improvements that I made last weekend) is that Xconq tables are
generally setup in such a way that if you don't touch them, they will do
the most sane and expected thing in light of the designer not explicitly
caring about the behaviors they control. I think 'hit-by' should follow
that principle.

Besides, if a designer wants to use multiple ammo types and selectively
enable them (based on target unit type), then it is trivial for him/her
to write:
  (u* m* 0)
at the beginning of the 'hit-by' table definition, if we change the
default.

> >Personally, I think that:
> >(a) There should be no built-in range restriction on capture-by-fire.
> >Instead, both attack and fire should have enabling tables
> >'capture-by-attack' and 'capture-by-fire', plus range restriction tables
> >on these types of capture.
> 
> This would certainly work, and somewhat extent the possibilities of game
> design. However, I doubt these extra range tables would be of much use. The
> reason why I put a range restriction of 1 on capture-by-fire (and I believe
> I did that at some point) is that I thought that capture-at-a-distance was
> inherently silly.

Potential examples of capture at a distance include:
(1) Spiderman throwing webs at criminals.
(2) Starships firing tractor beams at other starships.
(3) Swat teams throwing stun grenades into buildings.

>  To me, capture implies some kind of direct physical
> control, which you cannot exert from a remote position. This also made the
> capture-by-fire work the same way as capture-by-attack, which already is
> limited to adjacent units by the attack code itself.

Ooops. For some reason, I had thought that capture-by-attack was not
limited to adjacent cells (if someone was using an 'attack-range' > 1).

> >(b) Ammunition should also be able to be selectively consumed by
> >attacks.
> 
> It already is. That is what the consumption-per-attack table is for.

I forgot that 'hit-by' is also checked in the case of attacks. I just
looked at the code, and, yes, you're right. Let's forget about item (b);
it's a non-issue.

> >As far as failing over to an attack if a unit can no longer fire, this
> >sounds like a worthy feature request that could be fairly easily dealt
> >with in the attack/fire task logic.
> 
> I'm not sure about this. Many units that can fire are specialized at that
> and not very good at melee combat. Forcing them to attack when out of ammo
> would therefore be a bad idea. 

As a game designer, I generally do not even allow firing units to attack
the same unit types that they can fire upon. If someone does allow an
attack by a firing unit (which can happen easily enough by just ignoring
'fire-hit-chance' and using 'hit-chance' instead), then he/she should
suffer the consequences. 'fire-hit-chance' is there for a reason, and if
an unit is not intended to attack, then its 'hit-chance' entries should
be left at 0%. (Or, better still, its 'acp-to-attack' should be set to 0
against all units.)

> Moreover, it's hard enough to get the AI to
> use units that can fire properly (that is to fire at a distance and avoid
> rushing into combat), as already discussed on this list.

I think that I need to do some work with the 'hit-unit' task. The victim
finder logic (at the planning level) already makes some decent attempts
to determine whether firing or attacking should be used, but I never got
around to ensuring that the task code honors such choices.

> P.S. As a final note, some of the problems with consumption-per-fire are
> due to the fact that you can use the fire-into action to fire at invisible
> units. To avoid leaking info about unseen units back to the attacker,
> check_fire_into_action therefore calls enough_ammo_to_fire_one_round which
> does some kind of general check for ability to fire. However, I'm not sure
> that this code, which bypasses the use of the hit-by table, works as
> expected in all cases.

This concern is sitting in the back of my mind as well.

Eric