### Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

### Messages - gazugafan

Pages: 1
1
##### Ask a Question / Re: Finite State Machines Tutorial?
« on: January 18, 2020, 02:11:42 pm »
Did you download my example, try it out, and look through the code? If not, download the .stencyl file, import it, and then create a new game based on it...
http://community.stencyl.com/index.php?action=dlattach;topic=54586.0;attach=56467

I think my post did a decent job explaining how to use it. For exactly how it works, check out the code in the State Machine behavior. The details are maybe a little complex, but the basic idea is that the State Machine behavior contains a stack of states (actually, one stack of states for each state machine), and each state corresponds to a behavior. The State Machine behavior is then responsible for ensuring that ONLY the behavior corresponding to the active state (the one at the top of the stack) is enabled, and all of the other behaviors corresponding to inactive states are disabled. It also triggers enter and exit events whenever a state change occurs. I think it's pretty elegant!

2
##### Shared Resources / Re: Finite State Machine Platformer
« on: September 15, 2017, 10:40:10 pm »
Appreciate the kind words, @liberado. Glad you like it!

3
##### Shared Resources / Finite State Machine Platformer
« on: September 07, 2017, 08:36:18 pm »
Have you ever had trouble managing how your character can transition into different states? Can a ducking character wall jump? Can a jumping character duck? If you've been tackling these problems with lots of flags and if statements, you might want to give finite state machines a look!

It sounds complicated, but a finite state machine is basically just an object that can be in a single state at a time... like jumping, falling, walking, etc. As the object transitions between states, enter and exit state events are triggered. When the jumping state is entered, for example, you would probably want to start the jumping animation and play a jump sound effect. You could even have an object with multiple state machines. Maybe another state machine for whether you're holding an object, throwing an object, or without an object? Maybe another state machine for who is controlling the character--a script, AI, or the user?

In this implementation, you simply attach the "State Machine" behavior to an actor, and specify a list of state machines that the actor will have, along with a list of the different states each machine can be in. For example, the "Movement" state machine might be able to be in an Idle, Walking, Jumping, Falling, or Ducking state.

Each state corresponds to a behavior.  If you list "Walking" as a possible Movement state on your character actor, for example, your character actor must also have a corresponding "Walking" behavior. All the listed states (behaviors) are disabled by default, except for the first one listed. This is the default starting state. The order you list the states is otherwise unimportant.

From here, you can call a few different methods on the State Machine behavior to change what state the machine is in--thereby activating the new active state (behavior) and disabling the previous one. Only one state (behavior) will ever be active at a time for each state machine. The methods for changing state are...

Change State: Replaces the current state of a machine with a new one.
Add State: Adds a new state to the top of a machine's state stack--changing to the new state.
Remove State: Removes the state from the top of a machine's state stack--restoring the previous state.
Reset State: Clears a machine's state stack--resetting the machine back to its default state.

Whenever a state change occurs, an "ExitState" event is triggered on the previous behavior (the one that's about to be disabled), and an "EnterState" event is triggered on the new behavior (the one that's about to be enabled). You can handle these events in your state behaviors to play animations and other setup/teardown procedures.

The attached example is a complete rework of the original Jump and Run Kit. It comes with a few other noteworthy things...
An animation queue allows you to easily queue up animations. For example, when a character lands on the ground, you could queue up a landing animation that plays once, followed by the idle animation.
A control translator that allows control of an actor to be switched (from user input, to a script, or AI, etc) at runtime.

It might look a little complicated at first glance, but once you wrap your head around it I think you'll find it's a much more manageable structure for large projects. The project I wrote this for is stagnant now, but hopefully someone else will find it useful!

Pages: 1