State Machine

Finite State Machine is something that would trivialize several of major game development paradigms, which all projects could benefit from. Of course implementation with events and stuff is possible, however it basically would mean reinventing the wheel for each project.

So a FSM plugin would be a welcome addition to Construct.

How should it work? Here are a few concept ideas:

a) Behaviour. Simply add FSM behaviour to an object, thus all of the object's transitions would be handled in a simple way. In event sheet we'd have access to defined transitions.

Example: Sprite with FSM behaviour

OnStart, OnStop, Walking, Standing

OnStart and OnStop are custom names for triggers, accessible within event sheet. They would act just like any triggers. Walking and Standing are current states, which could be checked in conditions somewhere.

b) Non-Layout Object. Sometimes a pure FSM is needed to handle more complex transition trees. Some states may not necessarily relate to objects. In this case, transitions and triggers could be accessed globally without having to pick the specific object up.

Example: FSM Object

OnGameStart, OnGameOver, OnPause, Paused etc.

I leave further technicalities to more knowledgeable. There is no doubt, however, of usefulness of such a plugin in Construct projects. It would reduce much of clutter.

I know we'll call it the wait object.

+ Wait: My condition {"sprite"}

-> Sprite: Set opacity to 0

+ Sprite: X Equal to 0

-> Wait: Example action ("sprite")

When did the "Wait" object sneak into Construct?? lol.. I didn't even know it was there. Wait isn't as powerful as a Finite State machine (although maybe you could create one with a bunch of Waits and other conditions). I think Mipey's point is to reduce the clutter of combining a bunch of actions and conditions to equal an FSM.

David said its a beta, so be sure and test it out.

FSM, now what does that remind me of... Oh yeah Max Payne, I don't know what does this do to Construct but from what you wrote it should make things easier.

I guess I'm sorta using a form of FSM for my character animation... I have a single variable called animstate, and then I just run events like "If animation != animstate -> Change animation to animstate" and then I have events like "When animation raiseweapon finished -> set animstate to weaponraised".

It does make handling animations in the events quite easy.

Would there all the states be hard coded or would the user be able to define a new state and check if that state was on and off? And if the user can define a state would they define it via an action or in the edit time?

For the behavior same thing would the user define states and if so how would they define the states?

States should be definitely customisable.

How? No idea. Runtime is surely possible, but edittime.... I am not clear on the extension mechanisms of Construct's IDE.

Why would hard coded FSMs even be necessary when there is an unlimited number of vars available to you to use to track states?

And as an idea for those who cannot adapt the idea of an FSM to work in construct as is, you can always place all the different states in groups and activate/deactivate as necessary according to the number stored in a var.

Why overcomplicate the simple? Streamlined happens to be a formula that works. I would hate for Contruct to turn into bloatware because of pointless requests like this...

/my two cents

Why would hard coded FSMs even be necessary when there is an unlimited number of vars available to you to use to track states?

And as an idea for those who cannot adapt the idea of an FSM to work in construct as is, you can always place all the different states in groups and activate/deactivate as necessary according to the number stored in a var.

Why overcomplicate the simple? Streamlined happens to be a formula that works. I would hate for Contruct to turn into bloatware because of pointless requests like this...

/my two cents

its not hard coded FSM you would define your own states and turn those states on and off as you please. Construct is a giant FSM. If this -> do this. Which is almost exactly what a FSM does. What I think people are actually asking for here is a Boolean type value that is either on of off. Or triggers once and then never runs again. and it wouldnt be bloat because you have the choice to install the plugin if its made we dont force you to install plugins at knife point.

Construct is a giant FSM. If this -> do this. Which is almost exactly what a FSM does.

.. not exactly the same.

[quote:3ap1k3mg]What I think people are actually asking for here is a Boolean type value that is either on of off. Or triggers once and then never runs again.

Nope, not at all.

That said, you CAN make a FSM in Construct, it's not hard at all, just harder to read and mantain (state name typos, for example).

• Use a global var to hold the state
• compare the status var to check for the current state.
• when changing the state, you directly change the value of the var.
• for On Enter State patrolling, you would do this instead: + System: Trigger once + System: global('state') Equal to "patrolling"
• for On Leave State patrolling, you would have to either use a function objects or copy all the actions to each of the events that may change the state to another one.

Sure, it is easy, but it is also tedious and I use it in nearly every project. It would cut a lot of development time down if there was a plugin for that.

Moreover, I'd also like to have more or less independent FSM cells (one for each AI entity). It is easy to design AI using state machine, however in current form it is very tedious. Then some state machines run in parallel, so they shouldn't interfere with each other. For example game and GUI states, if you only use one global for states, as soon as you change the state, say open a game menu, there is a risk of breaking the game context.

What I want is a FSM plugin that would allow me to create independent enclosed machines or one big huge tree of states, whatever suits the purpose. It would also make managing events easier - when your caveman is hungry, he goes to hunt, thus activate Hunt state machine which handles hunting procedure. As soon as it finishes, it returns to whatever the player was doing before hunting. Then there'd be interrupts, such as spotting a lovely cavewoman, then Romance state machine is invoked. Some interrupts would stop the current procedure altogether or just pause it and resume after the interrupt is completed.

That's a lot of code to do.

Aeal5566 wrote:Construct is a giant FSM. If this -> do this. Which is almost exactly what a FSM does.

... not exactly the same.

I didn't say it was exactly the same but essentially that is what construct is and I even said that. read posts before you reply.

What I think people are actually asking for here is a Boolean type value that is either on of off. Or triggers once and then never runs again.

Nope, not at all.

Again if you read the original post mipey gave examples of what he wanted.

OnStart, OnStop, Walking, Standing

OnStart, OnStop are triggers and he also gave the examples of StartofLayout start of game. The start and stop would trigger when there was a state change but essentially walking and standing are Boolean values that are either true or false, and when the value changed you would would call the trigger. and instead of just saying something like "nope not at all" actually contribute something to the topic, we know you can make a state machine in construct we were talking about what a plugin would look like for it.

Now mipey

can you answer some of my questions about how states are defined. Are they runtime edittime etc.

I'm yet to be convinced what the fuss over finite state machines is. A concrete example showing how useful a .cap designed this way would be would help persuade me. Right now I can't see any benefit over the usual event system.

Edit time, I guess; states would be part of the engine, which is not altered in runtime. We'd have to define the state machines in edit time. There is no point in altering the state machine in runtime (at least none that I can see right now). Basically create sprites, families, stuff, then create state machines, maybe object or family specific, maybe free (to handle transitions, slideshows or whatever).