Finite State-Machine Engine
Whilst I was working at Massive I was introduced to the idea of applying finite state-machines to the management of an RIA's application model or state. The idea whilst not new was being used by James Mc Parlane in a project of his called ThumbWhere. James had written a JavaScript based finite state-machine engine to control the application state of his HTML based RIA.
At the time I was approaching the end of a project our Flash team was working on that involved the building of a "catch up" media player for an Australian television channel. The project is still waiting to be released but as a general description we pushed the boundaries of interactivity, implementing a 3D interface for show selection. Reduced the number of controls required so that it could operate at full screen with keyboard input (for remotes) etc. and a host of other design and usability considerations. But one of the problems we were running into was how to manage the state and the rules of transition that applied to each state. Our solution at the time was to do what most developers do and use a display model and various flags to control what was happening and what was allowed to happen next. This method can become extremely difficult to debug and scale up.
After the project finished I was thinking about this problem and came across some of James' work in the area. Initially I spent a lot of time investigating state-machines in general and there application to workflow and an application's state. Most of the options currently available involved code generation or hand coding the state-machine to fit that one particular problem domain. Now being a fan of using metadata and annotation to describe a system (think ORM) and having an engine that does all the laborious work James's solution seemed perfect.
I'll let you read James's post to get the background info but essentially the system is described in XML and the engine will try to enforce the rules as best it can. In AS3 there is a benefit to using XML and that is the fact that it is a first class data type and can very easily be generated and/or compiled into the SWF if needs be.
Now the fact that James’s engine was written in JavaScript meant it was a fairly trivial task to port it over to AS3. The code for this sits in the repository for James' engine but he tells me he will be making the repository available as opensource in the not to distant future.
Of course all of this is just boring without a demo. It's an old style memory game were you flip over two cards that you think match. This demo is totally controlled by the XML description and the state-machine engine. The source for the game is available, but unfortunately the engine's AS3 source is not. You can however have a look at the JavaScript source of some of James' demos on his site.
What next? Well I am in the process of developing a framework (I know, I know not another one) that will use at it's heart a finite state-machine (any state-machine not necessarily this one) to control an application's state. It's mostly there in code - I am just finishing off the unit tests and then come some integration tests and finally the documentation. All this takes time so please bear with me if it lags a bit. I am however committed to releasing it as it will be a great step forward in the way us AS3 developers manage an applications state.
