CodingButter - Spreading [...Knowledge][1] <Byte> at a Time

From Chaos to Structure

So here's what happened after Episode 1: I had a workspace. I had Bun running. I had the structure in place. But nothing was actually rendering yet. And that's the thing about game engines—you can talk about architecture all day, but until you see a rectangle on the screen, you're just pushing files around.

Episode 2 was about fixing that.

This episode introduced what I'm calling the BHVR stack—Bun, Hono, Vite, and React. It's not the engine itself, but the development conduit that holds everything together. Fast, modular, and most importantly, it stays out of the way when you're trying to build the actual engine logic.

The BHVR Stack: Not the Engine, the Workshop

Let me be clear: BHVR isn't the game engine. It's the tooling layer that makes the engine easier to develop, test, and iterate on.

Bun — Lightning-fast runtime and package manager. Handles workspace management and keeps builds snappy.
Hono — Lightweight server framework. We're using it for dev tooling and eventually API endpoints for editor features.
Vite — Fast, modern build tool with HMR (Hot Module Replacement). Makes iterating on the editor a breeze.
React — The UI layer for our editor. We're not using it for game rendering—that's all Canvas 2D—but it's perfect for building editor panels and controls.

This stack lets us focus on the engine itself without getting bogged down in build config or slow reload times.

Building the Renderer

The first real piece of engine code in this episode was the renderer package. It's deliberately simple right now—just a thin wrapper around the Canvas 2D API.

Here's what it does:

clear() — Wipes the canvas clean
drawRect() — Draws a rectangle at a given position with a specified color

That's it. No bells, no whistles. Just the absolute minimum to get shapes on the screen.

But here's why this matters: it's modular. The renderer is its own package with its own types and API surface. That means later, when we need to extend it—add sprite rendering, layers, cameras, whatever—we're not digging through a monolithic codebase. We're just expanding one focused package.

Why Canvas 2D?

I went with Canvas 2D instead of WebGL for a few reasons:

1. Lower barrier to entry. Canvas 2D is simpler to work with, and for a 2D engine, it's more than capable of handling what we need.

2. It's easier to debug. When something goes wrong, the API surface is smaller and more predictable.

3. We can always add WebGL later. If performance becomes a bottleneck, swapping in a WebGL renderer is possible because we've abstracted the rendering layer.

For now, Canvas 2D gets us moving without overcomplicating things.

Drawing Our First Rectangle

At the end of the episode, we had this: a rectangle rendering on the screen.

Sounds trivial, but it's actually a huge milestone. It means:

The workspace is wired up correctly
The renderer package is working
The client can import and use engine code
We have a visual feedback loop

That last one is critical. Game development is iterative, and you need to see the result of your changes immediately. This setup gives us that.

What's Next

Now that we have rendering working, the next step is adding a proper game loop and timing system. That's Episode 3—where we build the engine package and start thinking about how entities and systems will interact with the renderer.

But for now, we have our foundations. The BHVR stack is in place, the renderer is working, and we can draw to the screen. That's a solid starting point.