The physics behind the bounce

The arena is simulated in discrete steps called ticks. The game runs at 60 ticks per second, so each tick is about 16.67 ms of simulated time.

Every tick, each sphere updates its position by adding its velocity:

This is the discrete form of v = dx/dt. In real physics, velocity is the derivative of position; in a game loop we approximate it by adding velocity × Δt every frame (and we just fold Δt into the units, so "velocity" is measured in pixels per tick).

When you hold W/A/S/D, the game applies an acceleration to your velocity each tick:

This mirrors Newton's second law: F = m·a. The keypress is a constant force, so the sphere's velocity grows linearly until it hits the speed cap — same as a car at full throttle against air resistance.

Let go of the keys and your sphere slows down. The game multiplies velocity by a friction factor every tick:

Because we multiply (not subtract), velocity decays exponentially — fast at first, then ever-slower, never quite hitting zero. That matches real viscous drag (think of a ball slowing in water), where friction force is proportional to current speed.

Fun fact: with a decel of 0.997, your sphere loses about 16.5% of its speed every second of coasting.

Each sphere has a mass. Your starting mass is 40, and your visible radius grows with it (size = 11 + mass/8). Heavier spheres are harder to push around, exactly like real objects.

In collisions we use inverse mass (1/m) as the “pushability” weight. A sphere with twice the mass moves half as much from the same impulse.

When two spheres touch, the game computes the contact normal — the unit vector pointing from one center to the other. Velocities are split into:

• Normal component — along the line of impact (this bounces)
• Tangent component — perpendicular (this slides through unchanged)

The impulse that changes their velocities is:

where e is the coefficient of restitution (bounciness), v_rel·n is how fast the spheres are approaching along the normal, and the denominator is the combined inverse mass. This is the textbook 2D elastic-collision formula from any first-year mechanics course.

Notice e = 1.05 is slightly > 1 — that's why this game feels punchy. Spheres leave a collision with more kinetic energy than they came in with, like a superball on espresso. Real-world collisions always have e ≤ 1.

If two spheres are overlapping after a collision, the game pushes them apart along the normal, weighted by inverse mass:

The lighter sphere moves more. This is the same trick rigid-body physics engines (Box2D, Bullet, Unity's PhysX) use to resolve interpenetration without spheres tunnelling through each other.

1. Read keys → apply acceleration to player velocity
2. Multiply velocity by friction (0.997)
3. Move every sphere by its velocity
4. For each pair, check overlap → resolve with the impulse equation
5. If a sphere drifts past the arena edge → it falls into the void (knockout!)
6. Render the frame

That's it. Six steps, run 60 times a second, produce every chaotic bounce you see. The same loop — integrate, detect, resolve — powers everything from Rocket League to NASA spacecraft simulations. Scale matters; the math doesn't.