Variable Jump Height?
- 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. 
And someone who doesn't, well, doesn't. - Edited
Toxe No. Classic fsm is objectively a poor choice for player state management. Beyond the simplest cases of player control, the pattern doesn't very well model all the finesse and complexity needed for something that plays and feels good. In a good action game, the player is almost never in a single discrete state. If you approach it like that you're guaranteed to end up with something that feels sluggish and unresponsive. You'll at least need to run several simultaneous fsms. This of course defeats the very purpose of using the fsm in the first place because you need to synch them which leaves you with the exact problem the fsm was supposed to solve.
It's fine for npc state management though, if npcs are sufficiently simple. But then again, a bunch of ifs would do the job just fine in that case.
But my main gripe is not with using the pattern itself, where adequate. You can conceptualize parts of your state management thinking in terms of discrete states just fine. I can't stand monolithic, bloated, turbo-oo implementations that are typically presented as "the solution"
xyz I am talking about state machines (and the State pattern, if we want to throw that into the mix as well) in general and just like any other tool they have their uses. And, just like any other tool, they can equally be misused. But one pro aspect is can be that they might make your design a little more data-driven, which in turn can help with visualizing what is going on with debug UIs.
xyz But my main gripe is not with using the pattern itself, where adequate. You can conceptualize parts of your state management thinking in terms of discrete states just fine. I can't stand monolithic, bloated, turbo-oo implementations that are typically presented as "the solution"
Oh we can agree on that one for-f'ing-sure. 
- Edited
Toxe they can equally be misused
Player state in an action game being one blatant example of misuse 
Whenever I enter into discussion about this it always ends with me asking the proponent of "state machines" have they shipped a game that does it. The answer is always either "no" or they go silent 