Additional AI Carrier planning

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Post Reply
Message
Author
User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Additional AI Carrier planning

#1 Post by Dilvish »

As Matt noted in Issue 1013, the AI currently expects that FIghters can attack planets, whereas actually they cannot. (And yes, to make sure this was not just due to the AI Carriers being on Passive I checked the CombatSystem code to confirm that Fighters are not allowed to attack planets at all). So as it stands the AI would just be sending Carrier ships into death because they would drastically overestimate their effectiveness against planets.

Long term we'll want the AI to be able to properly assess the respective combat uses of both Carriers and conventionally Armed ships (and actually I envision multiple military ship subtypes that would be somewhat specialized for different roles), but I don't think we'll be able to pull that together for 0.4.7, so I think we need an interim fix/workaround that can go into 0.4.7.

Near term, I see two potential workarounds/fixes, neither very satisfying but both much better than ignoring the issue.
  1. Continue to allow them but have the CombatRatingsAI substantially reduce the combat strength contribution that it calculates for them, and probably also modify the CarrierShipDesigner adjusted rating downwards a bit also, especially if there are no direct fire weapons on board at all (perhaps adjusted down to zero to prevent that case). The idea being that Carriers could still be built so long as they have at least some Direct Fire weapons, and the AI can get their benefit in ship-to-ship fights, but the AI combat calcs would not be relying on fighters to attack planets. It's not clear how easy it would be to get this balance to work out OK without the AI effectively just giving up on Carriers, but we can try.
  2. We just disable the AI from using carriers at all. Not a happy choice, since Morlic has put a lot of effort into enabling them, and it sounds like they be useful enough that not being able to field them would be a competitive disadvantage, but it would be very easy and at least it would prevent the AI from misusing them and wasting resources/time.
So, I would be inclined to try the first approach, and if we couldn't get it working satisfactorily in time for 0.4.7 then we would fall back to the second approach. Anyone have thoughts on these or other ideas?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Morlic
AI Contributor
Posts: 296
Joined: Tue Feb 17, 2015 11:54 am

Re: Additional AI Carrier planning

#2 Post by Morlic »

In the code, there is already made a distinction between fleet and planet threat in a system.
CombatRatingsAI could trivially be extended to offer a rating_vs_planets() function where carrier stats are ignored.

Instead of only comparing the total threat of a system to the fleet strength, we could then add a second check if the rating_vs_planets() is (significantly) greater than the planet threat of the system.

Finally, we need to convince the AI to not only build carriers. For that, we could simply prefer a ratio of at least x % conventionally armed ships. Two-line-implementation is to compare to a random variable if a Carrier Design was chosen and then potentially choose the conventional warship instead.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Morlic
AI Contributor
Posts: 296
Joined: Tue Feb 17, 2015 11:54 am

Re: Additional AI Carrier planning

#3 Post by Morlic »

I started to implement my suggestion. Still need to touch the military allocation code but I should get it done until release.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Additional AI Carrier planning

#4 Post by Dilvish »

OK, great! (note: I think that the step of "add a second check if the rating_vs_planets() is (significantly) greater than the planet threat of the system" will need to be checked at quite a few different spots, probably everyplace that planet_threat gets checked/used.)

Since it is a bit related (and would probably make a useful part of this implementation), do you think that you could also implement that ShipDesigner.strength() feature we talked about recently, which would be combat strength from CombatRatingsAI for warships, troop count for troopships, etc., and which would be returned as an additional value for each build location by optimize_design() and stored in the design cache along with the other info?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Morlic
AI Contributor
Posts: 296
Joined: Tue Feb 17, 2015 11:54 am

Re: Additional AI Carrier planning

#5 Post by Morlic »

I aim for a slightly different approach: I want to refactor the ShipDesigner class to use a PseudoShipDesign class which contains the design stats as attributes.
Then the cache will consist of instances of that class which allows calling arbitrary functions on/from it. Seems both more elegant design and more future proof instead of having some n return values that need to be updated and maintained...

Second step then is to provide an appropriate __init__() function for CombatRatingsAI.ShipCombatStats to get the stats from a PseudoShipDesign object instead of a real ship. Then those rating functions can be used and we are rid of the code duplication...
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Additional AI Carrier planning

#6 Post by MatGB »

Observation: option 2 isn't really an option.

This is meant to be the Fighters release, everything else is secondary, if Fighters aren't ready then we need to delay.

I need to finish a small number of minor balancing tweaks and there are some UI adjustments going in but beyond that we're OK apart from AI which isn't working as well as I thought it was earlier.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Additional AI Carrier planning

#7 Post by Vezzra »

MatGB wrote:Observation: option 2 isn't really an option.

This is meant to be the Fighters release, everything else is secondary, if Fighters aren't ready then we need to delay.
Pretty much this. The AI definitely needs to be able to use fighters/carriers at least sufficiently well so that players can playtest the new mechanic reasonably well in single player games.

Consequently, if the AI team needs more time to put together something that meets this requirement, then you guys are going to get that time, and 0.4.7 will have to be delayed. Just keep the rest of us updated on your progress and on some rough estimates about until when you expect to be able to get that done. I'm aware that you won't be able to optimize anything within reasonable time, but at least the basics should be covered.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Additional AI Carrier planning

#8 Post by Dilvish »

MatGB wrote:Observation: option 2 isn't really an option.
Yeah, I am very much regretting that I even mentioned it as a fallback option, I think I wasn't thinking so well that day, hehe. My apologies to Morlic and anyone else who might have felt pain at the idea.
MatGB wrote:beyond that we're OK apart from AI which isn't working as well as I thought it was earlier.
Morlic and I have a few things pending that I think will put the AI into pretty good shape. Some of it is working and is mostly just help up on code formatting / refactoring type issues. I don't think I got #1328 submitted in time for this week's builds (and it has C-code changes so it needs a rebuild), but if you can build the code yourself these days then rebuild current master and cherry pick in the commits from #1329, 1352 and 1353 (at least right now there are no conflicts for them) and give that a try with 400 systems, low monsters, 6-8 AI, and, well, I at least think you won't be disappointed with the AI.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Morlic
AI Contributor
Posts: 296
Joined: Tue Feb 17, 2015 11:54 am

Re: Additional AI Carrier planning

#9 Post by Morlic »

Dilvish wrote: Since it is a bit related (and would probably make a useful part of this implementation), do you think that you could also implement that ShipDesigner.strength() feature we talked about recently, which would be combat strength from CombatRatingsAI for warships, troop count for troopships, etc., and which would be returned as an additional value for each build location by optimize_design() and stored in the design cache along with the other info?
As hinted in previous post I implemented a more general approach which should provide an obvious interface for everything you want to do:
https://github.com/freeorion/freeorion/pull/1387
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Additional AI Carrier planning

#10 Post by Dilvish »

Morlic wrote:
Dilvish wrote: Since it is a bit related (and would probably make a useful part of this implementation), do you think that you could also implement that ShipDesigner.strength() feature we talked about recently, which would be combat strength from CombatRatingsAI for warships, troop count for troopships, etc., and which would be returned as an additional value for each build location by optimize_design() and stored in the design cache along with the other info?
As hinted in previous post I implemented a more general approach which should provide an obvious interface for everything you want to do:
https://github.com/freeorion/freeorion/pull/1387
Great, thanks.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply