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!

 

Devblog Entry 1

 

Hey everyone!  First of all, welcome to the Shadowforge Devblog!  This is the first entry in what will be a weekly blog.  We plan on posting at least once a week, probably on Sundays.  This week has been all about web design and social media preparation so there isn’t a whole lot to show you but the plan is to keep a record of development every week for accountability and to serve as an educational resource for anyone who might be interested in what we’re doing.

 

So the learning point for this week for us has been about social media marketing and refining and simplifying our website.  For starters, we decided to route our social media presence through our company page.  Previously we were trying to split our attention between our company Facebook page and the game-specific page.  This meant that we were essentially trying to manage two separate communities and that for future game projects we would have to start from scratch all over again.  It may seem like common sense but unfortunately we had to learn the hard way.  Now, the idea is to take all of our followers and feed information through our main company sources:  Shadowforge Facebook , Shadowforge Instagram so that when we have new projects in the future, everyone who is interested in our games has easy access to updated information without the need to follow another page.

We’ve also simplified our website so that we highlight the things we’re working on and get rid of unnecessary clutter.  Well, thanks for reading the first first entry.  Next week will be more interesting, with gifs and game development things.  So stay tuned this week to find out how we’re creating the illusion of depth on pixel art using normal mapping!