#001:TheArchitect'sRiteofPassage

Why you should build an engine (especially if you're broke)

There's an old saying: "To leave your mark, you must plant a tree, build a house, and raise a child."

Let's be real: The housing market is a disaster. Since I'm not a millionaire, I had to pivot: My house became a custom game engine, and the child? That's my roguelite. It keeps me up at night, drains my energy, and occasionally screams at me in the form of stack traces.

Why the hell not just use Unity or Unreal?

I get this question at every single meetup. "Shai, why don't you just use what's already there?"

The answer is simple: Because I don't want to live in a house where I don't know where the pipes are.

Using Unity is like renting an apartment. It's fancy, it's comfortable, but when a fuse blows, you're standing in the dark waiting for a support ticket. Building your own engine is like building your own workshop in the garage: You know where every single tool is, you know why the workbench is bolted to that specific spot on the floor, and when something breaks, you don't call a hotline-you grab a hammer.

No Silicon Valley hype, no subscription models, no black boxes. Just me and the code.

The Struggle is the Feature

When you build from scratch-especially a deterministic ECS engine-you aren't just fighting bugs. You're fighting the fundamental nature of JavaScript itself.

For example: JavaScript's floating-point math is non-deterministic across different CPUs. 0.1 + 0.2 might give you slightly different results on an Intel vs ARM chip. In singleplayer? Who cares. In multiplayer lockstep networking? That tiny difference compounds into total desync within seconds.

This forced me to build a fixed-point math library from scratch. I wouldn't have learned this from any tutorial-I learned it because my replay system kept breaking in bizarre ways until I dug into the IEEE 754 spec at 3am.

That's the real education: Problems you can't Google your way out of.

The "House" (The Engine): The foundation must be rock-solid. If my fixed-point math is off by even a single bit, the whole thing collapses in multiplayer. This taught me more about memory management and cache-locality than any "Clean Code" book ever could.

The "Child" (The Roguelite): It grows, it gets more complex, and it forces me to refactor the engine every time I want to implement some crazy new item. It's a constant dialogue between the system and reality.

The Reality of Rendering

Let's talk rendering: I use Pixi.js. Not because I can't write a renderer, but because I'm not stupid. My battle isn't with GPU pipeline optimization-it's with deterministic state management.

By offloading rendering to a battle-tested library, I can focus 100% on what actually matters: the simulation logic. In ShaiEngine, the renderer is just an observer. Every frame, Pixi draws what my fixed-point math has already decided. The game state is the single source of truth.

It's about separating the what (logic) from the how (visuals). Even with a library handling the pixels, you only realize why interpolation and frame-perfect timing matter once you try to sync them across a network with 100ms lag.

An architect knows when to use specialized tools. I'm not reinventing graphics pipelines-I'm solving problems that existing engines don't handle the way I need them to.

What I'm Actually Building

ShaiEngine powers a roguelite where determinism isn't just a nice-to-have-it's core to the design. Think procedurally generated runs that can be perfectly replayed, shared, and even verified. Think competitive leaderboards where cheating is mathematically impossible because every input is logged and re-simulatable.

That's why I needed full control. No existing engine handles deterministic physics the way I need it. No middleware solves fixed-point collision detection out of the box. This isn't NIH syndrome-this is "the tool I need doesn't exist yet, so I'm building it."

The Verdict

Should you build your own engine for a commercial project? Maybe not. But should you build one once in your life? Absolutely.

It transforms you from a tool consumer into a tool creator. You stop asking "I hope this works" and start knowing "This works because I built it."

You don't do it to save money. You don't do it to be cool. You do it because the alternative is living in someone else's mental model for the rest of your career.

Be the architect, not the tenant.

And if you're curious about the tech: I've open-sourced the fixed-point math library that powers ShaiEngine. Check it out on GitHub.