How Do You Start Making Your Own Game Engine?
Where do we even start?
Introductions
My name is Alex, though most people online know me as Analog Dream Dev.
I’ve spent the last decade working across game art, tech art, gameplay systems, and low-level rendering. I’ve been shipping indie titles, contributing to larger projects, and slowly expanding the boundaries of what I understood about how games are actually built. I didn’t start as an engine programmer. I started as a 3D artist who couldn’t leave the technical side alone.
RetroEngine is the natural result of that trajectory: a custom DirectX 12-based engine built to simulate CRT displays physically, not cosmetically. This Substack is where I’m documenting that journey in public.
1. Retro Game Engine Origins
Since I started recently sharing progress online of my adventures into writing my own custom game engine, people keep asking me the same question:
“How do I start making my own game engine?”
Some of them are indie developers who’ve shipped games in Unity or Unreal. Some are curious engineers. Some just like the idea of it. They expect a technical answer, I think. Pick a language, pick an API, build a renderer, maybe write an ECS.
But that’s not actually where you start.
If I’m honest, you don’t start by choosing C++ or Rust or Vulkan or DirectX. You start much earlier than that. You start by understanding why you’re even capable of wanting to build one in the first place.
For me, Retro Game Engine wasn’t just a decision I made in 2025. It was the culmination of everything that came before it. It was the culmination of me and 30 years of relationship with games.
And that story begins with sitting too close to a CRT.
2. The Glow
I was four or five years old when I beat Sonic the Hedgehog 2 for the first time. It’s the first game I remember finishing completely on my own. I can still picture the living room floor, the way the light from the television filled the room in the late afternoon, and the voice in the background telling me I was “too close to the TV.”
I can still hear the iconic “SEGA!” as the blue blur raced across the screen.
Back then, every cartridge felt like a universe. There was no Google. No YouTube walkthroughs. No patch notes. You learned because you had to. Those games could be brutally challenging. You shared secrets at recess like you were exchanging contraband. Entire playground economies were built around rumors and cheat codes. Above all else, the experience of playing those games instilled a sense of tenacity in me.
At friends’ houses we played GoldenEye with older siblings. Normally a bunch of ten-year-olds and teenagers wouldn’t hang out, but put four N64 controllers in their hands and suddenly age doesn’t matter. Mario Kart 64 did the same thing. If you were good, you could beat anyone. Games collapsed social barriers.
What I didn’t understand at the time was that I wasn’t just playing games. I was absorbing magic: the glow, the blur, the way color bled into itself. The way motion felt different. CRTs weren’t just showing an image, they were emitting light.
That detail would sit dormant for decades.
3. When Magic Got A Name
Eventually, I saw the credits roll on a game. Names. Real people. It was the first time I understood that the magic came from somewhere. These worlds weren’t spontaneous. They were built.
I didn’t grow up in a place where tech careers were obvious or accessible. I was born in 1990 and raised in a more rural area. Internet meant library computers for a while. I wanted to do graphic design as a kid, but I didn’t have a straight path toward it. Eventually, I found my way into school for game art and became a 3D artist.
I loved making art. But something always felt incomplete. I would build a model, texture it, polish it, then hand it off to someone else to “make it work.” They would wire it into the engine, add behavior, hook up logic.
That part felt like magic.
And I didn’t like that I wasn’t part of it. The art alone wasn’t enough for me. People always firmly placed themselves into boxes around me. I only do hard surface modeling. I only animate characters. I only write AI enemy behavior. I felt odd. None of that was enough for me. I wanted to do all those things…but was this allowed? Could a 3D artist learn to do more? I didn’t know. But decided I’d try it anyway.
So I started asking questions. Then more questions. I learned visual scripting. Then C#. Then C++. Not because I set out to become a low-level graphics programmer, but because curiosity kept pushing me further. This was important, at least for me. I spent almost a decade working in Unreal and Unity, learning how to twist them into things they weren’t originally built to do.
I accumulated tools without realizing what they were preparing me for.
4. Shipping Changes You
In 2024 and 2025, I shipped two indie games with another developer: The Quantum Conflict and Cozy Holes. We had no funding. Just persistence and the willingness to keep solving problems until they were solved.
They weren’t commercial breakthroughs. But they were formative. Shipping something forces you to confront reality. It teaches you discipline. It teaches you humility. And it removes a kind of fear that would otherwise hold you back.
After each release, I would look back and think: why did I assume that was impossible?
Around the same time, something else was happening. I found myself drifting back to older games. I was getting bored with modern gaming trends. Continued feelings of a loss of that magic and soul games once had. So I returned to childhood favorites. Titles from the 90s/early 2000s I hadn’t gotten to play as a kid. I was trying to recapture something. But on modern displays, they didn’t look the way I remembered. They felt flat. Sterile. Chunky.
So in September of 2025, I bought a 1998 Sharp CRT from an older gentleman for $35. He just wanted to clear out space in his house with what he saw as a relic. I just wanted to relive a phosphor-soaked past. It cost me more in back pain than money to get it home. I plugged in a Super Nintendo and powered it on.
The magic came back.
It wasn’t nostalgia. It wasn’t placebo. It was physics.
The glow. The motion persistence. The way light diffused across phosphors. The subtle analog softness that modern panels don’t reproduce.
It was joy…and also sadness. Because I realized that what we lost wasn’t just a display technology. We lost a relationship between hardware and image. We lost the magic of infinity.
That’s when the question stopped being “how do I add a CRT filter?”
It became “what is a CRT actually doing?”
5. When Post-Process Isn’t Enough
I had built post-process CRT effects before. Scanlines. Bloom. Curvature. Color grading. They were fine. But they always felt like they were sitting on top of the image, not emerging from it.
That’s when I had a realization that shifted everything.
Post-process, by definition, is after the fact.
Scene → Render → Post → Present.
You’re manipulating a finished image.
But a CRT isn’t filtering a texture. It is the final physical mechanism. An electron beam sweeps left to right. Phosphors excite and decay over time. Brightness affects beam spread. Subpixel geometry shapes the emitted light. Motion is literally persistence.
That’s not an overlay.
That’s simulation.
And I realized that in modern engines, I couldn’t “get before post” without fighting abstractions that were never designed for that level of control. They assume a camera capturing a scene and then applying screen-space effects. I didn’t want a camera metaphor.
I wanted a display metaphor.
If I wanted to simulate a CRT physically, I had to control the entire pipeline.
CPU. GPU. Swap chain. Frame loop. Resource states. Render targets.
Which leads back to the original question.
Where do you start?
6. Starting Smaller Than You Think
You don’t start by designing an engine architecture diagram. At least, I certainly didn’t
I started by opening a window.
Literally.
My first milestone wasn’t anything “grand”. It was making the GPU put pixels on the screen there were under MY control. That meant creating a Win32 window, initializing DirectX 12, setting up a device and command queue, creating a swap chain, allocating a render target, and presenting a frame. None of which I had done before. So I got to reading. To experimenting. To asking questions.
No ECS.
No physics.
No content browser.
No fancy editor.
Just a loop.
The CPU records commands into a command list. The GPU executes them asynchronously. Fences synchronize frames. The swap chain presents the back buffer. That’s the foundation underneath every modern engine.
Once I had that loop under my own control, everything else became layered intent.
From there I rendered a simple scene into an HDR buffer. Then I introduced a second render target to simulate phosphor persistence. Then I built a multi-pass pipeline: render the scene, accumulate persistence, composite the CRT simulation, present to the swap chain.
Only after that vertical slice worked did I expand outward into a SceneGraph, entity transforms, mesh importing, sprite rendering, and eventually an editor with live CRT parameter tweaking.
I didn’t build an engine horizontally. I built one thin slice of it deeply and then widened it.
That approach matters.
7. Why C++ and DirectX
Not because they’re superior. Because they were familiar to me.
I learned C++ through Unreal. I had already touched DirectX 12 enough to not feel lost. That meant I wasn’t trying to learn a new language, a new graphics API, and a new architecture all at once.
When you attempt something this ambitious, you don’t maximize novelty. You minimize friction.
Pick tools that are already in your bones.
The point isn’t to impress anyone with your stack. The point is to move forward. To learn, to progress, to see the outcome of your hard work.
8. Projects Pick You
If you’re thinking about building your own engine, I’m not going to tell you to go study a graphics API tonight.
Instead, I’d tell you to study yourself.
There’s a difference between picking a project and a project picking you.
RetroEngine wasn’t a business strategy. It was the intersection of childhood memory, a decade of accumulated technical skill, shipping games, and a specific frustration I couldn’t let go of.
It was inevitable.
There is something in your life that has been quietly accumulating the same way. Some frustration. Some aesthetic. Some technical curiosity that keeps resurfacing.
Study that.
What tools are already second nature to you? What problems do you keep circling back to? What idea feels less like a choice and more like an obligation?
That’s the project you’re primed for. With any project there will be ups and downs, moments of euphoria and depression. If you can’t put it down, can’t let it go, no matter what, then those things won’t matter. What can you not stop yourself from pursuing?
And once you recognize it, you’ll realize you were always walking toward it.
Join the Analog Dream
If this resonated with you, please subscribe.
I’m documenting the build of RetroEngine in public, from low-level rendering fundamentals to CRT simulation, scene architecture, and eventually a full game built on top of it.
Future posts will dive into:
How a frame actually works (CPU ↔ GPU)
Building a custom rendering pipeline from scratch
Simulating analog displays physically, not cosmetically
Engine architecture decisions (and mistakes)
General love of retro video games and game art.
This isn’t a tutorial series. It’s a tenacious build log. Its a love of gaming and retro hardware.
If you’re the kind of person who can’t let go of an idea once it grabs you, you’ll probably feel at home here.
— Analog Dream Dev
Just saw your post from twitter. What an article! Will definitely be reading more of this.
Impressive article.
It's all about pixel warmth.
Keep inspiring us to create amazing gaming tech.