Simple physics math

I hvaen't taken physics since high school, and since that time I've probably done more damage to my brain cells that I care to think about(or can think about...)

Anyway, I don't want some complex physics engine for a simple 2d scroller game, I just want basic accel/velocity/position stuff.

How should I get this to work?
My idea currently is to check for keyDown, when keyDown occurs set the acceleration to something. Then the event looper timer that fires every 60th of a second(would I be correct in saying that is 60 fps, and someone once said a human mind can't differentiate between 45 and 135, because we can only process 45) takes the acceleration and drops it into the velocity based on the time step (timestep * acceleration cancels the s^2, but since it's 60th's of a second...?) and then moves a certain number of pixels based on the speed.

When I receive a keyUp event, sets the array of movement keys to false, and then removes the acceleration from the sprite...however, it's still got speed and continues moving.

Also, is a good way to determine if a sprite needs to move to the next frame by just seeing if the speed >0?

Quote:Originally posted by LongJumper I hvaen't taken physics since high school, and since that time I've probably done more damage to my brain cells that I care to think about(or can think about...)

Anyway, I don't want some complex physics engine for a simple 2d scroller game, I just want basic accel/velocity/position stuff.

How should I get this to work?
My idea currently is to check for keyDown, when keyDown occurs set the acceleration to something. Then the event looper timer that fires every 60th of a second(would I be correct in saying that is 60 fps, and someone once said a human mind can't differentiate between 45 and 135, because we can only process 45) takes the acceleration and drops it into the velocity based on the time step (timestep * acceleration cancels the s^2, but since it's 60th's of a second...?) and then moves a certain number of pixels based on the speed.

When I receive a keyUp event, sets the array of movement keys to false, and then removes the acceleration from the sprite...however, it's still got speed and continues moving.

Also, is a good way to determine if a sprite needs to move to the next frame by just seeing if the speed >0?

Thanks in advance.

The physics you describe sounds fine. There are variants. Depending on how you want the player to control the sprite, you may opt to allow the player to set a throttle amount that in turn sets the target velocity. Then the player's acceleration would be applied automatically to try and reach the target velocity. You may also elect to add a dampening force, or a velocity cap, and/or the ability to reverse thrust without needing to turn the sprite 180 degrees around. Also, strafing. It all depends on the game and how you want the player to control the ship/avatar.

The speed > 0 test you describe might be appropriate if the 2nd frame is of the ship with thrusters on, for instance. If the second frame was something else then you might want to advance the frame at regular time intervals, or at random times when the player isn't doing anything (otherwise known as "idle animations.")

Rather than hard-wiring the frame rate to 1/60 many people elect to have the timer fire as fast as possible and all the physics calculations are done based on however much time has elapsed. This makes your game adapt to the hardware if someone can't run at 60 fps. Also, the occasional frame rate stutter is much less noticeable when you do it that way; if a frame takes twice as long to draw, the object moves twice as far. It makes the motion seem steadier.

An advanced technique is to have the physics "frame rate" be completely different from the screen frame rate. This lets you get more accurate collision detection, for instance, by updating the objects in the world as quickly as possible, while updating the screen only when enough time has elapsed. This is overkill for many types of games, I think.

There you have it, a dump of my brain's entire contents.
Hope it helps.

I found the following article very helpful when i was looking at this sort of stuff. It goes into a lot of car specific detail (gear ratios, skidding etc...) but the first couple of pages deal quite well with the basics like acceleration, velocity and drag.

[oops, I just re-read this and it looks like I'm dissing Matt's comments. No such thing was intended. He makes some very good points. ]

It's important that you determine what sort of timing mechanism your game will use early on. Not all games are created equal, and different types of games require different approaches for the best result! One size does not fit all!

For a 2D shooter, where you have lots of sprites moving around, you have two basic options:

1) absolute time, as described earlier in the thread. This is where you let the frame rate go as high as it can, but you do all movement based on speeds and how much time has actually passed,

2) frame based time. This is where your frame rate is fixed to a maximum level, and your game processing is locked to this frame as well.

