Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experimental AI: make AI recruit higher level units #4437

Merged
merged 4 commits into from Oct 17, 2019

Conversation

@mattsc
Copy link
Member

commented Oct 8, 2019

The ExpAI recruits almost no higher level units. In the scenarios I tested with default era units, there's maybe one L2 unit recruited every dozen or so recruits. Yet, it's reasonable to assume that if scenario designers give the AI higher level units to recruit, they expect that to happen not just sporadically.

The reason why almost no L2s or higher are recruited might be partially because unit cost is not as well balanced for the higher level units. But mostly it happens because cost is penalized by the ExpAI recruiting. This is in order "to avoid recruiting many expensive units -- there is a requirement for bodies in order to block movement" as per a comment in the code. I don't want to change that, as it would mess up the recruiting ratios of L1 units of different cost, so instead I am adding a bonus for higher level units that increases as the high-to-low-level units ratio decreases. A few comments on that:

  • The code tries to recruit so that the ratio of level i+1 to level i units is approximately high_level_fraction. The evaluation could be set up so that that this ratio is exact, but I actually think it is better to make it an approximate ratio, it adds a bit variety and unpredictability.
  • high_level_fraction could be made a configurable parameter. The current value of 0.33 is chosen because having 1 L2 for every 2 L1 units "sounds about right", but this is clearly somewhat dependent on the scenario. I don't currently know how to do that when setting up the ExpAI using ai_algorithm= though (I do know how to do it when it is set up as rush recruiting Micro AI), but I am sure I can figure it out.
  • The factor 0.25 in the equation for the bonus is chosen because in my tests this was roughly the average rating difference between L1 and L2 units of the same advancement tree. The exact value does not matter all that much though because of the square on unit_deficit.
  • I only start the bonus at L2 units. There's no such bonus for the relative ratio of L1s to L0s, as those are handled pretty well already (likely because their cost is balanced better in the default era).

@sevu You brought this up. Any comments?
@Alarantalara Pinging you in case you are still around and interested in following this.

Because unit cost is penalized in the ExpAI, it recruits almost no higher level units. This adds a bonus for such units to be recruited at approximately the ratio defined in 'high_level_fraction'.
@mattsc mattsc added the AI label Oct 8, 2019
@mattsc

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2019

Just to clarify, that ratio I am referring to is the ratio of units of the AI side currently present on the map, not of the units being recruited that turn (or over several turns).

@soliton-

This comment has been minimized.

Copy link
Member

commented Oct 8, 2019

I would definitely make high_level_fraction configurable. I don't think recruiting high level units is generally a good idea. Perhaps even more so for the usually reckless AI.

It can make sense under certain circumstances though which are likely very difficult to figure out automatically so a configurable parameter sounds perfect. Cicumstances I could imagine would be choke points where power density per hex is more important than absolute power or needing special abilities of certain high level units.

Btw, I think that the cost of high level units is not too bad nowadays. Given more special abilities being factored in for high level units, that the AI will often have trouble using effectively, the unit cost is necessarily a worse indicator for the AI.

@mattsc

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2019

Yeah, makes sense. An additional advantage of making high_level_fraction configurable and setting the default to zero would be that that preserves backward compatibility consistency of AI behavior.

I've now looked into how we would do that it practice. I don't think there is an easy solution for adding that functionality when setting up the ExpAI using [ai]ai_algorithm=experimental_ai. That would require adding a new aspect or other C++ changes which I really don't want to do, given that the additional content of the ExpAI is entirely Lua and should be simple to change and expand on.

However, it is easy to provide a macro that would be used like this:

{CUSTOMIZABLE_EXPERIMENTAL_AI (
    high_level_fraction = 0.4
    other_custom_parameter = 17
)}

Setting up the ExpAI in its default configuration could then be done as before, and for custom settings one would use the macro.

mattsc added 3 commits Oct 8, 2019
This also sets its default value to zero, in order to have consistent default behavior with versions from before this parameter was introduced.

It also provides a macro so that the ExpAI can be used with custom parameters in a scenario config, and adds high_level_fraction as an optional parameter to the Recruit Rushers Micro AI.
This was already an optional parameter for the Recruit Rushers Micro AI.
Without this, the AI always starts with whatever it considers the best unit without taking the level bonus into account. This mostly only matters when one sets high_level_fraction to a very large value (1 or larger) in order to force only high-level recruits. In other cases it makes no, or no significant, difference.
@mattsc

This comment has been minimized.

Copy link
Member Author

commented Oct 15, 2019

I'd like to merge this before 1.15.2 is tagged this weekend. I'll do so within a day or two if I don't hear any objections by then. I'm also planning to backport this to 1.14, as the default behavior does not change and it gives UMC authors a chance to change potentially undesirable AI behavior (and we'll get more testing that way, as @sevu pointed out on Discord).

BTW, I'm not planning to squash this as each commit is functional and reasonably logical stand-alone, but if somebody has strong objections to that, let me know.

@mattsc mattsc merged commit bdf5421 into wesnoth:master Oct 17, 2019
2 of 3 checks passed
2 of 3 checks passed
label
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@mattsc mattsc deleted the mattsc:expai_recuit_higher_levels branch Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.