Games Developer | Programmer

Bradys Blog

Bot Tournament - AI Behaviour Design

This trimester our first task is to create a bot for a bot tournament. Each person in the class will be creating their own bot with unique behaviour and at the end of three weeks we will put them against each other in a battle. 

For this we were given the program the tournament will be run in and a bot framework that we can add our own behaviours to. The base bot has three stats that we can change, move speed, shoot speed and turn speed. These three stats are balanced between each other, meaning if you increase one value the other two values will decrease (this is percentage based). In this blog I will be going through the behaviour designs I will be adding to my bot.

Planning and Initial Ideas

Burst Fire

The first idea I had for the bot was a burst fire. The way I was thinking this would work is once the bot spots an enemy it will stop and fire six random shots in the bots cone of vision towards the enemy before it resumes looking for an enemy (the bots can't shoot and look for an enemy at the same time). An issue I noticed when observing the base bot against another bot was that it was extremely inaccurate against a moving target. This would in theory have a greater chance at hitting an enemy and counters bots that move in unpredictable ways. The other option here was to try shot prediction which I will talk about later.



For my bots movement I wanted it to find the enemy fast and keep it in its vision as much as possible. Firstly, the idea was to have it move around the map in a spiral with its starting position in the top left corner of the map as seen in the image below. This idea was to counter the base bots clockwise scanning functionality. I thought most people would keep this part of the bot as it works pretty well so I wanted this to be my focus. The advantage of this was that because my bot it travelling in a anti clockwise action, enemy bots will only have a fraction of second to spot the bot travelling over its cone of vision. However there is some obvious flaws with this initial design so I iterated on it.


I soon discovered that the more efficient way to achieve this is by simply just having it loop around the outside of the map and not spiral inwards. Enemy bots won't be able to get behind my bot this way and if a bot charges towards mine it will have a greater chance of running into a wall and taking more damage.


The other way to achieve a similar result was to have it move up and down on one side of the screen while it looks towards the opposite side of the screen. This is quicker patrol route and it has better coverage of the entire map. A problem with this is that the bot would have to slow down as it was just about to reach the top and bottom walls so it doesn’t run into them. This might be able to be solved by simply playing around with the patrol distances between the two walls so it has a greater distance to slow down or just reducing the movement speed. This would be a similar issue on the previous design as well.


Shot Prediction

Shot prediction was another option to fix the issue of the bots accuracy. After playing around with the implementation of the method below I noticed a few problems. As there was no way to get the enemies movement vector directly you need to calculate it manually. This means you have to get the enemies position for two concurrent frames and calculate the vector between the two. This takes time and is often still inaccurate as it's difficult to see an enemy for more than one concurrent frames and the calculation doesn't take you own bots movement into consideration. This is why I decided to scrap shot prediction and just go with my initial burst fire tactic.



The last idea I had was to have my bot try and dodge incoming bullets (and enemies?). I’m thinking this could be achieved by just travelling in the opposite direction that the bot is currently travelling in. This would likely prevent any shot prediction as well, like I said above there’s no way of knowing the enemies velocity without calculating it which assumes it will travel in that direction at the same velocity. This would work well with my movement technique of patrolling as well.

Brady JohnstonComment