Welcome to my Zero to Sixty Game Engine Development series.

Find the second article in the series here: Game Engine Design Patterns.

In this series of articles, I present an approach to building a game engine that I call the Zero to Sixty approach.

This series is geared toward professional software engineers proficient in C++ that are already working in games or graphical simulations. It is assumed that the reader has experience with at least one graphics API and, more broadly, experience with game engines, such as Unity or Unreal.

Why Build a Game Engine

Off-the-shelf engines are certainly a fine choice for many game development teams.

However, there are situations where home-rolling one’s own game engine is the correct choice. Following are some of those situations.

  • You are a sole software engineer or part of a small team experimenting with novel or specific game engine architectures. Sometimes, the sheer size and learning curve of those other engines can be prohibitive. If you are a small, but capable, independent team, rolling your own engine affords some strategic advantages.

  • You or your team wants to learn a new graphics API or new graphics programming paradigm. In these situations, off-the-shelf engines can obfuscate the systems being explored and learned due to all of the concerns and legacy code in the engine.

  • You simply want to exercise your ability to architect your own game engine.

No matter the reason for choosing to roll your own, this series of articles can be of help. By the end of this series, we will have a starter game engine, complete with a scene editor, that makes use of both modern and legacy graphics APIs, such as Direct3D 11 and 12, and Vulkan and OpenGL.

Zero to Sixty Approach

The emphasis with this approach is on producing results quickly, without sacrificing performance potential or necessary abstractions. Following are some guiding principles that we will follow in this endeavor, with some examples of how we might apply them.

  • We will make choices that get our engine code to be useful by others as soon as feasible. To that end, we will choose open source components and system libraries where appropriate. For example, to avoid the minutiae of building a 3D math library, we will include glm as a submodule directly in our git repository and ensure that library is easily available by engine code.

  • We will avoid adding many system-level configuration parameters that are worthwhile in a mature, long-lived game engine, but would impede our rapid progress. For example, we will skip right over options such as building our engine as a static library or as a shared library. As another example, we will avoid debating with ourselves the merits of frames-in-flight architectures. Triple- or double-buffered? We dont care. We will just make a hard-coded choice, knowing full well that we can change it down the road.

  • We will focus on configuration parameters that enable other team members to collaborate. We assume we are working with content creators, even if we are a small or solo team. Tech for tech’s sake has its place. However, we want to get to the creative parts of this effort. As an example, we will make sure that content can be edited and persisted for our game engine.

So strap in and join me on this Zero to Sixty Game Engine Development adventure!