Hello,

I am trying to make a 2D platformer Character Controller, and there's two movement mechanics I have had a lot of trouble getting to work in unison: that being, variable jump height and double jumping. What I mean by variable jump height is that your jump height depends on how long you hold down the jump button. I guess my question is, why shouldn't this work?

var can_jump: bool = false
var can_double_jump: bool = false
var jump_timer: float = 0
var jump_force: float = 200

func jump(force):
> velocity.y = -force

func _physics_process(delta: float) -> void:
> if is_on_floor():
>> can_jump = true
>> can_double_jump = true
>
> if Input.is_action_just_pressed("jump"):
>> if can_jump && can_double_jump:
>>> can_jump = false
>> if can_jump == false && can_double_jump:
>>> can_double_jump = false
>
> if Input.is_action_pressed("jump") && jump_timer < 0.25 && (can_jump or can_double_jump):
>> jump(jump_force)
>> jump_timer += delta
>
>if Input.is_action_just_released("jump"):
>> jump_timer = 0

Thank you for your help, hopefully this code is readable. I am just getting into game dev and I'm excited to hear feedback!

  • Applying jump force at the start of every jump and cutting velocity on jump release is the most common way to implement it. You're implementation doesn't work because you set your checks to false, then check again to apply jump velocity. Logic pipeline should be

    1. Listen for jump input from floor
    2. Apply jump velocity and set can_jump to false and start timer
    3. on timer timeout or timer > max_length check jump input again. --> still pressed do nothing. --> not pressed cut vertical velocity

    Double jump doesn't interfere with this functionality as long as you reset the timer on action pressed + not on floor + can_double_jump.

    A state machine would make this even easier because even with this small example you're already drowning in boolean checks and conditionals that would much rather live in state transitions.

Some formatting suggestions to make the code more readable:

Instead of using > and >>, place ~~~ on lines before and after the code. Then the code copy/pasted from the Godot editor will retain its indentation.

Use and instead of &&.

Use not can_jump instead of can_jump == false.

    For consistency, since he's using or instead of ||.

    And because and,or are more readable than &&,||.

    • Toxe replied to this.

      DaveTheCoder And because and,or are more readable than &&,||.

      Well that's debatable, I'd say. But personally I just pick the version that's the most clear and readable in the situation at hand. Sometimes it's a ! and sometimes it's a not, and same with the other operators.

      Totally non-committal, hippie answer, I know. 😆

      • xyz replied to this.

          • xyz

          • Post #7

          Toxe They never should have included c style boolean operators into gdscript. They look nasty in python-like surroundings.

          • Toxe replied to this.

              xyz Now that you mention it, that's true I suppose. But on the other hand they stand out more and for people used to C-style languages are easier to notice.

                xyz so basically because gdscript developers come from a visual basic bg? So there is no performance penalty.

                    kuligs2 This has nothing to do with anyone's background, GDScript is just heavily based on Python. And there is no difference between && and and etc.

                      • xyz

                      • Post #11

                      kuligs2 so basically because gdscript developers come from a visual basic bg? So there is no performance penalty.

                      You seriously believe there is "performance penalty", or you're just trolling? By what magic would such "penalty" occur?

                        Applying jump force at the start of every jump and cutting velocity on jump release is the most common way to implement it. You're implementation doesn't work because you set your checks to false, then check again to apply jump velocity. Logic pipeline should be

                        1. Listen for jump input from floor
                        2. Apply jump velocity and set can_jump to false and start timer
                        3. on timer timeout or timer > max_length check jump input again. --> still pressed do nothing. --> not pressed cut vertical velocity

                        Double jump doesn't interfere with this functionality as long as you reset the timer on action pressed + not on floor + can_double_jump.

                        A state machine would make this even easier because even with this small example you're already drowning in boolean checks and conditionals that would much rather live in state transitions.

                          • xyz

                          • Post #13

                          HerbalHerb A state machine would make this even easier because even with this small example you're already drowning in boolean checks and conditionals that would much rather live in state transitions.

                          Contitionals are meat and potatoes of programming. Saying that code is "drowning in boolean checks" is like saying a fish drowned in water.

                              xyz

                              Moving them from physics_process to a state machine still massively improves maintainability (and reduces the total amount of conditionals if OP ever expands on player movement).

                                  HerbalHerb state machine in it self is an if machine? If you have more than one state..

                                    • xyz

                                    • Post #16
                                    • Edited

                                    HerbalHerb Moving them from physics_process to a state machine still massively improves maintainability (and reduces the total amount of conditionals if OP ever expands on player movement).

                                    You can't reduce the number of conditionals. You can only mask them. You can reduce the number of explicitly visible ifs but at the cost of increased number of functions and classes. The question is - is that really "better" in terms of maintainability. In practice, it's often worse, especially as the system grows larger and you have to deal with more and more loose ends and bug chases. You'll need to mentally track ever growing number of "abstracted away" and "invisible" things, constantly jumping around functions and classes scattered around many source files.

                                    Following nested polymorphic function calls demands more brain resources than following nested ifs. Especially if you didn't design the classes and wrote the functions yourself, or you wrote them two years ago.

                                        xyz

                                        Hard disagree.

                                        Forcing an object to one state at a time makes it much easier to track down loose ends, especially when systems grow larger. Precisely because all the logic lives in one function or node and is not scattered behind a number of tangled checks in the physics loop.

                                        Looking at States.AIRBORNE is immediately clear. Tracking down five seperate booleans in the now spaghetti physics process because you want to incorperate wall jumps after two years is what's messy.

                                        FSM's solve the exact problems you're atributing to it. There's a bit of mental overhead in the beginning, but every developer learns what it is at some point. I'd argue it's even more useful when working in a team because it's modular.

                                        • xyz replied to this.

                                            xyz we all are waiting for when you gonna post your project here for show.

                                            As for OP, i would do as his code does, just wouldnt use delta but use a switcherooney - meaning, on input pressed "jump" set a varriable, and on input release reset a varriable. And in the _process check for the variable - if jump is pressed then keep jumping or applying force.

                                            • xyz replied to this.

                                                HerbalHerb Thank you for your answer. I managed to fix it on my own after some time, I noticed the logic issue eventually lol.

                                                What is a state machine? I am unfamiliar

                                                • Toxe replied to this.

                                                    • xyz

                                                    • Post #20

                                                    kuligs2 we all are waiting for when you gonna post your project here for show.

                                                    I posted at least 5 projects here, some in form of "educational" devlogs. All likely before you were even a member.

                                                    You can also buy my game on Steam and write me a bad review.