60 FPS with 600 Snakes: How I Got the Browser Client to Survive a Room Full of Snakes

The server took me one week. The client took another. Phaser 3 + React 19 + Vite. I know there are magic numbers, TODO comments, and obviously cleaner ways to write half of it — but it runs at a steady 60 FPS on a regular laptop, and that's good enough for a side project.

This post is about how I kept the browser from dying.

---

1. Why Mix React and Phaser?

I first tried building the UI entirely inside Phaser. Bad idea — Phaser's UI system is painful for anything beyond a score counter. I ended up with React 19 + Tailwind CSS for menus, HUD, and leaderboard, and Phaser 3 for the game canvas. They communicate through callbacks: React sends commands to Phaser, Phaser pushes score and leaderboard data back to React.

The upside is React's reconciliation never touches the game render loop because the Phaser canvas and React DOM live in separate worlds.

┌─────────────────────────────────────┐
│  React DOM (Tailwind CSS)           │
│  - Main menu, HUD, leaderboard      │
│  - Skin selector, i18n              │
└──────────────┬──────────────────────┘
               │ props / callbacks
┌──────────────▼──────────────────────┐
│  Phaser 3 Game                      │
│  - NetworkedGameScene               │
│  - WebSocket input / state sync     │
│  - 60 FPS fixed-timestep loop       │
└─────────────────────────────────────┘

Client Architecture Flow

My targets were modest but tricky:

• 60 FPS while rendering 100 visible snakes and ~200 food items.
• Input latency < 50 ms — the mouse must feel instant.
• Remote snakes must move smoothly, never snap to position.

---

2. Viewport Culling: The Foundation of Scale

The single most important optimization is don't render what the player cannot see. On a 16,000×16,000 map with 600 snakes, creating every Phaser game object every frame would obliterate the frame rate.

2.1 ViewportManager

class ViewportManager {
    viewRadius: number = 1000;   // strict visible radius
    bufferRadius: number = 100;  // hysteresis buffer

    isInViewport(x, y, centerX, centerY): boolean {
        const dist = sqrt((x - centerX)² + (y - centerY)²);
        return dist < (viewRadius + bufferRadius);
    }

    updateViewRadius() {
        const w = scene.cameras.main.width;
        const h = scene.cameras.main.height;
        // Cap at 1200 px to limit max render load regardless of monitor size
        this.viewRadius = min(sqrt(w² + h²) / 2 + 100, 1200);
    }
}

The buffer radius prevents objects at the screen edge from flickering in and out as the camera moves. An object must move 100 px beyond the visible edge before its render objects are destroyed.

2.2 Lazy Render-Object Lifecycle

Each snake has two layers:

Layer	Cost	Lifetime
LocalSnake (data)	Cheap (numbers + arrays)	Permanent while snake exists in server state
Phaser objects (head, eyes, body circles, text)	Expensive (GPU textures, draw calls)	Only while snake is in viewport

// On server state update
for each snake in state:
    const inViewport = viewportManager.isInViewport(snake.x, snake.y, cameraCenter);

    if (inViewport && !snake.isRendered):
        snake.createRenderObjects();   // Allocate Phaser objects
    else if (!inViewport && snake.isRendered):
        // 3-second grace period before destroying (anti-flicker)
        if (now - snake.lastVisibleTime > 3000):
            snake.destroyRenderObjects(); // Free GPU resources

Why destroy instead of hide? I originally used setVisible(false). Frame rate barely improved. Then I read the Phaser docs and realized GameObjects still participate in internal updates — tweens, transforms, culling checks — even when invisible. Only destroy() removes them from the scene graph entirely. That debugging session ate my entire afternoon.

Lazy Render Lifecycle Flow

2.3 Food Culling

Food uses the same pattern:

for each food in serverState:
    const inViewport = viewportManager.isInViewport(food.x, food.y, centerX, centerY);

    if (inViewport && !foods.has(foodId)):
        createFoodSprite(food);      // Spawn new circle
    else if (!inViewport && foods.has(foodId)):
        destroyFoodSprite(foodId);   // Immediate cleanup
    else if (inViewport && foods.has(foodId)):
        updateFoodPosition(food);    // Magnetic attraction movement

