The Reality of Building Something That Renders Pixels Without Crashing Every Fifteen Minutes
Most people who want to build a game engine start by watching Unreal Engine 5 source code breakdowns and thinking they understand what they're looking at. They don't. The gap between building a working prototype and shipping something usable is massive and mostly consists of plumbing nobody wants to talk about. Here's how the actual work goes when you're not writing for a textbook. Start with a resource management system. Not the renderer, not the script interface, the resource system. Everything your engine touches flows through it, and if you get this wrong your memory usage becomes a lottery where most tickets lose. I built a simple streaming system early in my project that used a least-recently-used eviction policy with a hardcoded 512MB cap per texture group. Looked fine on paper. Ran into a wall when a single open-world level with four high-poly character variants pushed VRAM to 3.2GB before the garbage collector even had a chance to run because the resource manager wasn't integrated with the allocator pool properly. Workaround was rewriting the entire allocation strategy to use arena allocators with explicit lifecycle tracking instead of relying on std::free, which cut memory peaks by roughly 60% and eliminated the random crashes. Takes about two weeks of work if you know what you're breaking. Took me six because I had spent three weeks unaware of what I'd broken. This is where every engine designer fights a war they should have researched before joining. The scene graph approach gives you intuitive hierarchy and spatial queries out of the box. It's also a performance nightmare at scale because every transform update requires traversing the entire tree, and cache coherence dies the moment you have more than a few hundred objects. Entity Component Systems solve that by laying out data in contiguous arrays that CPU caches actually like. The tradeoff is that spatial queries become a pain to implement cleanly, and you lose the nice parent-child visual debugging that makes level design tolerable.
I went with a hybrid. ECS for everything that needs performance, a lightweight hierarchy layer on top that only exists for editor convenience and physics broadphase. The hierarchy doesn't drive transforms during runtime — that's handled by the component data layout. Editor tools read the hierarchy separately and sync writes back to the ECS at tick boundaries. This means the actual game loop never walks a tree, which matters more than you'd expect when you're targeting 60fps on hardware that has a cache line smaller than your average actor.
Data-Oriented Design Is Not A Buzzword You Can Skip
Object-oriented design feels natural because that's how you think about problems. It's also the primary reason engines built by small teams stall out when they try to scale past their test scene. When your GameObject has a Transform component, a MeshRenderer, a PhysicsBody, and a ScriptComponent all as virtual inheritance chains, your CPU is spending more time following pointers than doing actual work. The fix isn't heroic refactoring, it's restructuring your hottest loops to store data in arrays of structures rather than structures of arrays that hide pointers behind virtual dispatch. A practical example: a standard render pass iterating over all visible objects with OOP architecture might process 80,000 cache misses per frame on a midrange CPU. Refactor that same pass to use SoA layout with batched draw calls and you're looking at maybe 12,000 misses. That's not a theoretical improvement, I measured it on a project with roughly 400 dynamic objects in a typical combat scene. The numbers held up across three different architectures. Intel, AMD, ARM — the pattern was consistent enough that I stopped benchmarking individual chips.
Get the Full Details
Scripting Integration: The Part Everyone Underestimates
You need a scripting layer that your designers can actually use without waiting on engineers to expose APIs. Lua is the industry workhorse for a reason, not because it's the fastest language but because embedding it is straightforward and the GC model is predictable enough to manage. LuaJIT gives you FFI access to C++ without generating binding code, which saves enormous amounts of boilerplate. The downside is that it's 64-bit only and the JIT compilation can stall your main thread for a few milliseconds on cold start, which matters if you're doing frame-pitch-perfect audio synchronization. For my project I used LuaJIT with a thin C++ binding layer that marshals common types directly. Custom types go through a registry with explicit lifecycle hooks. This means garbage collection doesn't accidentally destroy a C++ object that the engine still holds a reference to, which is the bug that will keep you up at 3am once it hits production. I learned this the hard way after a level loaded incorrectly three times during playtesting because a script reference to a destroyed mesh was returning stale memory that happened to look valid. The fix was adding reference counting with explicit owner validation on every Lua-to-C++ bridge call. Adds maybe 200 nanoseconds per call. Worth it.
Math And Coordinate Systems Will Burn You
Right-handed versus left-handed, column-major versus row-major, pre-multiplication versus post-multiplication. Pick your convention early and commit to it before anyone on the team starts writing matrix code. I picked right-handed Y-up with column-major matrices and pre-multiplication, which is the Unity convention, and spent approximately one month reconciling it against every asset pipeline tool and graphics API that assumes something different. OpenGL is technically left-handed in clip space despite the rest of the spec being frustratingly ambiguous about it. Vulkan is explicitly left-handed. DirectX is right-handed. Three different coordinate conventions sitting in the same codebase because nobody decided until after the renderer was written. The workaround was wrapping every matrix operation in a single inline function that handles the transpose internally when crossing API boundaries. Cost is negligible — it's one conditional per matrix multiply in the worst case, and compilers optimize it away when the condition is compile-time constant. The real cost was the two weeks of debugging where normals were flipping direction depending on which API path the draw call took.
Asset Pipeline: Where Projects Actually Die
Your engine is only as good as the assets it can consume, and asset pipelines are boring infrastructure work that rarely gets prioritized until someone tries to import a model and the engine explodes. A functional pipeline needs at minimum: format detection, version handling, dependency tracking, and incremental import. Format detection means your importer knows whether it's looking at an FBX, glTF, USD, or raw OBJ without manual configuration. Version handling means you don't corrupt existing assets when the pipeline tool updates. Dependency tracking means if you change a material, only the meshes that reference it rebuild, not the entire scene. Incremental import means the build system understands what changed so it doesn't reprocess three hours of data for a single texture swap. I built this on top of a file watch service that triggers import jobs on filesystem changes, with a manifest-based dependency graph stored in JSON. The manifest tracks asset GUIDs, input file hashes, output file paths, and which other assets depend on each one. When you change a texture, the system looks up which meshes reference it, marks those as dirty, and queues only those imports. Cuts import time for a typical level from twelve minutes down to about forty seconds on a machine with eight cores and an NVMe drive. The four seconds of manifest parsing overhead is completely dwarfed by the skipped work.
Testing And Debugging Infrastructure Matters More Than Features
A game engine without profiling tools is just a collection of bugs with a rendering loop. You need frame timing visualization, memory allocation tracking, GPU compute counters, and a way to replay captured frames deterministically. The replay capability is the one most people skip and immediately regret. When a bug only reproduces under specific conditions — which is always — being able to pause, step forward frame by frame, and inspect the exact state of every system at the moment of failure saves days of guesswork. I use a hybrid approach: frame capture with state serialization for the render layer and a separate lightweight checkpoint system for game logic. Checkpoints cost about 4MB of disk per save point on a typical scene, and you can set them at strategic moments like boss encounters or level transitions without filling the drive. The checkpoint format is just a binary dump of component data arranged by archetype, which makes serialization trivial because you already have the archetype structure from your ECS implementation. Deserialization runs in roughly 2 milliseconds for a medium-complexity scene, which means fast iteration during debugging without making the tool suite slow enough that nobody uses it.
What This Approach Doesn't Solve
Data-oriented redesign takes real effort and most small teams don't have the bandwidth to do it properly. If your engine started as a traditional OOP project, refactoring the hot paths is a multi-month undertaking that will cause regressions. There's no clean incremental path, you either do it in a big refactor or you live with the performance ceiling. Similarly, the hybrid ECS-hierarchy approach I described adds architectural complexity that creates new bugs, particularly around sync timing between the hierarchy layer and the ECS layer. If you get the sync wrong, you'll see objects rendering in the wrong place or physics bodies desyncing from visual position, and diagnosing which layer caused the mismatch is not trivial. There's also the reality that some problems simply cannot be solved by engine design alone. Memory fragmentation from long-running sessions, GPU driver bugs that appear on specific hardware combinations, and the eternal challenge of balancing quality against platform constraints are all unsolved at the industry level. No architecture choice eliminates these. They just become your problem to manage rather than someone else's. If you're starting fresh and the target platforms are modern desktop and console hardware, the approaches above will serve you reasonably well. For mobile or web targets, you'd need to reconsider the asset pipeline entirely and probably revisit the scripting layer choice, since LuaJIT's memory footprint is too large for constrained environments. Each target has its ownset of compromises, and none of them are free.
