DEV Community: Tomer Levy

i know rust

Tomer Levy — Mon, 13 Apr 2026 09:00:00 +0000

In part 1 I wrote that I wanted to learn Rust by building something real. That I'd use AI as a mentor. That the measure of success was whether, at the end of it, I could honestly say "I know Rust."

Nine posts later, I can.

Not in the "I could pass a Rust interview tomorrow" sense. In the "I now catch JavaScript bugs by thinking like the borrow checker" sense. The moment it actually landed was debugging client-side prediction in part 8. I reassigned a buffer reference in TypeScript and my brain said no, that's a dangling borrow. JavaScript doesn't have borrows. But the pattern-recognition was already there.

That's the point. Not syntax. Intuitions.

the numbers

18 days from first commit to last. 15 of those were actual working days (nights actually).
74 commits across the server, client, shared protocol, and docs.
2,295 lines of Rust across 10 modules.
1,220 lines of TypeScript across 16 client files.
9 journal entries that became 8 technical blog posts (plus this one).

Not huge numbers. But every line was fought for. Every Arc<Mutex<T>> got picked apart. Every match on a GameState enum came from thinking about what should exist in which phase. The code is small because I refused to write code I didn't understand.

what rust actually taught me

Not the syntax. I can google syntax. Three things moved into my bones:

The borrow checker as a thinking tool. Ownership isn't just a compiler thing. It's a way of asking "who is allowed to change this, and when?" That question turns out to be useful in every language. The stale array reference bug from part 8 is the clearest example. A module held a reference to an array that had been reassigned out from under it. Classic dangling reference. Rust would have caught it at compile time. My JS brain caught it too, because I'd been trained.

Enums-with-data as the default way to model state. In TypeScript you'd use a discriminated union. Close, but nothing stops you from accessing a field that only exists in one variant. In Rust, match forces you to handle every case, and fields that don't exist in a variant literally don't exist. Once you've modeled state this way, going back feels sloppy.

"If it compiles, it's probably right" is real. I didn't believe it when people said it. Now I do. Not because the compiler is magic, but because by the time you've satisfied it, you've already answered every question about lifetimes, ownership, and error handling that the code implies. The kind of bug left over is usually a logic bug, not a wiring bug.

the AI-mentor experience

Claude wrote zero lines of the production code. That was the rule. Claude explained concepts, proposed architectures, reviewed code, debugged at the wire. I typed. (I cheated a little and had Claude write some tests when I got lazy.)

What worked:

Concept explanations in JS terms."An Arc<Mutex<T>> is the Rust equivalent of a shared mutable reference, except you have to be explicit about both sharing and mutation." That framing unlocked me faster than any Rust Book chapter.
Debugging heuristics. In part 6, when I saw ghost explosions, Claude didn't guess. It suggested "start at the wire." Turned out to be a visual rendering quirk, not a data bug. The investigation structure was the real value.
Spec writing. ADRs, phase plans, protocol definitions. Claude is relentless about writing down the "why" before the "what." I built a docs/ folder I can still read 18 days later and understand.

What didn't:

Writing idiomatic Rust on the first try. Claude would suggest imperative loops that worked. They passed tests. They were also not how Rust people write Rust. I had to learn the idioms by reading the standard library and asking "is there a shorter way?"
Replacing understanding. Any bug I fixed by pasting into Claude and pasting the answer back came back as a different bug a week later. The fixes that stuck were the ones I understood.

The loop that worked was: Claude proposes, I question, we refine, I write, we review. Nine journal entries captured that loop in real time. The journal became the blog.

the repo is open

github.com/tomerlevy1/bomberman-multiplayer.

It's not a tutorial. It's not polished. But it has all the commits in sequence, the ADRs, the journal entries, the specs, and the mentorship rules I wrote for Claude. If you want to see what "AI-assisted learning" actually looked like for one JS dev learning Rust, it's all there.

The sprites aren't. Those were Atomic Bomberman's and I can't share them. The placeholder is well-documented — bring your own tile sheets.

what's next

