This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Major bug and what to do about it (long)
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Hans Ronne <hronne at comhem dot se>
- Cc: xconq7 at sources dot redhat dot com
- Date: Mon, 16 Aug 2004 19:16:29 -0600
- Subject: Re: Major bug and what to do about it (long)
- References: <l03130301bd46b33ac8ea@[212.181.162.155]>
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