1. Yeah I realized I had an old version of SVN after I had already pulled it all down. I also decided not to use git/github at this point anyways. It is just too difficult especially when dealing with generating a SVN patch from git. I might eventually come back to this but for now I'll live with just SVN. C'est la vie.
2. That is exactly what I'm planning to do but since I've only worked on combat move I didn't bother creating it yet. Eventually the structure will be something like this:
ProAI (extends StrongAI at least until every phase is rewritten and initializes/calls the following)
- ... several more
The main ProAI class will mostly just be used as a controller. Eventually I hope to separate each phase class into calculation and perform methods so I can run pretty much all the calculation phases during purchase and just save the data. Then actually call perform for each phase and just use the calculated data. This will allow purchase to consider what combat/noncombat moves I'm going to make and what units I'll need to actually buy.
3. So I don't expect you to review every line code as that would take a good deal of your time. But I'm hoping you can take some time to glance through it and let me know if I'm calling any methods I shouldn't, if there are better utilities to use, general feedback, etc as you know the engine better than anyone. Also I'm hoping you are eventually interested in doing a little testing to see how the AI performs and giving feedback (also if you know of anyone else that is interested please let me know). It is just hard to test the AI on every map in many different scenarios as it takes a good deal of time.
I'm also hoping to maybe get some help cleaning up and enhancing some of the utilities that the AI code uses such as Match/Matches (really needs cleaned up and commented better) and BattleCalculator (look into optimizing performance). These are the types of things that people who know the source better than I do would be of assistance plus they are separate from the AI code so can easily be worked on in parallel.
4. I don't believe I'm making any map specific references but there are a few limitations currently like I'm only considering moving blitz units and transport units up to 2 tiles so that I eventually need to go back and enhance so they work better with other unit sets. I figured most of the maps that come with TripleA are a good place to start in terms of testing. Again I have mostly been testing on WWII revised cause that is what I have played the most so I know all the rules and can determine whether the AI is making optimal moves. As soon as I'm relatively happy with it on revised I'll start running through the other maps. If you had to pick 2 other maps besides WWII revised to test with what would they be (based on popularity and differences from revised)?
I should be submitting another patch this week to add amphibious assaults as that was the one feature the initial combat move AI submission didn't include.
i think there is a bug in determining which territories can hold: it said red could hold blue middle 2 on its first turn, with only air
this is a bug for 2 reasons: red can not hold blue middle 2, even if the air could land there, and also the air can not land there
of course, just because we can't hold a territory, doesn't mean we shouldn't attack it
i didn't see anything bad in your code when i looked over it, from an engine point of view.
a few general things to consider:
1. never edit the game data directly. all game data edits must go through an iDelegateBridge, and you shouldn't be doing that anyway.
2. if you need to access any delegate state information, please use one of the methods provided in the iDelegate, such as getTerritoriesWhereAirCantLand() in IMoveDelegate. Moore AI sometimes uses DelegateFinder, but I want to delete that class, so don't use it unless you absolutely have to. If you must access something that isn't presently accessible, talk to me and we can make a patch that adds a remote method for this to the idelegate.
3. if you plan on making your AI keep information between phases and between turns, please remember the following:
a. there can be multiple instances of your AI, up to one for each player in the game. So if you plan to make anything static, remember that it will be used both by the russians and the germans, etc.
b. ai state information will not be saved with the gamesave. so if i save the game in the middle of your combat move, and then reload the game, I should not have any errors. This means you must have a method of regenerating this state information, or at least handling if none exists when some is expected.
c. if i exit the current game then load up another different map, without exiting triplea, i should not encounter errors (i only mention this because dynamix ai had an issue where because it saved a lot of static information, it would persist after you exited and loaded up a different map, which caused errors because those units didn't exist in that map, etc).
4. you might want to look into making your AI log to somewhere other than the console, and also to not use "FINE [Triplea start thread] ProCombatMoveAI -> " at the start of each line since that is not needed.
i would suggest either:
a. a log file under /logs/ per each nation being played. such as "/logs/proai_russians.log"
b. a window similar to the dynamix AI settings window, where you can view the log information in game, on a per-player basis, with different levels of logging (fine, finer, finest, etc), and so on.
the settings window is probably best, since it allows actual users to view your AI's decisions as well, and possibly help debug it for you
5. you should try validating all movement before you add it to your map of moves-to-make
you can simply throw the move through MoveValidator's main static method to get the result
in addition, there is a situation that you will soon encounter:
* you have a giant move of 20 units all set up, but the move validation fails because of a single unit. because of this, you do not do the entire move.
maybe you want to do the move anyway, with the 19 valid units?
maybe you don't?
MoveValidator's static method will sometimes tell you which unit is failing, but a lot of the time it will also just fail the entire group without pointing out which unit is the cause of it.
You should handle this situation, and at the very least do your best to log why it is failing (and on what map) that way you can fix it.
TripleA has too many rules sets and custom rules. But even if you coded the AI perfectly and played only Revised and AA50 (v3) maps on it, this situation will still probably occur.
Dynamix tries to solve it by moving the units individually instead of in groups. This can be bad if an important part of the group can't move, and the attack or w/e subsequently fails. It is up to you how you want to handle this.
all 3 AI's are coded really really poorly, so please do not look to them for advice on how to do something
Yeah for none-blitz land units it only considers 1 movement range so it also needs enhanced though most maps I've played all land units that have more than 1 move are blitz units.
I'm not sure what you mean by red and blue. The determine which territories can hold isn't perfect right now but is just used to get an idea of the enemy counter attack size. It is then used when deciding on how many units to attack with since if it I can't hold it then move just enough to win otherwise move as many as are useful to increase TUV swing.
1. Yeah definitely not editing the data :)
2. Ok. I haven't really used the delegates much mostly just the move delegate.
3. Yeah I tend to stay away from static unless it is truly a utility method. I don't really plan to use any static member variables. For save games, like I mentioned in my previous post I hope to calculate everything at once so I would make checks in each phase method to make sure it has been calculated otherwise recalc remaining phases or just do nothing at first since saving in the middle of an AI turn is rare.
4. Ok. I tried to just do something similar to StrongAI logging as wasn't sure what else was available. In game logging would be the best I think and didn't realize dynamix AI did this. I guess I'll have to take a look at it (looking at dynamixAI is very painful so I try to avoid it).
5. So for movement I took the let's move one unit at a time approach except transport/amphib units which sort of have to be paired up. Validation may eventually be useful but at this point I would probably just ignore that unit which is what happens if the move fails anyways with the idea that very few moves should ever fail if you calculate them properly. I just log the failure message and the only time I've seen this so far is related to canals which I haven't coded for yet.
I sort of have to look at something to get an idea of how to use different things and get information. I've mostly been looking at StrongAI and a little bit at WeakAI. Honestly, DynamixAI is so messy I don't even know where to look in there :)
1. How do you check to see if there is a canal blocking the connection between 2 water territories? This is really the only move delegate error I've been seeing.
2. Where does the engine end and AI start? I noticed there are lots of things in Match/Matches and Delegates but also similar utilities in the different AIs. Should things like get all territories that this unit can attack be in the engine portion or is that part of the AI? I wrote a bunch of AI methods to find all of the possible attack territories for the various types of units cause I didn't really find that anywhere else. But then some of the delegates have methods like you mentioned getTerritoriesWhereAirCantLand().
3. I hate how unit attachments work. Why isn't there a method in UnitType so I can go something like: myUnit.getType().getAttachments().getAttackValue()? Instead I have to do something like UnitAttachment.get(myUnit.getType()).getAttackValue() which seems so awkward or am I missing something.
Red (Russians) and Blue (Italians) are from minimap.
In my test, i let your AI do the combat move phase on minimap, and found that it thought it could hold "Blue Middle 2" territory. Of course Red can not hold this territory, since blue can hit it with a ton of units on their turn. And oddly it was looking only at red air units as the defenders, and even more odd since those air units couldn't land there. I think something is wrong with the code, but I didn't have time to fully debug this.
Dynamix is not that bad, just stay away from the utility functions. He has some bright ideas mixed in with a lot of non-object-oriented "C"-like utility crap.
I would suggest seeing how he made the "dynamix settings window", and then simplify and improve on it.
1. Look at how the MoveValidator class handles it, and then go from there. A couple points to mention:
a. It is not specific to sea movement: Any territory or territories, can block movement from one territory to another, until you and your allies (and anyone with the correct relationship attachment) own those territories.
b. You can have multiple canals for each territory being controlled and each territory doing the controlling.
c. Units can be excluded from being controlled by the canal (such as air units).
Example: I could have Territories A and B and C (which could be land or sea), be required to own in order to pass from Territory D to E (which could be land or sea).
I looked at the code and it is a little inefficient. I should probably make a utility method that returns a set of canal objects, containing all this information.
2. I don't think previous AI makers gave that much consideration. If there is some method or match that is clearly specific to AI's only, then I would suggest making a utility class full of these kinds of things, under either /ai/ or /ai/proAI/
If it is something that cleans up, improves, or is otherwise potentially needed by non-ai parts of the engine, then I would suggest editing those classes directly to include it, etc.
3. You can have many different types of attachments for any "NamedAttachable" object. So for example, a PlayerID can have PlayerAttachment's, TriggerAttachment's, RulesAttachment's, etc. Sometimes we allow only 1 of a certain kind of attachment, and other times we allow multiple.
So the best way to get the attachment is through the static convenience method in attachment's class. Whether it returns 1 or a Set of attachments is a clue to whether we allow one or multiple. (UnitAttachment's only have 1).
There are some good utilities in BattleCalculator and DiceRoll for determining unit strenghts and powers and hp and rolls and stuff, which also take account of things like Support and TerritoryEffects.
I just submitted another AI patch. Main changes are:
- Added amphibious assaults
- Finished determineWhichTerritoriesToHold
- Added logic to consider canals
- Fixed logic around neutral units
- Fixed lots of bugs
I think it only has one change outside of the AI code which was a method to determine distance ignoring condition on end tile similar to to several other ignore end methods in the class.
In general, do you prefer that I submit smaller patches more often or larger patches less often? Just trying to get a feel for what works best for you and how often you create releases.
I also saw you renamed all the AIs which looked fine to me.
I tested on a few other maps but just a few turns to make sure it didn't crash. It seems to do ok but is pretty slow on larger maps (NWO) because choosing which territories to attack when there are like 30 options takes a while (NWO Germany turn 1).
I just have one last large enhancement to the initial combat move AI (sorting attack units and intelligently choosing which ones to attack each territory with as right now it is pretty much random). Then I'm going to focus on optimization and testing on other maps.
I'm going to try to keep the AI as general as possible that being said I'm focusing on testing on the most popular and default maps in particular WWII revised as that is my favorite. It should work on all maps but it might not make great decisions if the map has lots of non-standard rules.
I haven't made any official docs and mostly just documenting in the code so far. When I get it to a pretty stable place, I'll most likely create some basic documentation for it.
I have play A&A for a long time and know revised very well (I used to play on TripleA War Club Ladder). I'm probably not the best but should know enough to teach the AI how to at least be decent.
The general design so far is focused on just rewriting the combat move AI phase and I'm going to just do one phase at a time. I'll hook into the existing Moore AI for the other phases until I've rewritten them all. The combat move AI has this basic algorithm right now:
- Find all territories each of my units can attack and how many units can attack each territory
- Prioritize territories that I can attack based on:
--- If I can win
--- TUV swing if I attack with max units
--- Does is have factory or AA to capture
--- Territory's production value
--- Is it an enemy capital
--- Is it adjacent to my capital
--- Is it an amphibious assault (require transports)
- Decide which territories to attack by looping through prioritized territories and place attacking units to determine which ones I can win if I attack. Remove territories that I can't win.
- Calculate max enemy counter attack units for territories that I'm going to attack
- Determine if I can try to hold the territories I'm attacking
- Replace attacking units again based on if I can hold the territory (place min units to win in territories I can't hold, place max units to increase TUV in territories I can hold)
- Actually move all attacking units
Let me know what you think. Also I'm looking for people to help code and test.
sounds reasonable, how good it will be really depends on how you do the details of all those things though. Personally I prefer to heavily document and plan the design before doing too much coding.
Not interested in coding myself; I prefer design to coding (though I tend to design fairly thoroughly). Lack of coders is one reason I haven't tried to make one myself. Very understandable of course, most people want to make their own rather than someone else's.
Fair enough though a decent overall structure/flow is the most important thing.
In terms of design, I drew most of it out and how each phase and steps within the phase would basically work at a high level. But couldn't get too far into the details without learning the engine and what I had to work with. Its hard to design all the details without knowing what the capabilities of the engine are and what information/hooks I'll have available.
For documentation, I knew too many things would change as I learned the engine and didn't want to maintain documentation and code.
If you put out documentation on how you would design an AI, I would be interested in reading it. Also if you aren't interested in coding then you can always help play test the AI and let me know why it sucks :)
O M G Redrum, so glad you made this thread. I first started posting on this forum because I love the Axis and Allies game and wanted to see it succeed and so I started requesting a better AI since everyone says the AI is weak and then we were told no one is working on the AI and since I am literally 80-1 vs the hardest AI (posted screens of capturing 2 countries in 2 rounds and another in 3 rounds) so I started posting here 2 years ago about the AI with suggestions to improve it and received not 1 response except now recently in 1 thread about AI someone linked to the Triple A wiki which says to increase the AI dice but that really isn't an AI improvement just a technical advantage. Redrum, I look forward to your progress but I will post my ideas from past threads and if you find all my old posts they are mostly about the AI but here are the basic ones;
Basically, since humans are the best strategic players, I suggested a "learning AI" which was simply ONE FILE saved FROM THE WINNERS SIDE AFTER THE GAME named "Winnerterritorytally" or "Winnertally" or "Territorytally" or whatever you want to call it - WHICH ALSO INCLUDES SEA ZONES! - that is a saved file AT THE END OF A MATCH whether its human vs human or human vs AI or even AI vs AI and basically its the saved file of the WINNERS captured territories and thus, at the beginning of a new match, the AI can thus use this "tallyfile" to influence its strategic goals since that file shows what territories are always captured BY THE WINNING SIDE and streamlined and improved THE MORE MATCHES YOU PLAY. It would thus become a "learning AI" since only the "winners captured territories" are tracked and saved at the end of the game and thus that file is updated and more accurate THE MORE GAMES YOU PLAY. I might even call this new AI the "Learning AI" option.
Just my ideas and perhaps you could implement what I consider a very easy to do idea (PERHAPS FOR EXAMPLE, all maps have a list of the named territories and use that file to add "+ 1" every time the winners side captured that territory and thus, as more games occur, that territory gains an additional "+ 1" as it is captured for the win and so eventually you would have prioritized the "Winners objectives" and this would be used by the AI as its prioritized game objectives to try and win).
Good luck and let me know how it goes and, also, my past threads suggested an "AI challenge" thread where people tweak game settings (as the Triple A wiki suggested) and players submit their hardest AI and that could be fun but really I would love to see a "Learning AI" option in this game and that would be quite fun to try out and would improve this games AI abilities since it seems to be a big issue with the feedback from the players here who enjoy games versus the AI (ie playing computer chess AI's, poker AI's etc. etc.)
Eurofabio, did you do a typo I'm not sure what you asked.
Anyways Redrum, I do want to see what you are coming up with first because maybe you have a good AI system and I can't wait to try it! My suggestion is just an outline and I don't know where you insert it into the current AI but it includes all Capitols, Territories, and Seazones and would be a prioritizing file that would help the game AI decide what direction to attack and so I think it's possible but you as a programmer would have a way better idea.
Good luck and look forward to whatever you people come up with!
Glad to see some responses. Hey all. If you are interesting in helping develop or test the AI let me know.
douglyfresh - very true though amphibious attacks are one of the most difficult things to calculate. Most likely my AI will also initially suck at protecting them but I eventually hope to improve that.
captaincrunch - very interesting idea though it would take a considerable amount of work. I think I would probably implement something simpler first which would be creating AI XML for each map that gives extra "strategic value" to certain territories. The benefits of this is that you wouldn't have to play a map a bunch of times for the AI to get the values and its easier to code. The drawbacks are it is less dynamic and I'd have to create XML for each map.
eurofabio - the current Moore AI does add a little extra value for victory cities but I don't believe it takes into account how many it currently has or how many more it needs to win. In general, this is actually not very important because on almost all maps the game is decided by TUV and production by the time someone gets enough victory cities. Eventually, I'd like to consider this but it is very low on my list of things to do.
captaincrunch - I'm really doing a complete rewrite of the AI not enhancing the existing one. There are way more important things that need to be improved before considering map specific data. My plan is to rewrite 1 phase at a time of the current Moore AI and I've started with combat move since I think that is the most important. I have a post further up that explains the basic algorithm I'm coding for the combat move.
"I think I would probably implement something simpler first which would be creating AI XML for each map that gives extra "strategic value" to certain territories. The benefits of this is that you wouldn't have to play a map a bunch of times for the AI to get the values and its easier to code"
Yes. That is exactly what I have described but my scheme only works on the regular standard Axis and Allies game type where the winner is capturing capitols and TUV isn't really important. There are other game types for the Axis and Allies Triple A computer game and so it wouldn't work for them but the system I described works FOR ALL MAPS which is my point since then you wouldn't need a different AI XML file for every map - you would only need 1 for any map - because that I AI XML file is about "learning what territories won the previous match on the map you are currently playing" and so obviously a different map won't make any difference because the territories you are picking on your AI XML file you might do will be arbitrary to YOUR opinion on the strategy for any map whereas my concept is based on how the victor won (a first run of the AI should be its weakest in principle) and the Victors game file is the EXACT SAME FILE you described but mine has data based on Captured Territories of the victor the game before.
If you think your explanation is easier than mine then that's ok. You are the one programming. I thought my concept can be done with 1 AI XML without needing 1 for every map was what I explained here. Basically, I think down the road after you've done an AI XML file for a map or 2, you might see how to eliminate the need for separate files per map and then incorporate it into my general system for any map .... although yes it may be more complicated as you are saying I dunno. Still, I can't wait to see what you come up with and tell us the link to it so I can try it out and maybe it will be better than the current system.
Veq - national objectives is definitely on the list of things to consider, most likely I'll just add attack value to territories involved based on how much the objective gives and how many territories are needed
captaincrunch - we'll see but again this is definitely down the road some. My simpler implementation would most likely pave the way for something more complex like you describe.
Veq - I added a new patch: https://sourceforge.net/p/triplea/patches/92/ Main Notes:
- Added logic to intelligently place attacking units (used to be random)
- Added logic to consider neutral unit TUV swing differently
- Improved performance by an order of magnitude on large maps (still slow, around 2-3 mins for NWO Germany turn 1)
- Fixed lots of bugs
I think it is probably stable enough to release in a beta now. My focus for the next patch is:
- Improve performance
- Fix bugs
- Test on lots of maps (mostly have just tried WWII revised and a little NWO at this point)
Veq - looking at the BattleCalculator do you think I can add a new method that instead of copying the whole data each time just does that the first time and uses it for all subsequent AI calculation calls for that phase? It would pretty much just remove the following line so that it is only called once per AI phase:
m_data = GameDataUtils.cloneGameData(data, false);
I assume that is what is really slow?
I look forward to Veq's answer to your last question.
Anyways Redrum, after thinking about it I realized every map does have a different list of Territories for it and perhaps that is what you meant but I was just assuming you could copy/paste easy each different maps Territories into the new AI XML but my main point was my system was a script that is accessed BEFORE reading the Victorcapturedterritories file and that is what still needs to be implemented but at least you agreed that it could be included after you first get your main AI done and then see how you can have this Victorcapturedterritories information added later to improve the AI's strategy. When thinking about Naval AI, I thought that my idea for this "learning AI" should override any specific Naval actions by the AI because I think if a possible land assault is the same turns as a water assault by the AI then no need to build a Navy but IF there is no other shorter route to the enemy capitol then the computer AI should have a logarithm that determines the AI's Navy purchases and that logarithm needs to be very specific as far as "overall Naval strength" ... I mean that the logarithm should know the enemys' "air and sea proximity" and built up (even transport, battleship, sub, then carrier, then planes on carrier etc.) with some kind of strength because Navy zones are always the hardest to defend so this is my guess how you can maybe implement a better Naval AI function. I can see how Naval command is not absolutely needed and why I've demoted it to secondary importance after the AI's first priority of choosing which direction/territory to attack which is what I'm now calling the Victorcapturedterritories file (or if you prefer "Previousvictorcapturedterritories" file).
Good luck and I'll be watching for your new AI. I will want to try it on the WWII Classic map ofcourse :)