With 1,600 total food items, typically only 80–150 are visible at once. That 90% reduction is the single biggest reason I can hold 60 FPS.

---

3. Client-Side Prediction & Server Reconciliation

My first attempt was pure server-authoritative: send input, wait for the server, then move. Even 50 ms of latency felt like dragging through mud. I switched to client prediction + server reconciliation.

3.1 Prediction (Local Player)

Every frame I simulate the local snake forward using the exact same physics constants as the server:

predict(inputAngle: number, isBoosting: boolean, deltaTime: number) {
    const speed = isBoosting ? BOOST_SPEED : BASE_SPEED;
    const dt = deltaTime / 1000;

    const vx = cos(inputAngle) * speed * dt;
    const vy = sin(inputAngle) * speed * dt;

    this.x += vx;
    this.y += vy;
    this.angle = inputAngle;

    this.updateTrail(this.x, this.y);   // Same trail algorithm as server
}

This runs at 60 Hz inside the fixed-tick loop. The player feels zero input latency.

3.2 Interpolation (Remote Players)

Other players cannot be predicted — I don't know their inputs. Instead I interpolate toward the latest server position:

interpolate(deltaTime: number) {
    // Lerp toward server state at 20% per frame
    this.x = lerp(this.x, this.serverX, 0.2);
    this.y = lerp(this.y, this.serverY, 0.2);

    // Angle wrap-around for shortest path
    let angleDiff = this.serverAngle - this.angle;
    while (angleDiff > PI)  angleDiff -= 2*PI;
    while (angleDiff < -PI) angleDiff += 2*PI;
    this.angle += angleDiff * 0.2;

    this.updateTrail(this.x, this.y);
}

0.2 is a value I tuned by hand.

• Above 0.5: jerky, snaps to server state.
• Below 0.1: sluggish, feels underwater.
• 0.2 felt right after an evening of tweaking.

3.3 Reconciliation

Prediction inevitably drifts from the server. I reconcile in two layers:

reconcile() {
    const diffX = this.serverX - this.x;
    const diffY = this.serverY - this.y;

    // Small drift: invisible 5% nudge per frame
    if (abs(diffX) > 1 || abs(diffY) > 1) {
        this.x += diffX * 0.05;
        this.y += diffY * 0.05;
    }

    // Large drift (> 100 px): teleport and reset trail
    if (abs(diffX) > 100 || abs(diffY) > 100) {
        this.x = this.serverX;
        this.y = this.serverY;
        this.initTrail();   // Rebuild from new position
    }
}

The 5% nudge absorbs normal tick drift. Players never notice it. The 100 px hard-sync handles respawns, lag spikes, or anything else where smooth correction would look weirder than a snap.

Prediction & Reconciliation Flow

---

4. Trail-Based Snake Rendering

I use the same trail-following algorithm on the client that I built for the server. My first attempt simulated every body segment with independent physics. Frame rate died instantly.

4.1 Algorithm

TRAIL_STEP = 2;           // pixels between trail points
SEGMENT_DISTANCE = 10;    // pixels between body segments

updateTrail(headX: number, headY: number) {
    const dist = distance(lastHeadPosition, {x: headX, y: headY});

    if (dist >= TRAIL_STEP) {
        const steps = floor(dist / TRAIL_STEP);
        for (let i = 1; i <= steps; i++) {
            const t = i / steps;
            trail.unshift({
                x: lerp(lastHeadPosition.x, headX, t),
                y: lerp(lastHeadPosition.y, headY, t)
            });
        }
        lastHeadPosition = {x: headX, y: headY};

        // Prevent unbounded growth
        const maxPoints = (bodySegments + 2) * (SEGMENT_DISTANCE / TRAIL_STEP);
        if (trail.length > maxPoints) trail.splice(maxPoints);
    }
}

