How Physics Simulations Use Numerical Methods

Drop a ball in a video game and it falls, bounces, and settles, all in real time, sixty times a second.

But the game doesn't know calculus. It's never seen Newton's equations of motion written out symbolically, and it definitely can't solve them. All it has is arithmetic: addition, multiplication, nothing fancier.

So how does it get gravity right?

It doesn't solve the motion. It guesses the next instant, over and over, thousands of times a second. That's the entire trick behind physics simulation. Once you see it, you'll notice it everywhere: every game, every orbit tracker, every weather model you've ever looked at.

Newton's laws are a rule, not a formula

Newton's second law, $F = ma$, tells you the acceleration if you know the force and the mass. But acceleration is just the rate of change of velocity, and velocity is the rate of change of position. So really you have two statements chained together:

For a handful of textbook setups, constant gravity, no air resistance, you can integrate these by hand and land on a clean formula for $x(t)$. We walk through exactly that case in How Is Calculus Used in Physics? A Connected View.

Real forces are rarely that polite, though. Air drag depends on speed. The pull between two orbiting bodies depends on distance, which keeps changing as they move. A spring pulls harder the further you stretch it. Add a second spring or a second mass and no algebra trick untangles it. There's no formula sitting there waiting to be found. The equation only tells you the slope, everywhere, all at once, and finding the actual path means walking that slope forward.

Walking the rule forward, one short guess at a time

We already have a name for that walk: Euler's method, the simplest way to follow a slope rule without solving anything.

Let's watch it work on the simplest slope rule there is: $dy/dt = -y$, something that shrinks in proportion to its own size. Starting at $y = 5$, the exact answer is $y(t) = 5e^{-t}$. Pretend you don't know that formula, though. All you're allowed to do is check the current slope and take one small step.

We write that update rule as:

where $h$ is the size of the step and $f$ is whatever the slope happens to be right now.

Watch the red line. Shrink $h$ and it hugs the dashed exact curve almost perfectly. Push $h$ past 1 and the polygon starts overshooting so hard it flips to the wrong side of zero every step, still shrinking overall, just badly. That overshoot is the whole reason step size matters.

A falling ball needs two numbers updated together, not one

Motion isn't one slope rule, it's two, tied to each other. Position depends on velocity. Velocity depends on force. So a simulator has to update both every step, each one using the other's current value:

Take a mass on a spring as the cleanest example, scaled so the spring constant and the mass are both 1. Pull it out to $x = 1$ and let go. The restoring force is $a = -x$, which gives us a pair of slope rules tied together:

This one has an exact answer too: $x(t) = \cos t$. Plot position against velocity instead of against time, and that exact answer traces a perfect circle. Position and velocity trade off, energy stays constant, and the circle never grows or shrinks.

Numerical stepping doesn't know any of that. It just applies the update rule, blindly, one step at a time.

Click through the three methods. Euler's circle isn't a circle at all, it's a slow outward spiral. Every step adds a sliver of energy that was never there to begin with. Heun does better, since it checks the slope twice per step and averages them, but it still drifts outward. RK4, which samples the slope four times per step at different points, tracks the true circle so closely you'd need to zoom in hard to spot the gap.

That outward drift isn't a rounding error you can shrug off. It's the reason naive simulations gain energy from nowhere and eventually fall apart.

Watch a simulation actually blow up

Physics engines run inside a game loop. Every frame, the engine has a few milliseconds to update every object's position, and it uses whatever step size fits that budget. Push the step size up, whether because there are too many objects on screen or the frame rate drops, and the same energy leak from the last section shows up in real time, in front of you.

Drag the step size up while it's running. At first the mass just orbits the anchor a little wider each pass. Keep pushing and the swings turn violent within a couple of seconds, launching the mass off the edge of the track. Nothing about the physics changed. Only the size of the arithmetic step did.

Some stepping rules are just smarter

We already saw RK4 beat Euler in the spring example. The reason isn't magic. RK4 samples the slope at four points inside each step instead of one, then blends them so the errors from the early samples cancel out. The full derivation of what "order" means and why it works is in How to Solve Differential Equations: First Order Methods. Here we just want the payoff.

Drag the step count up. Both errors fall, but not at the same rate. Euler's error falls in a straight line with slope 1 on that log-log grid: halve the step, halve the error. RK4's line falls with slope 4: halve the step, and the error drops to a sixteenth. That's not a small difference. By the time Euler needs a thousand steps to get somewhere useful, RK4 already got there in ten.

So what do real engines actually use?

Game engines like Box2D or the solver inside Unity mostly use a small tweak called semi-implicit Euler, sometimes called symplectic Euler. Update velocity first using the current force, then update position using that new velocity instead of the old one. It costs exactly the same one slope check per step as plain Euler, but instead of leaking energy outward forever, it just wobbles around the true energy level and never fully escapes it. That's cheap enough to run for thousands of objects at sixty frames a second, and stable enough that a stack of boxes doesn't quietly gain energy and start vibrating apart on its own.

Serious scientific simulation leans the other way. Spacecraft trajectory calculations, molecular dynamics, weather models, these mostly use RK4 or higher order methods, sometimes adjusting the step size automatically based on how fast the local error is growing. A spacecraft gets one shot at the right orbit. No amount of spare frame budget matters if the answer is wrong three years from now.

Same arithmetic idea, tuned for two completely different priorities: speed against accuracy.

The short version

A physics simulation never solves Newton's laws exactly. It takes the current position and velocity, checks the current slope, and guesses a tiny step ahead, then repeats that guess thousands of times a second. Euler's method is the simplest version of that guess: one slope check, one step. Smarter methods like Heun and RK4 check the slope several times inside a single step and blend the results, and that's the entire reason their error shrinks so much faster as the step gets smaller.

The step size you choose isn't just a knob for precision. Push it too far and a simulation doesn't just get slightly wrong, it gains energy from nowhere and falls apart. That trade-off, between how large a guess you can afford and how wrong that guess is allowed to be, is why your phone can run real-time game physics and why it still takes a supercomputer weeks to simulate next month's weather.

All simulations above run live in your browser using nothing but the update rules described in this post: forward Euler, Heun's method, and classical RK4. The spring simulator uses a real fixed-timestep loop, the same pattern used inside actual game engines.