Building My Game from Scratch: The Journey of a Custom Engine

When most developers start a new project, they reach for Unity, Unreal, or Godot. These engines are powerful, well-supported, and time-tested. So why would anyone decide to go down the long, winding road of writing their own engine?

For me, it wasn’t about reinventing the wheel—it was about understanding how the wheel works, and then shaping it exactly to fit the kind of game I wanted to build.

Why a Custom Engine?

The short answer: control.

I wanted the freedom to experiment with rendering techniques, terrain generation, and simulation systems without having to fight against a pre-existing framework.

Commercial engines give you speed, but they also come with assumptions baked in—assumptions that don’t always line up with unusual game ideas.

By building my own engine, I could:

Design the rendering pipeline specifically for HDR and physically based lighting.

Experiment with custom terrain systems (like heightmap streaming and erosion-based generation).

Write my own multithreaded job system tuned for the workloads my game needs.

Sure, it’s slower at first, but the creative possibilities open up over time.

The First Milestone: Rendering Something

The first time I got my terrain on screen in DirectX 9, it felt like magic. That terrain eventually turned into:

A robust swapchain that supports HDR10 (Rec.2020 PQ).

A deferred renderer with physically based shading.

A custom post-processing pipeline with ACES tonemapping.

The entire code and shaders are written now in DirectX 12.

Every new effect—from bloom to atmospheric scattering—wasn’t just about “adding a feature.” It was about learning how modern graphics work under the hood.

Tools and Pipelines

Game engines aren’t just about graphics. They’re about content pipelines.

I built importers for:

Models.

Heightmaps for terrain (from tools like Gaea and World Creator).

Textures with automatic mipmap + compression.

The asset system is still basic, but it’s mine. I know exactly how it loads, caches, and streams data, which makes debugging so much easier.

The Challenges

Let’s be real: building a custom engine is hard.

Time cost: Every feature takes longer. There’s no marketplace of ready-made shaders.

Debugging: Sometimes the engine breaks in ways I never imagined—because I’m the one who wrote the rules.

Temptation to over-engineer: It’s easy to get lost optimizing the engine instead of making the actual game.

But the flip side is that each hurdle teaches me something I never would’ve learned if I’d stayed inside Unity or Unreal.

Where the Game Stands Now

Right now, the game itself is a mix of prototype and playable experiment. It’s got:

Streaming terrain with ocean, lakes and rivers carved procedurally.

A working day-night cycle with physically-based sky rendering.

Basic gameplay systems layered on top of the tech.

It’s not polished yet, but it feels alive—because it grew from the ground up.

Lessons Learned

If you’re considering writing your own engine, here’s my advice:

Start small. Get a window open, get a triangle drawn. Build layer by layer.

Focus on your game. An engine is only a tool; don’t lose sight of why you’re building it.

Embrace the slow grind. Progress feels slower than using Unity—but every milestone is yours.

Final Thoughts

Creating a custom engine is a strange mix of masochism and passion. It’s not the fastest way to make a game, but it’s the most rewarding if you want to deeply understand what’s happening under the hood.

My project is still evolving, and I don’t know exactly where it’ll end up—but that’s part of the fun.

After all, it’s not just about making a game. It’s about building the world, the rules, and the tools with your own hands.

September 20, 2025