Using true values for gravity in a 2D game that must use physics

This topic is 673 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hello everyone, I would like to know your opinion about the problem I'm facing right now. I'm try to using GameMaker for make a simple game that will let user control a box where I will apply a "normal" force of gravity like on earth of 9.81m/s², for convenience I decide to use a scale of 1 mt equal to 32 pixel. 1 second is equivalent to 60 frame execution so based on this I will get a velocity increment of around 5.232 pixel per frame and offcurse that's a lot and result in my object just disappear from screen in 2 seconds.

I want to keep correct numbers just because I want then to implement the drag and lift force for this object but I'm already stopped from this simple limit. What's your suggestions ? Thank you for the patience, best regards.

Share on other sites

Why is actual physics scale important? Does the game become more fun if you use 9.81 m/(s*s) than, say 8 m/(s*s) or 6 m/(s*s) ? EDIT: Note that what you compute and what you print doesn't have to be equal.

I would pick a value that is fun to play rather than trying to be realistic.

Tweaking the value is a good way to change the difficulty perhaps.

If you do want to stick to realism, I believe you have to rethink your pixel size. Pixel size of 0.03m isn't very useful at such velocity accelerations. (that is, the player likely doesn't care for positions less than 0.1 to 0.5m, would be my guess).

Edited by Alberth

Share on other sites

Well fun is not take into account if I have to write some drag and lift formula and expect certain behavior by my body with certain values and in opposite find totally different :) my object it's a 5 mt box and must be this size but not think I can scale down to 32px per 5 .....

Drag and lift based on speed so I would like to get at least some sort of normality on numbers.

Edited by plaguebreath

Share on other sites

Everything you've added is doing exactly what it should. So, your options are:

• make gravity less powerful
• change your rendering scale so that more of it fits on the screen
• scale your objects so that they're bigger and appear to respond more slowly

Share on other sites

Hmm, you can also work in a continuous [m] unit space, and separately translate to pixels by some offset and scale factors. That would give you freedom in how to display things, at least more than having a fixed [px/m] scale.

Nonetheless, if you want to show the speed adequately, you'll need more space due to the high speeds. That means as far as I can see either means more pixels or a different scale.

Maybe have some sort of dynamic scale? At high speed give an overview, at low speeds provide more details?

Share on other sites

Not sure what the problem is. You want your object to be on screen longer while having a static camera? Zoom out further? Why can the box fall off screen? Can you move the camera with the box? Please provide a better description of what you're trying to do and what your actual problem is.

Share on other sites

Everything you've added is doing exactly what it should. So, your options are:

• make gravity less powerful
• change your rendering scale so that more of it fits on the screen
• scale your objects so that they're bigger and appear to respond more slowly

I guess the only solution usable could be the adapt gravity value on smaller value. I will try to fix the view on the screen too as suggested Mussi, thank you for the suggestions.

Share on other sites

and offcurse that's a lot and result in my object just disappear from screen in 2 seconds.

if two seconds is too fast , then your scale of  1 mt = 32 pixels is too small (what's an mt? you mean meters? m is the SI abbreviation for meters).

try 1 mt = 3.2 pixels or 1 mt = 0.32 pixels.

if you can't see your unit at that scale, hey - what can i say? that's life.  that's what it would be like in real life. that's real physics. take it or shake it.

in such cases its common to put a targeting recticule on the pixel that represents the target - to help the player track the target - as seen in wing commander when a ship first comes into visual range.

the other option is to bend the rules of physics - or toss them out completely - by starting to fudge things - make them bigger (ships)  or less (gravity) than they should be.

i've found that if you understand the physics, its not that hard to build something realistic with out having to fake it. In fact, faking it can be more work (racing car pseudo-physics comes to mind here).

faking it means you have to balance stuff, while physics means mother nature's already done that for you.  just look up the formula, look up the constants, plug them in and watch it go! no tweaking required.

Share on other sites

You have a math error. 9.81 m/s2 at 32 pixels/m and 60 frames/s is 0.0872 pixels/frame2, not 5.232.

Pay attention to the units - acceleration is in units of distance over time squared, which means that if there is a time unit conversion you have to apply it twice.

Please note that there is a very good chance that you'll find this corrected gravity too "floaty" - there's a reason most 2D games actually use gravity significantly stronger than Earth's.

Edited by Anthony Serrano

Share on other sites
You have a math error. 9.81 m/s2 at 32 pixels/m and 60 frames/s is 0.0872 pixels/frame2, not 5.232.

i'm coming up with 0.005109375 pix / frame^2

9.81 m/s^2 / 32  pix / m = 0.3065625 pix / sec^2

0.3065625 pix / sec^2 / 60 frames / sec = 0.005109375  pix / frame^2.

however, pix/sec^2 / FPS != pix / frame ^2 as i recall.  its not truly a linear relation as i recall. but linear is often an acceptable estimate.

pix/sec^2 / FPS = pix*frames/secs^3 ?  no, that's not right...  been too long since i did this stuff.

hmm, hitting intellectual thicket here,  anyone have a machete handy?

given an acceleration of A per sec, what the equivalent accel per 60th of a second? i think its an integration...

Edited by Norman Barrows

1. 1
2. 2
Rutin
18
3. 3
khawk
15
4. 4
A4L
14
5. 5

• 9
• 13
• 26
• 10
• 11
• Forum Statistics

• Total Topics
633744
• Total Posts
3013665
×