Welcome to Unknown Horizons

Aug 8, 2012

Combat AI Update part 2


Category:Summer of Code Coding 
Posted by: kiryx

Hello again!

Welcome to the second part of my Combat AI update. In case you missed it, first part of the update can be found here: Combat AI Update part 1

Let's start by looking at a diagram showing the basic relationship between the 3 main components in the Combat AI module: StrategyManager, CombatManager and BehaviorManager.

What they do is work side by side for each AI player, sometimes communicating with each other when required.

CombatManager is responsible for handling groups of ships during short outbursts of combat. The abstract idea of detection/handling applies here as well since every group of ships scans the area around them and looks for enemy units: pirates, frigates and even trade ships. Once it spots a certain type of unit, it proceeds to handle combat.

StrategyManager follows the proposed general combat AI idea more closely. Its purpose is to iterate over a collection of predefined Conditions, that scan the game's current state for certain scenarios. Every condition is checked, and in case where it occurs, it is added to the list of possible conditions. Each condition has a priority attached to it, so when many conditions apply at once (as it is often the case), only the most important one is resolved. Trying to resolve many conditions at once (e.g. top 3) could end up not working so well. Certain conditions evaluating as True could have a common cause - a scenario we don't necessarily check for - thus we would end up overreacting based on corelated data. StrategyManager is not really a detector on its own. It's composed of Conditions which - according to our abstract model - are the actual Situation detectors.

Notice that each component operates on a different scope with a different frequency:

  • CombatManager scans the area around each group of ships within a very short range. This check has to be executed quite frequently.
  • StrategyManager scans the whole map and game state, looking for certain conditions to occur. Currently it is executed 4 times less frequently than a CombatManager's loop.

What we've covered so far was Situation detectors for both of the components. To make things interesting we decided beforehand to introduce some sort of "Personality" feature along with combat AI.

In theory we would like to have a component that is composed of small, replaceable knowledge-blocks that can respond to certain game situations. The replaceability of small parts of component's reasoning is where the real power lies. The AI programmer no longer has to read the whole AI code and think where the new kind of feature (not yet recognized by AI) would fit well.

BehaviorManager plays the main role, while BehaviorComponents are small "building-blocks" that create the whole reasoning. Notice that I didn't give out details on how CombatManager and StategyManager's Conditions resolve given situation in game. Well, here it is: All they do is pass certain request of action to BehaviorManager, e.g. "pirate_ships_in_sight" or "player_shares_settlement" (called when StrategyManager notices that AI has to share an island with another player - a classical scenario for a war). Once that is done, BehaviorManager asks its BehaviorComponents whether any of them would be interested in resolving the given case. Very often more than one component is able to respond to given scenario - in that case it is resolved by predefined probability value and calculated "likelihood of success" by each Component.

It is worth noting that with such hierarchy we are able to model different profiles of behavior, e.g. very aggressive, risk taking players, or a cautious, defensive ones.

And that would be it for Combat AI Update part 2. See you later in the last (I promise) part 3!

Cheers.

 
Add a comment for this news:
Comment Title:

Your Name:

Your Email Address:

Additional Comments: