#97 ProAI Updates (Retreat AI Implementation, Amphibious Assault Enhancements)

Unstable (example)
closed-accepted
Chris Duncan
None
5
2014-04-19
2014-04-19
redrum
No
  • Added new Retreat AI instead of using Moore AI's implemenation
  • Made amphibious assault enhancements
  • Removed all references to getTerritoryUnitIsIn()
  • Fixed bug in GameObjectInputStream so it copies unit's state (hits)
  • Fixed various bugs and refactored battle utilities
1 Attachments

Discussion

  • redrum
    redrum
    2014-04-19

    Please use this version of the patch (V2) instead of the original one. I made a few more fixes that I'd like to get in.

     
  • Chris Duncan
    Chris Duncan
    2014-04-19

    i don't understand your change to game object input stream
    also, why make getGameData() public in the abstract ai?

     
  • redrum
    redrum
    2014-04-19

    1. When the BattleCalculator was copying units into the copied game data it wasn't copying the state of the unit (hits). So if you would simulate a battle with a damaged battleship then it would actually calculate it with a full life battleship because when it got copied it didn't copy its current hits.

    2. I made it public so I could access it in the retreat AI class. The alternative is to create a public getGameData() method in ProAI that wraps the protected getGameData() in AbstractAI.

     
  • Chris Duncan
    Chris Duncan
    2014-04-19

    1. if the method didn't work, then all our gamesaves would show all units healed, but this is clearly not the case
      please have another check for something else going wrong, somewhere in the calc, not in the game data copying.
      i remember that i had to code a workaround, but it is part of the UI (btl calc panel), so have a look there first.
      (and YES, there is actually a LOT of unit state besides hits)

    2. ok. i guess the ai instance references shouldn't end up anywhere funny, so there is little risk

     
    Last edit: Chris Duncan 2014-04-19
  • redrum
    redrum
    2014-04-19

    1. I don't think this is used for gamesaves. If you look at where the class/method is referenced:

    GameObjectInputStream -> GameObjectStreamFactory -> (GameDataUtils and Decoder)
    GameDataUtils -> (HistorySynchronizer and OddsCalculator)

    The issue isn't copying the data. Its when the units passed in the calculateBattle call are translated into the copied data. It tries to find if the unit is already there and gets that unit instead of taking the one passed in:

    final Unit local = m_dataSource.getData().getUnits().get(unit.getID());

    This unit in the copied data doesn't have the same state that unit that is passed in the calculateBattle call has. So if I pass in a damaged Battleship, it finds the original Battleship that's undamaged and takes that.

     
  • Chris Duncan
    Chris Duncan
    2014-04-19

    why would the unit be different?
    you copied the data, then put in some units, that presumably have not changed since you copied the data, therefore they should have the same stats in both the copy, the main, and the list you are passing in

     
  • redrum
    redrum
    2014-04-19

    I think I know what was causing the problem. The Pro AI needs to copy the game data when retreat is called each time since it has changed. That's why the copied game data was out of sync with the units being passed in.

     
  • Chris Duncan
    Chris Duncan
    2014-04-19

    and the method is also used for communication over the network as well

     
  • redrum
    redrum
    2014-04-19

    Updated to remove that change and copy the game data into the BC each time retreat is called. Sorry for the confusion.

     
  • Chris Duncan
    Chris Duncan
    2014-04-19

    are you really running a calc for each cycle of the battle?

    does it take a long time?

    would it be better to just do an estimation, like the one i already do in the battle calc (retreat if 'meta-power' is lower than enemy)?

    also, as a side note, what do you think of using the following method for determining battle results:

    1. run the calc
    2. take the records of ALL battles produced by the calc
    3. sort them from worst to best results
    4. use the middlepoint battle or use a battle located at like 30, where worst starts at 0 and best is at 100, if 100 calcs

    this would give you a more reliable result rather than taking the 'average units left' figure (averages are bad, because you can have some cases throwing off the results, and typically with A&A battles the results actually form a double humped graph, where you either have lots of attackers left over, or lots of defenders left over, and nothing the middle).

     
  • redrum
    redrum
    2014-04-19

    Yeah, it will run a calc each time retreat is called. It doesn't take very long since it is only one data copy and one calc run of 100. The combat move AI probably does thousands of calc calls so doing 1 for each retreat should be fine.

    The estimations just aren't accurate enough when battles are close. There are also complex situations such as I'm attacking a capital and after 2 rounds of combat I have only a 30% chance of winning but most likely it is still worth attacking since the prize of winning is so high. So you need to have a pretty good estimate of what your win percentage is.

    Interesting idea. Pretty much use median battle instead of averaging all of them. I'm not sure if that would be better or worse. But you would probably still need some averages like win percentage since if you have 100 results (50 wins, 50 loses) and you just take the 51st one which is the first win that would make it seem like you have good odds where really your odds are 50/50.

     
  • Chris Duncan
    Chris Duncan
    2014-04-19

    hm... recopying the entire gamedata, just to record a couple changes to a few unit objects, seems overkill
    there must be a better way to do this
    perhaps a translate option that recreates units/obj from scratch
    or perhaps a createUnit method which copies all state data from one unit to another
    lets talk in the forum, if this ends up being needed due to the extra time overhead involved in copying over data with each retreat query

     
  • redrum
    redrum
    2014-04-19

    Ok. Though I think you should be fine to merge this patch.

    It is definitely overkill but not sure if it really matters. I'll do some testing to see how much time ProAI retreat calculations are taking to see if it is considerable and worth looking into or not.

     
  • Chris Duncan
    Chris Duncan
    2014-04-19

    • status: open --> closed-accepted
    • assigned_to: Chris Duncan