I don't know yet. The game is playable. It works on a LAN. Four players can connect and fight it out in the four corners, and there's no hard cap on connections. It has all the mechanics a round of Bomberman needs. I could add bots (there's a design note for FSM-driven virtual clients in the ADRs), add proper matchmaking, port the client to native, or start something else in Rust since I now have a language I enjoy.

The honest answer is "we'll see." I set out to learn Rust. I learned Rust.

Thanks for reading.

the algorithm that saved online gaming

Tomer Levy — Sun, 12 Apr 2026 09:00:00 +0000

I have a Quake tattoo. The logo, not the netcode architecture diagram, though I considered it. The netcode is the one John Carmack figured out in 1996 that made online FPS possible on dial-up connections. Client-side prediction with server reconciliation. Before QuakeWorld, Quake multiplayer was unplayable over the internet. After it, online gaming existed.

This week I implemented that same algorithm in my Bomberman clone. In a browser. In 2026. The physics are simpler (grid-based movement instead of 3D trajectories) but the fundamental problem is identical: how do you make a game feel responsive when the server is 50-100ms away?

the problem nobody notices on localhost

The game worked perfectly on localhost. Movement was instant, bombs exploded on time, everything felt responsive. That's because the round trip between client and server was under 1ms.

Add real network latency, even 50ms, and there's a visible gap between pressing an arrow key and seeing your character move. You press right, wait, then your character slides right. It feels like you're piloting a submarine. Or playing the original Quake over a 28.8k modem.

The server-authoritative model from part 2 is the cause. The client sends input to the server, the server processes it, the server broadcasts the new state, the client renders it. Every action takes a full round trip before the player sees it. Correct, but sluggish.

the Carmack model

The idea is deceptively simple:

Predict. When you press a key, the client moves your character immediately using the same physics the server will use. Don't wait for permission. Just move.
Verify. The server is still the boss. It processes your input, runs its own physics, and broadcasts the authoritative state.
Reconcile. When the server's answer arrives, the client compares its prediction to reality. If they match — and they usually do, because both sides run the same physics — nothing visible happens. If they don't match, the client snaps to the server's position.

The trick that makes it work: sequence numbers. Every input the client sends gets a monotonically increasing sequence number. The server echoes back "I've processed up to seq 42." The client keeps a buffer of all unconfirmed inputs. When the server confirms seq 42, the client:

Discards inputs 1–42 (the server has processed them, the prediction was correct).
Takes the server position as ground truth.
Replays inputs 43–48 on top of that position, re-predicting the inputs the server hasn't confirmed yet.

This replay is what prevents the snap-back from erasing your recent movement. Without it, every server update would teleport you backwards by ~100ms of movement, then your next input would push you forward again. Visible jitter, 60 times a second.

rethinking the input loop

The old input system was event-driven: send a message on keydown, send another on keyup. Simple, and fine for a server-authoritative model where the client is just a dumb terminal.

Prediction needs something different. The client has to simulate movement at the same rate as the server, 60 times per second, with matching physics. Event-driven input doesn't give you that. You need a tick.

The input system moved from events to a PixiJS ticker callback:

Keydown/keyup now only updates a heldKeys set. No network sends.
Every tick (60fps): read held keys, compute dx/dy, send input with sequence number to server, push to pending buffer, call the prediction callback to move the sprite immediately.

This was a bigger refactor than expected. The input module became a Client class that owns the ticker callback, the pending buffer, the sequence counter, and the WebSocket connection. The old functional approach couldn't hold all that state cleanly. Sometimes a class is the right tool, especially when multiple pieces of state need to be mutated together on a shared cadence.

the bugs that teach

Three bugs, each teaching a different lesson about state management in JavaScript.

the stale array reference

The reset function for a new round:

pendingInputBuffer = [];

Looks innocent. But the players module held a reference to the old array. After reset, it was reading from a detached, empty buffer that would never get new inputs. The prediction worked for one round, then silently broke.

Fix: pendingInputBuffer.length = 0. Mutates in place, all references stay valid.

This is the JavaScript version of Rust's ownership problem. In Rust, the compiler would catch this: you can't reassign a reference out from under a borrower. In JavaScript, it silently works until it doesn't. The failure mode isn't an error. It's correct behavior on stale data.

the reconciliation that didn't accumulate

First attempt at replaying unconfirmed inputs:

pendingInputs.forEach((input) => {
  setPlayerPosition({ ...playerData, ...input }, player);
});

Each iteration spread the server position with one input's dx/dy. The last input won. Earlier ones were lost. The player would snap to server position + one tick of movement instead of server position + six ticks.

Fix: accumulate across the loop:

myPlayerSprite.x = serverData.x;
myPlayerSprite.y = serverData.y;
for (const input of pendingInputs) {
  myPlayerSprite.x += input.dx * speed;
  myPlayerSprite.y += input.dy * speed;
}

Start from the server's truth, apply each unconfirmed input in order. The position builds up incrementally. That's what replay means.

the one-frame snap-back

The update loop called setPlayerPosition(serverData) for all players, including the local one, before running reconciliation. For one frame — 16ms — the local player would visibly jump backwards to the stale server position. Then reconciliation would push it forward. The result: visible jitter on every server tick.

Fix: skip setPlayerPosition entirely for the local player. Let reconciliation handle their position exclusively. The local player's visual position is always the result of server truth + replayed inputs, never raw server data.

what's missing

No client-side collision. The client predicts movement through walls and bombs. It doesn't know they're solid. The server rejects the move, and reconciliation snaps the player back. With low latency it's imperceptible. With 100ms+ latency near a wall, there's a visible rubber-band effect: you walk into the wall for a frame or two, then get pulled back.

The proper fix is duplicating the server's collision logic in TypeScript so the client predicts correctly. That means sharing constants (tile size, player size, grid layout) and reimplementing can_player_move. Deferred for now. The game is playable without it, and the architecture is ready for it when it matters.

testing without a network

Chrome's network throttling doesn't affect WebSockets reliably. I needed a way to simulate latency in development.

The solution was crude but effective: wrap the ws.onmessage handler with setTimeout(100). Every server message arrives 100ms late. Prediction felt instant: you press a key, your character moves immediately. Other players lagged behind by 100ms, which looked correct. Reconciliation corrected smoothly. Removed the setTimeout before committing.

No fancy network simulation tool. Just a setTimeout and your eyes.

what prediction taught me

The algorithm itself is ~30 lines of meaningful code. The sequence number protocol, the pending buffer, the replay loop. But getting it right required understanding three things:

References vs values. Reassigning an array creates a new object. Anything holding the old reference is now reading dead state. Mutate in place when shared.
Accumulation vs replacement. Replay means applying inputs cumulatively on top of a base position. Each step builds on the last. Spreading properties replaces; adding to coordinates accumulates.
Rendering authority. The local player's position should come from exactly one source: reconciliation. Not from the server directly, not from prediction alone. One authoritative path prevents flicker.

Carmack solved this in C, on a 28.8k modem, in 1996. I solved it in TypeScript, on a broadband connection, in 2026, with an AI explaining the concepts. The tools change. The problem doesn't.

next up

The game plays well now. Movement is responsive even with latency. Rounds have structure. The core loop (lobby, play, die, rematch) works end to end.

Next time: what I actually learned building this thing, and the gap between "it works" and "it's a game."

when your game needs to care about not being a game

Tomer Levy — Thu, 09 Apr 2026 09:00:00 +0000

Up until now, launching the server meant everyone was immediately in the game. Open two browser tabs, both players are already moving and placing bombs. When someone dies, you restart the server. No countdown, no waiting for other players, no concept of rounds.

The core gameplay loop was working. But a game that starts without asking and ends without telling you isn't a game. It's a tech demo. This week I added the thing that turns a tech demo into something you'd actually want to play with friends: a lobby, a ready system, and a round loop.

the state machine

The game now has three phases, and I modeled them with a Rust enum:

enum GameState {
    Lobby,
    Playing,
    RoundOver { timer: u64, winner_id: Option<u8> },
}

Lobby: players connect, see each other, press R to ready up. Playing: the actual game. RoundOver: brief pause showing the winner, then back to Lobby.

The interesting part is RoundOver carrying its own data. The countdown timer and winner ID only exist in that phase. They're not floating around as fields on some god struct waiting to be accidentally read during the wrong phase. When you match on the enum, the compiler forces you to handle every variant:

GameState::RoundOver { ref mut timer, ref mut winner_id } => {
    *timer -= 1;
    // ...
}

Coming from TypeScript, where you'd model this with a type discriminant and a union type, the Rust version feels more enforced. You can't access timer during Playing because it doesn't exist during Playing. In TypeScript, you'd narrow the type with an if check — but nobody stops you from skipping the check and accessing timer anyway. In Rust, it's structurally impossible.

the deadlock returns

I hit a deadlock during the refactor. Third time in this project, same class of mistake.

The game loop acquired the players mutex at the top of the loop body and held it across every interval.tick().await. Meanwhile, the connection handler was trying to lock the same mutex to insert new players. The game loop never released the lock between ticks, so accept_connections blocked forever.

The symptom was subtle: players "connected" — the WebSocket handshake succeeded — but never appeared in the lobby. Zero players, every tick. No errors, no panics, no crash. Just silence.

The fix was straightforward: lock per tick, not per loop. Acquire the mutex, do the work, drop the guard, then await the next tick. The lock is held for microseconds instead of forever.

The rule I keep relearning: lock late, release early. If you just moved a lock acquisition to a wider scope, and something stopped updating, check whether you're holding the lock across an await point.

the "alive = false" trick

During Lobby, players shouldn't be able to move or place bombs. My first instinct was to add phase checks to every input handler: if we're not in Playing, ignore the input.

Then I realized: I already had a mechanism that blocks all player actions. Every input handler starts with if !player.alive { continue; }. So I just set alive: false on player creation. The existing guards block everything. When all players ready up, set_all_players_alive() flips them on right before transitioning to Playing.

Reusing an existing field to enforce a new constraint. No new code paths, no phase checks scattered across handlers. It felt like the right kind of lazy.

the inverted condition

The update_players_state function handles both building the player state for broadcast and updating positions. I added a freeze_positions: bool param so RoundOver could broadcast positions without letting the winner walk around during the victory screen.

First attempt:

if freeze_positions {
    update_player_position(map, bombs, player);
}

Moves players when they should be frozen. The fix:

if !freeze_positions {
    update_player_position(map, bombs, player);
}

Classic. Classic. A unit test caught it immediately: just checked that x didn't change when freeze_positions was true. The kind of bug that would have been confusing in production ("why is the winner teleporting during the victory screen?") but trivial to catch with a test.

the vanishing explosion

When the last player died, the server immediately transitioned to RoundOver. But RoundOver wasn't broadcasting game state. The client got one last frame of the killing explosion, then nothing. The explosion vanished instantly, no death played out.

The fix: broadcast game state during RoundOver too, keep ticking explosions so they expire naturally, and only start the 3-second countdown after the fireworks finish. The round-ending kill now plays out in full before the winner banner appears.

This is the kind of thing you don't think about when you're designing state transitions on paper. Phase transition means "stop doing game stuff." But the visual consequences of the last game event still need to resolve. The state machine moved on; the player's eyes haven't.

finally using React for something

Up until now, React was a shell around the PixiJS canvas — everything happened imperatively inside a useEffect. The lobby was the first time React state actually earned its keep.

The game phase (lobby, playing, roundOver) lives in useState, and the WebSocket message handler updates it. Overlays render conditionally based on the phase. Standard React pattern, except for the stale closure.

The onmessage callback is created inside useEffect and captures the initial phase value from the closure. So this check is always true inside the handler, even after the game starts:

if (phase === "lobby") {
  // always true — phase was captured at effect creation
}

The fix is the functional form of setState:

setPhase((prev) => (prev === "lobby" ? "playing" : prev));

This reads the latest state at the time of the update, sidestepping the stale closure entirely. It's the kind of thing you know intellectually but still trip over when you're wiring up a WebSocket handler inside a useEffect.

The overlays themselves are simple. DOM elements positioned absolutely over the canvas. Lobby shows a player list with color-coded borders matching sprite colors, ready/not-ready status, and a "Press R" prompt. Round-over shows the winner's name in their player color, or "DRAW" in grey. No CSS files, just inline styles. It's a game prototype, not a design system.

what the lobby taught me

The lobby has zero gameplay code. No physics, no collision, no timers. But it touched almost everything:

The game loop needed to branch on phase and handle state transitions.
The connection handler needed to interact with game state without deadlocking it.
The player struct needed to pull double duty (alive = false as a lobby guard).
The client needed React state for the first time, plus stale-closure awareness.
The broadcast needed to keep running during RoundOver so explosions could finish.

The non-gameplay parts of a game — lobby, menus, transitions — are where the integration complexity lives. The gameplay code is self-contained: physics in, state out. The lobby code has to coordinate across every system.

next up

The game has a loop now. Lobby, play, die, see the winner, play again. It works perfectly on localhost.

But everything works perfectly on localhost. The round trip between client and server is under 1ms. Add real network latency and suddenly there's a gap between pressing an arrow key and seeing your character move. The game feels like you're piloting a submarine.

Next time: implementing the algorithm John Carmack pioneered in 1996 to save online gaming. Client-side prediction with server reconciliation, in a browser, with a Rust server.

the three rules that make bombs feel fair

Tomer Levy — Tue, 07 Apr 2026 09:00:00 +0000

At the end of the last post, the game looked like Atomic Bomberman. Real sprites, real animations, directional explosions. But there were two problems you could spot in the first ten seconds of playing: movement felt stiff (walk diagonally into a wall and you'd freeze in place) and bombs didn't do anything. You could walk straight through them. Your own, your opponent's, it didn't matter.

That's not Bomberman. Half the strategy of the game is trapping people with bomb placement. If bombs don't block movement, you're just dropping fireworks on a walking simulator.

This week I made movement feel right, implemented the three bomb rules that every Bomberman game gets right, extracted the collision system into its own module, and debugged a ghost that turned out to be a feature.

wall sliding: the feature that isn't a feature

Before tackling bombs, I had a movement problem. Walking diagonally into a wall just...stopped you dead. Hold up-right, hit a wall on the right side, and your character freezes. No sliding along the wall face, no partial movement on the unblocked axis. It felt stiff.

The fix lives in calc_player_new_position, and it's shorter than you'd expect:

if can_player_move(player.x, y, ...) {
    resolved_y = y;
}
if can_player_move(x, player.y, ...) {
    resolved_x = x;
}
if can_player_move(x, y, ...) {
    resolved_x = x;
    resolved_y = y;
}

Three checks, each axis tested independently:

Try moving on Y only (keep old X). If clear, accept Y.
Try moving on X only (keep old Y). If clear, accept X.
Try moving on both. If clear, accept both — full diagonal.

If you're moving diagonally into a wall that blocks X but not Y, step 1 accepts the Y movement, step 2 rejects X, and step 3 also fails. Result: you slide along the wall on the Y axis.

The thing I didn't expect: wall sliding and diagonal movement aren't two features. They're one algorithm. Axis-independent resolution handles both cases identically. Diagonal input where one axis is blocked is wall sliding. No special-casing, no branching on direction combinations. The behavior emerges from the structure rather than being hand-coded for each case.

One trade-off I left alone: I noticed that moving diagonally felt noticeably faster than moving in a straight line. The reason is simple. Cardinal movement updates one axis per tick, so you travel 1 unit. Diagonal movement updates both axes, so the actual distance is √(1² + 1²) = √2 ≈ 1.41 units per tick. That's 41% faster. Classic Bomberman normalizes the diagonal vector to unit length, but on a small grid the speed boost isn't game-breaking. If it becomes a problem during playtesting, normalization is a one-line fix. For now, simpler wins.

collision outgrows the map

Before bombs could block anything, I needed to answer a question: where does collision logic live?

The existing is_blocked function was in map.rs. It checked whether a tile was a wall or a destructible block — pure map concerns. But bomb collision isn't a map concern. Bombs are dynamic game objects, not part of the grid topology. Stuffing bomb checks into the map module would be mixing responsibilities.

I considered util.rs, but that's a dumping ground waiting to happen. If you can't name what a module does in one sentence, it's probably not a real module.

The answer was collision.rs — a module that owns the question "can this entity move here?" It combines map solidity checks with bomb position checks. is_blocked and is_solid moved out of map.rs. Grid constants like TILE_SIZE and PLAYER_SIZE stayed where they were — those describe the map, not collision behavior.

I also extracted get_player_edges, a helper that converts a player's pixel coordinates into the four tile indices their bounding box touches. Both is_blocked and the new is_bomb_blocking need this math, and duplicating it would be asking for a subtle off-by-one bug later.

rule 1: no stacking

The simplest rule. You can't place a bomb on a tile that already has one.

if bombs.iter().any(|b| b.row == row && b.col == col) {
    return; // tile already has a bomb
}

One line in try_place_bomb. I'd actually implemented this one before the session started. It was the most obvious missing behavior. Without it, mashing the bomb key stacks infinite bombs on the same tile, and the explosion chain reaction becomes absurd.

rule 2: bombs are walls

Bombs block movement for all players. This is what makes Bomberman a strategy game: you can trap an opponent (or yourself) with a well-placed bomb.

The implementation: is_bomb_blocking iterates the bomb list, converts the player's position to edges using get_player_edges, and checks if any bomb occupies a tile the player touches. This combines with the existing is_blocked into a new can_player_move function:

pub fn can_player_move(
    x: f64,
    y: f64,
    map: &[TileType],
    bombs: &[Bomb],
    player_id: u8,
) -> bool {
    !is_blocked(x, y, map) && !is_bomb_blocking(x, y, bombs, player_id)
}

One function, one question: can this player move here? The caller doesn't need to know whether it was a wall, a destructible block, or a bomb that stopped them.

rule 3: walk off your own bomb

Here's where it gets interesting. When you place a bomb, you're standing on it. If rule 2 applied immediately, you'd be trapped by your own bomb every single time. That's not how Bomberman works. You need to be able to walk away first.

The solution: an walkthrough_player field on the Bomb struct.

pub struct Bomb {
    pub row: usize,
    pub col: usize,
    pub timer: f64,
    pub fire_range: u32,
    pub walkthrough_player: Option<u8>,
    // ...
}

When a bomb is placed, walkthrough_player is set to Some(player_id). The bomb doesn't block its placer. Each tick, update_bombs_owner_blocking checks whether the immune player has moved off the bomb's tile. Once they have, it clears to None and the bomb becomes solid for everyone — including the player who placed it.

The naming took a few rounds. Started with blocking_owner, which reads like the owner is doing the blocking. Then owner_exempt, which is accurate but clinical. Landed on walkthrough_player. It says what it means: this player can still walk through this bomb.

This rule is invisible when it works. You place a bomb, walk away, and never think about it. But without it, bombs would be unusable. It's the kind of game design that exists purely to prevent a terrible experience, and you only notice it when it's missing.

an idiomatic rust moment

The is_bomb_blocking function started as an imperative habit I brought from JavaScript, even though both languages have a better option:

let mut blocked = false;
for bomb in bombs {
    // check if bomb blocks this position
    if /* ... */ {
        blocked = true;
        break;
    }
}
blocked

Mutable flag, loop, early break, return the flag. It works, but Rust has a better way:

bombs.iter().any(|bomb| {
    // check if bomb blocks this position
    // ...
})

The question was: how do you continue inside .any()? You don't — you return false from the closure. continue skips to the next iteration in a loop; return false in .any() does the same thing, because .any() stops at the first true. Same semantics, less ceremony.

This is the kind of refactor that doesn't change behavior but changes how the code reads. The any() version says what it means: "is any bomb blocking this position?" The loop version makes you read the whole body to understand the intent.

the ghost in the machine

With all three rules implemented, I started testing chain reactions — the satisfying Bomberman moment where one bomb's explosion triggers another. And that's when I saw the ghosts.

A chain of three bombs would produce "extra" explosions — bomb center sprites appearing on tiles where no bombs were placed. My first instinct: stale state. Maybe the bomb-to-explosion transition is leaking old positions. Maybe the client isn't cleaning up properly.

This is the kind of bug that looks terrifying in a networked game. State corruption in a 60Hz game loop? That could be anything.

following the wire

My AI mentor (Claude) suggested the senior engineer's approach to networked bugs: start at the wire. Before you blame the logic, figure out if the server is sending bad data or the client is misinterpreting good data.

Three investigation threads:

Wire truth — add protocol logging to capture the raw JSON. Is the server sending explosion tiles that shouldn't be there?
Rust collection integrity — check bomb.rs and map.rs for the bomb-to-explosion transition. Are we indexing into a Vec that's being mutated during iteration? Stale IDs from a removed bomb?
PixiJS lifecycle — with AnimatedSprite, the visual lifecycle is more complex than raw Graphics. Are "fire and forget" explosion sprites actually being forgotten by the renderer?

the discovery

The ghosts weren't stale data. They weren't leaked sprites. They were visual intersections.

Remember the explosion direction inference from part 5? For each explosion tile, the client checks its neighbors to decide which sprite to use. Two horizontal neighbors → horizontal arm. Two vertical → vertical arm. Multiple directions → center.

When two explosion arms from different bombs cross at a 90-degree angle, the tile at the intersection has neighbors in all four directions. The inference logic sees "neighbors everywhere" and defaults to the center sprite — the one that looks like a bomb origin.

The "ghost bombs" were cross-shaped intersections being rendered as centers. The server was correct. The networking was correct. The state management was correct. What looked like a data corruption bug was emergent visual behavior from a rendering heuristic.

the lesson

Deterministic reproduction was the key. Once I placed bombs in specific patterns and watched the "ghosts" appear at exactly the coordinates where blast paths crossed, the pattern was obvious. The bug wasn't in the data — it was in the interpretation.

The fix (if I want one) is either having the server flag which tiles are true bomb centers, or adding a "cross-intersection" sprite to the client's inference logic. For now, I left it. The networking and state management are working perfectly, and that's what I was actually worried about.

what this session taught me

The wall sliding algorithm and the three bomb rules were each a handful of lines. But they surfaced real design questions:

Let behavior emerge from structure. Wall sliding isn't a feature — it's a side effect of testing each axis independently. The less you special-case, the fewer bugs you write.
Where does collision live? Not in the map module. In its own module, because the question "can I move here?" combines multiple concerns.
How do you handle temporary immunity? With an explicit state field that gets cleared by a condition, not by a timer.
How do you debug a visual bug in a networked game? Start at the wire. Isolate server vs client. Reproduce deterministically.

And the ghost explosions reminded me of something I keep relearning: in a system with emergent behavior, not every unexpected result is a bug. Sometimes the code is doing exactly what you told it to, and the problem is that you didn't anticipate the combination.

next up

Movement feels right. Bombs block, trap, and punish. Chain reactions cascade. The core gameplay loop is there — place bombs, dodge explosions, collect power-ups, kill your friends.

But right now, two players connect and immediately start playing. There's no lobby, no ready check, no round structure. The game just... begins. And when someone dies, nothing happens. There's no "you win," no rematch, no waiting for the next round.

Next time: building a lobby and ready system, and what happens when your game needs to care about state that isn't gameplay.

your game server shouldn't know what a sprite is

Tomer Levy — Mon, 06 Apr 2026 09:00:00 +0000

For four posts, my Bomberman clone looked like a game designed by a spreadsheet. Players were colored squares. Bombs were black squares. Explosions were yellow rectangles. It worked — the game logic was solid — but it looked like a developer art museum.

This week I swapped every Graphics primitive for actual Atomic Bomberman sprites. And in doing so, I learned something I didn't expect: the sprite swap itself was the easy part. The interesting part was discovering how cleanly the rendering layer separated from the game logic — and what broke when it didn't.

Before:

After:

the thesis

Here's the rule I accidentally followed and now consciously endorse: your game server should never know what a sprite is.

The server in this project manages game state: positions, timers, collision, death. It sends a game_state message 60 times a second. Here's what that message contains for explosions:

pub struct ExplosionState {
    pub tiles: Vec<(f64, f64)>,
}

That's it. A flat list of tile coordinates. The server doesn't know which tile is the center of a blast, which is an arm, which is a tip. It doesn't know that explosions have direction. It placed bombs, counted down timers, and computed which tiles should be on fire. Its job ends there.

Every rendering decision lives on the client. Which sprite to use, how to animate it, whether to flip a texture. And this separation made the entire sprite overhaul possible without touching a single line of Rust.

finding the assets

I spent time on itch.io and OpenGameArt looking for Bomberman-style sprites. Plenty of generic top-down packs, nothing that felt right. Then I remembered: years ago I'd started a CraftyJS Bomberman clone using the original Atomic Bomberman sprites. I never finished it, but the sprites were still sitting in the old project folder. Sometimes the best asset is the one you already have.

the sprite pipeline

The loader module ended up being small:

export const loadSheet = async (path: string) => {
  const sheet: Texture = await Assets.load(path);
  sheet.source.scaleMode = "nearest";
  return sheet;
};

export const loadTexture = (
  sheet: Texture,
  x: number,
  y: number,
  spriteWidth: number = 16,
  spriteHeight: number = 16,
) => {
  return new Texture({
    source: sheet.source,
    frame: new Rectangle(x, y, spriteWidth, spriteHeight),
  });
};

loadSheet fetches a PNG and sets nearest-neighbor scaling, which is essential for pixel art. Without it, PixiJS interpolates when scaling up and everything looks like vaseline on a camera lens. loadTexture slices a sub-rectangle from the sheet.

All original sprites are 16px. The game renders at 64px per tile. PixiJS handles the scaling through sprite.width and sprite.height, so no image preprocessing needed. 192 grid tiles, 4 textures. Sprites are cheap instances pointing at shared image data.

the async cascade

Before sprites, creating a manager was synchronous. new Graphics(), draw some rectangles, done. But Assets.load() is async. That single change meant every manager factory that loads a spritesheet became async, and the useEffect in App.tsx that wires everything together had to await each one before connecting the WebSocket:

const gridManager = await createGridManager(gridLayer);
const playersManager = await createPlayersManager(playerLayer);
const bombsManager = await createBombsManager(entityLayer);
const explosionsManager = await createExplosionsManager(gridLayer, gridManager);

None of the actual logic changed, just the function signatures and the init order. But touching every manager's factory function to add async/await felt like the kind of refactor where you question whether sprites were worth it. (They were.)

the pixel measurement problem

The power-up spritesheet was 117x33 pixels with inconsistent spacing between icons. I couldn't eyeball where one frame ended and the next began. You could open it in GIMP and zoom in with a pixel grid, but Claude suggested something I wouldn't have thought of. ffmpeg can scale pixel art with nearest-neighbor filtering:

ffmpeg -i powerups.png -vf "scale=iw*8:ih*8:flags=neighbor" powerups_8x.png

Scaled 8x, every original pixel became an 8x8 block. It's still eyeballing, but at 8x the boundaries between sprite frames become obvious. You can clearly see where the background color changes and where the 1px gaps are. Turns out the frames were 16x16 with 1px gaps between them. The bottom row (red backgrounds) are debuffs. Those went into the stretch goals.

explosions: client-side direction inference

This was the most interesting rendering problem, and the clearest example of the server/client split paying off.

The server sends a flat set of explosion tile positions. No metadata about shape. But explosions need different sprites: a center piece, horizontal and vertical arms, tips at the ends. The client has to figure this out.

The solution: for each explosion tile, check which neighbors are also in the explosion set:

const left = tilesSet.has(`${x - TILE_SIZE}-${y}`);
const right = tilesSet.has(`${x + TILE_SIZE}-${y}`);
const top = tilesSet.has(`${x}-${y - TILE_SIZE}`);
const bottom = tilesSet.has(`${x}-${y + TILE_SIZE}`);

let direction: ExplosionDirection = "center";

if (!left && !right && !top && bottom) direction = "topEdge";
else if (!left && right && !top && !bottom) direction = "leftEdge";
else if (left && !right && !top && !bottom) direction = "rightEdge";
else if (!left && !right && top && !bottom) direction = "bottomEdge";
else if (left && right && !top && !bottom) direction = "left";
else if (!left && !right && top && bottom) direction = "top";

Both horizontal neighbors? Horizontal arm. Both vertical? Vertical arm. Only one neighbor? Tip pointing away from it. Multiple directions? Center. Pure function, no graph traversal, O(1) lookups per tile using a Set.

The server didn't need to change. It still sends tiles: Vec<(f64, f64)>, just coordinates. The client derives the visual structure from the spatial relationship between tiles. If I later want fancier explosion sprites or different animation styles, I change client code only.

the flip gotcha

PixiJS lets you mirror sprites with scale.x = -1, which saves you from needing separate left-facing and right-facing assets. But there's a catch: the flip happens around the sprite's anchor point, which defaults to the top-left corner. So flipping a sprite doesn't just mirror it, it also jumps its position.

Fix: set anchor(0.5, 0.5) to flip around the center, then offset x and y by half the tile size to compensate. Small thing, but it took longer to debug than the entire direction inference algorithm.

players: animation from velocity

The server sends this for each player:

pub struct PlayerState {
    pub id: u8,
    pub x: f64,
    pub y: f64,
    pub alive: bool,
    pub dx: i8,
    pub dy: i8,
}

Position, alive/dead, and a direction vector. No animation frame, no facing direction enum, no sprite index. The client's PlayerSprite class maps this to animations:

private play(frameType: FrameType) {
  if (this.currentFrameType === frameType) return;
  this.currentFrameType = frameType;
  this.sprite.textures = this.frames[frameType];
  this.sprite.visible = true;
  this.sprite.loop = true;
  this.sprite.play();
}

public up() { this.play("up"); }
public down() { this.play("down"); }
public left() { this.play("left"); }
public right() { this.play("right"); }

The play() method early-returns if the requested animation is already active. This matters because the game loop calls player.right() on every tick while the player moves right. Without the guard, it would restart the walk animation 60 times a second.

Vertical movement takes priority over horizontal in the update logic, matching how classic Bomberman looks during diagonal movement. That's a rendering opinion the server has no business holding.

The player spritesheet was the most complex. 4 colors, each with walk cycles in 4 directions plus a death sequence. The frame layout came from reverse-engineering my old CraftyJS project: Crafty.sprite(16, 26, ...) told me each frame was 16px wide and 26px tall, with the actual character occupying 16x24 and the rest being padding.

bombs: the easy win

Bombs were the simplest sprite swap. PixiJS AnimatedSprite takes a texture array and cycles through it:

const animatedSprite = new AnimatedSprite({
  textures: frames, // [0, 1, 2, 1, 0] for ping-pong
  animationSpeed: 0.05,
  loop: true,
  autoPlay: true,
});

Three frames, reversed for a ping-pong effect (small → big → small). Set loop: true and forget about it. The server sends bomb positions and timers; the client handles the pulsing animation independently.

what the server sends, what the client decides

Here's the full picture of the boundary:

	Server sends	Client decides
Players	id, x, y, alive, dx, dy	Which animation to play, sprite color, death sequence
Bombs	x, y, timer, owner	Pulse animation, sprite size
Explosions	tile coordinates	Center vs arm vs tip, direction, flip
Power-ups	x, y, kind	Sprite frame, pickup flash
Grid	tile types	Wall/floor/destructible sprites

The game_state message is ~200 bytes per tick. No texture references, no animation state, no rendering hints. The server is a physics engine that happens to know about game rules. The client is a renderer that happens to know about game state.

This meant the entire visual overhaul was a client-only change. Every Graphics rectangle replaced with a sprite, every animation added, every directional inference implemented. The server kept running its 60Hz loop, unchanged, unaware that the game had gone from looking like a developer prototype to looking like Atomic Bomberman.

next up

The game looks like Atomic Bomberman now. But there's a problem: you can walk straight through your own bomb. And another player's bomb. Bombs are supposed to trap people — that's half the strategy of Bomberman. Right now they're decoration.

Next time: the three rules that make bombs feel fair, and why implementing them in a server-authoritative multiplayer game is harder than it sounds.

react vs. the game loop

Tomer Levy — Thu, 02 Apr 2026 19:00:00 +0000

The server was running. The Rust was making sense. But on the client side, I had a problem I hadn't anticipated: React and real-time rendering don't want the same things.

React is built around a simple idea — your UI is a function of state. State changes, React re-renders, the DOM updates. It's elegant, and it's the mental model I've used for years. But a game renderer running at 60fps doesn't work this way. You don't want to trigger a React re-render every 16 milliseconds. You want to reach into a canvas and move pixels directly.

This post is about mounting an imperative game engine inside a declarative framework, and all the places where the two models clash.

the escape hatch

React gives you exactly one way to say "I need to touch something outside the React tree": useRef plus useEffect. The ref gives you a DOM node. The effect gives you a place to run setup code that React won't interfere with.

Here's the skeleton:

function App() {
  const canvasRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    const init = async () => {
      const app = new Application();
      await app.init({
        width: GRID_COLUMNS * TILE_SIZE,
        height: GRID_ROWS * TILE_SIZE,
      });
      canvasRef.current?.appendChild(app.canvas);

      // everything else happens here — outside React
    };

    init();

    return () => {
      // cleanup: destroy the PixiJS app
    };
  }, []);

  return <div ref={canvasRef} />;
}

The [] dependency array means this runs once on mount. Inside init, we create a PixiJS Application, append its canvas to the div, and from that point forward, React has nothing to do with rendering. The game lives entirely in the useEffect closure.

One thing that caught me off guard: app.init() is async. PixiJS v8 moved initialization to a promise-based API, which means you can't just construct and go — you need the async wrapper inside the effect. A useEffect callback can't be async directly, so you define init inside it and call it immediately.

the StrictMode trap

React's StrictMode intentionally double-invokes effects in development to help you find missing cleanup logic. For most components, this is fine — you clean up and re-run, no harm done.

For a game renderer that creates a canvas and opens a WebSocket, it's a disaster. Two canvases. Two connections. Two sets of everything, fighting each other.

I spent an embarrassing amount of time debugging ghost players and duplicate renderings before realizing the issue. The fix was removing StrictMode from main.tsx:

// before — double mount in dev
createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <App />
  </StrictMode>,
);

// after — single mount
createRoot(document.getElementById("root")!).render(<App />);

This feels wrong if you've internalized the React best practices. StrictMode is supposed to catch bugs, and removing it feels like giving up. But the reality is: StrictMode assumes your side effects can safely run twice with no consequences. A PixiJS canvas and a WebSocket connection can't. The "correct" fix would be elaborate teardown and re-initialization logic, but for a game client that mounts once and stays mounted, removing StrictMode is the pragmatic choice.

why `setState` doesn't work here

My first instinct was to store game state in React state. Players move? setPlayers(newPositions). Bombs appear? setBombs(newBombs). It's how I'd build any other React app.

The problem is frame rate. The server sends game state 60 times per second. Each setState call triggers a re-render — React diffs the virtual DOM, calculates what changed, and updates. That's a lot of machinery for something that needs to happen in under 16 milliseconds, every frame.

More importantly, the rendering model is wrong. React re-renders by destroying and recreating DOM elements (or diffing to avoid it). PixiJS works by mutating existing objects in place — you change sprite.x = 100 and it's done. There's no diff step. There's no reconciliation. You just move the thing.

So the answer is: don't use React state for game state. Use React to mount the canvas and set up the WebSocket. After that, everything is direct mutation.

the factory pattern

Each game system — players, bombs, explosions, power-ups — is a factory function that takes a PixiJS Container and returns an update method. No React. No hooks. Just closures over mutable state.

Here's the core of the players manager:

export const createPlayersManager = (container: Container) => {
  const players = new Map<number, Graphics>();

  return {
    updatePlayers: (playersData: PlayerData[]) => {
      for (const player of playersData) {
        let g = players.get(player.id);
        if (!g) {
          g = new Graphics();
          g.rect(8, 8, PLAYER_SIZE, PLAYER_SIZE);
          g.fill(COLORS[player.id % COLORS.length]);
          container.addChild(g);
          players.set(player.id, g);
        }
        g.x = player.x;
        g.y = player.y;
      }
      // + cleanup for disconnected players
    },
  };
};

The state is a plain Map<number, Graphics> inside a closure — not React state. When updatePlayers is called 60 times per second, it mutates Graphics objects directly. g.x = player.x — that's it. No diffing, no reconciliation. New player? Create a graphic and add it to the container. Existing player? Update two properties. Player disconnects? Destroy the graphic and remove it from the map.

This pattern repeated across every system. Bombs, explosions, power-ups — they all follow the same shape: a collection of PixiJS objects, an update function that syncs them with server state, and cleanup for removed entities.

App.tsx became pure wiring:

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  switch (data.type) {
    case ServerMessageType.WELCOME:
      gridManager.drawGrid(data.map);
      break;
    case ServerMessageType.GAME_STATE:
      bombsManager.updateBombs(data.bombs);
      playersManager.updatePlayers(data.players);
      explosionsManager.updateExplosions(data.explosions);
      powerupsManager.updatePowerUps(data.powerups);
      break;
  }
};

Message comes in, dispatch to the right manager, done. No setState, no re-renders, no virtual DOM.

the z-order problem

Here's a bug that's obvious in hindsight but drove me crazy at the time: game objects kept rendering in the wrong order. A player would walk behind a bomb instead of in front of it. Explosions would hide behind the grid.

PixiJS renders children in addChild order. The first child added to a container is drawn first (behind everything else). When you have multiple systems adding graphics at different points in time — grid on startup, bombs when placed, players when they connect — the order depends on when each object was created, not on any logical layering.

