kuligs2 Also because style guide says so 
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#boolean-operators
Variable Jump Height?
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. 
- Edited
- Best Answerset by OccasionalCrust
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
- Listen for jump input from floor
- Apply jump velocity and set can_jump to false and start timer
- 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.
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.
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..
- 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.
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 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.
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
HerbalHerb How many games you've shipped that use fsm for managing player state?
IMO both can be the right and wrong tool. As always it's about code clarity and readability.
- If you have only a few conditions then
if's are fine. - If you have a couple more then
if's are still fine but you should try grouping them a little (like in subfunctions). - If you got still more conditions then a good state machine can help a lot.
- If you got still more conditions then you are fucked either way.
- Edited
OccasionalCrust What is a state machine? I am unfamiliar
A state machine is, in short, a design pattern that can help reduce code complexity when you have to deal with a lot of conditions like "on the ground", "walking", "running", "jumping", "falling", "idle" etc. There are a million ways to make a state machine and some can actually improve readability whereas a lot just make things more complicated. As always: it depends. 