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: CRT Combat Model (really long)


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

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

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

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

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

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

>7. The AI should be smarter about protecting its self-unit.

Yeah. New code would be needed for that, too.

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

Hans

Hans Ronne

hronne@pp.sbbs.se



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