The fix is explicit layers:

const gridLayer = new Container();
const entityLayer = new Container();
const playerLayer = new Container();
app.stage.addChild(gridLayer);
app.stage.addChild(entityLayer);
app.stage.addChild(playerLayer);

Grid on the bottom, entities (bombs, explosions) in the middle, players on top. Each manager gets the container it should draw into. No matter when a bomb is placed or a player connects, the z-order is correct because the layer containers are added to the stage in the right order.

If you've worked with CSS z-index, this is the same idea — but without the ability to set a number on each element. You create the ordering through container hierarchy instead.

the destructible tile problem

The grid started as a single Graphics object — one draw call for all 195 tiles (15 columns x 13 rows). Efficient and simple. Walls, floors, pillars, all drawn into one shape.

Then I added destructible blocks. When a bomb explodes, it destroys certain tiles. And you can't partially erase a Graphics object. It's one shape — you'd have to clear and redraw the entire grid every time a block is destroyed.

The solution: destructible tiles are separate Graphics objects, each stored in a Map keyed by position:

const destructibleTiles: Map<string, Graphics> = new Map();

const drawGrid = (map: TileType[]) => {
  for (let row = 0; row < GRID_ROWS; row++) {
    for (let col = 0; col < GRID_COLUMNS; col++) {
      if (map[row * GRID_COLUMNS + col] === "destructible") {
        const destructible = new Graphics();
        destructible.rect(0, 0, TILE_SIZE, TILE_SIZE);
        destructible.fill(TILE_COLORS.destructible);
        destructible.x = col * TILE_SIZE;
        destructible.y = row * TILE_SIZE;
        destructibleTiles.set(
          `${destructible.x}-${destructible.y}`,
          destructible,
        );
      }
    }
  }
  container.addChild(...destructibleTiles.values());
};

const removeDestructible = (x: number, y: number) => {
  const key = `${x}-${y}`;
  const destructible = destructibleTiles.get(key);
  if (destructible) {
    destructible.destroy();
    destructibleTiles.delete(key);
  }
};

The static grid (walls, floors, pillars) stays as one Graphics object — cheap and never changes. Destructible tiles are individual objects that can be independently removed. When the explosion manager processes a blast, it calls removeDestructible for each affected tile, and only that tile disappears.

This is the kind of decision you don't think about in a DOM-based app. React handles element creation and removal for you. In a canvas renderer, you're managing every object's lifecycle yourself.

React as a shell

The irony is that this is a React app where React barely does anything. It mounts a div. It runs one effect. After that, it's PixiJS closures and direct mutation all the way down.

If I were starting over, I might skip React entirely and just use vanilla TypeScript. But having React there means I can add a lobby UI, a settings screen, or a HUD later without building a UI framework from scratch. The game canvas is one component in what could become a larger app. For now, React owns the page lifecycle, and the game engine owns everything inside the canvas. They coexist because they don't try to share control.

next up

The server and client were both working. I had multiplayer movement, bombs, explosions, and power-ups. But everything was colored rectangles. Players were squares. Bombs were black squares. The game logic was solid — it just looked like a developer art museum.

Next time: swapping every Graphics primitive for actual Atomic Bomberman sprites, and discovering that the hardest part isn't the sprites themselves — it's everything that breaks around them.

ownership hell

Tomer Levy — Tue, 31 Mar 2026 21:00:00 +0000

In JavaScript, if two functions need the same object, you just... pass it. Nobody asks who owns it. Nobody cares. The garbage collector handles the mess, and you move on with your life.

Rust does not work this way.

This post is about the first week of writing Rust as someone who's spent most of their career in JavaScript — specifically, the ownership model and all the ways it made me feel like I was fighting the language before I understood it was protecting me.

the first wall: `async move`

I needed to spawn an async task for each WebSocket connection. In JS, this is a closure that captures whatever it needs from the surrounding scope. In Rust, it's an async move block — and move means what it says. The closure takes ownership of every variable it captures. The original scope can't use them anymore.

