AI Development Discussion

classic Classic list List threaded Threaded
1250 messages Options
1 ... 27282930313233 ... 63
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

redrum
Administrator
@all - Just committed the latest changes to add support attachment consideration to AI purchases and updated the pre-release. The AI should now appropriately value support units besides just isArtillery and purchase them appropriately. In combination with the recent battle calculator changes, the AI now performs relatively well on maps that use support attachments. Please test and let me know what you think.
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

Frostion
This post was updated on .
It will be some days before I can test it out, but I am looking forward to it :) Will have to test it with my Caribbean Trade War "General", "Admiral" and "Indian-Scouts".
@redrum
I wonder if this will keep the AI from sailing around the seas with an unprotected Admiral?
Or keep AI from selecting the General as first casually?
Another thing....Have you made the AI value any and all ÷ or +1 A/D support equally? I mean like a unit's single +1 support is valued the same as another's (like a unit with 20 times +1 support) the number 19 +1 og the 20. +1.
My logic says that a units first +1 will be put to use more often and is more value for the money than the same unit's (or another unit's) number 10, 15 or 20 +1 support. The reason is that a unit like "General" wouldn't always walk around with his maximum capacity of units,  but an artillery with a +1 for one infantry would nearly always make good use of it's support ability.
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

redrum
Administrator
@Frostion - Respones:

1. So the AI shouldn't sail around with any unprotected ships. I'd have to see a save game to determine if/why that's happening.

2. Yeah, support units should be appropriately taken as casualties based on how much attack/defense they are providing. This still need some work for the AI as it should also consider the PU value of the unit (ex. in most WW2 maps, bombers shouldn't be taken as casualties before infantry since they are worth 5x the PUs).

3. So you are correct. The formula I use to decrease the value of each additional unit it supports is:
value = (0.9 * numSupportedUnits)^0.9
So example values are:
supports 1 -> 0.91
supports 3 -> 2.44
supports 5 -> 3.87
supports 10 -> 7.22

So this means an normal artillery that supports 1 unit has an added attack of 0.91, an Indian-Scout has an added attack of 2.44, and a general has an added attack of 7.22. This may still be too generous to multiple support units and I may need to increase the exponent to say 0.75, 0.8, or 0.85.

There are also calculations to ensure that there are enough units near the factory to provide support to so the above assumes there are at least 10 units near that don't have the given support.
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

redrum
Administrator
@all - Committed latest changes and updated the pre-release:
- Replaced all remaining isArtillery considerations with support attachments
- Made some non-combat move performance enhancements for large maps with many units
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

Eschelon
@Redrum,

One thing I've noted is that on large maps with a large number of empires (say 8+) that it takes a LONG TIME for the AI to complete turns.  My 3rd Century BCE Wars map is almost identical to 270BC (actually, without the sea zones it has about 77 less territories to consider), and in the mid-late game plays quite similarly (once the neutrals are cleared out of the way), so I'd imagine that 270BC may have similar issues.  I'll try play the latest version of that map to see if it fares much better (taking into account that it has 8 empires instead of 10, so that should shorten the time between a single player turn every round by about 20%).

I'm very glad to see that you managed to shorten the time for non-combat move calclulations (haven't tested the new build yet, but I noted your comments above).  

Combat move calculations I agree need to be well thought out.  

But the purchase phase also takes a long time to calculate on these maps.  

I'm wondering if there is some duplication of effort between the purchase phase and the combat move phase, and if it might be possible to have the AI store some variables so that any 'duplicated' calculations can be eliminated/bypassed/shortened?  Or if there is some other way to streamline the build phase time-wise?

