Blog 3 (10/22-11/5) - More AI

Introduction

These past two weeks have given me the chance to fully immerse myself in the AI systems. I have been finishing up a couple AI strategies while also starting on a new system that will hopefully help our AI make better decisions.

Meetings (4 hours)

As usual, we had our weekly studio meetings to discuss planned features and playtest the current build.

AI Purchase Behavior (6 hours)

During week 2 of sprint 2, I was tasked with finishing up the purchase behavior for the AI. If you remember last week, I had written a formula to help calculate the best unit to spawn and wheret to spawn it. This week, I just had to implement it.

I began by figuring out a way to calculate the best unit to fit in a team comp. First, the AI calculates what its current unit composition is. It should ideally strive for 50% melee units, 30% ranged units, and 20% aerial units. If a unit helps the AI get closer to this target, it will be more likely to purchase that unit.

When determining how to counter the enemy's composition, the AI will look at the proportion of the player's army that is weak to ranged and the proportion that is weaked to air units. If the player has a larger proportion of units weak to a certain type than the AI has to counter it, then the AI will prioritize purchasing the countering unit.

The last element to implement was the location score. The AI should prioritize purchasing units where the AI is outnumbered by the player. To check for this, I used the AICityState implemented previously in the code base which tracks nearby allies and enemies. A strategy will lose score for placing units where the AI outnumbers the player and gain points where the player outnumbers the AI.

AI Commander Special Behaviors (6 hours)

My major task for week 1 of sprint 3 was to give the AI the ability to consider and use their commander's special ability. I started with the Swordmaster's second attack ability and the Old King's spawn unit ability.

To maintain DRYness, I decided to implement the strategy for the Swordmaster's second attack within attack strategy. Theoretically, the Swordmaster's decision to use their second attack should take into account all the factors that caused them to do their first attack. Adding this behavior required the AI to check for the Second Attack ability on each unit. If a unit could attack again and had already attacked, it would consider a second attack strategy

I had a similar idea of maintaining DRYness with the Old King. Since the Old King's ability effectively turns him into a city, I decided to implemented his special behavior inside the purchase strategy. I accomplished this by overloading the AICityState constructor with a set of parameters that accepts a commander instead of a city. The AI was also supposed to prioritize purchasing unit with the Old King over cities since those units will be more powerful, so I added an extra check that prevented purchase strategies from cities being created if the Old King had a special charge.

However, working on these features was not a smooth process. Early on this week, I was running into a gamebreaking bug where the AI would break when attempting to capture cities. I couldn't figure out why this was happening, even when stepping through the debugger, so I decided to ask the other programmers on the team for help. After some investigating, I learned that a change had been made so that the commanders no longer could capture cities. However, the AI would still attempt to use commanders for capturing cities, causing the game to stall indefinately. Fixing this problem was as easy as adding an extra check in the city capturing strategy, but it was a good lesson to always stay in the loop about design decisions.

AI Scriptable Objects (2 hours)

My last small task for the second week was to move some of the weights and multipliers which score AI behavior out of scripts and into scriptable objects. This will hopefully help our designers better tune the AI without needing to dive into the code themselves. I also made sure to provide helpful tooltips for everything designers know what they need to modify to change the AI's behavior.

AI Tile Weighting System (1 hour)

Next week, I plan to finish a system which will allow the AI to evaluate the importance of each tile on the board. I began creating it this week, but won't finish until next week. Stay tuned to learn more about this nifty system!

Conclusion

I spent a total of 19 hours this week. I feel happy with my progress and am excited to continute to refine the AI system in our game!