How is time-based programming done?

Question

I'm not really sure what the correct term is, but how are time-based programs like games and simulations made? I've just realized that I've only wrote programs that wait for input, then do something, and am amazed that I have no idea how I would write something like pong :)

How would something like a flight simulator be coded? It obviously wouldn't run as fast as the computer could run it. I'm guessing everything is executed on some kind of cycle. But how do you handle it when a computation takes longer than the cycle.

Also, what is the correct term for this? Searching "time-based programming" doesn't really give me helpful results.

Answer 1

There are two approaches to this, each with advantages and disadvantages.

You can either go frame based, whereby a timer signals n new frames every second. You calculate movement simply by counting elapsed frames. In the case that computation exceeds the available time, the game slows down.

...or, keeping the frame concept, but this time you keep an absolute measure of time, when the next frame is signalled, you calculate world movement via the amount of elapsed time. This means that stuff happens in real-time, but in the case of severe CPU starvation, gameplay will become choppy.

Answer 2

Searching for time-based movement will give you better results.

Basically, you either have a timer loop or an event triggered on a regular clock, depending on your language. If it's a loop, you check the time and only react every 1/60th of a second or so.

Some sites

• http://www.cppgameprogramming.com/
• Ruby game programming
• PyGame

Answer 3

Games are split into simulation (decide what appears, disappears or moves) and rendering (show it on the screen, play sounds). Simulation is designed to be time-dependent: you can tell the simulator "50ms have elapsed" and it will compute 50ms worth of simulation. A typical game loop will render (which takes an arbitrary amount of time), then run the simulator for the duration since the last time the simulator was run.

• If the code runs fast, then the simulator steps will be short (only a few ms) and the game will render the scene more often.

• If the code runs slowly, the simulator steps will have longer steps and there will be proportionally fewer renders.

• If the simulator runs slower than the simulation itself (it takes 100ms to compute 50ms worth of simulation) then the game cannot run. But this is an exceedingly rare situation, and games sometimes have emergency systems that drop the quality of the simulation to improve performance when this happens.

Note that time-dependent does not necessarily mean millisecond-level precision. Some systems implement simulations using time-based functions (traveled distance equals speed times elapsed time), while others run fixed-duration simulation steps.

Answer 4

I think the correct term is "Real-time application".

For the first question, I'm with spender's answer. If you know the elapsed time between two frames, you can calculate (with physics, for example) the new position of the elements based on the previous ones.

Answer 5

This is where you can learn the basics: http://www.gamedev.net/reference/start_here/

Nearly all of the games are programmed in real time architecture and the computer capabilities(and the coding of course :)) determine the frame rate.

Game programming is a really complex job including object modeling, scripting, math calculations, fast and nice rendering algorithms and some other stuff like pixel shaders. So i would recommend you to check out available engines in the first place.(just google "free game engine")

Basic logic is to create an infinite loop (while(true){}) and the loop should:

• Listen for the callbacks - you get the keyb, mouse and system messages here.
• Do the physics due to the time passed till the previous frame and user inputs.
• Render the new frame (gdi, derictX or openGL)

Have fun

Answer 6

There's an old saying that "the clock is an actor". Time-based programs are event-driven programs, but the clock is a constant source of events. At least, that's a fairly common and reasonably easy way of doing things. It falls down if you're doing hard realtime or very high performance things.