Help with a state machine double jump

[downtoknight]

Godot Version

4.7

Question

Currently working on getting a better understanding of state machines and finally got one to work. Now that I have a better grasp though, I’m trying new things in it and I’ve hit a small roadblock as I can’t discern what is keeping the double jump from working? So any help with that would be appreciated!

if there’s any pointers or suggestions as well on how this could be cleaner or better done, I’d greatly appreciate that as well, thank you!

# Available states
enum States {idle, walk, sprint, jump, doublejump}

# Conditional variables
var can_double_jump = true
var can_sprint = true

var walk_speed = 400
var sprint_boost = 0
var jump = -400.0

# Track current state
var active_state = States.walk

func _physics_process(delta: float) -> void:
	if not is_on_floor():
		velocity += get_gravity() * delta
		
	var direction := Input.get_axis("move_left", "move_right")
	
	match active_state:
		States.jump:
			var jump_count = 0
			var jump_max = 0
			
			if can_double_jump == true:
				jump_max = 1
			
			velocity.y = jump
			
			if is_on_floor():
				active_state = States.walk
				jump_count = 0
			if  Input.is_action_just_pressed("jump") and can_double_jump == true:
				active_state = States.doublejump
		
		States.doublejump:
			velocity.y = jump
		
		States.walk:
			if direction:
				velocity.x = direction * (walk_speed + sprint_boost)
			else:
				velocity.x = move_toward(velocity.x, 0, walk_speed)
			
			if Input.is_action_just_pressed("jump") and is_on_floor():
				active_state = States.jump
			if Input.is_action_pressed("Sprint"):
				active_state = States.sprint
		
		States.sprint:
			if direction:
				velocity.x = direction * (walk_speed + sprint_boost)
			else:
				velocity.x = move_toward(velocity.x, 0, walk_speed)
				
			if Input.is_action_pressed("Sprint") and can_sprint == true:
				sprint_boost = 200.0
			else:
				sprint_boost = 0
				active_state = States.walk
			
			if Input.is_action_just_pressed("jump") and is_on_floor():
				active_state = States.jump
			
	
	move_and_slide()

[baba]

			if  Input.is_action_just_pressed("jump") and can_double_jump == true:
				active_state = States.doublejump

I belive that the problem here is that you go straight to double jumping when you enter the jump state. Your can_double_jump is true so whenever you enter jump state, it switches to double jump state on the same or next frame.

Add a condition to make a normal jump and then a separate elif for the double jump. But i would do this in _unhandled_input(), because i believe the problem right now is that you use the same input twice. Once to enter jump, once to enter double jump.

To make the script cleaner, either get rid of all of these bools or get rid of the state machine. “can_jump”, “can_double_jump”, “can_run” etc are not needed if you have a state machine. If you are in jump state you can double jump. You don’t need a bool to track it. Likewise, if you have the bools, you don’t need the state machine. The bools create a simple state machine by themselves. Having both just forces you to keep track of both state machines and make sure they are in sync. It will be harder to expand upon, debug, understand etc. Choose one of the two. Unless these are bools for upgrades or skills you learn throughout the game?

Also, use typed variables. It will make life easier for you. You will get autocomplete suggestions in the editor, you will get error messages if e.g. you try to assign a vector2 to a float. Bugs will be easier to find and fix, and the code will be easier for you to read and understand later.

[downtoknight]

That makes a lot of sense that that’d be the issue, my thinking was since double jump was only accessible by going through through jump, that it would wait to take another input. But that makes sense it would just go straight through since nothing is exactly stopping it from doing so ha

How would you write that out using _unhandled_input()? I read up on it and it makes some sense, but wasn’t able to find any concrete examples or visualize it myself, if you wouldn’t mind giving an example!

With the bools they’re for skills you’d get throughout the game, was really just messing around to see how to get something like that to work and was later going to mess further on how to connect them to objects you’d collect to then change the bool to true/false; which I assume would be best done with signals at the moment.

