The first week back from a Christmas Break and already back in the swing of things!
This week was a very theory-heavy week, while also dabbling into the beginnings of our first programming project: Killbots. The math discussed in the classes all attributed to the development of our individual Killbots, which will be tested against each other in week 3 in a tournament created through Visual Studio.
The “Killbots” that we are to develop are purely AI, where the bot is limited to movement in whatever way you see fit, and then searching and shooting, but not at the same time. While the bot is searching it has a cone of vision that it can find other plays through, and as it decides to shoot the enemy Killbot, the vision becomes lost through what is apparently a “muzzle flash”, momentarily blinding the Killbot. The arena is surrounded by walls, and if the Killbot is to run into either the walls, or another bot, it takes a chunk of health away.
So the main question becomes, in what ways can I develop my AI to act “smarter” than another persons AI? With this, I can begin theorizing the behavioral patterns that I want to apply to my bot that may give it at advantage over another. One way in which I can achieve this is through a prediction of enemy AI movement, through which I can intersect their movement by the bullets that I shoot. A handy tool to start with this would be through this blog:
In this, given that the enemy has a constant velocity and direction, a prediction is able to be made as to where my bullet will intersect the future position of the enemy AI.
The pseudo code for this is as shown:
With the killbots often having an sporadic movement, this equation might not be sufficient enough for the bullets to make contact with a player. In such a way, there may have to be two ways in which this can be carried out. Firstly, a small second observation of the enemy AI would determine, over time, a possible consistent velocity is able to be gained from which the calculation would carry out and shooting becomes enabled. If a constant velocity isn’t able to be gained, or upon next observation of the enemy the health hasn’t decreased at all, then another function would have to be carried out that might help the accuracy based on the type of enemy AI (yet to be decided upon).
So with the shooting theories half solved, the matter of balancing scanning and shooting needs to also be addressed. The current situation is, once the AI loses sight of the enemy the bot rotates clockwise until the enemy is found again. This is an issue because if the enemy was to move a out of sight just a bit anti-clockwise out of sight, then there is a long period of time while the AI scans before finding the enemy again allowing for damage to be taken. So to remedy this, I would perhaps take note of the direction that the enemy was going to, similar to the bullet prediction calculation, and upon the instance that the enemy goes out of sight the bot would rotate in the direction of the last known enemy velocity… If that makes sense. However this should eliminate the lazy searching rotation of the AI.
With the AI movement in general, I want to make it so that the AI covers a large area with long, sporadic movements. This ensures that I’m not just moving back and forth in a small amount of space, while also ensuring that a random bullet hail cannot have as much of an effect on my AI.
So for the last bit of planning I need to do thus far for my Killbot AI, I created a simple draft of a state machine:
In this, there are 3 main states, searching, attacking and fleeing. The fleeing is still in question which will be tested when the bot is actually created, but this will be the state machine that will be followed upon the creation of the bot. It’s pretty self-explanatory so I’l just leave that there.
For now, I’ll keep this as a bot planning blog, and talk more about the C++ implementation of ideas in another blog, where the math that I have learnt will also be discussed. In any case, this is a start!
Author: Kirsty Tschirpig, SAE Institue Brisbane