|
Boost : |
Subject: Re: [boost] [MSM] Single event, multiple orthogonal submachines
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2012-05-23 16:58:25
> I'm trying to deal with having multiple orthogonal submachines that
> process one event containing data. I have a contrived example that
> hopefully conveys the issue. Suppose I am hoping to create a state
> machine "Game2D" with a set of orthogonal submachines that guard
> certain transitions based on each other, and I would like some events
> to be processed by multiple submachines.
>
> Parent Machine:
> Game2D
>
> Event:
> CharacterStatus - contains character position and velocity
>
> Submachines:
> IsMoving - changes state based on CharacterStatus
> CorrectPosition - updates position based on CharacterStatus
> CharacterStatusUpToDate - times out to an error state if
> CharacterStatus hasn't been received for a while
> EnemyAlive - doesn't process CharacterStatus
> RunSystem - guards some transitions based on the state of IsMoving
>
> Since some, but not all of these submachines needs the
> "CharacterStatus" event, what is the best way to make sure they all
> get it when I call Game2D.process_event(CharacterStatus)?
You don't need to do anything. If every submachine is in its own orthogonal
region, then MSM gives each of them a chance to process the event (in the
order defined by your initial_state typedef). And if some are not
interested, nothing bad happens, only the interested regions will process.
> I want to be able to reuse these pieces, and keep things as simple as
> possible. Does this seem like an ok approach? Should I simply have a
> state "UpdateCharacterStatus" that directly updates each of these
> objects then creates an event to transition away, or something else
> entirely?
I think you're doing it right. If you also provide a MSM flag in isMoving,
you'll be able to check its status in RunSystem.
The only thing is that submachines are compile-time-intensive. If it becomes
too bad, you might have to switch to regions without submachines. They won't
be reusable but otherwise they'll do the same job.
> Cheers!
> Andrew Hundt
Cheers!
Christophe
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk