I spent one week building a multiplayer Slither.io clone. The server runs on PartyKit + TypeScript, the client on Phaser 3 + React. Honestly the code is far from perfect — there are hard-coded magic numbers, TODO comments, and parts I would definitely refactor if I had more time — but it works. One room supports 600 snakes (100 real players + 500 bots) and the latency feels fine.

This post is about the core algorithms and the bugs I stepped on.

1. Why PartyKit?

I initially wanted to write the server with plain Node.js + WebSocket, but deployment and horizontal scaling looked like a nightmare. Then I found PartyKit. It compiles to Cloudflare Workers / Durable Objects, so each room is a single Durable Object with all state in memory. No Redis, no database, no ops headache. For a one-week side project, that was perfect.

My goal: one room, 100 human players + 500 AI bots, on a 16,000 × 16,000 world. Not huge, but not tiny either — one sloppy algorithm and the event loop stutters, sending every snake teleporting forward.

I gave myself three hard constraints:

• Authoritative server: All movement, collision, and scoring computed server-side. The client only renders.
• Low bandwidth: Cannot broadcast full state every tick or 600 entities would saturate the pipe.
• Client-prediction friendly: The server must tolerate small client-side prediction errors, or players will scream "I clearly ate that!"

2. Fixed-Timestep Game Loop: Why I Cap maxSteps at 3

My first game loop was naive: setInterval(() => tick(), 16). During testing I noticed that whenever the event loop hiccuped — garbage collection, a burst of messages — deltaTime would balloon to 100 ms and tick() would fire six times in a row. The snakes would lurch forward in a sickening speed-up. Players hated it.

I switched to a semi-fixed timestep:

fixedTimeStep = 1000 / 60 ≈ 16.667 ms
maxStepsPerFrame = 3

function runGameLoop():
    now = currentTime()
    deltaTime = now - lastTickTime
    lastTickTime = now
    elapsedTime += deltaTime

    steps = 0
    while elapsedTime >= fixedTimeStep and steps < maxStepsPerFrame:
        elapsedTime -= fixedTimeStep
        fixedTick(fixedTimeStep)
        steps += 1

    schedule next runGameLoop after fixedTimeStep

Why cap maxSteps?

Without the cap, an event-loop stall causes the server to simulate a dozen frames at once. The snakes teleport. I set the cap to 3 steps (~50 ms of catch-up). I would rather drop temporal accuracy than let players see that teleport.

Here is the full loop flow:

Per-Tick Pipeline (fixedTick)

3. Snake Movement: The Trail-Following Algorithm I'm Most Proud Of

My first idea was to simulate every body segment as an independent rigid body — head pulls segment 1, segment 1 pulls segment 2, and so on. It failed for two reasons: 400 segments per snake crushed the CPU, and the body would glitch out — snapping, bunching, occasionally detaching.

Then I flipped the problem: simulate only the head, derive the entire body from a history trail.

Data Structures

class ServerSnake {
  x, y: number;           // Head position
  angle: number;          // Heading in radians
  trail: Vector2[];       // Dense history of head positions
  segmentsX: number[];    // Derived body segment X positions
  segmentsY: number[];    // Derived body segment Y positions
  bodySegments: number;   // Count of visible segments
}

• trail is a dense array of head positions sampled every TRAIL_STEP = 2 pixels.
• segmentsX/Y are not independently simulated — they are read-only lookups into the trail.

Head Movement

Each tick the head moves forward based on its angle:

speed = isBoosting ? BOOST_SPEED(380) : BASE_SPEED(180)  // px/s
vx = cos(angle) * speed * dt
vy = sin(angle) * speed * dt
newHeadX = x + vx
newHeadY = y + vy

Trail Recording with Linear Interpolation

When the head moves farther than TRAIL_STEP, I interpolate intermediate points so the trail stays uniformly spaced:

distMoved = distance(lastHeadPosition, newHeadPosition)
if distMoved >= TRAIL_STEP:
    steps = floor(distMoved / TRAIL_STEP)
    for i = 1 to steps:
        t = i / steps
        interX = lastHeadPosition.x + (newHeadX - lastHeadPosition.x) * t
        interY = lastHeadPosition.y + (newHeadY - lastHeadPosition.y) * t
        trail.unshift({x: interX, y: interY})   // newest at front

    lastHeadPosition = {x: newHeadX, y: newHeadY}

    // Trim to prevent memory leaks
    maxPoints = (bodySegments + 2) * (SEGMENT_DISTANCE / TRAIL_STEP)
    if trail.length > maxPoints:
        trail.splice(maxPoints)

Interpolation is critical. Without it, high-speed movement lets the head outrun the body, creating visible gaps.

Segment Derivation

Body segments sample the trail at fixed intervals:

pointsPerSegment = SEGMENT_DISTANCE / TRAIL_STEP   // 10 / 2 = 5
for i = 0 to bodySegments - 1:
    trailIndex = floor((i + 1) * pointsPerSegment)
    segmentsX[i] = trail[trailIndex].x
    segmentsY[i] = trail[trailIndex].y

Segment 0 is the neck, the last segment is the tail. Because the trail is dense and pre-interpolated, the body follows the head with zero additional physics.

Growth & Shrinking

When a snake eats food or boosts, bodySegments changes. I reconcile the trail length like this:

newSegments = calculateBodySegments(score)
newRadius   = calculateSnakeRadius(newSegments)

// Extend trail if needed
pointsNeeded = (newSegments + 2) * (SEGMENT_DISTANCE / TRAIL_STEP)
while trail.length < pointsNeeded:
    trail.push(copy of last trail point)

// Extend segment arrays
while segmentsX.length < newSegments:
    segmentsX.push(lastTrailPoint.x)
    segmentsY.push(lastTrailPoint.y)

New segments spawn at the tail position, so the snake visibly grows from the back.

The complete movement flow:

4. Spatial-Grid Collision: How I Dropped O(n²) to O(n)

Brute-force snake-to-snake collision for 600 snakes is 180,000 checks per tick — instant death.

I implemented a uniform spatial grid for broadphase culling.

Grid Construction

gridSize = 200 px
grid: Map<string, Snake[]>   // key = "gridX,gridY"

for each snake:
    if not alive: continue
    gridX = floor(snake.x / gridSize)
    gridY = floor(snake.y / gridSize)
    key = "${gridX},${gridY}"
    grid[key].push(snake)

Neighbor Query Only

For each snake I only check the same cell plus the 8 adjacent cells:

for each cell in grid:
    for each snake in cell:
        checkFoodCollisions(snake)

        gx, gy = parse cell key
        for dx = -1 to 1:
            for dy = -1 to 1:
                neighborKey = "${gx+dx},${gy+dy}"
                for other in grid[neighborKey]:
                    if other != snake and other.isAlive:
                        checkSnakeCollision(snake, other)

        // World boundary
        if snake.x < 0 or snake.x > mapWidth or snake.y < 0 or snake.y > mapHeight:
            handleSnakeDeath(snake)

On a 16,000×16,000 map with 200 px cells there are 6,400 cells. With 600 snakes, most cells hold 0 or 1 snake. The inner loop runs in effectively O(n).

Narrowphase: Snake vs. Snake

The collision shape is the head circle tested against all opponent segment circles:

segments = [{x: other.x, y: other.y}]   // opponent head
for i = 0 to other.bodySegments - 1:
    segments.push({x: other.segmentsX[i], y: other.segmentsY[i]})

collisionDist = snake.radius + other.radius - 5   // 5px forgiveness
for segment in segments:
    dist = distance(snake.head, segment)
    if dist < collisionDist:
        handleSnakeDeath(snake)
        return

That -5 is my forgiveness margin. Without it, network jitter causes false-positive deaths and players rage-quit.

Full collision flow:

Food Collision & Magnetic Attraction

I skipped spatial partitioning for food. There are only 1,600 items, so O(1,600) per snake per tick is ~1M distance checks — well within what a PartyKit Durable Object can handle.

The magnetic attraction uses linear attenuation:

attractSpeed = 150 * (1 - dist / (snake.radius * 6))

Strongest at contact, zero at 6×radius. It feels great and costs almost nothing.

5. Bot AI: Keeping 500 Bots from Melting the CPU

I needed bots to fill rooms and give human players targets. The AI had to be stupidly cheap because 500 bots updating at 20 Hz adds up fast.

State Machine

Two states:

• WANDERING — pick a random target, steer toward it
• AVOIDING — threat within 150 px, steer away

Target Selection

margin = 200 px
targetX = margin + random() * (WORLD_SIZE - margin * 2)
targetY = margin + random() * (WORLD_SIZE - margin * 2)
changeTargetTimer = 3000 + random() * 4000 ms

Threat Detection

for each otherSnake in world:
    if otherSnake == this or not alive: continue
    dist = distance(this.head, otherSnake.head)
    if dist < 150:
        threatAngle = atan2(this.y - otherSnake.y, this.x - otherSnake.x)
        state = AVOIDING
        avoidTimer = 1000 ms

Only head-to-head distance. Bots do not anticipate body collisions — too expensive.

Smooth Steering

angleDiff = targetAngle - currentAngle
while angleDiff > PI:  angleDiff -= 2*PI
while angleDiff < -PI: angleDiff += 2*PI

maxTurn = 3 * dt
angleDiff = clamp(angleDiff, -maxTurn, maxTurn)
currentAngle += angleDiff

The ±2π wrap and turn-rate clamp were deliberate. Without them bots snap-turn instantly and look fake.

Boosting

shouldBoost = random() < 0.05

Completely random. I added BOOST_MIN_SCORE = 20 so bots don't boost themselves to death immediately after spawn.

Bot decision flow:

6. Growth & Scoring Formulas

Score → Segments

segments = INITIAL_SNAKE_LENGTH + floor(score / POINTS_PER_SEGMENT)
segments = min(segments, MAX_BODY_SEGMENTS)

Segments → Radius

growth = floor(segments / RADIUS_GROWTH_INTERVAL)
radius = min(INITIAL_RADIUS + growth, MAX_RADIUS)

Boost Cost: Why I Use an Accumulator

My first attempt was score -= 15 * dt. Floating-point drift gave ugly decimal scores. I switched to an accumulator:

boostCostAccumulator += dt * BOOST_COST_PER_SECOND
if boostCostAccumulator >= 1:
    cost = floor(boostCostAccumulator)
    score = max(0, score - cost)
    boostCostAccumulator -= cost
    updateBody()

Now the score stays integer-clean.

7. Networking: The Compromises I Made for Client Prediction

Input Queue

The client sends inputs as fast as it wants. The server queues them:

snake.inputQueue.push({ angle, boosting })
while (input = snake.inputQueue.shift()) {
    snake.angle = input.angle;
    snake.isBoosting = input.boosting;
}

If two inputs arrive in the same tick window, the queue preserves order.

Lenient Food Validation

The client predicts eating food and hides it immediately. To avoid feeling laggy, I accept eat_food messages with a relaxed radius:

maxEatDist = snake.radius + food.size + 60   // +60 px leniency
if dist < maxEatDist:
    approve eat

That +60 is a deliberate anti-cheat compromise. Smooth gameplay beats strict validation in this genre.

Broadcast Throttling

Full state every tick would saturate bandwidth. I broadcast every 3rd tick (~50 ms, 20 Hz):

broadcastCounter++
if broadcastCounter % 3 === 0:
    room.broadcast(JSON.stringify({...}))

At 20 Hz with ~600 entities, payload is roughly 100–300 KB/s per client — comfortable for WebSocket.

Client-server message flow:

8. Performance Numbers

9. One Week Later: What I Learned

The code works, but looking back there is plenty I would refactor:

1. Trail-based movement beats rigid-body chains. Simulate one head, look up the body from history. Zero physics glitches, tiny CPU cost. This is the design decision I'm happiest with.
2. Spatial hashing is non-negotiable. My first O(n²) brute-force version choked at 50 snakes. The grid dropped it to effectively linear.
3. The maxSteps cap saved the feel. Event-loop stalls are real. Cap at 3, swallow the time debt, never let snakes teleport.
4. Be lenient with clients. +60px eat radius, loose validation — players notice lag way more than they notice mild server-side forgiveness.
5. Dumb AI scales. 500 bots running A* would melt the CPU. Random wander + flee is indistinguishable to most players and costs nothing.

Deployment is one command: npx partykit deploy. Global edge nodes in seconds. If you want to ship a playable multiplayer game in a week, PartyKit removes a mountain of infrastructure work.

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