State Machine

New releases and general discussions.

Post » Fri Jan 29, 2010 1:36 pm

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.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Fri Jan 29, 2010 9:59 pm

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")
Image Image
B
161
S
48
G
89
Posts: 7,347
Reputation: 66,249

Post » Sat Jan 30, 2010 12:55 am

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.
B
8
S
3
G
7
Posts: 835
Reputation: 5,313

Post » Sat Jan 30, 2010 1:03 am

David said its a beta, so be sure and test it out.
Image Image
B
161
S
48
G
89
Posts: 7,347
Reputation: 66,249

Post » Sat Jan 30, 2010 6:58 am

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.
B
9
S
2
G
3
Posts: 176
Reputation: 1,954

Post » Tue Feb 02, 2010 8:48 am

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.
B
16
S
8
G
4
Posts: 136
Reputation: 3,144

Post » Fri Feb 05, 2010 6:43 pm

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?
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Fri Feb 05, 2010 7:37 pm

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.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Sat Feb 06, 2010 9:49 pm

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
B
2
G
3
Posts: 20
Reputation: 890

Post » Sun Feb 07, 2010 12:16 am

[quote="StAtrill":1ohsimz6]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[/quote:1ohsimz6]

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.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 1 guest