Re: Major bug and what to do about it (long)

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

Hans Ronne wrote:

> I have given the above bug and its consequences some serious thought. Here
> is what I think should be done:
> 
> 1. We should eliminate the attack unit/attack position code split. Instead
> of the four actions that are possible today, we should just have two:
> do_attack_action and do_fire_action. These actions should be
> unit-independent, i.e. work pretty much like the old do_overrun_action and
> do_fire_into_action.
> 
> This would have a number of advantages. First, we could do away with unit
> pointers in the combat code. 

I agree with doing away with the unit pointers, and I mention this in my 
Dec 29 fix from last year.

> For example, clicking on an enemy unit could schedule a normal
> attack (overrun action) and right-clicking on it a fire action. 

We would then lose the ability to do selective attacks into a cell.

Also, I am still quite apprehensive about using right-clicks for firing 
(as we have discussed previously).

> Yet another advantage with this scheme is that it
> would make combat model 0 more similar to combat model 1, which only uses
> overrun actions. 

I don't particularly see this as advantage, since one would then get 
much more combat than one necessarily bargained for or even desired.

> 2.
> Specifically, I don't like the fact that you get a free shot at every unit
> in the cell for just one acp consumed, even if you have to pay for it in
> ammo. 

I agree. More combat should imply more ACP expended (though possibly at 
a discounted rate; "buy one attack, get the next one at half price" to 
apply mercantile jargon to the situation).

>It seems more logical that one attack (either normal or round of
> fire) is just that, and that you consume 1 acp and 1 round of ammo each
> time you attack. As a consequence, you should also be able to hit only one
> unit (and possibly its occupants) each time you attack.

Right, unless the attack or fire does spread (surface) damage.

> 3. The question is then how to pick the unit to hit. I can see three
> possibilities. 

>The first is to hit units in stack order. This is easy to
> implement and is therefore how things frequently work in the kernel, but I
> don't think it is a good idea in this case. 

This would be reasonable if one could assume that the game designer set 
up the stack order with defensive ranking on mind. If we did this, I 
would then set up Halberdiers (acting as pikemen) to be before 
Longbowmen in the stack in Wreckreation.

>The second possibility is to
> pick a unit at random, perhaps weighted according to unit-size-in-terrain.

I like this idea very much in the case of fire. I am not sure that it 
makes much sense in terms of melee combat though.

> The third possibility is to always pick the best defender, on the theory
> that this is the unit that the defending side would send forward to meet
> the enemy.

This could turn out to be a complicated calculation, and, in the end, we 
would probably end up with someone asking for it to me made into an AI 
"hints" table, as has happened with some of the other aspects of AI 
behavior recently. And, as with the second possibility, I am not sure 
how relevant this is for firing.

> The main difference between them would
> remain the fact that a model 1 attack continues until death, while a model
> 0 attack continues only as long as the attacker wishes to continue and has
> acps left.

Right. And, if I get around to implementing the modular combat system 
after the 7.5 release, then this multi-round combat behvaior will just 
be controlled by a GDL switch. Setting 'combat-model' to 1 will flip 
this switch on, but it will also be able to switched on independently. 
Of course, a variation on mutli-round combat (involving more than 2 
units) alos might be considered (see the "battle" and "commit level" 
concepts in 'doc/PROJECTS').

> 4. However, I doubt that this is a good solution for fire actions, which by
> their very nature are more random. In that case, I'm leaning towards a
> size-weighted random target, as described above. 

I would agree with the "size-weighted" part, but not necessarily the 
"random" part. If the fire damage does point damage, and the target is a 
ghost unit, then the fire should miss. (I suppose a random chance could 
be added that another unit just happened to be in the ghost unit's 
position and thus got clobbered.) However, if the fire does spread 
damage, then I think all units in the cell (or spread damage radius, or 
spread damage max victim count) should be affected.

> These are my thoughts so far. The proposed changes would have profound
> consequences for all games in the library, so they require some careful
> thought. 

Indeed!

Eric