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:


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.

And it is a very hefty price for games in which players might rely on guerilla tactics against specific types of units, commando strikes against specific targets, etc....


What I also meant is that it sounded to me that you were suggesting the use of overrun, which would imply engaging _all_ units (or, as many as the attacker had ammo and ACP for) in the cell, would it not?

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.

True, but this is not always the case. With what you are proposing, I could always escort tankers with destroyers, and ruin a sub's day because it would be unable to target the tanker. Not good.


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 some cases. In other cases, as alluded to above, it most definitely is not (when an unit is being individually attacked).


In effect, this kind of scheme might partially compensate for
the AIs rather poor ability to defend key units.

Perhaps. But at what price?


But it is
still easier to find good interface solutions for two actions instead of
four, which was my point.

This is true. But, I wouldn't consider it a selling point for what you propose.


I'm not arguing that the multiple rounds of attack in combat model 1 should
apply in model 0.

I know, but you were arguing that an overrun rather than an individual attack should always be used. That is what I am taking issue with.


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.

Model 1 uses attack and defense values, but model 0 has much more to consider, such as range, hit chance, protection, damage, minimum HP against a given unit type, etc....


At this point I would suggest that a 'defense-order' unit property might be called for. That way we can let 'stack-order' pertain to unit views as was intended. And this also gives the advantage that the game designer can rank for himself/herself what units defend first rather than trying to fight with a calculation.

And, I think that 'defense-order' should only apply in conjunction with units than cannot do selective attacks. I do think, as I have already argued, that the ability to do selective attacks should be kept though.

I think spread damage could be easily implemented, perhaps as some kind of
detonation-on-hit action.

I would agree that it should be fairly easy. I have been holding back on doing it until I take care of the combat code modularization, but depending on how far I get with Wreckreation development, I may be tempted to implement it before then.


Eric


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