Game Physics Basics

By Kokil Thapa | Last reviewed: September 2026

Game physics basics decide whether a platformer feels tight or mushy, whether a ball rolls believably, and whether your frame rate survives a pile of crates. If you are building anything interactive—a browser mini-game, a mobile prototype, or a full Unity project—you need a mental model for forces, integration, and collision before you wire up sprites or shaders. This guide walks through the core math and loop patterns that every engine hides behind APIs, with practical notes for web and application developers who touch game-like simulations. For a broader build path, see the companion piece on game development with Unity getting started.

What are game physics basics and why do they matter?

At its core, game physics is applied Newtonian mechanics tuned for real-time performance. You track where things are, how fast they move, and what pushes them. Gravity pulls downward. A jump applies an upward impulse. Friction slows sliding. Collisions stop interpenetration and bounce objects apart.

Players rarely read equations. They feel the result. A 60 Hz simulation with sloppy collision response produces jitter, tunneling, and “sticky” walls. A clean implementation makes controls predictable. That predictability is why arcade racers, puzzle games, and legal-tech training simulators all lean on the same primitives—even when the “game” is really a workflow demo built inside a custom software application.

Game physics basics sit between pure animation and full scientific simulation. You simplify on purpose. Most 2D platformers ignore air resistance. Many 3D action games use kinematic characters that never tip over. The art is knowing which simplifications keep fun intact while staying fast enough for target hardware.

Vectors, scalars, and units

Position and velocity are vectors. Mass and time are scalars. Keep units consistent—meters and seconds in SI, or arbitrary “game units” everywhere, but never mix them silently. A gravity value of 980 often means pixels per second squared in 2D, not 9.8 m/s².

Store 2D vectors as { x, y } or a small struct. Normalize direction vectors before scaling by speed. Dot products tell you if two normals face each other. Cross products (in 2D, the scalar z component) help with torque and winding order.

How does a game physics engine simulate movement each frame?

Most engines use semi-implicit Euler integration because it is cheap and stable enough for games. You update velocity from acceleration, then update position from the new velocity. Explicit Euler (position first, then velocity) drifts more under large timesteps and is rarely used alone in production.

The per-body update looks like this in pseudocode:

function integrate(body, dt):
    body.velocity += body.acceleration * dt
    body.position += body.velocity * dt
    body.acceleration = gravity + externalForces / body.mass

Impulses change velocity instantly—jumps, gun recoil, collision bounce. Forces accumulate over the timestep—gravity, springs, thrusters. Static and kinematic bodies skip dynamics: static never moves; kinematic moves by script without receiving forces.

Angular motion mirrors linear motion. Orientation integrates from angular velocity. Torques change angular velocity. For 3D you also track orientation as a quaternion to avoid gimbal lock. Many 2D tutorials skip rotation until you add spinning crates or angled ramps.

Damping and sleep

Linear and angular damping bleed energy so stacks settle instead of vibrating forever. Sleep flags disable simulation for bodies at rest until something wakes them. Both tricks save CPU on mobile and on busy web experiences that embed canvas games.

What is fixed timestep vs variable timestep in game physics?

Variable timestep uses the real frame delta dt from the display loop. It is simple: one integrate call per rendered frame. When frame times spike, simulation behavior changes. Jump height and collision depth shift. Speedrunners notice. QA notices faster.

Fixed timestep runs the physics step at a constant rate—commonly 60 Hz (FIXED_DT = 1/60) or 120 Hz for fighters. Rendering interpolates between the previous and current physics state for smooth visuals. This pattern is the industry default for deterministic, replay-friendly simulation.

Glenn Fetter’s fixed timestep article remains the canonical reference for this loop. Unity’s physics tick defaults to 50 Hz while rendering may run higher; Godot 4 exposes similar project settings. Match your gameplay code to the physics rate or convert carefully.

const FIXED_DT = 1 / 60;
let accumulator = 0;
let previousState = copyState(world);
let currentState = copyState(world);

function gameLoop(realDt) {
  accumulator += realDt;
  let steps = 0;
  while (accumulator >= FIXED_DT && steps < 5) {
    previousState = copyState(currentState);
    simulate(currentState, FIXED_DT);
    accumulator -= FIXED_DT;
    steps++;
  }
  const alpha = accumulator / FIXED_DT;
  render(interpolate(previousState, currentState, alpha));
}

Cap maximum substeps. If the game hangs for 200 ms, uncapped loops run a dozen physics steps in one frame and stall again—the “spiral of death.” A cap trades accuracy for survival during load spikes, similar to how you throttle API retries in rate-limited web backends.

How do collision detection and response work in games?

Collision splits into broad phase and narrow phase. Broad phase finds candidate pairs cheaply—spatial hash grids, sweep-and-prune, or bounding volume hierarchies. Narrow phase tests exact shapes: circles, AABBs, oriented boxes, capsules, convex polygons.

When overlap exists, you get a contact normal, penetration depth, and contact points. Response pushes bodies apart along the normal and adjusts velocities. Impulse-based resolution uses restitution for bounce and friction for sliding.

Shapes and trade-offs

Restitution e controls bounce: 0 means no bounce, 1 means perfect elastic (rare in games). Combine friction coefficients from both materials—often geometric mean—for believable sliding on ice or rubber.

