Apply gravity when grounded?

I’ve been prototyping a 2D platformer where gravity is applied every frame to characters. This happens regardless of whether or not grounded is true or false. This helps keep characters grounded so they are able to use the jump action, as well as for attaching them to moving platforms. Recently I watched a video by Jon Blow where he specifically spoke against this and said that it is preferable to attach characters to surface normals and then move them along the normal. This would help with implementing slopes, which I have not done yet.

Regardless of the fact that both work, my question is which do you think is preferable and what are the pros and cons you could surmise for each?

They all have draw-backs or iffy edge-cases in my experience… If you change the characters left-right run-dir to match the terrain slope he is running on, you wont run off the edge of a gentle slope, and you can modify the movespeed for up/down hill…

That matches player intent better, I think… He does not mean “run exactly horizontally left”, he means “follow the terrain left”…

In the game “The Swindle” when you are walking down stairs you come off of the ground all of the time and then if you hit the jump button nothing happens and you can die very easily and it’s made the game unplayable for me.

If you wish to apply gravity every frame then in order to not move thru objects you must simultaneously check for collisions of the future motion or after moving adjust the position which makes this more about the collision detection you employ.

I use to disagree with Jonathon Blow 100% of the time because his personality rubbed me the wrong way. Now my opinion has changed. I still find his personality grating but I now think he is very insightful and thoughtful about game dev. I would follow his advice…

For collision, I’m using a sweep method based on a minkowski algorithm. It works pretty well, and is pretty useful in finding when and where a collision occurs between 2 frames. However, I’m only using AABBs at the moment. So in implementing slopes I’ll have to do a workaround, since I’d prefer not to use OBBs. That was the main crux of my question since applying gravity straight downwards may make implementing slopes more difficult. Right? Unless I’m overthinking it. So I would attach the character to the normal, then strafe along that normal. At least that’s my thought.

if you are doing the physics yourself then you have gravity G and friction F that counters sliding on a slope depending on materials interacting.

Only part of the gravity is applied to the slope in relation to the directional slope x y. Gravity affects the Y portion of a slope directly. So if the slope ratio y / (x + y) = 0 gravity is canceled as you’re on a flat surface you can just skip any long version of the check.
At y = 1 it is full gravity applied.
At say .5 its g = G * .5; accelerational slope force = g - friction;
if the force is negative friction is negating the velocity on the slope imparted by gravity. You might still slide if you have enough X velocity or you convert falling velocity into the x direction.
But that is a separate notion.
For the slope you should primarily think of a angled surface just having the player walk on to it with a constant force of gravity and a constant force of friction opposing it. The greater force wins out if gravity wins out the acceleration maybe diminished by friction so you might just start to slowly slide down the slope.

I usually have the character stick to the ground where it hasn’t jumped or run off the edge. Otherwise you get annoying effects like the mentioned hopping off the ground when going down a slope.

No what he is saying is just silly and wrong because it’s not about gravity at all. Its about how you handle collisions and specifically id wager that this is really about how you handle collisions with sloped surfaces.

What else after a long think could it really be about ?

His solution is to turn off gravity to make things easier for the way he thought about it and call it a day.
It doesn’t make it the only solution the right solution or the more physically correct solution.
It presents its own set of opposing problems as a result that you would have to deal with.
Maybe that works for him but it wouldn’t work for me.

Slopes is the main reason I have for pondering the grounded state’s use of gravity. Although my original question was more vague and open, since this was something I haven’t thought of before and was curious to cross reference with people. However, if there are a plethora of issues that occur as a result or can be solved by one or the other, that’s what I’m most open minded about.

What you explained in your previous post seems like it’s worth a go. The goal for my slope implementation is to be more akin to Super Mario/Mega Man-like slopes in simplicity, but the way collisions work in my game seems to make it less than simple. What I mean by that is:

The way the collision physics works now is that I have my horizontal and vertical displacements separate: horizontal collisions only horizontally displace and vertical collisions only vertically displace. But slopes would [be able to] displace on both axes.

In what I’ve made so far, some game object types can stack on top of each other in a parent/child tree. So with this stack of objects: gravity is applied to the parent → then it’s corrected by collision. Then we go through the children in order from bottom to top → displace according to parentapply gravity to ensure we’re attached to parentcorrect by collision.

Now the child at the tippy top hits the ceiling. This affects the whole stack all the way down to the parent. I correct the children from top to bottom, with the parent coming last. Now this is easy with how I separate horizontal and vertical displacement, but if this stack of objects would be on a slope then they would all need to be adjusted along the slope.

I do wonder though if not applying gravity could potentially remove 1-2 physics steps when that top child hits the ceiling. Take for example that same instance but the top child doesn’t hit the ceiling until the 2nd physics step: In the 1st step gravity pushes him towards the parent (so he doesn’t collide with ceiling) → then it’s corrected → then in the 2nd step he now collides with the ceiling → now push everything back down and maybe do a 3rd step.

If removing this potentially expensive (for CPU) hurdle can be done without breaking or making other things challenging to properly implement, then it may have its merits.

I watch a lot of GDC and other talks about game design and programming in general. So when I saw Jon Blow saying that it was preferable to not apply gravity while grounded (and move along the surface normal) I thought, “Wait is this the standard? Have I not been in the loop?” And I’m still not sure.