Arcade physics is not a failed attempt at simulation. It is a deliberate model, tuned so that a player can predict an arrow's path after two or three shots. This is exactly what is happening under the hood of every physics game on this site.
The integration step
Every frame, each arrow does the same four things: gravity is added to its vertical velocity, wind is added to its horizontal velocity, both are multiplied by a drag factor, and the position advances by the resulting velocity.
That is a single Euler step, the simplest possible integration. It is not the most numerically accurate method available, and at these speeds and timescales the difference is invisible - which makes the extra complexity of a better integrator pure cost.
The numbers
Gravity is 780 pixels per second squared. Drag retains 99.5% of velocity per second of flight. Launch speeds run from roughly 340 to 1,150 pixels per second depending on draw. Wind is applied as a horizontal acceleration up to a few hundred pixels per second squared depending on the game.
Those values were chosen for readability rather than realism. Real arrows leave a bow at around 60 metres per second and drop a few centimetres over a typical range - a trajectory so flat that a game built on it would have nothing to learn.
Ad space reserved. See README.md to connect an ad unit.
Why the delta time is clamped
The loop runs on requestAnimationFrame, which delivers a frame roughly every 16 milliseconds - but not when the tab is backgrounded, the device is throttling, or the browser is busy.
If a 900 millisecond gap were fed straight into the integration, every arrow would teleport most of the way across the field in a single step and pass straight through everything. So the step is clamped to 50 milliseconds, and games pause entirely when the tab is hidden.
Swept collision detection
A fast arrow can travel further in one frame than a small target is wide. Testing only the arrow's end position each frame would let it pass straight through.
So collision is tested against the segment between the arrow's previous and current positions, using a ray-circle intersection that returns the fraction along the segment where contact occurred. That fraction is also what places the arrow mark on the target at the correct spot.
Why the trajectory preview is exact
The preview runs the identical integration as the arrow, with the same gravity, drag and wind values, for a fixed number of steps. It is a simulation of the shot rather than an analytical approximation of it.
That is why the guidance throughout this site is to trust the preview completely. If it lands short, the arrow will land short - there is no approximation error to account for.
What is deliberately missing
No arrow spin, no fletching drag, no lift, no variable air density, no bow torque, no release inconsistency. None of these would make the games better; all of them would make the outcome less predictable from what is on screen.
The design principle throughout is that a player must be able to explain every miss. A model with hidden variables cannot deliver that, however accurate it is.
Key takeaways
- Each frame applies gravity, wind and drag to velocity, then advances position - a single Euler step.
- Gravity is 780 px/s squared and launch speeds run 340-1150 px/s, tuned for readability not realism.
- The frame delta is clamped so a stalled tab cannot teleport arrows through targets.
- Collision is swept along the arrow's path, not tested only at its end position.
- The trajectory preview runs the same integration as the arrow, so it is exact.
Frequently asked questions
Is the physics in these games realistic?
No, deliberately. Real arrows fly far flatter and faster. The model is exaggerated so the arc is visible on screen and learnable within a few shots.
Why does the game pause when I switch tabs?
Because a large frame gap would break the simulation, and because running a game loop in a hidden tab wastes battery. The run resumes exactly where it stopped.
Can an arrow pass through a small target by accident?
No. Collision is tested along the whole path the arrow travelled that frame, not just at its end point, so fast arrows cannot tunnel through targets.
Does the trajectory preview cut corners for performance?
No. It runs the same step function as the real arrow. Any difference between the preview and the shot comes from your draw changing, not from the maths.