# Can Time.deltaTime work to AddForce on Rigidbody over time?

Can a person use Time.deltaTime to AddRelativeForce -(or Torque) so a rigidbody can move while the player holds down the move button? This maybe newbie question I know. I have had usually good luck with scripting. This is my first time trying to make a moving rigidbody with script. thank you

Normally you don't want to scale applied forces and torques by the current time step. (You can do it, but it doesn't really make sense to do so.)

If I store the player's thrust in units per second squared (added force per second), shouldn't I multiply by Time.deltaTime?

Force isn't measured in units per second squared, but rather (mass units * length units) / (seconds squared), e.g. (kg*m)/s^2 in SI units.

For most physics engines, updating of a rigid body's velocity and position will look something like this (there are variations and various types of integrators that are used, but the following is pretty typical):

``````acceleration = accumulated_force / mass;
velocity += acceleration * time_step;
position += velocity * time_step;

``````

As you can see, the integrator already scales the force by the time step.

In any case, scaling the force by the time step hasn't seemed to be common practice with the physics engines I'm familiar with. (For example, if you look at the examples provided with the Box2D physics engine, applied forces are not scaled in this way.)

Note also that in the examples provided in the Unity documentation, applied forces are not scaled by the time step. (That said, there are some errors and inaccuracies in the Unity docs, so the fact that the time step is not used in these examples doesn't necessarily settle the issue.)

In theory at least, I don't think scaling of applied forces according to the time step is correct or necessary; if scaling of applied forces seems to be necessary to get consistent results in Unity, then it seems to me that likely indicates some sort of flaw in how Unity is handling physics updates.

That said, I'd have to do some research and/or experimentation to confirm my suppositions, so I'll just have to submit the above as my best guess and leave it at that. I suppose empirical results are what matter the most here, so if in practice scaling of applied forces seems to be a requirement, then I guess that's all that really matters.

I would actually highly recommend you do so.

In all my testing with my early Marble Madness-like project, if you don't multiply your AddForce by Time.deltaTime, the force will be stronger when you have a high FPS, and weaker when you have a low FPS. You won't see this happen in the editor, but try this:

Don't multiply by Time.deltaTime, and play in the editor. Note the speed. Then build an executable and run it, and suddenly you'll notice it's applying way too much force. Time.deltaTime is absolutely necessary to normalize the force applied across all frame rates, and for that matter, to just make sure that what you're seeing in the editor is what you'll get when you run the executable.