Here's where it got me: I was cloning a shared player map before a loop, then trying to move that clone into each spawned task.

let players_clone = Arc::clone(&players);

loop {
    let stream = listener.accept().await;
    tokio::spawn(async move {
        handle_connection(stream, players_clone).await;
    });
}

This compiles on the first iteration. On the second, the compiler yells at you — players_clone was moved into the first task. It's gone. You can't move the same thing twice.

The fix: clone inside the loop, so each task gets its own copy. And Arc::clone is cheap — it just increments a reference counter, it doesn't deep-copy the data behind it.

loop {
    let stream = listener.accept().await;
    let players_clone = Arc::clone(&players);
    tokio::spawn(async move {
        handle_connection(stream, players_clone).await;
    });
}

In JS, this problem doesn't exist. Closures share references freely, and the runtime sorts it out. In Rust, you have to think about who owns what, and the compiler won't let you pretend otherwise.

sharing state: `Arc<Mutex<HashMap>>`

In a Node.js server, shared state is just... a variable. You declare an object at the top of your file, and every request handler reads and writes to it. Single-threaded, no locks, no problem.

Rust makes you earn shared mutable state. My game server uses Tokio as its async runtime — think of it as the event loop you get for free in Node, except in Rust you choose and install one yourself. I have multiple async tasks — a connection handler per player and a central game loop — all needing access to the same player map. The pattern for this is Arc<Mutex<HashMap>>:

Arc (atomic reference counting) — lets multiple tasks hold a reference to the same data. Like a shared pointer that knows when everyone's done with it.
Mutex — a lock. Only one task can access the data at a time. You call .lock().await, do your work, and the lock releases when it goes out of scope. You need both because Arc lets everyone reach the data, but Mutex makes sure only one of them gets in at a time.
HashMap — the actual data. In this case, player ID to player state.

Every time I wanted to read or write a player, I had to lock the mutex first. Coming from JS where you just do players[id].x += speed, the ceremony felt heavy. But then I realized: in a concurrent system, JS doesn't protect you. If you had actual threads sharing a mutable object, you'd get data races. Rust just forces you to handle it upfront instead of discovering it in production.

everything is private

In JavaScript, everything is accessible by default. Export what you want, import what you need, and if you're lazy, just export everything.

Rust is the opposite. Everything is private by default. You have to explicitly mark things as pub to expose them. The module system works like this:

mod player; — declares that a module exists (like registering a file)
pub struct Player — makes the struct visible outside its module
use crate::player::Player; — imports it where you need it

The first time I split my server into modules, nothing compiled. Every struct, every function, every field — the compiler told me it was private. I went through and added pub everywhere until it worked, which felt like I was doing it wrong. I was. You're supposed to think about what should be public. The default is intentional.

the deadlock that taught me the most

Phase 3 introduced bombs and explosions. The game loop needed to read the map to calculate blast radius, then write to it to destroy blocks. Seemed straightforward — lock the map, read it, calculate, write, unlock.

Except I locked it twice. First an immutable read to calculate the blast, then a mutable write to destroy tiles. Tokio's mutex doesn't support re-entrancy — if you try to lock something you already hold, it doesn't error. It just waits. Forever.

The game would start, a bomb would explode, and everything would freeze. No error message. No crash. Just silence.

The fix was simple: take a single mut lock at the start of the tick and use it for both reads and writes. But finding the bug took longer than it should have, because "everything freezes silently" is not a helpful error message.

This was the moment Rust's ownership model clicked for me. The language didn't prevent this particular bug at compile time — deadlocks are a runtime problem. But the fact that I had to explicitly lock and unlock resources, that I had to think about who holds what and when, meant the bug was localized. I knew it was a locking issue because there was nowhere else it could be.

the rules that made it work

I didn't learn all this alone. I had an AI mentor — Claude — and we established a set of rules early on to make sure the learning actually stuck.

The core idea was "challenge-first": the AI explains new concepts and specs out a goal, then I write the code. No code dumps. If I'm stuck, we talk through it, but I'm the one typing. There's also a mandatory pause — the AI has to stop and wait for me to review before moving on. No steamrolling through steps I haven't digested yet.

After I write the code, we review it together. That's where I pick up Rust idioms I wouldn't find on my own — like using HashMap.retain() to filter in-place instead of building a new collection, or knowing when a local Vec is enough and Arc<Mutex> is overkill.

These rules sound obvious, but without them the default mode of AI-assisted coding is: you describe a problem, the AI writes the solution, you paste it in. You ship faster but you don't learn anything. For a project where the whole point is learning Rust, that's a trap.

The deadlock bug was a good test of this. The temptation was to paste the error (or lack of error — just a frozen game) and let the AI diagnose it. Instead, I talked through what I knew: the game freezes when a bomb explodes, explosions touch the map, the map is behind a mutex. That was enough to find it myself. The AI confirmed the fix, but the understanding was mine.

what I'd tell a JS dev starting Rust

After a week, here's what I wish someone had told me:

Stop thinking in references. In JS, everything is a reference and the GC handles lifetime. In Rust, every value has exactly one owner. When you need to share, you make explicit copies (clone) or use smart pointers (Arc).
The compiler is your pair programmer. Those error messages aren't obstacles — they're catching bugs you'd ship in JS and discover at 3am.
Not everything needs Arc<Mutex>. My first instinct was to wrap everything in shared state because that's how JS works — one global scope. But if only one task touches a piece of data, a local Vec is simpler and faster. Rust taught me to ask "who actually needs this?" instead of making everything globally accessible.
let ... else is your friend. Rust's version of early returns and guard clauses. Instead of nesting match inside match inside match, you write let Some(value) = expression else { continue; }; and keep going at the top level. Flattens deeply nested error handling into something readable.

next up

The server was running and the Rust was making sense. But on the client side, I had a different problem: how do you mount a 60fps imperative game renderer inside a declarative React app?

Next post: bridging React and PixiJS, and why everything I knew about state management was wrong for real-time rendering.

If there's a Rust concept you want me to dig into in a future post, or if you think I skipped over something that deserves more detail drop a comment. I'm writing these as I learn, and I'd rather go deeper on the things that actually trip people up.

the server is the boss

Tomer Levy — Tue, 31 Mar 2026 09:00:00 +0000

Before I wrote a single line of game logic, I had to answer one question: who decides what's true?

In a multiplayer game, two players might press a button at the same time. Their clocks don't agree. Their internet connections have different latency. If each client runs its own simulation, they'll disagree on what happened — and in a game where a split-second determines whether you dodge an explosion, disagreement means broken gameplay.

The answer: the server is the boss. The client is just a terminal.

the authoritative model

Here's the deal the client and server make: the client sends intent ("I want to move down", "I want to place a bomb"), and the server decides what actually happens. The client never runs game logic. It never calculates movement or collision. It just renders whatever the server tells it to.

This is called an authoritative server model, and it gives you two things for free:

No cheating. If the client doesn't decide where a player is, a modified client can't teleport.
One source of truth. Every player sees the same game state because it all comes from the same place.

The tradeoff is latency — the client has to wait for the server to respond before anything feels "real." We'll deal with that later (client-side prediction is on the roadmap). For now, on localhost, it's instant.

the game loop

The server runs a loop at 60 ticks per second. Every 16.66 milliseconds, it does the same thing:

Move players — read each player's current direction and speed, calculate a new position, check for wall collision
Tick bombs — decrement every bomb's timer. When it hits zero, boom
Resolve explosions — calculate blast radius in four directions (stop at walls, destroy breakable blocks), check for chain reactions where one explosion triggers another bomb
Update the map — destroyed blocks become floor tiles, with a 40% chance to spawn a power-up
Check for death — any player standing on an explosion tile dies
Pick up power-ups — players walking over a power-up get the bonus (extra bomb, bigger blast, faster speed)
Broadcast — pack up the entire game state and send it to every connected client

