VB:Tutorials:Time Based Modelling IT
What is Time Based Modelling?
Time based modelling is a method of programming that keeps the animation and game speed constant regardless of the computer the game is being played on.
Two methods of controlling game speed Firstly, we need some way to control game speed. First time game programmers typically hardcode in numbers for things such as movement. For example, a character may move 1 pixel a frame. If you are getting 20 Frames per Second, it will move 20 pixels each second. This may work fine on the developement computer, but what happens if its moved to different computers?
20 FPS = 20 pixels/second
40 FPS = 40 pixels/second
200 FPS = 200 pixels/second
Obviously this is bad. Faster computers will run the animations faster, and slower computers will run slower. There are two choices to combat this. The first is known as Frame Limiting.
Frame Limiting is very simple. You limit how many frames a second are allowed to be shown. Here is a simple pseudo-code example:
Do While bRunning = True
NewTick = GetTickCount()
If OldTick + 1000 > NewTick Then
OldTick = NewTick Render Routines
Each time through the loop, it checks to see if the old tick plus 1000 is greater than the newtick. By adjusting the number (1000), you can adjust how many frames per second it is limited to. This method has the advantage of being simple to set up.
But isnt it slightly unfair that someone with an amazingly fast Graphics card should run at the same FPS as someone with a junky one?
No, its not. Thats why there is another method, called Time Based Modeling. This approach is actually very simple, but requires a little extra work. This method does not use units/frame, but instead uses units/second. The number of units per second stay's constant, regardless of how fast/slow the computer is.
Quick example. We have a character that should move 20 pixels/second. We find the elapsed time between frames, and use that as a weighting to multiply against. For instance, say the elapsed time (time between each frame) was 50 milliseconds. The character would move 1 pixel (20 pixels/second * 0.05 seconds) On a slower computer, the elapsed time may be 100 milliseconds. The character would move 2 pixels (20 pixels/second * 0.1 seconds). A very fast computer, the elapsed time may be 10 milliseconds. The character would move .2 pixels (20 pixels/second * .01 seconds).
See the pattern yet? The units/frame varies depending on the computer, but the units/second stays constant. This allows for faster computers to take advantage of their speed, while displaying the animations correctly. In practice, this is fairly easy to set up.
NewTick = GetTickCount()
ElapsedTime = NewTick - OldTick
OldTick = NewTick
This snippet of code should go at the beginning of your loop. Each time through the game loop, it will determine how much time has elapsed between frames. Using the elapsed time is just as simple:
PlayerX = PlayerX + (10 * ElapsedTime)
Its that easy! Think of the '10' above as the units/second. We want the PlayerX to increment 10 each second. This is multiplied by the ElapsedTime so that we only move it a fraction of the way there.
Revision by Javin (12-21-2003)
Do keep in mind that while time-based modeling is a VERY good idea, it can introduce some interesting problems. Especially in the realm of your 2D animations. EVERYTHING in the game that moves, or is rendered, MUST be based on that time factor if you choose to use it. If you've got a sprite rendering (even in 3D games you'll render animated sprites on occasion) then you need to make sure that now, instead of incrementing the sprite's image every loop, you increment it only when the appropriate amount of time has passed.
Further advantages that this gives you, however, is that very few computers run at a CONSTANT speed. There's often other things happening in the background that could cause your framerates to fluctuate severely. Make a game that's based on the framerate, and you're asking for trouble.
Revision by Mutos (12-21-03):
Time-based modelling also has the advantage, that you're no longer limited to 1:1 on real:game time ratio. For instance, in Elite, while you were travelling across a stellar system, that would require some days, you could switch to time ratio 1:10, 1:100 or even 1:1000, that is PC time is 1000 times faster than player time. Easy to do with time-based modelling, you would just have to multiply the physics ratio by the framerate ratio.