Entry 2 – A Simple Mob and My Approach To His AI

Runner

Hey folks!

This week I’m going to talk a bit about some of the AI I’ve been working on for the game, specifically a very simple melee attack character who’s purpose is to harass and then run away, dealing moderate damage each time it dashes in toward the player.  I’ve used all sorts of techniques in the past for developing AI including the commonly used state machine method but this time I decided to go with a different, modular approach, where each behavior is controlled in a different script.  This was informed by our locomotion structure which is handled in a similar fashion.  Rather than having one script that controls the characters in our game, they are broken down into individual modules like horizontal movement, jump, dash, attack etc.  Player input normally controls these scripts but for AI we simply build behavior scripts that drive these locomotion modules in place of player input.

So, for this particular AI, I wanted him to be able to follow the player once the player entered a detection radius, then I wanted him to be able to dash toward the player when the player got within a pre-determined attack range.  I also wanted this AI to be able to jump up on platforms in order to follow the player and finally, I wanted the damage box produced by the AI when in dash range, to be disabled if the player was currently in a dash state (allowing the player to dodge attacks with properly timed dashes).  So let’s start with the structure of the Gameobject which is acting as the “Runner” mob which is controlled by the AI I just talked about.  We are using Unity to develop Beat Bot Commandos.  For those who are unfamiliar with out Unity works, I’m not going to go into too much detail but Unity utilizes objects inside the game scene which are called Gameobjects.  They act as a container for anything we want to do in the engine.   You can think of them as a folder that holds other objects, scripts etc which are its children in a literal hierarchy which can be accessed in the inspector or through code.  So the way this mob is structured, I have a separate game object as a child to the parent which handles player detection with a 2D Collider.  There is another object which handles the melee range and dash activation also using a 2D Collider.  The way this works is that there is an invisible shape that follows the AI.  when it comes into contact with something, it checks whether that something is a wall, platform, player, enemy etc.  If it’s a player then it activates the dash script, which makes it lunge toward the player, and also activates the attack script which, as mentioned before, is interrupted by a well timed dash from the player.  The AI determines whether or not to jump by comparing its height to the player’s height and using rays.  The rays find out if there is a platform in range and if the player is at a higher position and a platform in range is detected, the jump script is activated.  Pretty simple!  And that’s really all there is to it!  Stay tuned next week when I discuss the other element that we’re placing on all our mobs: hitbox detection for more dynamic death animations!

 

Posted in Uncategorized.

Leave a Reply

Your email address will not be published. Required fields are marked *