Hi mates, I made some test for a state machine and for my surprise I ended with something that may be intresting for some users a simple state machine thats include a 3 combo attack.
idle
walk
jump
fall
attack_1
attack_2
attack_3
air_attack_1
air_attack_2
air_attack_3
dash
I’ve also post a mini tutorial here
A playable demo here itchio here
Source code: here
Oh! by the way it’s MIT Lisence so you can use the code in any project you want, just note the hero asset must be attributed to his creator, the link for the hero asset plus a lot of other animations are included there.
This could be done in a lot of ways, is up to the game develpoper to decide.
The basic is to add a little square Sprite when the player attack and then check if that Sprite collides with other object, could it be an enemy or destructible or anything.
Thanks for sharing the project source, Ulises! It will be handy for my future reference in my games. There is a lot of good ideas in there.
For your example to be added to the GDevelop base, it will need a bit of clean up, I guess. There are unused elements in your project, like obj_floor_colision for example.
Also, to be added to GDevelop examples list, it has too many functionalities in just one place. Consider breaking it in smaller examples, for each purpose individually, like:
Code example 1: Platform movement - dash with smoke trail effect
Code example 2: Platform movement - sliding by walls
Code example 3: Platform control using the GAMEPAD extension
Code example 4: Finite state machine - platformer combo moves
For the Finite State Machine logic, instead of using one a 0/1 variable for each state like you are doing, have you considered using one single variable to manage the player multiple states? Like this:
gs_player_state = "by wall left"
gs_player_state = "by wall right"
gs_player_state = "jumping"
gs_player_state = "moving"
gs_player_state = "attacking"
One little last thing, you misspelt the variable name gs_jump_count.
I’ve been doing FSM by using animations, but can already see some longterm issues that I might clean up by switching to a single state variable as mentioned above.
A few questions:
You have some variables/events set up to detect the walls.
Any reason why you went that way instead of having your platforms in a “Platform” object group and using “Is in collision with PlatformGroupname”, your jumping state, and “is object horizontally flipped”?
I’ve currently ended up making each of my states be wholly separate external events that only get loaded if the condition for the state is met. It also means I have ~13+ external event sheets. I originally did this because this was how the FSM tutorial on the wiki showed to do it, but then I kept it because it made me think “This way there can be no false state triggers/conflicts between transitions”.
Have you seen any conflicts from having them all on the one sheet at all?
Questions: please when you add questions try number lists it’s easy to answer.
1 - Walls are in groups, it’s done like that because is easy to integrate other sprites to act as walls, the variables created just to ensure the collision. I couldn’t find a better way to do this, note I’m total noob in GDevelop.
2 - 1 event sheet or 20 event sheets, is the same if the code works, it’s ok no?
3 - Some of the animations, triggers again when try to limit the attack number.
When I have some time i will remake the state machine to just one variable, right now I’m with A Pixel Adventure Legion and is a lot of work to do there.
Thanks for the info. Either way, I think it’s really clean and a fine alternative to the FSM tutorial on the wiki. Once I’m done with (slowly) doing my save system, I might redo my FSM to something similar and test out the results.
Instead of using forces which comes with many issues with the platformer behavior, I used (Change X position with time delta)
I also disabled the platformer behavior when dashing so it doesn’t get affected with gravity or any other aspect of the platformer behavior.
Now you can dash Horizontally and the dashing feels 10 times better and much more consistent.
2- Second issue: clipping through the walls
So using forces or making changes to the X position result in clipping through walls and many other issues.
What I did was very simple, when the player is in collision with the walls, stop the dashing.
Now the player don’t clip through any walls and everything is fine.
Hi the first line centers the camera on player the secon line is used to limit the camera so the camera is not going further than obj_camera_limit in order for this to work you need to add a sprite called obj_camera_limit to the bottom right of your level if you don’t want to use a sprite you need to calculate where your level ends.
For instance my level is 3200x960 so I place the camera end at the right bottom of the level.
I’m sorry but I still don’t understand.
Given that you program in GD better than me (your code is very clean), if we removed the first command ( centers the camera on player), would it change anything?
