While libraries like Matter.js or Box2D are fantastic, relying on them for every project can lead to bloated codebases, slow load times, and unnecessary latency overhead. For our flagship game series (including War Tanks), we decided to build a high-performance 2D physics engine native to HTML5 Canvas. Here is a definitive guide on how you can architect a lightweight, zero-dependency physics system for your web games.
1. The Game Loop & Delta Time
Physics engines survive on consistency. If your physics calculations are tied to the browser's framerate, a lag spike will break your collision logic (an issue known as tunneling). Always decouple simulation from rendering.
We use requestAnimationFrame passing a deltaTime scalar to update positions. This ensures that an object traveling 100 pixels per second covers the exact same distance whether the browser renders 30 frames or 144 frames per second.
2. Broad-Phase vs. Narrow-Phase Collision
Checking every object against every other object results in an O(n²) catastrophe. If you have 1,000 projectiles, that's 1,000,000 checks per frame.
Broad-Phase: Spatial Hashing
We divide the canvas screen into a grid (e.g., 50x50 pixel cells). As entities move, they register which cell they occupy. During hit detection, an entity *only* checks for collisions against objects residing in the exact same cell or immediately adjacent cells. This drops complexity down to near O(n).
Narrow-Phase: The actual math
Once two objects share a cell, we use AABB (Axis-Aligned Bounding Box) logic for squares, or radial distance checks for circles. Because computing square roots is incredibly slow in JavaScript (`Math.sqrt`), we optimize circle collisions by comparing the squared distances against the squared radii.
if ((dx*dx + dy*dy) < (radius1+radius2)*(radius1+radius2)) { // Collision! }
3. Solving the Tunneling Problem (CCD)
If a bullet travels 100 pixels a frame, and a wall is 10 pixels thick, the bullet will teleport entirely *through* the wall between frames without ever mathematically triggering an intersection. This is tunneling.
To fix this, we implemented a lightweight Continuous Collision Detection (CCD) algorithm via Raycasting. Instead of checking if the bullet's current position overlaps the wall, we cast a mathematical line between the bullet's previous frame position and current position, checking if that invisible vector intersects the wall line.
4. Destructible Terrain (The War Tanks Method)
War Tanks features procedurally generated terrain that permanently deforms when hit. Handling pixel-perfect physics on moving destructible terrain is intensely CPU heavy.
Our solution? We maintain a secondary, invisible "collision canvas". When a bomb explodes, we use the `globalCompositeOperation = 'destination-out'` rule on the Canvas API to carve a literal circle out of the terrain image array. A quick `getImageData` pixel check confirms if a tank has fallen into empty space or is still standing on solid ground, eliminating complex polygon collision mapping.
5. Memory Pooling for Garbage Collection
JavaScript's garbage collector (GC) is the biggest enemy of 60 FPS HTML5 games. Every time you create a `new Vector()` or `new Bullet()`, you trigger memory allocation. When that bullet dies, the GC eventually pauses the game to wipe it, causing noticeable stutter.
We bypassed native GC pauses by using Object Pools. We instantiate an array of 500 bullet objects when the game boots. When a gun fires, we grab a "dead" bullet from the pool, enable it, and update its trajectory. Upon impact, we set its `active` flag to false without destroying the object. The result? Zero garbage collection pauses during intense combat.
The Result
By writing our physics calculations natively with heavily optimized math and spatial hashing grids, games like War Tanks load instantly and process thousands of particles on 5-year-old mobile devices without breaking a sweat. Sometimes, going back to basics is the best path to modern performance.