and got it with the variables, that makes sense. I’ll get those adjusted, thank you!

[baba]

Before trying to fix anything, i would make sure that the problem is what we believe it is. For example by adding a print in double_jump. print(“double jumping”). If it shows up when you should only be normal jumping, the issue is that the state instantly passes from jump to double jump. If it doesn’t show up, the issue is something else.

Some other ideas on what to do to clean it up.

@downtoknight

match active_state:
		States.jump:
			var jump_count = 0
			var jump_max = 0
			
			if can_double_jump == true:
				jump_max = 1
			
			velocity.y = jump
			
			if is_on_floor():
				active_state = States.walk
				jump_count = 0

I would get rid of almost all of the above. jump_count kind of tracks how many times you have jumped and can. But you never use it for anything. And the information is there anyway. For example if state is jump, jump_count must be 1. If you haven’t jumped once, you would not be in jump state, and if you have jumped more than once you are in double jump state. Same for jump_max. can_double_jump being true already means that you have a +1 to maximum number of jumps, without you needing a separate variable to track it. If you try to reuse variables like this, it will make it a lot easier to keep all of your variables in sync.

Same with sprint boost. You always apply it, no matter if you are sprinting or not. The difference is that you change its value back and forth depending on if you are sprinting or not. Adding 0 as a sprint boost when walking is just a more convoluted way of doing nothing. I would just keep sprint boost permanently set to 200 and never apply it unless i am in a state where i want to apply it. Again, right now it is easy to see how it works and figure it out, but add some more features and make it a bit more complicated, and suddenly you will end up in a mess in a few months, where sprint_boost is never set back to 200 after leaving sneak state or whatever, and you will have forgotten how sprint_boost was meant to work as time has passed.

[downtoknight]

Did the check and it seems the issue is actually something else, since it never prints it reaching the double jump state. I did an additionally check too putting a print under the input action meant to put you into double jump, and that doesn’t print anything either. So it seems to not be noticing the input at all(?)

For the extra variables those were there since I was eventually going to switch over from is_on_floor to jump_count < jump_max as a check instead, just hadn’t situated it yet since I wasn’t sure if there was a better way to write the if statement out. Unless it really would just be
if Input.is_action_just_pressed(“jump”) and can_double_jump == true and jump_count < jump_max:(something along these lines anyway)
Which doesn’t seem correct even though it would theoretically get the job done, but I could be wrong. True though that at the moment they’re just not needed since nothing uses them in the current state of the code ha

Sprint boost I did adjust to what you suggested though and you were super right on that ha, I didn’t realize how redundant a bit of the code was there so I appreciate that note a lot thank you.

[baba]

@downtoknight

	match active_state:
		States.jump:
			var jump_count = 0
			var jump_max = 0
			
			if can_double_jump == true:
				jump_max = 1
			
			velocity.y = jump
			
			if is_on_floor():
				active_state = States.walk
				jump_count = 0

OK, in that case I believe the issue is this. You enter jump state, but already during the next frame, before you call move_and_slide(), you check if on_ground() which will be true. You are in jump state but have not yet left the ground. Then you instantly reenter grounded state, but your velocity.y is still set to jump since before the state change - so you jump even though you are in walk state?

It seems a bit weird if this would be the problem but i’m kind of sure it is.

I would say that you are making some things a bit complicated for yourself. Asking about how to clean the code up, i found some small quality of life suggestions, but the biggest thing would perhaps be to split this chunk up into several separate functions and call them in the order you need them. Right now, here you have a block of code that manages switching between states and the processing of the states. It’s easy to end up with weird problems if then at some point you switch the state a bit earlier or later than you should.

if you create a function like this it would make it easier for you:

func _physics_process(delta: float) -> void:
	set_state()
	apply_state()
func set_state():
	#match the state you should be in and switch between states here.
func apply_state():
	#match the state behaviour

