fox-flux:

physics problems 2: still player on a slope

(crossposting from cohost)

you have a player actor. great. heres one. it’s lexy

[lexy sprite omitted because tumblr completely fucks it up]

she is standing on a slope. you are savvy at physics and understand that:

1. gravity will attempt to pull her downwards
2. she will immediately collide with the slope itself
3. her remaining motion will be projected onto the slope (roughly equivalent to subtracting the normal force)
4. she will then slide down the slope.

this is bad, because lexy is not trying to move. neither she nor the ground are made of ice, so surely she can hold herself in place.

but again, you are savvy at physics, so you know what holds her there: friction. so you say, ok, add a bunch of friction.

now you have a problem. the good news is that your physics engine is completely homegrown, so you can explain the problem in excruciating detail. the bad news is that it is your problem to solve for the same reasons. and the problem is that your movement code integrates everything upfront, then performs a motion.

that means you have your current velocity (presumably zero), gravity (pointing downwards), and friction (pointing up along the slope). you add them together in some fashion, and the result can never be zero, even with friction’s natural capping behavior — this is just how vector addition works. so lexy will definitely try to accelerate in some direction, and the best you can hope for is that she will try to accelerate exactly towards the ground. but working out how to make that happen requires essentially working backwards from gravity (non-trivial because various effects can interact with gravity) and also just feels real dumb to be doing.

so where did you go wrong?

(an aside: the reason this doesn’t happen in the demo is that i also have a cutoff on very small movement, so that little rounding-error levels of velocity don’t make things shift a pixel at a time over the course of seconds. but that cutoff is too coarse, and in particular it makes some slow objects just not move on monitors with high refresh rates, so i’ve reduced it dramatically, and that has caused lexy to slide downhill. i thought i’d fixed this before but apparently i was just masking it by accident!)

i think the problem,

conceptually, is that friction happens at the wrong time. it’s integrated with velocity and acceleration accumulated over the course of the last tic before movement is attempted, but friction isn’t something that happens in a vacuum. i mean, literally, it won’t happen if there’s nothing else around. friction is an interaction with another object we’re touching, and before we start moving, there aren’t any of those!

so it seems like friction should only apply between steps 3 and 4 — after colliding with the ground, before actually moving along it. this is the point at which we know we are, in fact, sliding against the ground. and now we even have the ground available, so we don’t need friction itself to be a vector at all, which is kinda convenient.

but that’s in the guts of basic motion i… hesitate… to put something like friction in the middle of that. also, what happens if you collide and slide again? does friction apply again? probably not. so it only applies specifically the second time through a loop? that’s rather weird. maybe it’s okay that it’s weird? it does add complexity for “out-of-turn” motion though, like being pushed or climbing a ladder, which probably won’t have a big perf impact but does feel inappropriate.

other solutions

skip gravity

i could simply not apply gravity to a player on the ground. i’ve seen mention of that being done before. but that just feels goofy?? they are trying to move downwards, and on a slippery slope they even should move downwards.

also i have a bunch of objects that care about things landing on them, and this implies some weird special cases (in who knows how many places) for detecting that a player is walking on top of them without actually moving into them. and i have enough special cases as it is man. expressing a physics condition is so goddamn hard. i have the unsettling feeling that this would have other unforeseen consequences as well

a possible upside of this is that it could very well skip an entire movement iteration every tic — currently, a walking player tries to move sideways (for walking) + downwards (for gravity), immediately hits the ground, projects along the ground, and then tries to move a second time. without gravity in there, they’d skip the first collision and move exactly sideways from the beginning.

remember the ground

i do in fact remember the ground (tile or actor or whatever) for each actor, so i could use that to get the friction right upfront.

but what does that mean in practice? i guess it means that the motion vector would be projected along the ground before even attempting to move at all (and then that would be shortened by friction). so it’s kind of like skipping gravity — if lexy is standing on flat ground, her attempted motion (straight down) will be projected along the ground (horizontal) and always come out zero.

i guess essentially this combines the other two options — it applies friction to the movement vector, but it skips ahead one attempt by making use of knowledge from the previous frame. it would get the friction stuff out of the movement core, which i like, but it would still make objects not push against the ground, which i don’t like.

ah, all the options seem nebulously Not Great, which is always a sign of a fun problem. and don’t worry, this gets even more complicated with physics problems part 3