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.