Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

"there's no smooth slowing down gradually"

If that's the case, maybe the problem you are facing isn't with the explosion jumping part of the code. From what I can tell, the explosion jumping part does what it is intended to do: it adds velocity to the player based on an explosive radius.

How are you handling the code that stops the player, when he is in motion? Like, the basic movement code. Maybe that's where you have to check to find your problem. If you are moving with code like this: 


If W pressed -> velocity = 1.0

If W not pressed -> velocity = 0.0


Then your character does not have any momentum, meaning you haven't coded any way to naturally slow down, it is only based on key inputs. Maybe that's why you don't slow down after an explosion jump, that's my guess.

(+1)

So I figured it out and it kind of happened in an instant of mad science magic so I don't know how to properly document it so I'll write my thoughts down as quickly as possible.
It was honestly dumb luck that I started multiplying and dividing things and I made this new variable called "move_multiplier" which I divided by the equation used to calculate velocity:

velocity = velocity.linear_interpolate(direction * speed, accel * delta * move_multiplier) / 1.0025

The "1.0025" is what I like to call, "the slog constant" or basically how dampened the movement is for the player. If divided by a small number under 1, it will accelerate the player in a way I do not like while they are in motion. If they are in motion though, this constant makes it so that they will start moving and then reach a max and then stop. I decided to add the move_multiplier first as a way to slow the player when they stopped moving as you suggested but then I gave it a less than 1 value and saw that it added what I can only describe as a "slippery factor" where they would glide off of surfaces and then stop. The movement was a bit too tight than I would have liked it to be and there was no momentum so I thought this was a cool addition. The problem was that this was only affective on floors so what I did was make another variable (which I already had for other reasons but decided to repurpose) called IsAirborne. IsAirborne is a boolean that uses is_on_floor as it's indicator. So what I did was this:

(This is in the _physics_process(delta) function by the way)

if IsAirborne == true:

move_multiplier -= delta

move_multiplier = clamp(move_multiplier, .05 ,.8)


if IsAirborne == false:

move_multiplier += delta

move_multiplier = clamp(move_multiplier, .05 ,.8)

Delta basically keeps account the time passed since the condition is met so the more a player is airborne they will experience a clamp (min and max range) that reduces the value move_multiplier (where small values make the movement more slippery) and in reverse, if the player was not airborne, they would experience less slippery, more grounded movement. I like to think about these values as the "grounded range" that controls how tight the movement is, where move_multiplier is made to go toward .05 (very slippery) when airborne and then on the ground will go to .8 (very tight but some slip for general movement consistency).

I probably inadvertently recreated something someone else already did and it broke part of my auto-bhop functionality but I'll plan to see if I can fix it somehow but right now I'm satisfied I concocted this weird but workable movement system.

I'll go more in depth if you want but I already rambled a lot and I frankly don't know how I even figured it out.

Nice! I'm glad you got it sorted out!