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

[Hans Ronne <hronne at comhem dot se>]

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

If you mean the ability to pick what unit to attack first within a single
cell, true. That is the price we have to pay. I've given it some thought,
but I don't think it is a big problem in any existing game. Units that you
really would like to hit with a high priority, like cities, frequently
occupy an entire cell. And you could always argue that it should be the
defending side's privilege to decide what unit to send forward when a cell
is attacked. In effect, this kind of scheme might partially compensate for
the AIs rather poor ability to defend key units.

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

Yes, there are also platform-specific issues as we already discussed (e.g.
right-clicking is used to bring up the unit closeup on the Mac). But it is
still easier to find good interface solutions for two actions instead of
four, which was my point.

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

I'm not arguing that the multiple rounds of attack in combat model 1 should
apply in model 0. On the contrary, this is the main difference between the
models, which should be preserved. My point was rather that if both models
use overrun actions only, it is easier to write AI code that can handle
both of them well.

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

I agree. Only the Roman and Russian Revolution games use stack order now,
however. And it is not yet supported by the unit view code (this is on my
todo list, but not a high priority).

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

No, I agree with that.

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

Well complicated or not, the code is already there. See model_1_attack. The
question is rather how to improve it. But even a simple solution such as
picking the unit with the highest defense value is far better (from the
defender's point of view) than a random pick. And in fact we have an
advantage in that the type of attacking unit is known at this point, which
makes any calculation much simpler.

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

I think spread damage could be easily implemented, perhaps as some kind of
detonation-on-hit action. My main point was that we should avoid solutions
that makes the hit-chance against one unit dependent on the presence or
absence of other units in the same cell. Unless, of course, these other
units provide cellwide-protection-for or some other property that modifies
the hit chances.

Hans