getSegmentPositions(): Vector2[] {
    const pointsPerSegment = SEGMENT_DISTANCE / TRAIL_STEP;  // = 5
    const positions = [];
    for (let i = 0; i < bodySegments; i++) {
        const idx = floor((i + 1) * pointsPerSegment);
        if (trail[idx]) positions.push({...trail[idx]});
    }
    return positions;
}

4.2 Why This Is Fast

• One head simulation per snake, not N body segments.
• Trail is a flat array — no linked lists, no complex structures.
• Segment positions are pure lookups into the trail array, zero physics.
• Memory is bounded: max 400 segments × 5 points/segment ≈ 2,000 vectors per snake.

Trail Update Flow

---

5. Render Optimizations in Detail

5.1 Body-Part Culling

Even when a snake is in viewport, not all its body segments need to be visible:

for (let i = 0; i < bodyParts.length; i++) {
    const partInViewport = viewportManager.isInViewportStrict(
        positions[i].x, positions[i].y, centerX, centerY
    );
    bodyParts[i].setVisible(partInViewport || this.isLocalPlayer);
}

The local player's entire body is always rendered (so the tail is visible when wrapping around), but remote snakes hide off-screen segments.

5.2 Dynamic Body-Part Allocation

I do not pre-allocate all 400 possible segments. I grow and shrink dynamically:

// Grow
while (bodyParts.length < positions.length) {
    const part = scene.add.circle(0, 0, radius * 0.9, 0xffffff);
    bodyParts.push(part);
}

// Shrink
while (bodyParts.length > positions.length) {
    bodyParts.pop()?.destroy();
}

This prevents allocating hundreds of invisible circles for every newly spawned snake.

5.3 Visual Tapering

To make long snakes look organic, the radius tapers toward the tail:

const taperFactor = 1 - (i / bodyParts.length) * 0.3;
bodyParts[i].setRadius(radius * 0.9 * taperFactor);

Computationally trivial, but the visual improvement is huge without extra sprites or textures.

5.4 Skin Caching

Custom skins read from localStorage. I originally read it every frame and noticed occasional frame drops. Now I read once on skin change and cache:

loadCustomSkin() {
    if (skinId === 'custom') {
        const cfg = loadCustomSkinConfig();   // Reads localStorage once
        this.customHeadColor = hexToNumber(cfg.headColor);
        this.customBodyColors = cfg.bodyColors.map(hexToNumber);
    }
}

localStorage is only accessed when the skin changes, never during the render loop.

5.5 Lightweight Food Effects

I skipped post-processing shaders — Phaser's postFX is expensive on low-end machines. I use simple tweens:

// Normal food: gentle pulse
tweens.add({
    targets: food,
    alpha: { from: 0.6, to: 1 },
    scale: { from: 0.9, to: 1.1 },
    duration: 800 + random() * 400,
    yoyo: true,
    repeat: -1,
    ease: 'Sine.easeInOut'
});

No postFX, no particle emitters — just alpha and scale that the GPU handles for free.

---

6. Network Efficiency

6.1 Input Throttling

My first attempt sent a WebSocket message on every pointermove. With fast mouse movement that hit hundreds of messages per second and choked the connection. I switched to a fixed 60 Hz sample rate:

this.time.addEvent({
    delay: 1000 / 60,      // 16.67 ms
    callback: sendInput,
    loop: true
});

sendInput() {
    ws.send(JSON.stringify({
        type: 'input',
        angle: this.inputAngle,
        boosting: this.isBoosting
    }));
}

Upload bandwidth is now hard-capped at ~60 small JSON messages/second, no matter how fast the mouse moves.

6.2 Client-Authoritative Food Eating

To hide network latency, the client predicts food collisions locally:

