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.

Not enough dials and switches. You need more dials and switches if you want to go pro sound.

Hey, we need the bacteria to survive. Beneficial bacteria and all that in our intestines.

Destroy the animation once it is finished.

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.

Is it in Construct? If so, it better not be something major right off the bat. I'd suggest starting with a barebone prototype to get the feel for Construct and allow for instability and fixes as it comes out of beta.

Yeah, I guess people who know Python prefer to develop games with Pygame and stuff, since it gives them more freedom.

Also, why do I have the feeling of deja vu? I'm sure I've said a similar statement somewhere on these forums...

Nooooo! They stole my dog!

Sorry, I didn't mean to ask that in an aggressive manner, it just seemed weird that you were asking all those questions. What would you think if someone asked you the same questions? I just wanted to know why you were interested in my name.

And yes, our people come from the same roots, which is why there are so many similarities between our languages (Dober Dan, Dobri Den etc.) as well as names, though most of names have older origins (Miha is a form of Mihael, which is obviously an ancient name).

Then again half the Europe is Slavic, so hardly surprising.

The first one. Why? Are you stalking me?

Miha. Slovenian.

If Score % 20000 = 0

What if you are at 19999 points and gain 10 points? It skips over 20000, which means the above condition is only run if you hit exactly 20000, 40000 or 60000 score.

If the score doesn't decrease, I'd suggest something like this:

+ if Score/20000 > var

Lives = Lives +1

Var = Var +1

What does this do? Well, it tracks how many times you gained life by scores! When you hit 20000 score for the first time, the above condition is true since var = 0 at the start and Score/20000 = 1 > 0. Once the event is processed, it also increases var by 1, so that it won't run again until you pass the next milestone.

Meanwhile, you can abuse lives all you want!