Pretty banner! :)

Entity State Machine in 60 Seconds or Less

Every now and then you come across a solution to a problem you never knew existed. Squize over at Gaming Your Way blew my mind this week when he posted a quick overview of how he supports the concept of state machines in his code. The solution is so simple and quick that I couldn’t help but just say “Wow!” when I read it.

You can learn about his implementation here. There are a number of things I like about this solution:

  1. It uses built-in language functionality. This means you don’t have to do any fancy imports or copy paste code from old projects because there are no external dependencies. This can help make your code more maintainable and portable.
  2. It can be incorporated into existing code with minimal effort.
  3. It is simple to understand and discuss.

The biggest draw back I have with this particular implementation is there is no concise way to manage state-specific data. For example, if you have two entity states, idle and attack, the attack state would need a target but the idle would not. In a more engineered solution (which doesn’t necessarily make it better), each state would track and manage its data, so that the idle functionality didn’t share logical space with the attack functionality, which has this distinct target data. It’s not a deal breaker by any means, and I think that for all but the most complicated state machine functionality, even with this drawback, this solution wins out because of the reasons stated above.

Thanks Squize and Gaming Your Way!

Post Metadata

Date
December 12th, 2008

Author
urbansquall

Category

Tags


2 Comments

  1. Check me out posting a comment about my own words on a different site, that’s how important I think I am ;)

    Thanks for your kind words about the state machine approach mate. I’ve said it a load of times since actually writing that though, that I thought everyone did it that way anyway.

    You raise a really good point about passing data. For example if you’re passing a timestamp to a instance every frame, that’s all well and good when that instance needs to know about it ( ie, it’s a space invader, and it’s moving and wanting to sync itself up ) but when the state changes so that info isn’t needed ( The invader is dying, so no movement just animation ’til death ) then it is slightly cumbersome.

    When it happens that way, I just swallow it, but secretly hate it. At the end of the day, it’s only really bugging me, it’s not doing any harm in the grand scheme of a running game, couple of lost ms, but nothing to worry about, so it’s easier to just secretly hate it :)


  2. I’ve been considering a few approaches that manage the data for the different states. The problem, though, is that it quickly devolves into something that loses a lot of the conciseness of the original solution which is bad.

    I feel like there is a solution there and I’m grasping but it just sifts through my fingers.


Leave a Reply