Hi Guys

I'm currently writing a 2d platformer for Android smartphones / tablets and I have a question regarding gravity.

I read up a bit before I applied gravity and from what I could tell, it seemed that gravity should be applied 'constantly' to characters (Like it is in real life).

By this, I mean, if the character is standing on a solid floor/platform, gravity will still be pulling him down.

My collision detection, will predict that his next position will be 'in' the platform and correct it before rendering. This way, when he isn't on a platform, he will just fall without me having to do anything extra.

However, I read an interesting article about how Sonic was made and it states that:

(Of gravity) This value is added to Y speed in every step in which Sonic isn't on the ground.

So I'm guessing they have a boolean value 'gravity' and just switch it true or false depending on when they want the gravity to be applied. (So false when on floor/platform, then switch to true when not).

I'm just wondering which of the two methods do you advocate and why? Which one would be easier to work with and why?

Thanks!

It depends on what you want exactly. Personally, I would go with the first approach you described (gravity constantly pulls, objects intersect, and collision response removes the intersection). This is relatively simple.

If you're just trying to make a basic platformer, I wouldn't try to emulate the Sonic physics. Sonice is nothing like most other platform games. Keep it simple.

Been a while since I wrote a platformer but the main reason not to apply gravity when on the ground is to prevent your character gradually sliding down slopes.

Whether you see this issue in the presence of slopes depends upon how you respond to colllisions of course:

- if you just say he's hit a 'floor' and move him straight up to resolve the collision then you won't see this problem

- if you move him in the direction of the normal of the surface then he will slide unless you also implement a friction model

- however, a general friction model can be difficult to get feeling precise enough for a platformer

In my opinion the no gravity option is easier to work with for getting very precise platforming mechanics but the gravity always on version can give you nicer secondary effects like little skids and bounces when you land a jump.

If all of your platforms are flat (i.e. no slopes) then there's not much in it.

Thanks all, yep my platforms are pretty much flat at the moment, I don't thik I will be introducing slopes at this point - thanks I will probably stick with the constant gravity method as it seems a lot easier to employ than switching between states. Cheers!

In the general case, there's no functional difference between applying gravity constantly and only applying it when the character is off the ground; however, there are certain situations when one approach works better than the other from a gameplay standpoint.

In the case of Sonic, for example, normal movement includes loops, corkscrews, and similar objects wherein Sonic is running vertically or upside-down, and which therefore do not work well without some form of conditional gravity.

(Most older 2D console games typically use some form of conditional gravity, because it's marginally faster to check if the character's on the ground and apply gravity if they're not than it is to apply gravity, check for ground collisions, and perform the appropriate collision response, and particualarly on the 8- and 16-bit consoles, every clock cycle counts.)

If you're just trying to make a basic platformer, I wouldn't try to emulate the Sonic physics. Sonice is nothing like most other platform games. Keep it simple.

In the case of Sonic, for example, normal movement includes loops, corkscrews, and similar objects wherein Sonic is running vertically or upside-down, and which therefore do not work well without some form of conditional gravity.

I believe that in the 2D Sonic games all of the weird terrain such as loops and corkscrews were done through the use of scripted events (Sonic's speed would have been calculated at the beginning of the loop to determine where he should fall off the loop if he wasn't going fast enough. Gravity would have no effect during these scripted events, of course) - so there was no advanced collision detection that needed to be done. So despite popular belief, Sonic was much like every other platformer of the time.

As for the original question, I believe you are misinterpreting that quote about Sonic's speed. What the quote describes is actually acceleration while airborne. For every frame that Sonic is in the air, his speed would continue to increase - making him drop faster and faster until he hits the ground, in which case his Y speed would reset. I also believe that in the original Sonic game, this Y speed had no maximum value.

Ludus, on 14 May 2013 - 17:09, said:

Anthony Serrano, on 14 May 2013 - 12:45, said:
In the case of Sonic, for example, normal movement includes loops, corkscrews, and similar objects wherein Sonic is running vertically or upside-down, and which therefore do not work well without some form of conditional gravity.

I believe that in the 2D Sonic games all of the weird terrain such as loops and corkscrews were done through the use of scripted events (Sonic's speed would have been calculated at the beginning of the loop to determine where he should fall off the loop if he wasn't going fast enough. Gravity would have no effect during these scripted events, of course) - so there was no advanced collision detection that needed to be done. So despite popular belief, Sonic was much like every other platformer of the time.

Your belief would be incorrect.

Loops, at least, are handled by the standard movement code that allows Sonic to walk along arbitrarily-sloped surfaces; tile metadata in Sonic includes the surface slope, so while sonic is in motion, the game checks the slope of the tile he's standing, and depending on the value changes which direction it looks for ground tiles in (either below Sonic, above him, to his left, or to his right). This is why the Sonic engine can support loops that aren't perfect circles, loops with arbitrary angles of approach and exit, and round objects that Sonic runs along the outside of.

However, if Sonic's run speed drops below a specific value, he is no longer considered to be "on the ground" (and the ground direction is reset to look beneath Sonic), and gravity is applied to him.

Similarly, for the corkscrews in Sonic 2 Emerald Hill Zone, which aren't scripted, but are instead special-cased versions of the normal movement code that override the normal "on the ground"-state positioning code to convert Sonic's run speed into position updates in unconventional ways. When Sonic enters one while in the "on the ground" state, he will continue moving forward, and his animation frame and position will be updated based on his current run speed. If his run speed drops below the threshold, however, he will fall right off, no matter where on the corkscrew he is, because the corkscrew doesn't collide with "in the air" Sonic - which is also why you can't jump onto a corkscrew. The coding for the vertical corkscrews in Sonic 3 operate along similar principles, though rather more complex.

You probably just assumed they're scripted because you've never tried to manually decelerate Sonic while moving on such an object, which let me assure you actually does work in-game.