This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]