Just a follow up on my last post, I've put up the code for parsing lua statecharts ( aka. hula, which stands for... ummm... let me make something up off the cuff: the "hsm-statechart under lua api" ), and a unit test (which is the only sample code for the lua bits right now).

A quick postmortem:

See full post...

Lua state machines

It's nice to have some time, now and then, to tackle ideas purely because they are interesting. I've had state machines on my mind for a decent bit of time, and have been working on an open-source statechart engine I call hsm-statechart.  I'm also looking for new paid work, and it just so happens one of the groups I'd most like to work with uses Lua for scripting, so I figure now's as good a time as any to (re)learn it. 

As a practical task, getting lua and hsm-statechart working together seems worthwhile. Lua excels at gluing different bits of an application together and, coincidentally enough, that's also what statecharts are meant for. The combo seems like it would be a powerful one.

There are any number of simple lua finite state machines, and even SMC can target lua. But, only Miros and rFSM seem to provide hierarchical statecharts. They are both pure lua. The former ( Miros ) is a port of Samek's engine, while the latter ( rFSM ) looks to be its own unique implementation. I haven't evaluated either in depth, but both seem useful. It's Edward Pereira, though, who seems to have what's closest to my mind: a relatively easy to read textual statechart in Lua.

What follows is the approach I'm taking, it's a sketch of a design and an explanation. It's the sort of thing I normally do scribbling in my notebook ( and, in fact it started the day that way ), but if it's interesting or useful to even just one other person out there in game dev land, so much the better -- so here goes.  The advantages of this implementation are hopefully going to be readability, and interoperability with C. It might be interesting to compare speed, but I don't think that's a killer feature unless Lua LCA finding is really slow, and transitions are triggering fast and furious.

See full post...

hsm-statechart code

Over on google code, I've put up a pure C version of my statechart code.

It's a C port from C++ of a port from ActionScript3.0. The new version still needs work to make state declarations actually look more like their statecharts but it's fully functional. Docs and more blogging on statecharts to come.

See full post...


This has just become my favorite programming language of all time:
Most modern programming languages do not consider white space characters (spaces, tabs and newlines) syntax, ignoring them, as if they weren't there.... Whitespace seeks to redress the balance. Any non whitespace characters are ignored; only spaces, tabs and newlines are considered syntax.

See full post...

State Hierarchy and LCA

Earlier, I posted about State Descriptors. Now I want to show why using state descriptors to track the depth of each state in a statechart can be so useful. Namely: it enables fast, low overhead, LCA - lowest common ancestor - searches.

Since no one can be more bored of the main menu example than I, here's part of the state machine I use for exploration and combat in Dawn of Sorcery.  I'll show you what the LCA means in terms of this state machine, and why it's necessary, and then I'll show how having the depth on hand via descriptors can make the LCA search trivial.

Combat in Dawn of Sorcery

See full post...

State Descriptors

Practical Statecharts in C/C++ has a chapter describing various ways of implementing the actual states for a statemachine. It's a good read, though as inevitably happens when trying to be exhaustive, he missed a few options. ( To be fair, he was trying to list the "standard" methods, not all possible options.) 

I want to tackle one important category of options missing from his list ( and from other people's ), what I'll call here a "State Descriptor". It's a pretty simple idea, but a powerful way of describing states.

To get at what a "State Descriptor" means, let's first separate the idea of *identifying* a state from the actual *processing* code which handles the incoming events for that state.

This separation is implicit when we talk about states, but this separation vanishes during implementation. Let's take a look...

See full post...

Statechart Data 3 - Instance Data

In the introductory post, I used the example of a game's main menu to highlight some of the issues with data that programmers have to worry about when working with state machines.  Subsequent posts have looked at different places to store and retrieve data in order to address those issues. First, was global and machine storage, followed by using events ( particularly the state entry event ) to bounce data from place to place.

That leaves just two remaining categories: state instance data and model data.

See full post...