You can unsubscribe at any time.
You can unsubscribe at any time.
Jan 14, 2026
Choosing a game engine turned out to be harder than building the game itself. Here’s what I tried, what broke, and why I finally committed to Unreal Engine.

Like many web developers, my first instinct was to look at the web.
WebGPU is exciting. BabylonJS is powerful. The idea of shipping a game that runs in a browser — or even wraps cleanly into a mobile app — is incredibly appealing. I managed to get a prototype up and running, and from a purely technical standpoint, it worked.
But very quickly, I ran into friction.
Writing shaders and materials in this setup just didn’t feel seamless. You’re often jumping between shader code, engine abstractions, and limited visual feedback. Iteration is slower than it needs to be, and small visual tweaks become disproportionately expensive in terms of time and focus.
For experimentation, it’s great. For building something polished, it started to feel like swimming upstream.
From there, I swung in the opposite direction and leaned into something much more systems-oriented: Bevy.
Bevy is impressive. Its ECS is clean, modern, and genuinely enjoyable to work with as a programmer. I built a working prototype with:
At one point, I even had multiplayer working using a peer-to-peer WebRTC-based networking layer (via an RPC-style abstraction). It worked — which felt great — but it also highlighted the core issue.
Shaders were the recurring pain point.
To be clear: this isn’t a knock on Bevy. It’s moving fast, and I think it will get there. But right now, if your goal is to build a finished, visually polished game, its not there yet.
And that matters.
There’s a common piece of advice in game dev:
“Don’t worry about polish — just get a functional prototype first.”
That advice is valid. But it doesn’t work for everyone.
For me, visual feel and UX aren’t optional extras. They’re what keep me motivated. If something looks clunky, unresponsive, or visually off, I lose energy fast — even if the underlying systems are sound.
When the tools make it hard to iterate on lighting, materials, animation, or moment-to-moment feel, the project slowly drains momentum.
And that’s exactly what kept happening.
I’d looked at Unreal Engine before — more than once — and bounced off it hard.
What put me off wasn’t its power, but its workflow.
As a programmer, Unreal initially feels like:
Compared to something like a Rust or web codebase, it can feel opaque and overly abstracted.
So I kept leaving.
Eventually, though, I had to be honest with myself.
If the goal is to make a polished game — with solid controls, good visual feedback, multiplayer support, and realistic paths to publishing on PC or mobile — Unreal removes huge amounts of friction.
Things that took days or weeks to assemble elsewhere are just… there:
Publishing to mobile platforms, especially iOS, is a great example. Apple is difficult at the best of times, and rolling your own pipeline around web or low-level engines adds complexity you really don’t need. Unreal (and similarly, Godot) drastically lowers that barrier.
At some point, the trade-off became clear:
I can keep reinventing the engine, or I can spend that energy making the game feel good.
Godot is still on my radar.
I haven’t explored it deeply yet, but it sits in an interesting middle ground: lighter-weight than Unreal, far more opinionated and complete than DIY engines. It may end up being a great fit — but I need to give one engine a real, focused attempt first.
Right now, that’s Unreal.
I still love digging into engine internals. There’s something deeply satisfying about understanding everything from the ground up.
But for this project — and for how my brain works — polish isn’t a “later” concern. It’s part of the core loop that keeps me engaged.
Unreal isn’t perfect. It has a learning curve, and it asks you to adapt to its way of thinking. But it also respects the reality that games are as much about feel, feedback, and presentation as they are about systems.
And that’s what finally made it click.
I’m committing to learning it properly — not dabbling, not bouncing — and seeing what happens when I stop fighting the engine and start using it for what it’s good at.
If nothing else, this whole process has taught me something important:
The “right” engine isn’t the most elegant one.
It’s the one that keeps you building.
You can unsubscribe at any time.