Making an Engine, or making Games?

06 May 2015  -  Jon Hall

This is the beginning of a blog series on Game Engines.
You've probably made your way here because you either want to make something you can call your own, or you'd like to better understand what makes games work. (Or maybe you just got lost on the internet, and came here out of curiosity)

This series will cover the core components[1] of a simple Game Engine; A closer look at the functionality of those components, how the components are linked together, and examples of implementing each component.


In response to feedback, I'll include a few points to note before you get too deep into the series.

  • The reader is assumed to already have a very basic understanding or experience with a scripting or programming language already (If statements, For loops, Functions, and Variable scope)

  • Each post will be able to be read and followed independently of the rest of the series. I'll make note, and link to dependencies on other content (So you can skip to whichever part of the series interests you).

  • The examples contained in this series are in some cases, simplified for ease of readability and understanding. This may include excessive in-line documentation, and snippets from a larger example (where appropriate, line numbering will be used for code examples).

  • I'll make an effort to update the blog at least fortnightly, unless otherwise mentioned at the end of a given post.

So what exactly is a Game Engine?

A Game Engine is a software framework comprised of a set of subsystems or components which provide the core underlying functionality for the game mechanics.
Strictly speaking, middleware components such as rendering and physics engines are not considered complete 'game engines' themselves, but linked together in a functional manner, or with additional components built around them, they can make up a Game Engine.

In layman's terms, it's a set of components which make use of each other to convert a given input into a meaningful output.

Why create our own engine, when there's already so many available?

Two of the most popular modern game engines around at the moment are Unity, and the UnrealEngine. They are known for their ease of use in making something 'playable' from scratch.
Although many people debate over which is the better engine to use, it is important to remember that it is not possible to create a 'best all-round game engine', because it is always a compromise between performance and perfection.

Although one may be better for rendering in high detail, the other may be better at rendering to a greater distance. One may handle physics realistically, the other may simulate physics on many more objects simultaneously. One may require less work to 'complete' a game, while the other allows for far greater customisation.

Creating your own engine, either from scratch, or by linking a set of existing libraries, allows you to ensure your engine has all the strengths for the mechanics your game requires, and as few compromises as possible. It's rarely going to be an identical set of components for different games, but the essential components usually remain in use within a genre (Most first-person shooters will require highly detailed nearby objects, while real-time strategy games would likely rather display a large representation of the terrain).
Having a better understanding of the components within a game - those that are computationally expensive, and those that are not - aids you in your choices of which algorithms you may use together to achieve the desired result at a reasonable performance.

What makes up a Game Engine?

In a very simple case, an engine is made up of

We will aim to cover each of these components over one or more posts within this series.

Do YOU want to make an engine, or a game?

Making an engine from scratch will rarely result in the completion of a 'polished' AAA quality game, but will leave you with a deeper understanding of specific subsystems and how they relate to each other. You'll be able to pick out techniques utilised in other games, and make well-informed practical suggestions, improvements, and optimisations. You'll understand the performance effect from various game settings, and recognise why 'high' settings perform badly on one device, and smoothly on another.

When making a game with an existing engine you will use a lot of libraries, algorithms, and code that you do not, or will not, need to understand. It involves a lot of trial and error in conforming your data to what the engine is optimised for, and may result in your final product being completely different to your initial vision. You'll learn methods specific to that engine, and be generally bound by the limitations already imposed.

Working from a hybrid of the two extremes is probably the most ideal route to take - use existing libraries for concepts you find tedious, too difficult, or already understand (no point in reinventing the already reinvented wheel!), and build your own components to work alongside those libraries, linking it all together into a functional framework for your game mechanics. You may be looking to experiment or increase your understanding of a particular component, and can figure it out while making use of familiar libraries.


By the end of the series you'll have the knowledge, and enough functional examples, to complete your own basic game engine. Who knows, perhaps you'll then build around that to produce and publish your very own game!

This series aims to help you understand which components are required for given functionality in a game engine, and show some alternative algorithms you can implement along the way. Explanations of components and algorithms will be given as we cover each subsystem, and where suitable, example code will be given.

Comments, Feedback, and Discussion can be found on our subreddit


[1] Core component: The core components of a Game Engine are individual modules or subsystems, each containing the logic for a specific task. Examples include Physics, Rendering, and Audio.