Choosing a Game Engine: Why I Kept Starting Over (and What Finally Clicked)

Starting in the Web: WebGPU & BabylonJS

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.

Going Lower-Level: Bevy and a Custom ECS

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:

• Chunk-based terrain
• Procedural generation
• A functioning world structure

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.

The Shader Wall (Again)

Shaders were the recurring pain point.

• Compile errors were frequent
• Error messages weren’t always helpful
• Documentation around Bevy’s rendering and shader pipeline is still evolving
• There’s very little immediate visual feedback compared to mature engines

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.

The Reality of “Just Ship It”

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.

Why Unreal Put Me Off (At First)

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:

• You have to learn an entire ecosystem, not just an API
• There’s very little guidance on project structure
• Tutorials often focus on isolated features, not architecture
• It’s not immediately obvious how to organise systems, components, or responsibilities

Compared to something like a Rust or web codebase, it can feel opaque and overly abstracted.
So I kept leaving.

Why I’m Giving Unreal a Proper Shot Now

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:

• Robust material and shader editors with live feedback
• Joystick and controller input pipelines
• Multiplayer frameworks
• Mobile and console build pipelines
• Asset workflows designed for iteration, not survival

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.

A Note on Godot

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.

Where I’ve Landed (For Now)

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.