FreeOrion

Forums for the FreeOrion project
It is currently Sun Oct 22, 2017 5:10 pm

All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Mon Feb 20, 2017 11:21 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4371
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


Top
 Profile  
 
PostPosted: Tue Feb 21, 2017 3:48 pm 
Offline
AI Contributor

Joined: Tue Feb 17, 2015 11:54 am
Posts: 222
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


Top
 Profile  
 
PostPosted: Tue Feb 21, 2017 4:54 pm 
Offline
AI Contributor

Joined: Tue Feb 17, 2015 11:54 am
Posts: 222
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


Top
 Profile  
 
PostPosted: Tue Feb 21, 2017 8:25 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4371
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


Top
 Profile  
 
PostPosted: Tue Feb 21, 2017 8:49 pm 
Offline
AI Contributor

Joined: Tue Feb 17, 2015 11:54 am
Posts: 222
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


Top
 Profile  
 
PostPosted: Tue Feb 21, 2017 8:50 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3245
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.


Top
 Profile  
 
PostPosted: Wed Feb 22, 2017 12:29 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4226
Location: Sol III
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.


Top
 Profile  
 
PostPosted: Wed Feb 22, 2017 9:07 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4371
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


Top
 Profile  
 
PostPosted: Wed Mar 08, 2017 12:20 am 
Offline
AI Contributor

Joined: Tue Feb 17, 2015 11:54 am
Posts: 222
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


Top
 Profile  
 
PostPosted: Thu Mar 09, 2017 6:02 am 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4371
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group