Threads, Fibers, and Other Ways I’ve Tormented Myself While Still Writing My Own Game Engine

Hey, it’s me again.

It’s been four years since my last update—four long years of dodging real-life deadlocks, juggling half-finished projects, and learning painful lessons in both coding and life. Today, I'm cutting through the BS and sharing raw engine ramblings that might actually help someone out there. No lofty life philosophy—just hard-earned insights from my chaotic journey.

EDGE: The Over-Ambitious Mess

Meet EDGE—short for Extensible Data-Driven Game Engine. It was my grand experiment in trying to solve every “big problem” in gaming all at once. With a mishmash of ECS, fibers, Lua, and a custom OpenGL deferred renderer, EDGE was an over-ambitious Frankenstein of dependencies that never quite played nice together.

Moral of the story: Start small. EDGE ended up as nothing more than an abandoned Git repo that screamed “I tried too hard.”

Itero: Less “Kitchen Sink” and More “Spork”

From the wreckage of EDGE, Itero emerged. I ditched the habit of importing every library under the moon for every tiny problem. When performance is your enemy, piling on fibers isn’t the magic bullet. Itero began humbly—with a barebones macro for logging (yes, plain printf until I needed something fancier).

Key takeaway: Choose your dependencies wisely. Don’t let your engine’s architecture be dictated by a library you randomly grabbed at 2 AM while trying to serialize your game objects.

Multithreading, Fibers, and the Beauty of Simplicity

They say multithreading is a “free performance boost”—spoiler alert: it rarely is. In EDGE, I juggled multiple Lua states, a fiber system, and exposed engine APIs, creating a perfect storm for race conditions.

With Itero, I scrapped the fiber circus and embraced a straightforward, single-threaded main loop. Suddenly, things got simpler. I knew exactly who was touching which data. Race conditions? They went from a daily meltdown to an occasional cryptid sighting.

Pro tip: If you must flirt with multithreading, offload your graphics calls. The GPU hogging your main loop is as fun as a root canal, but rewriting OpenGL for the 15th time is even worse—especially with WebGPU lurking on the horizon.

Graphics APIs: From OpenGL to WebGPU

I got my start with OpenGL back when even grandma’s potato PC could run it. Itero still runs on OpenGL—albeit with a lot more duct tape than I’d like to admit. I toyed with Vulkan, but it felt like writing a driver from scratch. Not exactly a one-person show.

Enter WebGPU. This upcoming API is poised to be the “OpenGL of tomorrow,” unifying Vulkan, Metal, and DX12 under one (relatively) sane interface. If you’re starting a new engine, especially one aimed at cross-platform or web, consider going all-in on WebGPU. Otherwise, enjoy the headache of building your own platform abstraction layer—it’s a real treat for your blood pressure.

Lua: A Love-Hate Relationship

Lua has always been my go-to for its lightweight charm and ease of embedding. It keeps my editor lean and mean. But there’s a catch: no type safety, poor IDE support, and a knack for letting you pass the wrong variable until everything spectacularly explodes at runtime.

I experimented with LuaJIT, luac, and a few forks, but nothing fixed the “I want scripting without the pain” dilemma. Nowadays, Itero uses Lua for quick prototyping, while a C++ hot-reload plugin handles the heavy lifting. Sometimes, hacking together a Lua script is far more productive than chasing the mythical “perfect system.”

Looking Ahead

For anyone daring enough to build their own engine, here’s my brutally honest advice:

• Scene Graph vs. ECS: I’ve danced with both. A simple scene graph works great for small demos, but multithreading quickly turns it into a headache. A well-implemented ECS scales better, though it demands more upfront work. If you’re chasing high performance at scale, go ECS.
• WebGPU: It’s coming, it’s powerful, and it might just save you from juggling Vulkan, Metal, and DX12. Consider it seriously if you’re starting fresh.
• Dear ImGui: It still just works. Building an in-engine editor that runs on the same runtime as your game was one of my few “nailed it from the start” decisions.

And if you want real results—forget building your own engine. Use Unity, Godot, Unreal, or any other engine with a massive community behind it. But if your constraints force you to roll your own, just know it’s a wild ride of trial, error, and plenty of hair-pulling.

Final Thoughts

I’m still here, still pushing triangles and patching up my mistakes. Would past me do it all over again? Probably not. But here are a few nuggets I’ve learned along the way:

1. Set Clear Goals: If you’re trying to build an engine that does everything, you’re setting yourself up for failure.
2. Keep It Small, Keep It Simple: Perfection is the enemy of progress—this truth never gets old.
3. Place Abstractions Judiciously: Overusing singletons or convoluted callbacks only adds to your future headaches.

Thanks for sticking with me through these ramblings. Whether you’re in the trenches building your own engine at 3 AM or just here for a laugh at my expense, remember: every misstep is a step toward mastery—if you survive the chaos.

Now, go forth and implement that one obscure feature that will supposedly fix everything—just try not to spontaneously combust in the process.

P.S: If there is interest I'll eventually drop some more detailed articles with actual data, charts and metrics. I promise this time it won't take another 4 years.