ECS Game Engine Framework

ECS Game Engine Framework + Asteroids Demo

Background

In highschool, inspired by games I had played as a kid, I wanted to make one of my own. I had progressed from playing around in MIT's Scratch to developing in Unity, but there was a degree of control and understanding I wanted to have in the development process that these high-level engines didn't easily provide. To solve this, in 2020 I naively set out to create my own game engine to build games with. This turned out to be an endeavor that would take multiple attempts and iterations.

During my initial research, I stumbled upon a fantastic GDC talk covering the proprietary game engine of my favorite game at the time, Overwatch.

The Overwatch engine employed a unique and popular architecture known as the Entity-Component-System (ECS) architecture. Having seen and experienced a successful example of an in-house game engine, I felt that my project was feasible, and set out to create an ECS framework.

This video has a good general overview of how ECS works. In words:

Objects in the game are referred to as "entities". In practice, entities in a game are really just a collection of data, such as position, velocity, appearance, etc.
Entity data can be broken down conceptually into its smallest shareable "components". For example, if I know that many objects in my game will need to store their positions (which is true for nearly every game), I can define a component called a "Transform" component to contain the position of an entity. By defining this one Transform component, positional data can be recreated for many entities, without having to manually define a variable for every individual entity.
Finally, rather than programming the behavior of each individual entity, behavior is provided through "systems", which can access sets of components at a time. A system doesn't have to know what the specific type of an entity is. For example, you could choose for a SpriteRenderSystem to iterate over only SpriteRenderer components and render them to the screen. In this scenario, any new entities created with a SpriteRenderer component would automatically be added to the SpriteRenderSystem and rendered appropriately.

If that was a lot, I have come to find that the driving principle behind ECS is really very simple- write as little code as possible to make the fastest program possible. By allowing the developer to reuse both data (through components) and behavior (through systems), similar code patterns should only have to be written once. This puts the focus on creativity and productivity.

Technical Design

With little experience at the time, my first attempts came from a tutorial by Austin Morlan demonstrating a simple ECS implementation in C++.

Following multiple iterations, attempted on and off over the course of several years, I finally reattempted to create my game engine from scratch. Using my previous experiences, I carefully planned a streamlined, deliberate framework that addressed previous issues and was easily accessible for the user. The general flow is shown below in a UML diagram.

NOTE

The rest of the Design section will be dedicated to showcasing some notable features of the game engine framework. For a more complete view of the library, check out the code for my Asteroids demo at its Github repository.

What's an object?

For this library I decided to refer to entities as objects for the purposes of legibility and user understanding. I feel that the term "object" has a much more intuitive meaning, and the very definition of the word "entity" is vague.

Figure 1a: A ship would be considered an object that is made up of data such as position, velocity, a sprite image, and potentially more.

What's a scene?

A scene is essentially just a collection of objects and systems. By grouping them together in this way, the developer can create multiple scenes that can be switched between during a game or simulation- for example, transitioning from a menu to a playable game.

Figure 1b: An example of a scene with multiple objects (asteroids, ship, score text) and behaviors (asteroids drifting, ship movement, updating score text)

Singletons and Persistent Singletons

As forshadowed by the GDC talk delivered by Tim Ford, I soon encountered several challenges while implementing the engine. While most of the game logic fell into the pattern outlined in ECS, there was some data needed by the game that didn't really belong to any particular object. This data was often more administrative, and was frequently needed to handle external libraries for rendering or networking.

Rather than create a permanent "object" to attach these special components, I embraced them and added the ability to create special components that exist only once. These special components, called Singletons, remove the need to create unnecessary objects for one-off data structures.

Figure 1c: A struct, called SDLton, used to contain the Simple DirectMedia Layer (SDL) Library, which is responsible for getting user input and rendering to the screen. Since only one copy of the struct is needed, it can be used as a Singleton to keep from having to attach it to an object unnecessarily.

I also encountered a scenario where data might not only be needed across a single scene, but across many. In particular, data used for rendering necessitated this type of "Persistent" Singleton, so that the rendering devices weren't lost when switching scenes. I created a special place for these persistent Singletons so that they can be accessed from any scene.

Interfaces

Just like certain data needed to be accessible across all systems in the form of Singletons, there is functionality that is often repeated as well. For example, rather than copy and paste the code to create an certain type of object, the user might want to create a centralized function that can be referenced by any scene. To solve this I introduced a structure that I'm calling an Interface. This is a place to define functionality that can be used across the entire scene.

Figure 1d: An interface called EntityCreator with a function for creating a ship at a specified position. This interface can be used to call the user's CreateShip function from anywhere in the game's code.

Pool Patterns

The last feature that I will discuss here is the library's extensive use of pool patterns. In games, many objects are often created and destroyed. Improper memory management is one of the biggest causes of slowdowns in games, so I decided to address this by never deallocating memory during the runtime of a scene.

When objects' components appear "destroyed", they still exist, and are actually waiting to be reassigned for the next component created. This reuse of memory, called a pool pattern, completely eliminates slowdown caused from allocating and deallocating memory when creating or destroying many objects. The result is that while being played, the game essentially "remembers" the maximum memory required for each type of component, and will keep that memory allocated for the duration of the scene.

Final Thoughts

Why this library?

The purpose of this library is to demonstrate how ECS works, as well as provide a flexible framework for the advanced development of games and simulations. While it puts the game's functionality into the hands of the developer, it also eliminates unwanted overhead from game engines. The developer has full transparency and control over the entire development process, which is useful when crafting games or simulations that need to feel unique from generalized game engine solutions.

I have found it particularaly useful when a developer wants to use many different libraries in their game, since it is very easy to incorporate new libraries in C++. For example, with this library, the developer doesn't have to rely solely on networking or physics solutions compatible with a specific platform or game engine- they can choose the best library for the solution in C or C++, and it will integrate seamlessly with the framework.

With the library fully functional, I am currently using it to create several games I have been wanting to make. If it aligns with your solution, you can use it without credit, although credit is definitely welcome. To see the library in use, you can find the code for my remake of Atari's Asteroids here. For more information, feel free to contact me here.