Physics in a game is a simulation, not the real thing
When a crate slides off a ledge or a character lands from a jump, the game is not discovering what would happen. It is running a small set of rules, many times per second, that produce something convincing enough. Real physics is continuous and extremely detailed. A game works in tiny discrete steps and uses approximations, because it has a limited amount of time to compute each frame and because exact realism is often not what makes a game fun.
This is why many games with very different art styles share similar physics code. Most game engines include a physics component that handles common tasks, so designers do not have to write the math from scratch.
Movement: position, velocity and acceleration
At the simplest level, an object in a game has a position, a velocity (how fast and in what direction it is moving) and an acceleration (how its velocity is changing). On each step, the game does roughly this:
- Apply forces such as gravity or an engine push, which change the velocity.
- Use the velocity to update the position.
- Check whether the new position causes any collisions, and respond to them.
A falling object illustrates it. Gravity adds a downward amount to velocity on every step, so the object falls faster over time. Move it by that velocity, and the familiar curved arc of a thrown object appears. Nothing in the code needs to mention the curve.
Time steps and why they matter
A game draws frames at some rate, but physics often runs on its own clock. Many games use a fixed time step for physics, advancing the simulation by the same small amount each time, regardless of how long the last frame took. The reason is consistency. If physics used the raw frame time, a computer producing more frames would run slightly different simulations from a slower one, and a jump could reach a different height depending on performance.
A fixed step keeps results more repeatable, which is important for fairness in competitive games, for replays, and for the networked games where several computers must agree on what happened. The game then blends or interpolates the drawn positions between steps so motion still looks smooth. Frame rate and physics rate are related but distinct, which is why a game can look smooth and still feel odd, or the reverse.
Collisions: shapes, not models
Detecting whether two things touch with a detailed 3D model would be far too expensive. Instead, engines attach simple invisible shapes to objects: boxes, spheres, capsules, or a combination. These are often called colliders, and in action games the ones used for attacks and damage are commonly called hitboxes and hurtboxes.
Because the shapes are simpler than the visible art, they sometimes do not match what you see. A character’s sword swing may have a larger or smaller hitbox than the animation suggests, and a tall character may use a capsule so they slide cleanly around corners. Designers tune these shapes for feel. A slightly forgiving hitbox for the player, or a slightly generous ledge-grab window, can make a game feel fair even though it deviates from strict accuracy. In online play, where the position the server sees may differ slightly from what you see, hit registration adds another layer of complexity.
Responding to a collision
Once the engine knows two shapes overlap, it has to decide what to do. A few common responses:
- Stop: the object is pushed back out of the wall or floor so it does not pass through.
- Bounce: velocity is reflected, and some energy may be lost depending on a value usually called bounciness or restitution.
- Slide: friction slows motion along a surface, so a box on a ramp may stay or slip depending on the setting.
- Trigger: nothing physical happens, but the game is told that something entered a zone, such as picking up an item or crossing a finish line.
Each of these is controlled by numbers that designers adjust. Changing friction on an ice level or mass on a heavy object can change how a whole stage feels without any new code.
Why things sometimes go wrong
Because physics is approximated, several familiar glitches have simple causes.
Tunneling occurs when an object moves so fast in one step that it jumps from one side of a thin wall to the other without ever overlapping it. Engines reduce this with continuous collision checks, thicker walls, or limits on speed, but it can still happen in odd cases.
Jitter and instability can appear when many objects are stacked or pressed together, since each correction can disturb the others. A tower of boxes that vibrates is an example.
Clipping happens when a character or item ends up partly inside the world, often because of overlapping colliders or an animation that moves outside its collision shape.
Odd launches can come from a correction that pushes an object out of a tight space with more force than expected.
Some of these glitches get discovered and become part of how people play. Speedrun categories sometimes involve exploiting physics quirks, and developers may leave harmless ones alone, fix them, or even keep them as features.
Realism versus feel
A common design lesson is that the most realistic physics is not necessarily the best. Many platformers use jumps that fall faster than they rise, let the player change direction in mid-air, or allow a jump just after walking off a ledge. Real bodies do not behave this way, but these choices make controls feel responsive and forgiving. Racing games range from simulation-style tire models to arcade handling that is deliberately simplified. Puzzle games may use physics as the central rule, with realism only as a rough guide.
What matters is consistency. If the rules behave predictably, players learn them and use them. If they feel random, players lose trust, even if the behavior is technically realistic.