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: Tue, 17 Aug 2004 12:36:59 -0400 (EDT)
- Subject: Re: Major bug and what to do about it (long)
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