That last step is the key. The server doesn't send individual events ("player 2 moved left"). It sends the whole world, 60 times per second. Every client gets the same snapshot, and they all render it.

every 16.66ms:
  move players → new positions
  tick bombs → countdowns, detonations
  resolve blasts → chain reactions, map changes
  check deaths → players on explosion tiles
  pick up power-ups → extra bombs, bigger blasts, more speed
  broadcast state → all clients get the full picture

client as a dumb terminal

The client's job is simple: send input up, render state down.

When you press an arrow key, the client sends a message like {"type": "input", "direction": "down"}. That's it. It doesn't move the player locally. It waits for the next game state from the server and renders the player wherever the server says they are.

When you press the bomb key, the client sends {"type": "place_bomb"}. No coordinates — the server looks up where you are and snaps the bomb to the nearest grid tile. The client doesn't even know where the bomb will end up until the server tells it.

This feels weird coming from frontend development, where the UI is in charge. Here, the UI is a display. The keyboard is a suggestion box. The server makes all the decisions.

the protocol

The whole conversation between client and server is JSON over WebSockets. Two messages go up, two come down.

Client → Server:

input — a direction (up, down, left, right, or none)
place_bomb — no payload, server figures out the rest

Server → Client:

welcome — sent once on connect. Contains the player's assigned ID and the full map (a flat array of 195 tiles — walls, floors, destructibles)
game_state — sent every tick. Contains the tick number, all player positions, all bomb positions and timers, all explosions, and all power-ups

That game_state message is the entire game. The client doesn't maintain any state of its own — it throws away the last frame and renders the new one. Dead simple to debug because there's only one place the truth lives.

the map

The arena is a 15x13 grid. Some tiles are indestructible walls (the border and a checkerboard of pillars), some are destructible blocks (randomly placed at ~70% density), and the rest is open floor.

The map is stored as a flat array — row * 15 + col gives you the index. No 2D arrays, no nested structures. Collision detection checks the four corners of a player's bounding box against the map to see if any of them land on a solid tile.

One design detail: players are 48 pixels wide, but tiles are 64 pixels. That 16-pixel gap is intentional — it gives you enough forgiveness to navigate between walls without requiring pixel-perfect alignment. Without it, the game feels frustrating. With it, movement feels natural.

what connects to what

The connection handlers and the game loop are separate async tasks that share state through Arc<Mutex> — Rust's pattern for safe concurrent access. The connection handler writes player input, the game loop reads it and writes back the updated positions. The broadcast channel is a one-to-many pipe: the game loop sends once, every client receives.

next up

The architecture works. The server is authoritative. The protocol is simple. But all of this had to be written in Rust — a language I'd never touched before this project.

Next post: what it's actually like to write Rust when you've spent most of your career in JavaScript.

why rust, why now

Tomer Levy — Mon, 30 Mar 2026 15:39:05 +0000

In the late 90s, my brother, my cousin, and I would crowd around a single PC and play Atomic Bomberman for hours. Arrow keys and WASD, elbows bumping, trash talk flying. It was chaotic and it was perfect.

I've been thinking about that game a lot lately. Not just the nostalgia, but the idea of playing it again — with them, over the internet this time. So I decided to build it.

My first instinct was to vibe code the whole thing. Pick a framework, lean on AI, ship something in a weekend. But as I started talking through the idea with Gemini — and later Claude, who became my main AI mentor — I realized I was holding something more interesting: a real excuse to learn Rust.

the hard path

I'm a senior fullstack engineer. Most of my career has been in the JavaScript ecosystem — browser, Node, React, the whole stack. I could build this in TypeScript and have it running by Sunday.

But I've been curious about what happens below the abstraction layers I usually work in. What if I didn't have to hope the garbage collector stays out of the way at the wrong moment? Rust has been on my list for a long time — a multiplayer game with a 60Hz server loop felt like the right reason to finally jump in.

So the plan became: Rust on the server, React and PixiJS on the client, WebSockets in between. Multiplayer-first from day one — no single-player prototype that I'd have to rip apart later.

learning with AI, not through AI

Here's the part that surprised me. I started this project with Claude as my AI mentor, and the first problem we hit wasn't technical — it was process.

Claude moved fast. Too fast. It would jump straight into code before I'd even digested the architecture. I'd end up with working code I didn't understand, which is the opposite of the point. We had to stop, take a step back, and establish rules.

We ended up with a "mentor-review" loop: the AI specs the goal and introduces new concepts, I write the code, then we review together. No writing code on my behalf unless I'm stuck and ask for it. We established rules to keep things on track.

The goal was never to get the game done as fast as possible. The goal was to learn Rust — really learn it — while building something I actually want to play.

what I'm building

The game is a multiplayer Atomic Bomberman clone. Here's what's already working:

Server: Rust + Tokio, running a 60Hz authoritative game loop over WebSockets
Client: React + PixiJS, rendering the game state the server sends down
Gameplay: Players move around a 15x13 grid, place bombs, blow up destructible walls, collect power-ups, and die in explosions
Networking: Client sends intent (direction, place bomb), server decides truth. No cheating possible because the client doesn't run any game logic

It's playable on localhost. Two players can connect, run around, and bomb each other. It's not pretty — everyone's a colored square — but the mechanics work.

what's ahead

There's a big gap between "works on localhost" and "a game I can actually play with my brother and cousin." Movement needs to feel better. There's no lobby or game flow. And the big one: client-side prediction, so it doesn't feel sluggish over a real internet connection.

This series will cover the journey — the Rust I'm learning, the multiplayer architecture decisions, the moments where things click and the moments where a deadlock silently freezes your game and you spend an hour staring at code that looks perfectly fine.

Next up: how the server actually works — the authoritative model, the game loop, and why the client doesn't get to make any decisions.

If any of this sounds interesting — the Rust, the networking, the nostalgia — stick around. This is going to be a fun ride.

DEV Community: Tomer Levy

i know rust

the numbers

what rust actually taught me

the AI-mentor experience

the repo is open

what's next

the algorithm that saved online gaming

the problem nobody notices on localhost

the Carmack model

rethinking the input loop

the bugs that teach

the stale array reference

the reconciliation that didn't accumulate

the one-frame snap-back

what's missing

testing without a network

what prediction taught me

next up

when your game needs to care about not being a game

the state machine

the deadlock returns

the "alive = false" trick

the inverted condition

the vanishing explosion

finally using React for something

what the lobby taught me

next up

the three rules that make bombs feel fair

wall sliding: the feature that isn't a feature

collision outgrows the map

rule 1: no stacking

rule 2: bombs are walls

rule 3: walk off your own bomb

an idiomatic rust moment

the ghost in the machine

following the wire

the discovery

the lesson

what this session taught me

next up

your game server shouldn't know what a sprite is

the thesis

finding the assets

the sprite pipeline

the async cascade

the pixel measurement problem

explosions: client-side direction inference

the flip gotcha

players: animation from velocity

bombs: the easy win

what the server sends, what the client decides

next up

react vs. the game loop

the escape hatch

the StrictMode trap

why setState doesn't work here

the factory pattern

the z-order problem

the destructible tile problem

React as a shell

next up

ownership hell

the first wall: async move

sharing state: Arc<Mutex<HashMap>>

everything is private

the deadlock that taught me the most

the rules that made it work

what I'd tell a JS dev starting Rust

next up

the server is the boss

the authoritative model

the game loop

client as a dumb terminal

the protocol

the map

what connects to what

next up

why rust, why now

the hard path

why `setState` doesn't work here

the first wall: `async move`

sharing state: `Arc<Mutex<HashMap>>`