Of course, on maps where the combat move & combat phase comes before the purchase phase, the situation will be different (you'll have sustained some losses), but pretty much all of the maps I've played have the purchase phase before combat move.  But as far as the 'most bang for the buck', I'd think that the combat move phase is by far the most critical calculations-wise, with the build phase coming in second.

Maybe a toggle could be introduced for 'fast builds?' for larger maps?  The AI would still do some calculations for builds, but not nearly as intense as it is now.

I also noted in the AI logs that the AI is looking for AA's and such.  This'd be more of a Verqyn thing, but it might be nice to have a couple of new flags to let the AI know if it needs to do air/aa related calculations for a specific map(if the map doesn't have these, this is essentially wasted effort).  Essentially something along the lines of:

Map Has Air Units: True/False
Map Has Naval Units: True/False

The defaults on these would be true, but for maps such as 270BC, which has no air units at all, this would allow the AI to bypass all of the 'air' related calculations, perhaps saving some computation time.  Not sure how many other maps don't have naval units (besides mine and Capture the Flag), but again this might be a good flag for economizing AI calculation times for these maps.
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

redrum
Administrator
@Eschelon - So somewhere around 80-90% of the AI turn time is when it is using the battle calculator to estimate attacks/defenses. In general, the more units on the map, the slower the AI is since this is what slows down the battle calculator the most.

The purchase phase is actually the slowest because it simulates all other phases until unit place and then determines what to purchase based on its estimate from the other phases. You can read the overall AI algorithm in the first post of this thread.

It already does some storing of calculated moves where possible. An example of this is when the phases are: purchase, combat move, battle, noncombat move, place. It simulates all phases til place during purchase and saves the combat moves to be run when it gets the the combat move phase so it doesn't have to calculate them twice.

I would like to just improve performance to a point that there isn't a need for any kind of toggle. The key again is making the battle calculator fast.

The AI does log that it is evaluating AA and naval on maps that don't have these but it already has checks after it logs those to see whether anything needs done so those flags aren't needed.

If you have any examples saves that are very slow, please upload them so I can play around trying to optimize AI turn times. Here is an extreme example of a slow AI turn (at least several minutes) caused by units stacks of 200-300 units: 1.tsvg
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

redrum
Administrator
This post was updated on .
@all - Committed latest changes and updated the prerelease:
- Fixed a few bugs
- Significantly improved performance on large maps

PS - I also significantly improved purchase phase time on all maps by removing AI pauses from purchase simulations.
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

Eschelon
@Redrum,

Thanks!  It's awesome that you continue to manage to nail down some significant performance enhancements!
I'll test the latest build when I get some time!
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

Irinam
In reply to this post by redrum
Found in an very old thread (2010)
(Brand New AI Development Thread)

Veqryn wrote already five years ago, what i was thinking about the last days
and a lot better than i could do this:

Veqryn wrote
Whatever AI we build should also be able to read information in XML form, from a new (does not yet exist) xml file in the main directory of the maps zip.  Call it "ai_hints.properties"

Things that would be easy to include are extra value for territories, by nation:
   <territory_considerations>
      <russia>
         <consideration territory="ukraine" bonus="4" />
         <consideration territory="norway" bonus="1" />
         <consideration territory="far east" bonus="-2" />
         <consideration territory="manchuria" bonus="-3" />
      </russia>
      </america>
         <consideration territory="algeria" bonus="8" />
         <consideration territory="norway" bonus="4" />
         <consideration territory="france" bonus="4" />
      </america>
   </territory_considerations>

This could be plugged directly into the calculus in part 2 of my algorithm.  



You could also do unit considerations,
   <unit_considerations>
      <russia>
         <consideration infantry="2" />
         <consideration bomber="-1" />
         // in this way, you giving a bonus to the internal consideration of the purchase part of the ai.  
         // the ai will try to buy more of things with higher values here,
         // but the ai should not buy exclusively one unit...
      </russia>
   </unit_considerations>

The other good part we could include is a purchasing schedule for a really good first and second turn purchase.  I might shy away from this though, because it decreases the replay-ability of the game.  Or you could have it randomly applied, say, 50% of the time, or something....  (you would need to make it so that the AI will still use any left over money, from a bid or etc.)

   <purchase_schedule>
      <russia>
         <turn tstart="1" tend="1">
            <purchase infantry="3" tanks="3" />
            // this is a specific purchase that uses up all 24 that russia begins with
         </turn>
         <turn tstart="2" tend="6>  // this purchase schedule would last from turn 2 to the end of turn 6
            <purchase infantry="2" ratio="70%infantry:10%artillery:15%tanks:05%fighters" />
            // this purchase would have russia buy 2 infantry, then spend the remainder of its money trying to approximate the ratio described
      </russia>
   </purchase_schedule>



Other things would could add are default modes to nations:
   <nation_modes>
      <russia personality="defensive" expansion="land" />
      <america personality="aggressive" expansion="sea" />
      <germany personality="balanced/default" expansion="land" />
      <japan personality="aggressive" expansion="both/default" />
      <british personality="balanced/default" expansion="sea" special_colonies="retreat" />
   </nation_modes>




Overall,
I think the territory considerations would be the easiest AND most effective things to implement in this fashion.  And we can worry about other bits later.

the more power we give the map makers in xml, the better.  I can't edit your java code, but I can change my map!

thx,
veqryn
Of course, the ai may not depend on such a file,
but IF it exists, the ai can (and must?) use the Information...

I don't know, how much work something like this is to implement in your ai?

Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

redrum
Administrator
@Irinam - I agree that this would be nice to add though I think its probably lower priority than most of the current items on the list. I'll go ahead and add it to the list though. Creating the XML structure and parsing it in is easy but determining what the values actually mean is the hard part.

An example is what does infantry with added value of 2 actually mean? That it should be considered to be cost 2 less PUs or have 2 more attack or 2 more defense or built twice as often or ... ? And what does Ukraine with added value 4 mean? That it should be treated as a 7 PU territory or 4 times the normal value or ... ?

To actually move forward, I would probably need some mapmakers to test their maps with the AI and then suggest an example structures with values and how the AI should interpret them in order to improve its play on those maps.
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

captaincrunch
Oook had a blast playing lots of games and your AI.jar update before this beat me a few times and some awesome games but then I tested your latest AI.jar update a few days ago. I lost the 1st match then won the last 2. The AI was tough and swift although I surprisingly played well against it my last 2 games. I never redo battles because it defeats the purpose of testing the AI just so you know. Some battles I had last week were hilarious like capturing and recapturing a capitol over and over and fun matches. I'm not sure if you made this AI a little more aggressive but it seemed that way to me. It was the NHL hockey all-star break and 2 weeks no NFL football so was good time to do some testing here.



1st Match: I was the Allies and the AI was the Axis and I even forfeited my very 1st turn with Russia for fun but its really hard and I couldn't take Germany or stop Japan so I gave up maybe round 9.




2nd Match: I was the Allies and the AI was the Axis again and I didn't forfeit my very 1st turn with Russia for fun and I played Russia well and I played the Allies well and took Germany and then Japan in round 17;


latestaxisaidefeated9.tsvg





3rd Match: I was the Axis and the AI was the Allies and I played well and took all 3 of AI's capitols by round 19;


latestalliesaidefeated9.tsvg




In that last match I noticed the AI will travel with Troops on Troop Transporters and not unload them at end of round and I'll eventually attack and destroy the Troop Transporters and kill the Troops and not sure why the AI didn't unload the Troops but thats all I can comment about this AI but it seems aggressive. The update before this one the AI attacked and took Russia aggressively but that let me take the German capitol with my 7 units vs 6 units but, again, when the AI has better numbers overall in the game it is very tough. It's figuring out the detailed attacks that can improve the AI but I still feel this AI is adequate.

Keep up the good work and I look forward to the next installment!
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

Frostion
In reply to this post by redrum
The latest version of the triplea.jar, the one that should have support tooltip display change, does not work with my latest version of my unreleased “Dragon War” map. When pressing play, an error pops up. Map does not start.

The previous Hard AI triplea.jar worked well

If I start with Human, Easy AI, Medium AI there is no problem.

Error wrote
triplea.engine.version.bin:1.8.0.5
java.lang.NullPointerException
        at games.strategy.triplea.Properties.getLow_Luck(Properties.java:563)
        at games.strategy.triplea.ai.proAI.ProCombatMoveAI.<init>(ProCombatMoveAI.java:97)
        at games.strategy.triplea.ai.proAI.ProAI.<init>(ProAI.java:110)
        at games.strategy.triplea.TripleA.createPlayers(TripleA.java:97)
        at games.strategy.engine.framework.startup.launcher.LocalLauncher.launchInNewThread(LocalLauncher.java:62)
        at games.strategy.engine.framework.startup.launcher.AbstractLauncher$1.run(AbstractLauncher.java:57)
        at java.lang.Thread.run(Unknown Source)
This is the XML Dragon_War.xml
Reply | Threaded
Open this post in threaded view
|

Re: Battle Calc error

redrum
Administrator
@Frostion - Yep definitely a issue with that pre-release. It included some AI changes that I hadn't tested yet which had issues. I fixed them and just uploaded the fixed pre-release jar.
Reply | Threaded
Open this post in threaded view
|

Re: AI Development Discussion

Frostion
In reply to this post by redrum
I downloaded the newest pre-release Hard-AI and encountered another error on my map. There might be some flaws in my xml that makes errors, but I think this is not one of them.

The game could not continue after error.

It seems to be an error in the AI thinking about what another AI player could do.
I could try to explain the situation, but it seems easier to post a screenshot:

DWError.png
Reply | Threaded
Open this post in threaded view
|

Re: AI Development Discussion

redrum
Administrator
@Frostion - The error actually occurs when the AI is trying to determine the attack efficiency of units. It does this by taking the attack value (attack + provided support) divided by cost of the unit. In this case, it appears the cost of the unit is 0 or undefined which is causing the "/ by zero" error. Do you have any units that don't have a purchase cost defined or have a cost defined as 0 in you XML?
Reply | Threaded
Open this post in threaded view
|

Re: AI Development Discussion

Frostion
No … but there are some units in the <unitList> that can not be bought, and therefore not listed in <production>/productionRule/productionFrontier lists.

Like the "Auxiliaries" unit…?

If this is a problem, what should I do?

PS: There are also other units that are not meant to be bought.
Reply | Threaded
Open this post in threaded view
|

Re: AI Development Discussion

redrum
Administrator
@Frostion - Makes sense. Unfortunately, not very many maps have units that can't be purchased (none that I've tested). If the unit doesn't have a cost then its hard for the AI to value how much losing it is worth.

I'm not sure exactly what the best solution is right now. But to avoid the error, I would suggest trying to add a production rule for all units that don't currently have one and just don't include it in any frontiers. So for Auxiliaries give them an approximate value like this:

                <productionRule name="buyAuxiliaries">
                        <cost resource="PUs" quantity="<some_value>" />
                        <result resourceOrUnit="auxiliary" quantity="1"/>
                </productionRule>

Let me know if that resolves the error. I can eventually add logic to avoid the error but it will most likely either consider the "cost" to be either really low or really high which will either make the attack efficiency really high or really low. This will make it so the AI either always uses these units first or last to attack with.
Reply | Threaded
Open this post in threaded view
|

Re: AI Development Discussion

Frostion
@redrum
It does.
I put a price that would be reasonable if it could be bought. If the AI uses this to determine something, then I guess it is a good idea to find some prices for all other units that are not meant to be bought.
Reply | Threaded
Open this post in threaded view
|

Re: AI Development Discussion

redrum
Administrator
@Frostion - Yeah at least for now I would recommend having a production rule for every unit and just don't use it in any production frontiers if it isn't meant to be bought. An example of how this helps the AI is the following:

The AI needs to decide whether to use the following units attack a territory:
- 1a/1d/1m unit
- 1a/4d/1m unit
- 1a/1d/4m unit

It sees that the attack power is equal for all 3 units but obviously the units with 4 defense and 4 movement are worth more so should be used after all the 1a/1d/1m units are used. This is where the cost of the unit helps to evaluate how much its overall stats are worth in comparison to its attack power. Now depending on the size of the map and unit set, the 4 defense may be worth more than 4 movement or vice-versa. That is why it would be hard to replace the actual PU cost of the unit with some formula to evaluate how much its worth.
Reply | Threaded
Open this post in threaded view
|

Re: AI Development Discussion

Veqryn
Administrator
it isn't enforced by the xml parser, but every single unit should have at least one production rule

just don't put that rule in a production frontier if you don't want it to be purchased
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
1 ... 27282930313233 ... 63