private checkLocalPlayerFoodCollision() {
    const eatRadius = snake.radius + 20;  // Looser than server

    foods.forEach((foodObj, foodId) => {
        const dist = distance(snake, foodObj);
        if (dist < eatRadius) {
            // 1. Apply locally immediately
            snake.score += foodValue;
            snake.bodySegments = calculateBodySegments(snake.score);
            snake.radius = calculateSnakeRadius(snake.bodySegments);

            // 2. Notify server (fire-and-forget)
            ws.send(JSON.stringify({ type: 'eat_food', foodId }));

            // 3. Remove from scene immediately
            foodObj.destroy();
            foods.delete(foodId);
        }
    });
}

The player sees the score increase instantly. If the server rejects the eat (rare because of lenient validation), the next state sync silently corrects it. The 20 px extra radius absorbs client-server drift.

Client Network Flow

---

7. Minimap & Leaderboard

7.1 Minimap

The minimap is drawn with raw Graphics primitives, not sprites:

drawMinimap() {
    minimapGraphics.clear();
    // Background circle
    minimapGraphics.fillStyle(0x000000, 0.5);
    minimapGraphics.fillCircle(cx, cy, MINIMAP_SIZE / 2);

    const scale = MINIMAP_SIZE / WORLD_SIZE;

    // One draw call per snake: fillCircle
    snakes.forEach(snake => {
        if (snake.isAlive) {
            minimapGraphics.fillStyle(color, opacity);
            minimapGraphics.fillCircle(
                x + snake.x * scale,
                y + snake.y * scale,
                radius
            );
        }
    });
}

Using Graphics avoids the scene-graph overhead of hundreds of individual game objects.

7.2 Leaderboard Throttling

Sorting all snakes by score is expensive. I run it only once per second, not every frame:

this.time.addEvent({
    delay: 1000,
    callback: updateLeaderboard,
    loop: true
});

---

8. Fixed-Timestep Game Loop

The client uses the same fixed-timestep strategy as the server for deterministic physics:

update(time: number, delta: number) {
    this.elapsedTime += delta;
    while (this.elapsedTime >= this.fixedTimeStep) {
        this.elapsedTime -= this.fixedTimeStep;
        this.fixedTick(time, this.fixedTimeStep);
    }

    // Reconciliation and rendering happen every display frame
    if (this.currentPlayer) this.currentPlayer.reconcile();
    this.renderVisibleEntities();
}

• Logic (prediction, interpolation) runs at 60 Hz.
• Rendering runs at the display refresh rate (60 Hz, 120 Hz, 144 Hz).
• If the display drops a frame, logic catches up by running multiple fixed ticks in one render frame.

Main Update Loop Flow

---

9. Performance Budget

System	Max Count	Optimization	Typical Active
Snakes (data)	600	Always stored	600
Snakes (rendered)	600	Viewport culling	20–60
Body segments	400 per snake	Dynamic allocation + per-segment culling	2,000–5,000
Food (total)	1,600	Viewport culling	80–150
Food effects	1,600	Simple tweens only	80–150
Minimap dots	600	Graphics primitives	600 (one batch)
Input messages	—	60 Hz throttle	60/s
State broadcasts	—	Server sends 20 Hz	20/s

---

10. One Week Later: Honest Thoughts

It works. Looking back, plenty I would rewrite:

1. Viewport culling saved the project. Without it, 600 snakes × 400 segments = 240,000 Phaser circles. Chrome would die.
2. Destroy, don't hide. I learned this the hard way. Phaser's scene graph is not free. destroy() gave me back 20 FPS compared to visible = false.
3. Predict locally, reconcile gently. The 5% per-frame nudge is invisible to players but keeps server and client aligned. Without it, drift becomes visible after a few seconds.
4. Mirror server physics exactly. BASE_SPEED, BOOST_SPEED, TRAIL_STEP — these numbers must match on both sides or reconciliation triggers hard-syncs constantly.
5. Throttle the expensive stuff. Leaderboard sorting, invisible object cleanup, input sending — none of this needs to run every frame.

All in all, going from zero to a playable multiplayer game in two weeks (one for server, one for client) feels pretty good. The code is rough, but it ships. If you want to borrow ideas or fork it, go ahead.

Want to try it yourself? Head over to Hi! Snake and see how long you can survive against 500 bots.