85 bits

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.

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?

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.

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.

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.

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.

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.

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.

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.