Finite State Machines and the reluctant programmer

My current project at Uni involves creating an automated robot that must vie with all other student’s robots, to the death.  There are a couple of constraints.  I can scan but not shoot or shoot but not scan.  In other words, I am looking for the enemy combatant but can not shoot and when I do see him, I am shooting blind.  I can however, move when ever I feel like it.  Having never used Finite State Machines (FSM’s) before, I have got to the stage where I wished I had sorted out a couple of them earlier.  One for looking and one for moving through the map.

Seeing as there is another part of this project to go – pathfinding, I can foresee the amount of work I have ahead, trying to implement through if statements and I have bitten the bullet (pun intended) and have decided to incorporate FSM’s now, before it gets too harder.

In my travels to find out the best, or better, ways to implement FSM’s, I stumbled across this blog post.  http://www.skorks.com/2011/09/why-developers-never-use-state-machines/

He explains why a lot of developers don’t start out with them, himself included , and goes on to say why we should implement them from the start.  I can relate to both sides of the argument but can see a stronger reason to try and nut out the “complexities” from the beginning.  It won’t be easy for me to convert to them now, but I will be doing it because I can see that there is a distinct possibility that I will have to expand on my states when I introduce pathfinding for the next part of this assessment.

I can already see where I will have to have a state for hunting, pursuing/attacking and fleeing for my movement states and there is likely to be another look state to find the best path through the maze that our robots will have to negotiate for the next map.

So I am now trying to introduce two FSM’s into my current project – one state for looking and one for moving.  The trick will be to implement this into my standard work flow for all my future projects, including Unity etc.  But they say that a habit has to start somewhere 🙂  This is one habit that I do want to get into.

Even if I have to re-write a lot of the code for the states, I can still keep the structure, which seems to be less cluttered than my current coding, and will end up with a lot less debug hunting, trying to find out why the robot keeps crashing into walls.

I anticipate that it will take me the rest of the day to fully implement the FSM’s but as I am close to having the desired outcome with several days till the assessment will be judged, it will be time well spent.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s