Continuous collision detection (CCD)

Discrete tests miss fast movers that cross thin walls between frames. CCD sweeps shapes along motion vectors or sub-steps small movements. Box2D offers bullet bodies; Unity exposes CCD modes on Rigidbody. Enable it selectively—full-scene CCD is expensive.

Layer matrices and collision masks filter who hits whom. Put players on layer 1, enemies on 2, pickups on 3. Ignore friendly fire or UI raycasts at the mask level instead of branching in gameplay code.

Which physics engine should you choose for your project?

You rarely write a solver from scratch unless you are learning or building a highly specialized tool. Pick an engine that matches dimension, platform, and licensing.

For a Laravel or WordPress site with a canvas mini-game, a JS library keeps deployment simple—no native plugins. For a standalone title, Unity or Godot gives editor colliders, debug draw, and prefab workflows. On a production booking platform with interactive maps, you might skip full rigid-body sim and use kinematic paths instead.

Profile before swapping engines. Bottlenecks are often too many dynamic bodies, over-tessellated meshes, or per-frame mesh collider rebuilds—not the integrator brand.

Determinism and networking

Fixed point math and locked iteration order matter for rollback netcode. Floating-point across CPU architectures diverges. If multiplayer lockstep is a goal, plan determinism early. Most single-player games tolerate float drift.

What are common game physics bugs and how do you fix them?

These issues show up in jam games and shipped titles alike. Treat the list as a debug checklist.

1. Tunneling: Reduce timestep, enable CCD, or clamp max velocity per frame.
2. Jitter on stacks: Increase solver iterations slightly; add linear/angular damping; allow sleep.
3. Exploding piles: Lower restitution; fix duplicate collision handling; check scale—tiny masses explode under bad tuning.
4. Stuck in walls: Add skin width on character controllers; separate render mesh from physics capsule.
5. Unstable joints: Reduce mass ratios; shorten joint anchors; increase constraint iterations.
6. Frame-dependent jump height: Switch to fixed timestep or apply jump impulse in physics step only.

Visualize colliders in debug mode. Gizmos beat printf debugging. Export pair counts from broad phase if CPU spikes when entity count rises. The same profiling mindset applies when you tune frontend performance on content-heavy sites.

Validate serialized level data with a JSON formatter when tile colliders load from CMS exports. One flipped axis in exported coordinates creates invisible walls that physics respects but artists never see.

Testing physics behavior

Automated tests can assert final positions after N fixed steps with deterministic input. Snapshot tests break when you change gravity or timestep—version those constants. Manual test rooms with labeled slopes, gap widths, and bounce pads speed iteration faster than replaying level one.

Mobile thermal throttling drops FPS; fixed timestep with capped substeps prevents physics from running away. Desktop editors lie about performance. Test on mid-tier Android where possible, especially if the game ships alongside a mobile commerce funnel.

Key Takeaways

• Game physics basics boil down to integrating forces, resolving collisions, and choosing shapes that match your gameplay—not your art mesh.
• Use fixed timestep with interpolation for stable jumps, replays, and predictable collision response.
• Split collision into broad phase (cheap pairs) and narrow phase (exact contacts) before applying impulses.
• Enable CCD only for fast movers; cap physics substeps to survive frame spikes.
• Pick Box2D, Unity, Godot, or a JS library based on platform—not hype—and profile body counts first.
• Debug with visible colliders, deterministic test rooms, and logged contact manifolds when stacks misbehave.

People Also Ask

Do I need to learn calculus for game physics basics?

You need comfortable algebra and vectors, not formal calculus day to day. Engines hide integration. Understanding that acceleration changes velocity and velocity changes position is enough to start. Calculus helps when you tune springs or write custom constraints.

What is the difference between kinematic and dynamic bodies?

Dynamic bodies feel forces and collisions. Kinematic bodies move by script and push dynamics aside but are not pushed back. Static bodies never move. Player capsules are often kinematic or use a specialized character controller to avoid unwanted tipping.

Why does my game physics run slow with many objects?

Pair count grows quickly. A thousand dynamics can mean millions of checks without broad phase. Merge static geometry, sleep resting stacks, simplify meshes, and shrink the active simulation region. Offload decorative objects to fake animation.

Can I use game physics in a web app without a game engine?

Yes. Libraries like Matter.js or cannon-es run in the browser. Keep body counts modest. Run the same fixed timestep loop inside requestAnimationFrame. For enterprise dashboards, consider whether simple easing meets the need before importing a full solver—see enterprise application development patterns for when simulation adds real value.

Ship believable motion with solid game physics basics

Game physics basics are not magic—they are disciplined bookkeeping at 60 steps per second. Model state clearly, integrate on a fixed clock, detect collisions in two phases, and resolve contacts with tuned material properties. Start simple: circles and AABBs before convex decomposition. Add complexity when gameplay demands it, not when a tutorial shows off features.

If you are blending interactive simulation with business software—training tools, configurators, or gamified onboarding—a short architecture review saves weeks of jitter fixes later. Learn about my background across production web systems, or contact us to plan game physics basics inside your next custom build, from browser prototypes to full Unity delivery paired with testing and optimization before launch.