Game Programmer

By: James Keats | November 13, 2017

As previously mentioned, the next Artificial Opponents project is a four-player tank battle. The movement portion has already been completed, and so the next step is to plan the AI for things like combat and planning.

First, though, a look back at moment. In my last post, I wrote about my plans to use Context Behavior for the movement in this project. After getting a quick implementation in place (heavily based off of my previously iteration of it), I realized that it was not going to work as well as I had hoped for this project. While it worked perfectly fine in the initial sample level we were given, more complex levels left it confused and unable to move anywhere. This may be a limitation to my code and not Context Behaviors in general, but I think it's safe to say they were not originally intended to solve mazes.

As a result, I spent some time implementing A* and graph generation based on the level grid that we were provided with. Once that was up and running, I was able to quickly iterate on differential drive, and found some numbers that worked fairly well. I ended up with 4 thresholds, based on the angle difference between the current "facing" angle of the tank and the angle of the desired movement. The thresholds were 0-15 degrees, 15-45 degrees, 45-90 degrees, and >90 degrees. I used a different combination of tread speeds for each of these scenarios, with the tread direction determined by whether the facing was to the left or to the right of the desired movement.

So now, we're on to the battle segment, which has the potential to be more complicated. Here's the plan:

Classes & Algorithms

The first thing to consider is purchases. Though the full details of the in-game economy have not been explained to us, the plan is to use a simple scoring system to determine what to buy. We also don't know the exact details of what variables we will be considering. Presumably, there will be some cost, as well as damage and potentially something like rate-of-fire. If this turns out to be true, the score could be as simple as dividing the damage by the rate-of-fire to get a potential damage per second, then dividing that by the cost and comparing values to get the best option. This could change when we find out what the actual variables are. There is also the potential that this system will get cut before the actual competition; stay tuned!

The other important feature is tracking down opponents and firing at them. My plan for this is to choose an enemy based on proximity, then attempt to position myself to their side or behind them and fire at them. The movement code is already written to send a unit to a particular location, and included in that is code to face a particular direction. When an enemy is within range of the weapon, we will fire at them. The specific follow values will inevitably have to be tweaked once the enemy tanks are actually moving and responding to the movement of my units, but the basic concept is simple. There will also have to be code to prevent re-choosing a target too often, otherwise the proximity check could cause us to flip between multiple opponents frame-to-frame.

Overall, there is a lot to be done for the second portion of this project, especially with the end of the first semester of Capstone getting so close. I'm looking forward to investigating the Tank Battle more after Thanksgiving break.

Category: Artificial Opponents 

Tags:

Comments:

Be the first to comment ...

Post a Comment