From Zero to Hero in Custom Game Engine Architecture

Project Chimera: A Postmortem of Our Custom Engine Nightmare

We’re “Bitwise Buccaneers,” a small indie team. Our dream was “Project Chimera,” a sprawling RPG with procedural world generation and a deep, branching narrative. Our ambition, however, far outstripped our experience, especially when it came to building our own game engine. This is the story of how our custom engine became the albatross around Project Chimera’s neck.

Initially, we envisioned a highly optimized engine tailored precisely to Chimera’s needs. We were convinced that off-the-shelf solutions like Unity or Unreal wouldn’t give us the control we needed for our unique world. That was our first mistake.

The Siren Song of Premature Optimization

We started by diving deep into low-level graphics APIs. We wanted to squeeze every last frame out of the hardware. Weeks turned into months as we battled with shaders, render pipelines, and memory management. We hadn’t even prototyped the core gameplay loop, yet we were already optimizing code that didn’t exist. This is classic premature optimization.

Our intention was noble, but the reality was a mess. We built complex systems before understanding the actual bottlenecks in our game. We ended up with a rendering engine that was technically impressive but incredibly difficult to work with. It also didn’t actually improve performance in the areas that mattered.

Abstracted Into Oblivion

Next, we decided to build the “perfect” entity-component system (ECS). It needed to be flexible, scalable, and handle every conceivable game mechanic. We spent months designing and implementing an overly abstract system with layers upon layers of indirection.

The result? An ECS that was so generic it was practically unusable. Adding a simple feature like enemy AI became a Herculean task, requiring us to navigate a labyrinth of components, systems, and message queues. We’d spent so much time abstracting that we’d forgotten the “game” part.

Ignoring the Obvious: Game First!

Our biggest sin was neglecting the actual game. We were so focused on the engine that we barely had a playable prototype for over a year. When we finally did start building the game, we realized our engine was woefully inadequate.

Simple tasks that should have taken hours in a proper engine took days. Our tools were primitive, debugging was a nightmare, and iteration was painfully slow. We tried to fix these issues by adding new features to the engine, leading to even more complexity and technical debt. We also didn’t document or track game development progress.

The Core: What Should We Have Built?

A modern game engine, even a custom one, should have these core components:

• Rendering Engine: Responsible for drawing things on the screen. Should support basic 3D rendering, shaders, and lighting.
• Entity-Component System (ECS): A data-oriented architecture for managing game objects and their behavior.
• Input System: Handles keyboard, mouse, gamepad, and other input devices.
• Physics Engine: Simulates realistic or stylized physics interactions.
• Audio Engine: Plays sound effects and music.
• Scripting System: Allows you to write game logic in a higher-level language.
• Tooling: Editor tools for level design, asset management, and debugging.

We tried to build all of this from scratch, and we failed.

Lessons Learned: An Iterative Approach

Here’s what we should have done differently:

1. Start Simple: Begin with a minimal engine that can render a single character and handle basic input. Focus on getting a playable prototype as quickly as possible.
2. Iterate and Refine: Build the engine iteratively, adding features as needed by the game. Avoid over-engineering and premature optimization.
3. Profile Early: Use profiling tools to identify performance bottlenecks. Don’t guess where the problems are.
4. Game-Specific Requirements: Design the engine to solve specific problems in your game. Don’t try to build a generic, one-size-fits-all solution.
5. Embrace External Libraries: Use established libraries for physics, audio, and other common tasks. Don’t reinvent the wheel unless you have a very good reason.

Balancing Bespoke and Borrowed

There’s a balance to be struck between building your own solutions and using external libraries. We should have leveraged existing libraries for things like physics and audio, focusing our efforts on the unique aspects of Project Chimera. This is where a game dev journal would have helped us record our progress.

We could have tracked why we made certain decisions and what the consequences were. Documenting the specific challenges and technical details would have been invaluable for future development or for other team members.

Don’t Be Afraid to Abandon

Sometimes, the best thing you can do is abandon a flawed approach and start over. We clung to our custom engine for too long, hoping to salvage it. In retrospect, we would have been better off switching to a pre-built engine sooner.

Project Chimera ultimately failed because of our misguided ambition to build the “perfect” game engine. We spent too much time on the technology and not enough time on the game.

Keeping a Game Dev Journal

One of the most valuable tools we lacked was a consistent way to track game development progress. Had we implemented a simple game dev journal early on, we might have been able to identify our mistakes sooner. We could have documented our decisions, tracked our progress, and shared our learnings with the team.

A good game development log doesn’t need to be fancy. It can be as simple as a text file or a dedicated tool. The key is to be consistent and to record your thoughts, experiments, and challenges.

For example, you might record:

• The specific problems you’re trying to solve
• The different approaches you’ve tried
• The results of your experiments
• The decisions you’ve made and why
• The challenges you’ve encountered
• Your overall progress

Several indie developers use devlogs to engage their community, but it also provides a great insight into their past design decisions when returning to old projects. Even solo developers can benefit from revisiting their devlogs when faced with design choices.

This creates a valuable record of your development process that you can refer back to later. A game dev journal can also help you identify patterns in your workflow and make better decisions in the future. It is a great way to keep consistent and organized with the creative process.

If you’re struggling to keep track of your progress and manage your technical debt, consider using our simple dev journal to document your journey. It’s a small step that can make a big difference in the long run. Don’t make the same mistakes we did with Project Chimera. Learn from our failures and build your game the right way.