I would also start changing between states using a change state function. It makes it a lot simpler to debug. I use one that prints whenever i change state. I mostly leave the print commented out with a # but sometimes for debugging i just remove the # and get prints like “changed from IDLE to DOUBLE_JUMP” and can quickly see that OK that’s where the issue is.

func change_state(new_state):
	if new_state != active_state:
  		#print("Changed state from %s to %s" % [States.find_key(active_state), States.find_key(new_state)])
		active_state = new_state

If you use this, you would just write change_state(States.idle) instead of active_state = States.idle

[downtoknight]

That would be weird but does?? seem like it’d be the problem at this point… Tried to fiddle with it a bit further with that in mind but still couldn’t get it to work, so chose to move on and attempt with the functions you suggested. Which after a few mistakes I did get it to work for the most part and this is genuinely a lot less complex and easier to read, assuming I set it up mostly right ha!

Yeah most of what I’m making right now is probably more complex than it needs to be, I’m still pretty new to GDScript and code as a whole, but this is helping a lot I appreciate it greatly. getting my mind more open to how flexible this stuff really is lol

This is what I currently have now with the new stuff implemented. The only things I’m having a problem with now are where I should calculate gravity, if I put move_and_slide() in the right place, and considering how to keep left/right movement available while in the jump states (unless you simply include the direction calc in the jump state along with velocity.y = jump) since I noticed once you’re in it you just are stuck at whatever angle you were going at while moving ha

With gravity specifically I’m mostly uncertain since I’d assume in the apply_state function, but since apply_state doesn’t have delta in it’s prams it doesn’t like it and I don’t have the knowledge to know how it’d be done differently. Did put it in _physics_process once just to see if the jump/double jump was recognized and can at least say it is now HA just with the side effect of once you’ve jumped you will simply go flying off into space.

extends CharacterBody2D

# Conditional variables
var can_double_jump = true
var can_sprint = true

var walk_speed = 400
var sprint_boost = 600
var jump = -400.0

# Available states
enum States {idle, walk, sprint, jump, doublejump}

var active_state = States.walk

func change_state(new_state): 
	if new_state != active_state:
		print("changed state from %s to %s" % [States.find_key(active_state), States.find_key(new_state)])
		active_state = new_state


func _physics_process(delta: float) -> void:
	if !is_on_floor():
		velocity += get_gravity() * delta
	set_state()
	apply_state()


# match the state you should be in and switch states
func set_state(): 
	match active_state:
		States.walk: # walk state and where it can go
			if Input.is_action_just_pressed("jump") and is_on_floor():
				change_state(States.jump)
			if Input.is_action_pressed("Sprint") and can_sprint == true:
				change_state(States.sprint)
		
		States.sprint: # sprint stte and where it can go
			if Input.is_action_just_pressed("jump") and is_on_floor():
				change_state(States.jump)
			if !Input.is_action_pressed("Sprint"):
				change_state(States.walk)
		
		States.jump: # jump state and where it can go
			if Input.is_action_just_pressed("jump") and can_double_jump == true:
				change_state(States.doublejump)
			if is_on_floor():
				change_state(States.walk)
		
		States.doublejump: # double jump state and where it can go
			if is_on_floor():
				change_state(States.walk)
	
# match the state behavior
func apply_state():
	match active_state:
		States.walk: # walk state behvaior
			var direction := Input.get_axis("move_left", "move_right")
			if direction:
				velocity.x = direction * walk_speed
			else:
				velocity.x = move_toward(velocity.x, 0, walk_speed)
		
		States.sprint: # sprint state behavior
			var direction := Input.get_axis("move_left", "move_right")
			if direction:
				velocity.x = direction * sprint_boost
			else:
				velocity.x = move_toward(velocity.x, 0, sprint_boost)
		
		States.jump: # jump state behavior
			velocity.y = jump
		
		States.doublejump: # double jump state behavior
			velocity.y = jump
	
	move_and_slide()

also realized while typing I could probably have the direction var in the apply_state function so it doesn’t need to be duplicated in both walk and sprint state but regardless of that; It definitely is to start a lot more legible, thank you

