9/24-10/8: AI Improvements

I’ve had a lot of progress over the past three weeks. Here are my updates:

AI Strategies (9 hours)

Most of my time these two weeks were spent on the AI. Our game allows players to play against a computer controlled opponent. While complex, the development of this feature will allow us to better test our mechanics (i.e. you don’t always need a multiplayer match to test things like UI changes), and ensure recruiters can play our game regardless of the state of Photon.

The AI essentially works like this:

• Every iteration of every turn, the enemy AI calculates all of the possible moves it can do and adds them to a list. For instance, the AI lists every city that it could capture, or every unit that could defend the commander.

• The AI evaluates each move one by one, assigning it a score. Higher scoring moves are better.

• The AI executes the highest scoring move, and repeats the process until it can longer move. Once it is done moving, it ends the turn.

A snippet of the data structure outputted for each strategy

The AI already had some work done over the summer. However, the AI needed a substantial amount of improvement in order to make it interesting to play against. I worked with the AI designer to make the changes necessary. The changes I spent the sprint working on are:

• Prioritizing Free Cities: The AI should go after “free” cities before contested cities. “Free cities” are cities that are either neutral or not well defended. The AI should also prioritize helping capture cities where the capturing unit is at a disadvantage. This involved creating a metric called “Battle Strength” to determine exactly who has the numerical advantage in a fight for the city.

• Prioritizing Helping Other Units: The AI should look for opportunities to get easy kills (i.e. to kill a unit without taking much damage, or to have a friendly unit nearby). This involved a similar calculation to the battle strength.

• Prioritize Attacking the Commander: Commanders in Project Multiply are a core component of the game - killing them wins the player the game by default. As a result, the enemy needed to heavily prioritize attacking the commander to ensure it would be damaged.

• Assist Commander: The AI needs to protect its own commander. If the commander is in danger from other units, the AI needs to find the nearest unit and prioritize defending the commander. This involved creating a new strategy class called the FollowCommanderStrategy and moving near the commander. The hardest part about this strategy was figuring out what position the unit should move to; a unit needs to find the position that will block the opponent’s units from attacking the commander.

• Escape from Danger: If a unit is in danger of being killed, they should attempt to get out of the area immediately. The hardest part about this strategy is figuring out the best position to move to. Right now, the AI calculates the average position of the surrounding enemies and finds the opposite direction to that.

AI Debugger (5 hours)

While testing out my strategies, I found that it was hard to determine what exactly the AI was trying to do and why. I knew that if I had trouble, the other programmers and designers would have trouble as well.

My solution to this was the AI Debugging tool. This tool could show all the strategies the AI calculates and display its score, along with any notes. This tool enables me to actually see how the AI is making their calculations and compare its results to my expectations. This tool makes future design decisions and iterations much easier.

In addition to the display, I added several connivence features, including the ability to breakpoint on calculations and the ability to see previous turns

Repository Management (4 hours)

I spent a lot of my time on maintaining the repository, which involves merging pull requests, fixing Merge Conflicts and hotfixing the build when needed. I merged in 75 pull requests this sprint (audio not included, as Gibby does most of that), which is the same count as the previous two week period. Much of my time was spent on solving merge conflicts, of which there were only a few; however, some of these merge conflicts were complicated, as they would involve the entire Unity prefab and require several merges. Solving these conflicts involved advanced techniques, such as using transfer prefabs. Overall, the negative impact of merge conflicts on the team were mitigated.

In addition to merge conflict resolution, I spent some time hotfixing and repairing the build, including:

• A fix for automated files being created by our third party packages (I just had to change the build file string)

• Integrated Parrel Sync, a package that many of my programmers wanted to make development easier

• Fixing the spawning UI when a failed merge conflict resolution left the player unable to spawn air units.