85 bits

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.

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.

This is 85 bits. A place where I write about things I'm building and learning along the way.

I've been meaning to start a blog for a while. Not because the world needs another dev blog, but because I keep learning things that feel worth writing down. So here we are.

Coming up: a series on a project I'm currently working on. Stay tuned.

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 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.