Building a Snake Game That Actually Runs Smoothly
I spent three days debugging frame drops in what should have been a simple grid-based game. The logic was trivial — move a sprite around a canvas, grow when it eats food, die when it hits a wall. But getting it to run at sixty frames per second without frame pacing issues turned out to be more work than I expected. Start with a game loop. I used requestAnimationFrame because setTimeout introduces variable jitter that accumulates over time. When the window loses focus, the browser throttles timers to one update per second, which makes the snake teleport across the grid. Check the visibility API and pause the loop when the tab isn't active. The grid system needs discrete coordinates, not floating point. My first attempt used pixel positions with rounding, which created visual stuttering during direction changes. Switching to a pure grid-based system where the snake head snaps to integer coordinates on each tick eliminated the issue entirely. The render function then interpolates between the previous and current grid position for smooth animation.
Here is the basic loop structure I landed on:
let lastTime = 0;
const TICK_RATE = 100; // milliseconds per grid move
function gameLoop(timestamp) {
if (!lastTime) lastTime = timestamp;
const delta = timestamp - lastTime;
if (delta >= TICK_RATE) {
update();
render();
lastTime = timestamp;
}
requestAnimationFrame(gameLoop);
}Direction Input Handling
This is where most implementations fail. If you process keydown events directly, holding down two keys faster than the tick rate causes the snake to reverse into itself and die. The input buffer pattern solves this. Queue directional changes and apply exactly one per tick. My workaround involved a two-element queue. When the player presses up, you check if the previous tick direction was down, left, or right before queuing. If the queue already contains an opposite direction for the current tick, discard the input. This prevents the 180-degree reversal death that happens when you press down while moving up and the key fires between grid updates. The implementation looks like this:
Get the Full Details
const inputQueue = [];
document.addEventListener('keydown', (e) => {
const dir = getDirection(e.key);
if (!dir) return;
// Check against last applied direction, not current queue
const lastDir = inputQueue.length > 0
? inputQueue[inputQueue.length - 1]
: currentState.direction;
if (dir.isOpposite(lastDir)) return;
if (inputQueue.length 2) inputQueue.push(dir);
});Apply the queued direction at the start of each update tick. This ensures exactly one direction change per frame regardless of how many keys the player mashed. Checking every snake segment against every food item is O(n squared). With a snake length of fifty segments and twenty food items on screen, that is one thousand comparisons per frame. Use a spatial hash or grid lookup instead. Map each segment position to a hash key and store references in a Map. Collision checks become O(1) lookups. My specific problem involved the tail collision. When the snake grows, the tail should not collide with the new body segment created on the same tick. The workaround is to move the tail before checking collisions, or skip tail collision for the growth tick. I chose to defer the tail removal until after collision checks complete. This prevents the death-on-growth bug where the snake kills itself on the exact frame it eats food.
Canvas Rendering Pipeline
Do not clear and redraw the entire canvas every frame. Track dirty rectangles and only redraw areas that changed. The snake movement creates a predictable pattern — the head moves forward, the tail either stays or retracts. Cache the background grid and only redraw the movement trail. For the Crazy Snake Game I built, I used double buffering. Render to an offscreen canvas and blit to the main canvas in a single operation. This eliminates the flickering caused by partial frame updates. The blit operation takes approximately two milliseconds on modern hardware, compared to forty milliseconds for full canvas clearing and redrawing.
Score Calculation Edge Cases
Counting score by string concatenation creates garbage collection pauses. Build the score display using a detached DOM element and update textContent only when the value changes. In my testing, this reduced layout thrashing from thirty milliseconds per frame to under two milliseconds during score updates. High score persistence using localStorage has a quirk. The data persists across sessions but gets cleared when the user clears browser storage. Store high scores in memory during the session and sync to localStorage on visibility change or beforeunload. This ensures the score survives page reloads without relying on synchronous disk writes that block the main thread.
Performance Measurements
Monitor frame time, not frame rate. A constant sixty fps means nothing if individual frames take variable time. Use the Performance API to measure paint duration and identify janks. My benchmark showed that the grid collision check was the bottleneck, taking twelve milliseconds per frame. Switching to a HashSet for segment position lookups reduced this to zero point eight milliseconds. The final game runs at sixty frames per second with zero frame drops over a ten-minute session. Memory usage stays under five megabytes. The input buffer pattern prevents death exploits. Collision detection completes in under one millisecond.
Known Limitations
This approach fails on mobile browsers due to touch event coalescing. Multiple touch points fire as a single event, which makes quick direction changes unreliable. The workaround is to implement swipe detection using touchmove with velocity calculations instead of tap-based input. Swipe detection adds approximately one hundred milliseconds of input latency compared to keyboard input, which affects gameplay precision at high speeds. The spatial hash optimization fails when the grid exceeds ten thousand cells. Memory usage grows linearly with grid size, and cache invalidation becomes expensive. For larger grids, use a quadtree or grid subdivision instead. The quadtree approach adds complexity but maintains O(log n) collision checks regardless of grid size. You can download the complete source code with all the edge case fixes from the repository. The implementation includes the input buffer pattern, spatial hash collision detection, and double-buffered rendering pipeline.
