I agree with the time based movement control. The only thing you have to do is to convert the velocity (or whatever) from a per second (or per hour) format into per frame-time format. While initializing multiply by frame time and when finalizing frame physics data multiply by the inverse of the frame time.

I agree with Clootie just partially. I have done several implementations of physics engines and I can tell you that there will be always a quadratic time paradox (a mathematical error) until you use a constant cycle time for physics engine (simulated and asynchronous to the graphics engine). But 20Hz is not enough. I would use like 50Hz. This means update each 20 milliseconds... I would even consider to simulate more often using shorter times if using step based physics engine (e.g. rigid body engine). A lot of engines, even commercial do not recognise the frame time variance in physics engine as a problem, but they should if the physical model is based on non-linear calculations as s = 1/2*a*t^2.

-kk
developer, pythianproject.org