Re: CRT Combat Model (really long)

[Lincoln Peters <peters2000 at mindspring dot com>]

On Thu, 2002-03-14 at 00:46, Hans Ronne wrote:
> >1. The computer has difficulty determining the best route from point A
> >to point B when it has to move away from point B somewhere in the
> >process.
> 
> This is a known issue. See the posts by "Ed" last year. he had some ideas
> about testing a "Knuth" algorithm but nothing came out of it. The worst
> problem is actually when units get stuck on a shore opposite an enemy.

I guess the problem just gets a lot worse when the AI is dealing with
mazes.  I'm not familiar with the algorithms that move units from one
place, so I'll have to leave all that in your hands.

> 
> >2. All of the items are most useful if carried by another unit.  In
> >fact, some items are *only* useful if carried by another unit (such as
> >the Guardian stone).  However, the AI would often see an item, "find"
> >(capture) it, and then leave it.
> 
> The concept of carrying a useful item is just supported in the ai yet. One
> would have to write new code for this.

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.

> 
> >3. I found that in this game, the best defense is usually a good
> >offense.  By default, the AI would have several units (a garrison)
> >occupying a place to protect it, but the garrison would never act while
> >there.  As a result, they would not prevent the place from being
> >captured; they would just delay it until they were all killed in the
> >siege.  I sort of fixed it by setting the ai-peace-garrison and
> >ai-war-garrison both to 0, but that left places wide open to attack when
> >nothing is standing in the way.
> 
> This is strange. The garrison units work fine in e.g. the advances game.
> You have to set ai-tactical-range greater than zero for them to attack
> units outside the city, but it is 4 by default so this should not be the
> problem. Maybe you should check out the code in advances.g and model your
> garrisons on it.

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.

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?

> 
> >4. The advances code in the AI allows it to effectively handle dwarves
> >and their ability to build places (colonize), but the colonizing code
> >seems to override almost everything else.  Oftentimes, the AI will
> >assign almost every orc hole a "colonizing" plan and build dwarves,
> >which in turn build more orc holes, which in turn build more dwarves,
> >etc.  This isn't good practice.
> 
> Well, it beats any other strategy in a game where the side with most units
> usually wins. But the colonizer production should cease if an enemy unit
> comes within range. And it does in advances.g. So maybe you should check
> out that code again.

I think that colonizer production does cease when enemy units come near,
but there is no strategic forethought to colonization activity.  Sure, a
dwarf can fight just as well as an orc, but in a given period of time,
it would have been able to produce 4 times as many orcs as dwarves.

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.

> 
> >5. The AI doesn't seem to coordinate units to work together very well.
> 
> True. There is of course support for moving units in formation, but that
> wouldn't help in your specific case.

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.

> 
> >6. If a unit is capable of normal attacks as well as firing, the AI
> >doesn't always distinguish the two very well.
> 
> Getting firing to work correctly is tricky. One way is to make the firing
> unit incapable of normal attack. Check out the panzer module for a game
> where firing at a distance seems to work really well.

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).

> 
> >7. The AI should be smarter about protecting its self-unit.
> 
> Yeah. New code would be needed for that, too.

I think that the key to this problem is that the AI needs a good
self-preservation instinct (I don't know if that already exists or
not).  If an imp meets an enemy spider, it should realize that it has
virtually no chance of defeating the spider and should search for a
target that is safer to attack.  Of course, if the outcome of the game
depends on defeating the enemy spider, the imp should attack anyway.

> 
> >8. The AI doesn't seem to understand concepts like combat experience
> >(CXP) or altering terrain.  Usually, these aren't major issues, but in a
> >big game where the sides are really well-matched, CXP and/or altering
> >terrain might turn the tide of the game.
> 
> Ditto.
> 
> Seems like we have a lot more coding to do ...
> 

If you implement self-preservation code, I think that you should try to
tie in CXP and self-unit-ness (just pretend that it's a word).  That
might be sufficient for allowing the AI to deal with CXP.

As for altering terrain, it seems to me that connection terrain is
typically the only type worth worrying about.  In this game, it is
possible to create tunnels (a connection type that allows units to move
through solid rock), but it is impossible to alter cell terrain, and, of
course, there is no border terrain.  Likewise, in games like "empire"
there is a highway connection type that can (theoretically) be used to
easily cross rough terrain or bodies of water.  My best idea for that
would be for the AI to have something like a "Trailblazing" plan that
would tell it to create some kind of connection terrain that connects
one unit to another, or that connects one unit to another connection.

I've never seen border terrain set up as something that can be added or
removed, but I guess it would be possible to use border terrain for
something like a wall.  That could be momentarily ignored, at least
until there's a game where border terrain can be manipulated.

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).


There are two more things I noticed going on with the AI that someone
should look at:

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?

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?