So, You're Considering Building a Game Engine (2023 Edition)

The recent turmoil surrounding Unity ignited a fierce conversation regarding the state of game engines.

The community split into several camps: some urged an immediate migration to alternative software, while others countered that switching platforms can be a grueling process lasting months or even years. Meanwhile, a third group suggested that the ultimate solution is to build your own engine from scratch, though critics quickly pointed out that this is an immense undertaking.

In reality, everyone is correct. There is no universal answer; the right path depends entirely on your specific circumstances. But is creating your own engine truly as daunting as the rumors suggest?

A Bit of Context

I haven't spent my time in mainstream engines. Instead, I've spent the last three years cultivating my own "pet engine." It has grown to approximately 100,000 lines of code and has powered over a dozen game jam entries and one commercially released title.

While my perspective is unconventional, it is informed by:

• Observing other developers' workflows.
• Listening to common grievances about industry-standard tools.
• Analyzing the source code of various open-source engines.

---

Part 1: The Hard Questions

Why bother making your own game engine?

This is a perennial debate, but it's worth revisiting. Here is a checklist of motivations for taking the plunge:

• Escape Corporate Whims: You are no longer subject to questionable business decisions from a parent company.
• Financial Independence: The engine is free (if you ignore the massive cost of your own time).
• Hyper-Optimization: You can tailor the engine to your specific project. This includes:
  • Performance: Stripping out what you don't need.
  • Iteration Speed: No more waiting for lightmaps to bake or shaders to recompile.
  • Architecture: Choosing an ECS (Entity Component System) over a traditional scene graph for games with millions of entities.
• Total Sovereignty: You control every internal mechanism and technology choice.
• Language Preference: Use the programming language you actually enjoy.
• Lean Distribution: My engine's footprint is under 2MB (mostly just the SDL2.dll).
• Community/Commercial Potential: You can open-source it (though maintaining FOSS is basically hell) or sell it (though marketing is also basically hell).
• Zero External Frustration: You'll never be annoyed that a corporate dev hasn't implemented a requested feature for ten years.
• Social Status: Some people on the internet will think you are incredibly cool.
• Pure Joy: It is genuinely fun.
• Educational Growth: You will learn an astronomical amount, which makes you a better developer even if you eventually scrap the engine.

For me, the fun and the learning are the primary drivers. If you're entering game dev, you have to learn a mountain of material anyway—you might as well enjoy the climb! I love the process of designing systems, implementing complex algorithms, and diving into low-level memory management.

The Psychology of Frustration

I've noticed a pattern: developers constantly complain about "broken" features or legacy support in big engines. In a corporate environment, there are always reasons for these flaws. However, when you build your own tool, the frustration vanishes. Why? Because you know exactly why a feature is missing—because you haven't written it yet.

It is psychologically easier to be patient with your own shortcomings than with the perceived incompetence of a stranger.

The Trade-offs

Of course, this path isn't without its thorns.

If you want to ship a game as fast as humanly possible, just use an existing engine. But if you have an abundance of time and want to secure your future as a versatile developer, build your own.

Decision Flowchart

---

What is a Game Engine, Anyway?

I would argue that a "game engine" isn't really an engine at all; it's more of a platform abstraction library.

Consider a minimal project that utilizes SDL2 for windowing, OpenGL for rendering, and stb_image for loading textures to move a few sprites around. Is that an engine?

To define this, we can think of an engine as a summation of various abstractions:

$Engine = \sum (Rendering + Input + Physics + Audio + Scripting)$

One of my friends creates highly successful text-based games that run entirely in a terminal. They have no graphics, no animations, and no GPU acceleration, yet they are undeniably "games." This suggests that the "engine" is simply the layer that allows the game logic to communicate with the hardware.

Example: A Simple Abstraction Loop

In a custom engine, your core loop might look something like this:

while (engine.isRunning()) {
    float dt = engine.calculateDeltaTime();
    
    engine.processInput();    // Abstraction of OS events
    engine.update(dt);        // Game logic
    engine.render();          // Abstraction of Graphics API
}

By writing this yourself, you aren't just making a tool; you're defining the very rules of how your digital world interacts with the physical machine.