Up to this point in my 2D side scroller I have been using an arbitrary number for gravity, I just adjusted it until it looked right.

GRAVITY = .5

player.y += GRAVITY

This would run every frame of 60FPS, it looked fine, worked well, etc.

I figured I should make the gravity realistic making the calculations to be converted to my game, like this:

player.height = 64 pixels, assumed height of 6ft
therefor 1 ft = 10.6 pixels
gravity in real life is 32.2 ft/s, which is 341.32 pixels/sec
341.32 pixles/ssec / 60fps = 5.6pixels per 1/60th second

Needless to say my character is dropping at a rate where if it were real life he would explode on contact from a 10ft drop. My assumption is since gravity is a squared number 32.2ft/s² does that mean I should use 5.67 (the square root of 32.2) in my calculation? When I do this my GRAVITY becomes around 1.0, and everything looks okay again.

My language is Python, but this question is more general I believe. Help?

There's two main ways to do timed simulations. Time-based and Frame-based. Each have their own advantages and disadvantages, but mainly it goes like: if you can guarantee that your game will always and at any point run at the desired framerate you are well off using frame-based timing. Sample scenarios would be closed systems like consoles where every machine is the same and no background processes can influence the performance. In every other case you are better off use time-based modeling.

This is a pretty broad topic in itself and getting a stable simulation is always key in game development. You can read more about this here:
http://gafferongames.com/game-physics/f ... -timestep/

To summarize: instead of calculating the amount of pixels your entity will move per frame, you use a measure based on seconds and multiply by the frame-time (delta time, the amount of time that has passed since the last frame was updated).



This will ensure that your player will move the same speed, regardless of the framerate. Take that with a grain of salt, since there's still inaccuracies in the way deltatime get's calculated, but most engines and frameworks handle this quite well; or well enough for your standard gaming experience.

On the topic of gravity i just had to look up my old platformer code which had a nice feeling of gravity.
You can try it here: http://wzl.vg/johnny.html



Happy tinkering

_________________
Long pork is people!

wzl's burrow

Err waitaminute... what?

"Gravity in real life = 32.2 feet/second"

Where'd you get that figure?

What object does that apply to?

Different objects have different "terminal velocities" (i.e. the speed at which they stop gaining speed as they fall)

consider this: Which will fall faster - a marble, or a sheet of paper? The marble of course, because it has a higher terminal velocity due to its mass/surface area ratio vs the peice of paper which is all surface area and almost no mass.

Another thing to consider is that it takes time to reach terminal velocity so if you're going for realistic physics, gravity should accelrate to its "maximum" value based on how long the object has been falling.

Just my 0.02

_________________
"None are more hopelessly enslaved than those who falsely believe they are free."
"It is no measure of health to be well adjusted to a profoundly sick society."
"Hope is the first step on the road to dissapointment." -Jonah Orion
http://tankzgame.blogspot.com

The gravity constant is 9.83m/s^2, or 32.3ft/s^2. The drag resulting from surface resistance etc is largely to ignore in game physics, except you're especially doing simulations for that kind of behavior.

Additionally it is not necessary to do a 100% accurate physics simulation, instead go with what feels good, especially in platformers. However it should perform equally at any framerate.

A good example for inaccurate physics are pretty much all games that use some kind of simulation. Ever wondered why boxes in games fall in slow motion?

_________________
Long pork is people!

wzl's burrow

That's the key right there.

_________________
"None are more hopelessly enslaved than those who falsely believe they are free."
"It is no measure of health to be well adjusted to a profoundly sick society."
"Hope is the first step on the road to dissapointment." -Jonah Orion
http://tankzgame.blogspot.com

Hi, thank you weezl for your reply. My game incorporates time based compensation for slower/faster framerate. I get tired of people posting 300 lines of code and saying "What's wrong?" So I figured I would simplify it to the problem at hand, which I believe is my calculation. I calculate "pixels per 60fps" as a baseline, and from there it changes depending on the actual framerate, as my game has a cap of 120fps.

I think I figured it out, the final number I get is a square number. Finding the square root of it seems to drop my character at a realistic rate (all considered). Sorry Meneliki but I don't take air resistance into consideration as terminal velocity doesn't occur in humans until around 200mph. Again, I'm talking of drops double and triple my characters height and having him accelerate to over 400 pixels per second.

weezl your sample code is confusing to me. You declare GRAVITY as 2.89f², is the 'f' a constant for feet? As a float shouldn't the value be a number without string? Also your GRAVITYSCALE doesn't make sense to me either, I see "verticalvelocity = 2.89f² * 10 * deltatime" then when applied to the player.y it is multiplied by the deltatime again. Wouldn't that screw things up? I'm not trying to ridicule or oppose, I just would like to understand as it may help me out.

My apologies I am self taught in Python and am not familiar with other languages.

Yes I should just go with what looks right. I tried to fix it when it wasn't broke.

Your confusion probably arises from adding gravity directly to position, which is physically incorrect.

(the stuff below is just basic physics of falling, I don't have URLs, but I'd be surprised if there are no sites explaining it)

Gravity is a force, not a speed.
The force increases the speed, and the speed makes you move, ie there are two steps involved here.



This makes you fall increasingly faster, which is basically why falling from a chair is not the same as falling off a building. The forces involved to reset the speed to 0 at the bottom are too large to handle in the latter case.

If you do this from an air plane, then the speed will grow so large that air-drag plays a role. Air-drag is the resistance force of moving fast through air, like sticking your hand out the car while driving fast.
The air-drag force counters the gravity force, so in the end they cancel each other out, and your speed does not increase any more. This is called terminal velocity (ie it is "v =v+(g-drag)*dt" where 'g' is constant, and 'drag' increases with speed).
Terminal velocity is around 200km/h for a human falling through air while in horizontal position (like all the freefall sky divers do).


But as others and yourself have already said, reality is often too boring to incorporate in a game. Use physics that work in the game instead.

Edit: Let's have a 'code' box to preserve white space.

_________________
My project: Messing about in FreeRCT, dev blog, and IRC #freerct at oftc.net

The f is a hint for the compiler that this is a floating point number and not a double. This is used in any c-based language. Might i also suggest to not use imperial measures, but metric ones. After all this is your call, but i won't bother converting your odd numbers into metric units to doublecheck Call me lazy.

Gravityscale is the factor used to determine the scaling of the world basically. The smaller your entities, the longer it takes for them to reach the ground, thats what the scale is for.

I had to tinker a lot with this code to make sure every jump will be the same. I had issues with the jumpheight being a few pixels short or too high every other jump. So what i came up with is to use the velocity multiplied by deltatime to scale it to the simulation time. Then i use the velocity to manipulate the actual player position, again multiplied by deltatime, to have it fit the simulation again.

Not sure about how 'correct' that is from a physical perspective, but for my purpose i damn well nailed it

_________________
Long pork is people!

wzl's burrow

Thank you all for your help. My problem seems to be solved. No more ruptured sprite limbs from dangerously fast falls.