Better gravity, falling, and jumping.

[MindVisceral]

Falling, as it is implemented right now, doesn't quite feel right. Visual effect will certainly help (#14), but this can also be improved with code.

Mainly, making gravity increase with time (up until a certain point) is a good step forward.

[MindVisceral]

I'm putting this here, but it is related to #29 too. The Player is, upon a regular jump or a walljump, allowed to strafe and move in the air. The issue is that the regular jump and the walljump are calculated differently, and they are based on very different variables, which results in way different speeds and feel while in the air.

The simplest fix would be to combine the two states, though my GoodPractice™ view on this is that these states should stay separate, because they perform different functions. This doesn't seem ideal and it'd take quite some work.

The next (and seemingly better) option is to edit both jump scripts to always behave (and feel) the same when strafing. The falling script would have to be edited to feel the same too. But at that point, shouldn't all the jump states and the fall state be made into one, since they will perform the same function, i.e. making the Player fall, then? Perhaps the fall state itself is unnecessary.

I'll do more reaserch and I will try option two.

[MindVisceral]

For now, I've just tweaked the jumping and gravity values to be very similiar to ULTRAKILL's and it seems that changing some floats around may be enough. Further testing needed.

[MindVisceral]

This certainly seems to be the case. The walljump is now similiar enough to ULTRAKILL's to cross it off my list.

[MindVisceral]

Possible enhancement: the faster the Player is falling, the higher they will bounce up, if they jump right after hitting the ground.

[MindVisceral]

Possible enhancement: the faster the Player is falling, the higher they will bounce up, if they jump right after hitting the ground.

This was partially implemented today.

Right now the problem is that it's not very forgiving, as the Player must Input a jump right before touching the ground. Ideally (necessairly, really), a higher jump should also happen a few miliseconds after touching the ground. A grace period of a kind is required.

Since we're on that topic right now; a better/cleaner grace period implementation would be very welcome. As it is now, we just use a Timer attached to a State node, and when the Player gives a jump Input beofre that time is over, we allow for a quick jump. Perhaps forgoing a node Timer and making one through code would be better here. Or maybe actual Input queueing could solve this issue, among others.

And another thing, the numbers must be tweaked a bit to make this work better. Perhaps this requires a few variables, or a check to see how far down the Player has fallen in the Stomp state - we can get the jump_height_multiplier based on that.

[MindVisceral]

Right, jump buffering and coyote time are the next items on the list. They're absolutely essentail for good gamefeel.

[MindVisceral]

jump buffering and coyote time are the next items on the list.

Nevermind, jump input buffering is already done and it works quite well. I got confused; it's just the jump_height_multiplier that doesn't have a jump buffer.

So, this is not true:

As it is now, we just use a Timer attached to a State node, and when the Player gives a jump Input beofre that time is over, we allow for a quick jump.

[MindVisceral]

On 2024.3.7 added coyote time. Very easy to add, it's just a Timer and a little check on _input(), and it's only really required on the fall state.

[MindVisceral]

This was finished (and changed) today:

Right now the problem is that it's not very forgiving, as the Player must Input a jump right before touching the ground. Ideally (necessairly, really), a higher jump should also happen a few miliseconds after touching the ground. A grace period of a kind is required.

Now, we store the Player's Y value of global_position when the Stomp is started. When it's finished, we calculate the difference between that value, and the Player's Y value of global_position on Stomp's exit() function.

And thus we get the distance between the Stomp's start and end points. We store this value in stomp_vertical_distance in the Player script. In the Jump state, we simply add this value to the jump_height.

We also use a StompJumpTimer to only allow for this higher stomp jump to happen within this Timer's wait_time. Otherwise, we just perform a normal jump.

NOTE: The stomp jump has a limited height, which can be set through stomp_jump_height_limit in the Player script. Setting this limit to 230, doesn't limit the jump to 230 meters up - likely because of gravity. 82.5 (96.5 - jump_height) seems to work though.