1: Writing a game engine, without writing a game engine

Last Updated: 6/9/2020

Note: This is NOT engine documentation. I write these articles as I learn. As such, information present here may be incorrect or out-of-date. I'm leaving these pages online for historical purposes only.

I've been writing software since 2010, and have always been fascinated with game development. I got into the game development space in 2015, using engines like Unreal, Unity, and Godot.

While each of these engines are extremely powerful and in dedicated hands will produce stunning results, I could never get into any of them.

• Unreal
  • Designed for Triple-A titles, so requires a lot of disk space (20+ GB!) and a powerful PC to run the editor
  • C++ documentation is poor to non-existent, and C++ API is not intuitive
  • Poor performance on mobile or low end PCs, especially compared to Unity and Godot
  • Lots of bugs in C++/blueprint interop leading to blueprint corruption
  • C++ incremental compile times are very slow
  • Lack of community-made resources and tutorials, compared to Unity and Godot
• Unity
  • Editor is buggy and unresponsive
  • Slow asset importing times
  • No built-in networking workflow. You must create symlinks of your project to trick the editor into opening the project twice, or create builds every time you need to test a change.
  • High percentage of broken or rushed updates with regressions, compared to Unreal or Godot
  • Features ship incomplete with no guarantee of future progress (RIP UNET)
• Godot
  • Does not scale upwards
  • Requires a custom slow programming language, bindings to other languages have poor documentation and/or are incomplete
  • Features behave in unexpected or incorrect ways, especially physics

As COVID-19 hit and my second semester at the University of Michigan finished, I found myself in need of a summer project. I decided that I would write my own game engine.

I have a few major goals for my engine:

1. Cross-platform, native, on mobile and desktop
2. Free automatic multi-threading via an Entity-Component-System model, while also supporting OOP
3. Offer a clean, well-documented, and easy to use Modern C++ API
4. Provide automatic memory management through reference counting instead of a garbage collector, to provide control over memory without risking leaks
5. Support modern rendering backends, like Metal, Vulkan, and DirectX

There's one problem with that idea: writing your own game engine from the ground up is a colossal waste of time, and with these goals, I would have no hope of finishing. I know that I cannot replicate the work of hundreds of talented, experienced developers, by myself. So instead, I decided to find out if I could write a game engine, without writing a game engine. I added two more goals:

• Leverage existing technology wherever possible
• No GUI

In essence: Don't reinvent the wheel (at least, not more than I already am by writing a game engine). The second one may seem a little odd though - how is no GUI better? It offers a few advantages: the complexity of creating a good UI is gone, and an engine GUI is often not necessary for the vast majority of engine tasks. Rather than design my own workflow, I can design my engine as a library and leverage existing creation tools.

This brings me to my first rule: always plan before you program! I plan out everything ahead of time on a simple text document, from what the code will do to how the API will look. This saves a lot of time, because iterating on paper is cheap. I've spent far less time rewriting code after adopting this strategy.

Next Up: Memory Management via Automatic Reference Counting

• The Beginning
• Memory Management
• Physics Simulation
• Rendering Megapost
• Build Systems
• Events and Interfaces
• ECS Megapost
• Assets and Factories