CRT Combat Model (really long)

[Lincoln Peters]

On Fri, 2002-03-15 at 11:55, Hans Ronne wrote:
> I think what would really help in your game is if each side starts with 3-5
> units instead of a single human. Now the single human gets lost in the maze
> half the time, and then goes into passive mode.

I do have one of each kind of place start independent near the human,
but they are sometimes separated by enough rock to make them hard to
find.  I do understand this issue, as I've seen that in other games
(e.g. "crater-lake"), the AI might starting build a battleship in its
only city and be completely vulnerable when my forces get there.

What if I could put the independent places at most three cells away from
the place where the human starts?

> 
> >Wouldn't an item that can be carried (e.g. a Guardian stone) be
> >comparable to a facility in a city (e.g city walls)?  If they are
> >comparable, it seems to me that the only necessary changes to the AI
> >code would be to allow units to pick up "facilities" instead of build
> >them.
> 
> You are right, and unfortunately, facilities are not supported in the ai
> either. By this I mean the city will pick one at random to build, with no
> regard for what is useful or neeeded.

Hmmm.

> 
> >Perhaps the problem is that vision is line-of-sight and rooms are small,
> >so it becomes much easier to launch a surprise attack.  Once I have
> >units in place to attack an enemy place, there is rarely any path that I
> >haven't cut off.
> 
> Looking at you game again, I noticed that the orc-holes etc. can fight. So
> you really don't need garrisons. They are intended for Civ-type games where
> cities are defenseless without a defender inside.

Well, that's actually sort of the case with this game.  Places are not
completely defenseless; they are unlikely to kill an attacker on their
own, but they have a chance to do some damage to the attacker before
being captured.  A defender inside will protect the place, but the place
can't protect the defender.  Maybe I should change that.

Could I use occupant-affects-defense (sort of like
occupant-affects-attack in "3rd-age.g") to boost the effectiveness of a
unit as a defender?

> 
> >Another thing that I should be able to do is tell the AI that a human
> >should not be used as part of a garrison.  Perhaps there should be some
> >way to weigh units as favorable or unfavorable for garrisons?
> 
> Just give the unit type a high defend value and a low attack value. Also a
> low speed. The ai is smart enough to figure that one out.

I tried that, and it does seem to affect the AI's strategy.  However, I
found another AI problem in the process:

11. When the AI has a unit that want to attack an enemy unit (e.g. an
orc hole) but another enemy unit is blocking its path, it should
consider attacking that unit, then proceeding to attack the first
target.  Right now, AI-controlled units that encounter such situations
simply go into reserve and are rather easy for me to kill.

> 
> >Perhaps the real issue is that when it is possible to colonize and/or
> >improve, the AI never anticipates military trouble until it is too late.
> 
> Yeah. Just like its human counterparts :-).

Good point, but I think that it would be wise if the AI could be a
little paranoid.  Just because you're paranoid doesn't mean that they're
*not* out to get you.

> 
> >I guess the coordination isn't as much a problem in most games as in
> >this one because not only do you have mazes instead of fractal terrain,
> >you have passages that only allow one of anything to pass at a time.
> >Also, most rooms aren't big enough to seriously fight in.  Maybe I
> >should try allowing two of anything to pass at a time instead.
> 
> That's a good idea for other reasons too. I noticed some lockups where
> units got trapped behind other units.

I changed the terrain capacity so that it allows two units in a passage
cell, and the game does run a lot more smoothly.

> 
> >I can re-configure Lightning stones so that they can't attack directly,
> >but I don't know if I would want to do the same with dragons and/or
> >beholders.  Sometimes, I want a dragon or beholder to be able to
> >directly attack a place in order to capture (and defeat any garrison
> >that might be there), but it would be unable to do so if it couldn't
> >attack directly (at least it couldn't do so very well).
> 
> You can allow both direct capture and fire, but still disable direct
> attack. The latter only disables indirect capture as a result of an overrun
> action.

This would be fine for Lightning stones, but not dragons and beholders. 
They are supposed to be able to attack directly as well as fire (the
advantage to direct attack being that less ACP is required).  A similar
(although more complex) setup is used in "galazy2.g", as a starship can
attack at close range or can fire photon torpedoes at a distance (the
difference is in damage done and material consumed).  Of course, the AI
is terrible at that game, too.

> 
> >When it comes to editing cell terrain, I really don't have a clue where
> >one would start.  I suppose that in an "advances"-like game, a player
> >who could alter cell terrain might want to turn desert into plains,
> >thereby making it more useful for advanced units.  Then again, there
> >doesn't appear to be any game yet where something like this is both
> >possible and beneficial (in WW2 games, of course, it's possible to alter
> >terrain with nuclear bombs).
> 
> It is possible to set up units in any game that can change the terrain. At
> least in those games where production is dependent on terrain type, this
> can make a huge difference.

What I meant was that I don't have a clue where one would start when it
comes to programming the AI to take advantage of units that can edit
terrain, at least beyond editing connection types.

> 
> >9. Sometimes, when a game is over, I find that the AI had some dwarves
> >that started building a few places (strangely enough, all orc holes),
> >but many were abandoned and left incomplete.  I could understand this
> >happening if I had shown up, because the dwarves would re-plan to fight
> >my forces, but my nearest units were all at least 10 cells away (and
> >probably unseen by the AI's forces)!  Why would the AI leave those
> >incomplete units lying around when there's no threat in the vicinity?
> 
> This is a known bug. I fixed it at one point in the advanced unit build
> code, by writing a special resume_build_task function. However, the fix was
> lost later when this code was merged with the general build code.

I guess I can't help you there unless I learn C.
Jim Kingdon mentioned that the AI doesn't do a whole lot of planning
before choosing a spot to build stuff.  I guess that that could be an
issue worth considering after resolving this bug.  One thing I find is
that if a passage is lined with places, units only move at 1/2 speed
through the passage (it takes 1 MP to move into an adjacent passage
cell, but 2 MP to enter another unit, and there is rarely an easy way to
go around them).

> 
> >10. Sometimes, a place will be assigned to hit or capture some enemy
> >unit.  That makes no sense; the places are capable of fighting, but
> >they're immobile, and they're much better at producing monsters that can
> >hit or capture enemy units for them.  Why would any place try to do
> >that?
> 
> Because you allow them to fight! This is not how places work in most games.
> Check out advances.g or 3rd-age.g.

I tried changing the acp-to-attack for places to zero, so that they can
defend themselves but not attack.  I ended up getting some kind of "bad
utype" error in every game, which quickly causing Xconq to segfault
(Fatal error 11 on UNIX).  For the moment, places can still fight, but
I'm working on fixing it so that places can't attack but they can defend
and Xconq won't segfault.