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

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

On Tue, 17 Aug 2004, Hans Ronne wrote:

> Not at all. This is how the current overrun code works (at least in model
> 0), but it is one of the things that I propose to change. One attack with 1
> acp and 1 round of ammo should hit one enemy unit, not all of them.

Okay, good. It had sounded to me like you were planning on binding 
'a' to the overrun action since you had planned on doing away with 
attacking individual units. 

> Well, to turn the argument around, naval escorts would for the first time
> work in Xconq. 

They already do: through the use of the protection tables.

>You would be forced to take on the escort before you could
> hit the valuable target. You would also for the first time be able to group
> high-offense and high-defense units together, and know that the former
> would benefit from the latter's defense. 

This only makes sense in some cases such as pikemen supporting 
longbow archers. It does not make sense if a sub slips in and has 
to first torpedo an escort ship before torpedoing a juicy target.

>Just as in Civ2, where you would
> group chariots together with a fortified phalanx, to give one example. My
> feeling is that it would make most games more fun to play. You would
> certainly have to give much greater attention to tactical unit deployments
> than with the current code.

It very well might. But, it is the games that it would degrade 
that I am worried about.

As an aside, I am going to get back to doing some more work with 
formations, hopefully in the next week or two. One of the things I 
hope to implement is AI support for using formations (possibly 
through some sort of unit-unit gravity table (as was suggested by 
Henry Cobb, I think)). Setting desired formation distance to 0 (in 
the same cell) in an unit-unit formation distance table would make 
your suggested change more relevant from the AI prespective.

(I am also seriously considering changing the way setting 
formations works in the Tcl/Tk interface. Selecting an unit, 
hitting "F", and then selecting its leader is tedious. I think it 
would be better to select the leader, hit "F", and the select all 
of its followers using a modal that it is terminated by escape 
(cancel) or enter (accept list of followers). This would be much 
more efficient and less tedious, I think.)

> However, if you want to have a game where subs primarily hit tankers, there
> should be ways to achieve that. What would happen if subs only can hit
> tankers? Should the presence of units that it cannot hit at all block an
> attack? I don't think so. 

If the sub has even a small chance to hit a destroyer, it should 
not be forced to engage the destroyer first before the tanker.

> These are important questions, and how the target selection is done is
> clearly the key point. 

Yes, I definitely think so. It seems we agree about the need use 
unit views with whatever form the rennovated actions take.

> might be too simplistic, I agree with that. Perhaps the hit-chance against
> different units should also play a role.

And it quickly blossoms out from there. Do you pick a unit with a 
low hit chance against but that can only survive one blow, or do 
you pick one with a higher hit chance against but that it quite 
tough. These are all things I wrestled with in the victim finder, 
and I am now inclined to avoid such calculations when possible.

> >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.
> 
> I agree. However, I suspect that this is what the stack order was supposed
> to be used for, though it was never implemented. The stack order has no
> practical consequence right now, so we could certainly give it a role in a
> reworked combat code. 

I will concede that. Both you and Jim have argued convincingly 
that stack order should coincide with defense order (in games 
where this ought to apply, at least).

> I agree that it would be nice, though getting rid of unit pointers in the
> AI code would be even nicer. 

I don't see those as diametrically opposing goals. Why should we 
need to get rid of selective attacks just because we are getting 
rid of unit pointers?

> last use a unit-specific attack in a real game, i.e. walk up adjacent to a
> unit, and then put the cursor on top of it, followed by pressing 'a'. It
> turned out that I couldn't even remember, which I suspect is fairly typical
> for the average Xconq player. I know that I tested this functionality a few
> times when i was debugging the Mac interface, but this is about it.
> Clicking on a unit is so much easier.

When all targets are equally desirable perhaps. But, both Jim and 
I actually do selectively hit targets using "a" and "f" in cases 
where we are, in fact, trying to single certain ones out to our 
tactical advantage. Without this ability, we are losing tactics in 
a big way and Xconq should essentially be regarded as strategy 
game engine, tactical games need not apply.

(I do think that the roles of "f" and "CTRL-f" could be swapped 
though, if some of us are willing to retrain our fingers....)

Eric