Both approaches have their pros and cons. I've seen a lot of books and articles written by people who pretty much say that you should just use approach 1. They are wrong, and probably haven't written a 2D shooter.

If you go with approach (1), then the frame rate can be variable, which can be quite unsatisfying to the player at times. More importantly, if the frame rate plummets, the objects STILL move at the same rate. For a sprite based game, especially with small sprites, this can be very nasty. (Because the objects are moving at a fast speed but the screen updates are fewer, giving the player unacceptable reaction time.)

Approach (2) means that if your frame rate plummets, the entire game processing slows down as well. This is bad in some times of game (like a 3D corridor shooter) but is not as terrible as you may think in a sprite game. This is because it's usually better to be able to see, with accuracy, the results of your firing and movement, when there are zillions of small objects on the screen. You do NOT want small objects flitting around the screen in large jumps, which can happen with approach (1).

Approach (2) also has the huge benefit of lending itself better to a deterministic model. What this means is that you set the random seed, and feed the inputs to the game, and the game engine will run from those inputs. Those inputs can be read from a film file, allowing you to play back recordings of each game with ABSOLUTE precision. This is invaluable during game design and testing, as results are reproducible and allows you to track down tricky bugs (such as forgetting to reset variables between games or levels).

You can do films with approach (1), but it's a pain in the bum, the films are usually much bigger and they're not as useful for tracking game logic bugs.

Whichever model you choose, or even a hybrid, it comes down to what YOUR game needs. Good luck.

Oh, and if you go with the frame based approach, there's another cool thing you can do really easily: unlock the drawing from the game processing.

This means that you can slow down or speed up the game logic without affecting the frame rate. It's easy to implement game speeds this way of:

Half
1/4
1/8th
1/16th
1/32nd
Stopped.

By doing this, you still get inputs such as a console, and the screen still updates in real time, but you can slow the game down to a crawl and even go through each game iteration step by step, allowing you to really fine things and fix bugs and resolve that nagging "Did that bullet REALLY fly through that ship???" feeling.

Another example is "stopping" the game at a certain point, then entering the game console to tell the game to display information about a certain object, or even modifying the state of an object and seeing it update in real time.

Myth TFL was the first game to do this really well. You could even speed up the action in films as well, without having to do awkward and slow game preloading as required in film playback enabled games like the old F/A-18 Hornet.

Mars, good info. I hinted that different games have different needs but I couldn't have articulated pros and cons of the different approaches like you did. (For starters, I have no experience with sprite games.)

Your response also gave me insight into a problem that Descent 3 has with saved films: the results of the film can change if the frame rate of the playback machine is drastically different! (They give you a way to cap the frame rate before playing back the film, which mostly helps...)

Quote:Originally posted by mars Approach (2) also has the huge benefit of lending itself better to a deterministic model. What this means is that you set the random seed, and feed the inputs to the game, and the game engine will run from those inputs. Those inputs can be read from a film file, allowing you to play back recordings of each game with ABSOLUTE precision. This is [b]invaluable during game design and testing, as results are reproducible and allows you to track down tricky bugs (such as forgetting to reset variables between games or levels).[/b]

Has anyone done this with sprites that use floats? Will it be deterministic from Mac to Mac and even (gulp) x86 machines? That is - will the floating point math give *exactly* the same results from machine to machine - processor to processor - etc... Or should one stick to fixed point math if you want to do films?

I've used floats extensively with films, and the films run exactly the same across all Mac models, that I know of. I _believe_ the same films run on Windows boxes as well, but haven't actually checked them.

Precision is an issue though, for some implementations. I remember that Bungie had big problems with Out of Sync errors on Myth TFL, and to a lesser extent, Myth II, because of floating point precision differences between processors, so they ended up going with fixed point.

Similarly, some 3D rendering applications give you a "baked" option for files, so that scenes can be transferred for processing to other platforms (e.g. render farms) and all the particles will be in the right places on all machines.

For the record, I don't use fixeds at all.

Even if the precision does lead to deterministic errors, all is not lost. The film may eventually become useless when distributed to another machine, but is still highly useful for your own debugging/development work, and for letting a player see replays on his own machine.