Correcting immediate event posting “feature”

As I consider the AS 3.0 implementation, I will address another small issue that occasionally crops up — the fact that events are handled immediately in my 2.0 architecture, rather than queued for processing.

The reason they are handled immediately is obvious when you consider how it is done — anyone sends an event to the event handler.  Really, anyone.  So this could be a routine handling an event already that sends a new event.  The problem is that the original event really should complete before posting the new event.  Most of the time this has little to no consequence, but it has to do with the run-to-completion concept from UML statecharts.

I think the correct thing to do is to have a new method, postEvent, which routines can use to post an event to the system.  If the main event handler is currently processing an event, it will queue the event until it is done (and then process the event).  I think I should also allow an optional delay parameter (msec or frames), kind of a concession to Flash, which would delay the processing of the event at least as long as (but perhaps longer than) the caller requests.  The concession is to how Flash updates the graphics, on a frame basis.  If someone has set up states tied to frames, they may want to wait until the frame is active before executing the stuff within the state.  We’ll see!

AS 3.0 State Machines

I’ve been meaning to write about this for some time, because occasionally people ask me about whether I am going to port my state machine to AS 3.0.  The answer is yes, but I just don’t know exactly when [Aug '09 Update: I did it!  see #3]

Those looking for state machines in AS 3.0 should check out:

1. Troy Gardner’s COGS (http://code.google.com/p/troyworks/) framework, which is based on Miro Samek’s (http://www.state-machine.com) QHsm and QFsm work — people know I’m a big fan of Miro’s.
2. Bill Sanders’ State Machine design pattern, from his excellent book, “ActionScript 3.0 Design Patterns” — not a hierarchical state machine, however.
3. [* New *, August 17th, 2009]  My As3 Flash State Engine, http://code.google.com/p/flash-state-engine/.

Certainly if anyone knows of others, please let me know!

Event handling for FStEng 3.0

I’ve been planning to port my FMXIS State Engine from AS 2 to AS 3, but haven’t really had the time to think about how I want to improve the system rather than just translate it.  This is an opportunity to rethink some things I didn’t like about the current (2.0) architecture, so I don’t want to waste the opportunity.

The main thing I plan to upgrade/modify is the way events are distributed, both to make it fit in the AS 3.0 model of events, and to avoid what I must do now to get the current event handling behavior, which is to make the state class dynamic — I think one of the reasons I’ve put off doing a 3.0 port is that I hadn’t solved how to keep the event handling I like while sealing the state class.

The Current State of Things (No Pun Intended)

Currently, an event that comes into the main event handler routine (ieh, for internal event handler) is identified by a string, a value, and a pointer to who generated the event.  The main event handler has what I call a “trigger table” that converts the incoming event into an event that one or more states or transitions want to use to trigger a state-internal action or a state-changing transition. The trigger table processes an incoming event and filters it, essentially.

For example, an incoming event might be a certain button press, and a state or transition may be waiting just for that to happen, so there’s no real conversion.  However, a state or transition might be waiting for a knob to reach a certain value — that is an event derived from a subset of all events from that knob.  The effect is that the trigger table is used to convert an event name and value into a potentially new event that some of the states or transitions have declared they want to use to initiate actions or transitions (hence the term, “trigger”).

What has bothered me is how to convert to 3.0 the current way of declaring that states want to handle events. For example, if a state wants to execute something on a certain button press, we write

myState.someButtonPress = function () { ... }

I like this format because I think it is easy to understand. In the trigger table, we have added an entry like:

someButtonPress : function (m) { return (m == "button1"); }

which means that our specific button has sent an event in called “button1″.

Internally, the state doesn’t really keep a someButtonPress method — the internal processing adds a filter that says “if the conditions for someButtonPress exist, trigger the corresponding function”.

The problem from a 3.0 perspective here is obviously that the state class would have to be declared dynamic to permit “myState.someButtonPress”. That’s a big price to pay considering now that ActionScript has the real ability to seal a class (unlike in AS 2.0, in which it would be limited to compile-time checking).

Making States the 3.0 Way

So I like the idea of the trigger table — a mechanism for filtering events — but I want to avoid making the state class dynamic.  The best solution I’ve come up with is to make actions and transitions register as event handlers for states.  This is more involved than the original way, but it is consistent with the AS 3.0 event model, and it lets me keep states sealed.

For the example above, instead of (from above) myState.someButtonPress, we will write:

myState.addEventListener(SomeButtonPressEvent, function () { ... })

or

myTransition.addEventListener(SomeButtonPressEvent, function () { ... })

which are a bit more complex to look at, but I think in line with what we need to accomplish.  This still means I need a concise way to filter events and generate new ones (the trigger table processing), but I think that is manageable.

The results are in from the virtual trade show

I won’t leave my readership (perhaps my mother) hanging…our experiment was a complete success at the show.  Our booth was rated #1 (or very close to #1) of all the participating exhibitors, in categories such as unique visitors, time, user ratings, etc.  It was directly attributable to the interactive sims we had (don’t take my word for it — this was real feedback).

Visitor time in our booth was over 150% of the average time spent at a booth, except for the prize booth.  Also, we did a little experiment in which we modified our simulations from Day 1 to Day 2 and actually got real user behavior demonstrating how we can tune performance.  I think it was a resounding success from the data point of view, and now it is time to go to potential customers with these results.  Of course the virtual trade show is like a web site, and so a lot of what we observed in the show microcosm I think can be applied to web site behavior (of course we intend to measure that as well, and compare behavior).

We’ve been talking with manufacturers who are interested in more virtual shows (some are not interested, and some publishers we understand are not convinced about the virtual show value).  I can’t say I believe the virtual trade show is here to stay, but it does offer some interesting advantages over merely having a web site, and I think it’s a wonderful opportunity to leverage simulations.