[Platypus] problem of speed with slopes of differents angles

Hello,

With Platypus, if using slopes with different angles, the speed of the player changes (with the same speed applied).

I’ve modified the grottoescape sample to show this. I have the same problem with my game. I’ve used the same tilesource than in my game.

It’s counterintuitive, because the player is moving faster on the straighter slope. And he’s slower on softer slope.

The only trail i’ve found is just before acceleration, platypus sends a message of « falling », and then « ground landing » and then accelerate. I don’t know if it’s related, or just a quirk on the tilesource i use.

You can find the modified grottosample here:

Thank you.

Yeah, slopes handling is not perfect in Platypus. Happily accepting pull requests!

1 Like

I’m not an expert in mathematics, but i’ve tried to search how slopes were computed in Platypus.

For what i’ve understood, the movement of the GO is computed with velocity and normals of the slope. So, when the normal values raises, the player goes faster.

For example, in my sample, normals are (i’ve removed the sign as the movement calculus uses math.abs) :
30% slopes : (0.45, 0.89) slower
45% slopes : (0.7, 0.7) faster when climbing (x value is higher than x for 30% slopes).

So what can i do with that ? Obviously, the computng of movement should use the inverse of the normal.
I’ve did a try with slope.right in platypus_right function:

-- up-hill
if state.slope_right then
	movement.y = -velocity * math.abs(state.slope_right.y)
	movement.x = velocity * math.abs(0.2/state.slope_right.x) -- <1>

<1> in my case, 0.2 is a good value.

But i need some help on this, it _seems_ to work in this case, but that's not a general fix. May be it can work for tuning a specific game, but that's all. Not a nice solution.

Ok i get it after i’ve slept on it ! So the idea is : the more the normal is rising, the player should advance slower. As normal are normalized (between 0 and 1), it’s easy to write:

-- up-hill
if state.slope_right then
	movement.y = -velocity * math.abs(state.slope_right.y)
	movement.x = velocity * (1 - math.abs(state.slope_right.x))

It’s far better now. I prepare a PR for this from my dev branch.

1 Like

Ok PR done. It has been added to https://github.com/britzl/platypus/pull/24 , hope you don’t mind (i’m not an expert of github, but it doesn’t seem i can open an new PR when there is still one which is already opened).

You can only have one PR per branch open at a time.

1 Like