EDIT: did some further messing around to try and figure stuff out myself
added delta to the prams of apply_state, realized why it didn’t like it was me not adding it to the use of apply_state in change_state (oops lmao), so I have the gravity calc + move_and_slide() in apply_state now
then added a if !Input.is_action_just_pressed(“jump”) to the jump state in set state, and that now has it all working Not sure if it could be done better or differently though so still curious! but wanted to note I got it working fully in some way (plus that fixed the movement issue from above HA)

[baba]

Yes, i forgot to add delta as an argument! Anyway, everything worked out. Hopefully this will save you some headaches in the future. If any questions pop up don’t hesitate to ask.

For your question about direction, gravity and stuff like that, that you will almost always have to process or check in some way, if will often keep them separate from the more specific state stuff in tiny functions after setting the state but before applying.

func direction():

     if state not in [States.KNOCKED_OUT, States.FROZEN]:
          # do the direction stuff
func gravity(delta):
     if !is_on_ground() and state not in [States.LEVITATING]:
          # do gravity stuff

It makes it easier to try to separate some of these things that almost all states have in common, so you don’t have to use to same line of code in a lot of places to add gravity when jumping, when double jumping, when in coyote time, when in knockback state after getting tackled etc. And if you would need to change something later, so that for example gravity doesn’t apply during knockback, you just add knockback to the array next to the check in func gravity.

Maybe i should share my final state machine suggestion too, if you have not yet had enough of my state machine conventions.

[downtoknight]

Already saving a huge headache right now ha. Will do as well which I already have some LMAO

With the direction/gravity stuff, how do you go about having them run after setting but before applying? I’ve done a few attempts on my own with what you gave me to problem solve, I’ve gotten a few things to work! but not sure in the intended way lol. Current attempt I have the functions set at the top right above _physics_process(), then called in the _physics_process() between set and apply… which does at least apply the gravity, but nothing for direction.

Just incase it’s what I put in the direction function that’s the issue what’s currently there is this

func direction():
	Input.get_axis("move_left", "move_right")

Which is then called in the states that need it like this

States.walk: # walk state behvaior
			if direction():
				velocity.x = direction() * walk_speed
			else:
				velocity.x = move_toward(velocity.x, 0, walk_speed)

still contemplating on how it’d get adjusted, but have hit a small wall with solving it.

unless with the ‘do the direction stuff’ it’s just putting “velocity.x = direction() * walk_speed” there, and then calling it in the state behavior? (though that wouldn’t work without changing how sprint works, or using a variable that changes like state_speed which direction then takes??? though that seems like overcomplicating it maybe lol) just to get my thought process down heh.

Would love to hear your other suggestions though, state machines have been my biggest wall to get over so getting this much of a grasp around it has been extremely appreciated.

[baba]

@downtoknight

func direction():
	Input.get_axis("move_left", "move_right")

The problem is you don’t set the direction anywhere, you just get an axis but don’t store it anywhere. You should add "direction = " before “Input.get_axis(“move_left”, “move_right”)”. And somewhere outside of the function in script wide scope, you should have the variable declared, so you can access it from any function.

My other thought for what to add to simplify is to when you match in apply_state(), is to have a function as the match, instead of all the state behavior. Example with only walk:

@downtoknight

func apply_state():
	match active_state:
		States.walk: walk_state(delta)

func walk_state(delta):
	Add the walk state code

I think having a separate function for each state makes it easier to focus on the one you are focusing on at the moment. Easier to debug too. And lets say in some time you will have nine states and throughout the script you check if state == States.jump etc in lots of different spaces. Then if you try ctrl+f to find States.jump to change or double check something, you will end up in all of these different places where you just do checks and changes. Just ctrl+f “func jump” or “jump_state(” will always lead to the right place instantly. It may sound tiny but in a big script with many different states it will make life a lot easier. I.m.o! I at point got so fed up with the ctrl+f:ing in a big script that I started using a separate function for each state.