# Differences

This shows you the differences between two versions of the page.

 gdevelop:tutorials:howtofinitestatemachine [2016/03/17 09:35]wendigo [Our first state “init”] gdevelop:tutorials:howtofinitestatemachine [2020/06/13 11:33] (current)rapperdinesh [Conclusion] Both sides previous revision Previous revision 2020/06/13 11:33 rapperdinesh [Conclusion] 2020/06/13 11:33 rapperdinesh [The “jumping” state] 2020/06/13 11:32 rapperdinesh [The “walking” state] 2020/06/13 11:31 rapperdinesh [The “idle” state] 2020/06/13 11:30 rapperdinesh [The “falling” state] 2020/06/13 11:30 rapperdinesh [Our first state “init”] 2020/06/13 11:29 rapperdinesh [Debugging information] 2020/06/13 11:28 rapperdinesh [Getting started] 2020/06/13 11:28 rapperdinesh [What is a state machine?] 2020/06/13 11:27 rapperdinesh [How to handle complex logic – The finite state machine (FSM)] 2016/03/17 09:35 wendigo [Our first state “init”] 2016/03/17 09:34 wendigo [Our first state “init”] 2016/03/17 09:33 wendigo [Debugging information] 2016/03/17 09:30 wendigo [Getting started] 2016/03/17 09:28 wendigo [Conclusion] - added project files zip2016/03/17 09:25 wendigo [What is a state machine?] 2016/03/17 09:23 wendigo [The “jumping” state] 2016/03/17 09:22 wendigo [The “walking” state] 2016/03/17 09:21 wendigo [The “idle” state] 2016/03/17 09:21 wendigo [The “falling” state] 2016/03/17 09:20 wendigo [Our first state “init”] 2016/03/17 09:19 wendigo [Debugging information] 2016/03/17 09:18 wendigo [Getting started] 2016/03/17 09:17 wendigo [Getting started] 2016/03/17 09:14 wendigo [Getting started] 2016/03/17 09:14 wendigo [How to handle complex logic – The finite state machine (FSM)] 2016/03/17 09:13 wendigo [How to handle complex logic – The finite state machine (FSM)] - image added2016/03/17 09:08 wendigo created - main text Next revision Previous revision 2020/06/13 11:33 rapperdinesh [Conclusion] 2020/06/13 11:33 rapperdinesh [The “jumping” state] 2020/06/13 11:32 rapperdinesh [The “walking” state] 2020/06/13 11:31 rapperdinesh [The “idle” state] 2020/06/13 11:30 rapperdinesh [The “falling” state] 2020/06/13 11:30 rapperdinesh [Our first state “init”] 2020/06/13 11:29 rapperdinesh [Debugging information] 2020/06/13 11:28 rapperdinesh [Getting started] 2020/06/13 11:28 rapperdinesh [What is a state machine?] 2020/06/13 11:27 rapperdinesh [How to handle complex logic – The finite state machine (FSM)] 2016/03/17 09:35 wendigo [Our first state “init”] 2016/03/17 09:34 wendigo [Our first state “init”] 2016/03/17 09:33 wendigo [Debugging information] 2016/03/17 09:30 wendigo [Getting started] 2016/03/17 09:28 wendigo [Conclusion] - added project files zip2016/03/17 09:25 wendigo [What is a state machine?] 2016/03/17 09:23 wendigo [The “jumping” state] 2016/03/17 09:22 wendigo [The “walking” state] 2016/03/17 09:21 wendigo [The “idle” state] 2016/03/17 09:21 wendigo [The “falling” state] 2016/03/17 09:20 wendigo [Our first state “init”] 2016/03/17 09:19 wendigo [Debugging information] 2016/03/17 09:18 wendigo [Getting started] 2016/03/17 09:17 wendigo [Getting started] 2016/03/17 09:14 wendigo [Getting started] 2016/03/17 09:14 wendigo [How to handle complex logic – The finite state machine (FSM)] 2016/03/17 09:13 wendigo [How to handle complex logic – The finite state machine (FSM)] - image added2016/03/17 09:08 wendigo created - main text Line 1: Line 1: ====== How to handle complex logic – The finite state machine (FSM) ====== ====== How to handle complex logic – The finite state machine (FSM) ====== - You probably followed some of the beginner tutorials and decided to create your own project based on the game mechanics you have learned. But as soon as you added more complex actions you quickly got lost in a jungle of nested conditions that lead to bugs which were hard to find. In the end you probably quit the project. + You probably followed some of the beginner tutorials and decided to create your own project based on the game mechanics you have learned. But as soon as you added more complex actions you quickly got lost in a jungle of nested conditions that lead to bugs that were hard to find. In the end, you probably quit the project. - Most tutorials you find on the internet (independent from the game engine) just try to show you a way to achieve the goal of that specific tutorial with least distraction possible. Unfortunately this usually results in code that doesn'​t care about extensibility. + Most tutorials you find on the internet (independent from the game engine) just try to show you a way to achieve the goal of that specific tutorial with the least distraction possible. Unfortunately, this usually results in code that doesn'​t care about extensibility. This tutorial will show you how to structure your project in a way that encapsulates the logic of your player (enemies or other dynamic objects). This tutorial will show you how to structure your project in a way that encapsulates the logic of your player (enemies or other dynamic objects). Line 9: Line 9: ===== What is a state machine? ===== ===== What is a state machine? ===== - As already indicated a state machine divides an objects ​logic into a fixed set of manually defined states that operate independently from each other. + As already indicated a state machine divides an object'​s ​logic into a fixed set of manually defined states that operate independently from each other. - Each State only contains the logic that is applicable to it. For example when the player is in “falling state” you neither have to check the buttons for left and right movement nor the jump button because there is no ground under your feet. + Each State only contains the logic that is applicable to it. For example, when the player is in a “falling state” you neither have to check the buttons for the left and right movement nor the jump button because there is no ground under your feet. To switch from one state to another you have to check if a specific condition is met. To switch from one state to another you have to check if a specific condition is met. - So lets pretend we were in “falling” state. While in the air we won't be able to perform any actions. We are just passively pulled downwards by gravity. + So let'​s ​pretend we were in a “falling” state. While in the air we won't be able to perform any actions. We are just passively pulled downwards by gravity. - In order to transit into another state certain conditions have to be met. In case of our falling state we would have to check if the player is in collision with the ground. If so we change the state from “falling” to “idle”. In “idle” state we check if a movement button is pressed which in turn would lead us to the “walking” state in which you keep on walking until some other event happens. ​You get the picture? + In order to transit into another state certain conditions have to be met. In the case of our falling state, we would have to check if the player is in collision with the ground. If so we change the state from “falling” to “idle”. In “idle” state we check if a movement button is pressed which in turn would lead us to the “walking” state in which you keep on walking until some other event happens. ​Do you get the picture? ===== Getting started ===== ===== Getting started ===== - So lets get started by downloading the assets from the “How to make a platformer game?” tutorial [http://​compilgames.net/​wiki/​doku.php/​gdevelop/​tutorials/​howtomakeeaplatformergame]. + So let'​s ​get started by downloading the assets from the “How to make a platformer game?” tutorial [http://​compilgames.net/​wiki/​doku.php/​gdevelop/​tutorials/​howtomakeeaplatformergame]. - Create a player as a “platformer object” and some platforms (“platform” behavior) to walk and jump on as described in the above mentioned tutorial. + Create a player as a “platformer object” and some platforms (“platform” behavior) to walk and jump on as described in the above-mentioned tutorial. {{ :​gdevelop:​tutorials:​finitestatemachine:​screenshot_scenes.png?​800 |}} {{ :​gdevelop:​tutorials:​finitestatemachine:​screenshot_scenes.png?​800 |}} Line 25: Line 25: Switch to the event editor ("​main"​ scene) and create these external events “player_state_init”,​ “player_state_falling”,​ “player_state_idle”,​ “player_state_walking”,​ “player_state_jumping”. Switch to the event editor ("​main"​ scene) and create these external events “player_state_init”,​ “player_state_falling”,​ “player_state_idle”,​ “player_state_walking”,​ “player_state_jumping”. - In the events of your main scene create a new event group from the drop down menu on the right hand side. Name it “Player logic”. + In the events of your main scene create a new event group from the drop-down menu on the right-hand side. Name it “Player logic”. - Now add a condition to check if the value of the player variable “state” is “init”. Add a sub event to the condition and link in the external event sheet “player_state_init” via the “add”/​”other” button. + Now add a condition to check if the value of the player variable “state” is “init”. Add a sub-event to the condition and link in the external event sheet “player_state_init” via the “add”/​”other” button. Do the same for all the other player states. Do the same for all the other player states. Line 32: Line 32: ==== Debugging information ==== ==== Debugging information ==== - In order to determine in which state the player currently is we will add a text object and call it “debug_state”. Add it to the main scene and create the following logic at the end of main scenes logic list in order to display the current player state right above it'​s ​head for debugging purposes. + In order to determine in which state the player currently is, we will add a text object and call it “debug_state”. Add it to the main scene and create the following logic at the end of the main scenes logic list in order to display the current player state right above its head for debugging purposes. So whenever something doesn'​t function the way we want we will always know in which state we have to look for the error. So whenever something doesn'​t function the way we want we will always know in which state we have to look for the error. Line 44: Line 44: Since we already set the condition about when to execute the code of the init state in the main scene events sheet we can leave out the condition here and just add actions. Since we already set the condition about when to execute the code of the init state in the main scene events sheet we can leave out the condition here and just add actions. - First of all we need to disable the default controls of the platformer behavior because these would get in the way when using a state machine. + First of all, we need to disable the default controls of the platformer behavior because these would get in the way when using a state machine. - Next we set the value of the player variable “state” to “falling”. + Next, we set the value of the player variable “state” to “falling”. - So in the next iteration of the game loop the events from the “falling” state will be executed. + So in the next iteration of the game loop, the events from the “falling” state will be executed. We choose the falling state here because the player was placed in the air and will eventually fall to the ground where we can transit into the idle state. We choose the falling state here because the player was placed in the air and will eventually fall to the ground where we can transit into the idle state. - You could also use this state to (re)set the players hit points, ammo or other things. If you decide to restart the level you can always transit back into the “init” state to reset the player attributes. + You could also use this state to (re)set the players hit points, ammo, or other things. If you decide to restart the level you can always transit back into the “init” state to reset the player attributes. {{ :​gdevelop:​tutorials:​finitestatemachine:​init_state_events.png |}} {{ :​gdevelop:​tutorials:​finitestatemachine:​init_state_events.png |}} ==== The “falling” state ==== ==== The “falling” state ==== - Falling is the most universal state of all. Whenever you are unsure which state to transit into “falling” state is usually a good choice because it will eventually lead into a sensible ​other state as soon as the player collides with an object. + Falling is the most universal state of all. Whenever you are unsure which state to transit into a “falling” state is usually a good choice because it will eventually lead to a sensible ​another ​state as soon as the player collides with an object. While falling the player won't be able to perform any active actions. He will only be passively affected by the forces that were applied to him before he entered the falling state. While falling the player won't be able to perform any active actions. He will only be passively affected by the forces that were applied to him before he entered the falling state. - For example if you enter the falling state after performing a jump you will still passively move in the direction you were jumping but you can't adjust the direction anymore. (see the exercises section at the bottom of this tutorial to change this behavior). + For example, if you enter the falling state after performing a jump you will still passively move in the direction you were jumping but you can't adjust the direction anymore. (see the exercises section at the bottom of this tutorial to change this behavior). So all we are doing in this state is to check if the player collides with the floor. If so we transit the player into the “idle” state. So all we are doing in this state is to check if the player collides with the floor. If so we transit the player into the “idle” state. Line 63: Line 63: ==== The “idle” state ==== ==== The “idle” state ==== - The idle state gets triggered whenever the person in front of the computer doesn'​t do anything. In other words no keys are pressed and the player object is just standing still. + The idle state gets triggered whenever the person in front of the computer doesn'​t do anything. In other words, no keys are pressed and the player object is just standing still. Like in the “falling” state there aren't any active actions to be performed. We just check for conditions that make us leave the “idle” state. Like in the “falling” state there aren't any active actions to be performed. We just check for conditions that make us leave the “idle” state. - So first of all we check if the player is on the floor. If not we transit into the falling state. + So, first of all, we check if the player is on the floor. If not we transit into the falling state. - Next we check if the player pressed the left or right arrow keys. If so we transit into the walking state. + Next, we check if the player pressed the left or right arrow keys. If so we transit into the walking state. Last but not least the up arrow key is checked and if pressed we switch the player to the jumping state. Last but not least the up arrow key is checked and if pressed we switch the player to the jumping state. - Sounds logical doesn'​t it? + Sounds logical, doesn'​t it? {{ :​gdevelop:​tutorials:​finitestatemachine:​idle_state_events.png |}} {{ :​gdevelop:​tutorials:​finitestatemachine:​idle_state_events.png |}} ==== The “walking” state ==== ==== The “walking” state ==== - In the walking state we finally get to integrate some active actions for our player ​to perform. + In the walking state, we finally get to integrate some active actions for our players ​to perform. Since we use just one state for walking to the left and for walking to the right we first have to determine the direction the player has to move. So we check again which key was pressed and set the direction variable of the player accordingly once when entering the walking state. Since we use just one state for walking to the left and for walking to the right we first have to determine the direction the player has to move. So we check again which key was pressed and set the direction variable of the player accordingly once when entering the walking state. - After that we will make the player move in that direction as long as it is in the walking state. + After that, we will make the player move in that direction as long as it is in the walking state. Now that the player is able to walk we'll again get to the conditions that make him leave the current state. Now that the player is able to walk we'll again get to the conditions that make him leave the current state. So what could happen while we are walking? So what could happen while we are walking? - The most obvious thing would be that the walking key is released. In that case we will transit into the “idle” state. + The most obvious thing would be that the walking key is released. In that case, we will transit into the “idle” state. If we walk over the edge of the current platform we transit into the “falling” state. If we walk over the edge of the current platform we transit into the “falling” state. And if the jump key is pressed we switch into the jumping state. And if the jump key is pressed we switch into the jumping state. Line 88: Line 88: As you may have guessed, the first thing we will do is triggering the jump action once we enter the state. The force will be applied passively so we don't have to worry about it anymore once we performed the jump. As you may have guessed, the first thing we will do is triggering the jump action once we enter the state. The force will be applied passively so we don't have to worry about it anymore once we performed the jump. As always the last thing we need to do is find conditions that make us transit into another state. As always the last thing we need to do is find conditions that make us transit into another state. - In this case we will check if the player is either not jumping or falling. If this is the case the player gets transferred into the “falling” state. + In this case, we will check if the player is either not jumping or falling. If this is the case the player gets transferred into the “falling” state. {{ :​gdevelop:​tutorials:​finitestatemachine:​jumping_state_events.png |}} {{ :​gdevelop:​tutorials:​finitestatemachine:​jumping_state_events.png |}} Line 97: Line 97: We have now split up the player logic into five different states which only handle the logic that is applicable to them and nothing more. We have now split up the player logic into five different states which only handle the logic that is applicable to them and nothing more. - If you want your player to gain additional abilities like flying, diving, ​dieing ​or getting smashed against a wall just create a new state and handle the logic there. + If you want your player to gain additional abilities like flying, diving, ​dying, ​or getting smashed against a wall just create a new state and handle the logic there. You can download the whole project here. You can download the whole project here.