So you want to build a 3D game engine? Well, you’ve come to the right place. Here, you will learn about game engine architecture, objects, scripting, rendering, networking, physics, IO, audio, building an editor, and putting it all together into a game (or at least a series of demos). We will do both a deep dive in each category and show how they all fit together.


The goals for the engine are:

  1. Make the engine data-driven. This places a strong emphasis early-on on serialization, both for storage and networking. It also makes the editor easier to build — if everything in the game is based on data, it’s easy to have a predefined list of data types and expose them all to the editor.
  2. Make scripting a 1st-class citizen. Almost everything should be exposed through scripting so that we don’t end up in the spot of having to do some things in C++ only and some thing in JavaScript.
  3. Reduce coupling of modules (ie. rendering and scripting or physics and rendering). The ultimate version of this is is that no one system or component calls another engine module directly. We’ll see how successful we are in this.
  4. Keep a mind towards multi-threading. This is especially true for scripting where most of the game logic will happen, but also for systems (ie. instead of iterating over all component in one function, use a callback on each component that can be executed in parallel).

The Basics

The engine is 3D and uses OpenGL 3+ (nothing from OpenGL 4, but 3.1 – 3.3); however, the graphics library is built in such a way as to be extendible so you could use DirectX 11. It is cross-platform and will be tested on macOS and Windows. It should also compile on Linux, though I haven’t taken the time to try that myself yet. Most of my background before putting this all together is in graphics. That will be evident when we build an entire graphics framework from the ground up, but use middleware for almost everything else.

The engine uses JavaScript as a scripting language. I wanted something OO (which Lua does not provide naturally) and was more familiar with JS than C# (that said, I have looked at integrating Mono several times to add C# support and will make notes in the scripting engine documents on how it could be ported to another framework). This is accomplished through Google’s V8 engine, which was the most performant JS engine at the time I started implementing.

While the engine itself (without the editor) ranges from 20k – 30k lines of code, it is built on backs of giants – in this case, on top of many other third party libraries (as you’ll see below).

How is it built?

The engine uses a number of pieces of middleware, listed below (alphabetically):

  • Assimp – Model loading (editor) and conversion to our own format
  • Bullet – Physics
  • FMOD – Audio
  • FreeType – Font rendering
  • GLew – OpenGL extension handling
  • GLFW – Cross-platform windowing
  • GLM – Vector and quaternion math.
  • cURL – HTTP(S) requests
  • MySQL – Remote database storage
  • OpenSSL – Encryption (both in cURL and our own networking)
  • Qt – Editor UI
  • Recast/Detour – Pathfinding
  • SOIL – Texture loading
  • SQLite – Local database storage
  • V8 – Google’s JavaScript engine, for scripting

What is included?

I’ve been working on this engine in various forms for over 10 years, but it’s just me. It is far from perfect. There are sections that are not as optimized as they could be, not as clever as the could be, and certainly not as modern as they could be. The point of this site is not to help you build the next Unreal engine; it is meant to bridge the gap between all of the individual tutorials and articles and showing how it all works together.

As mentioned above, we will go in-depth into real world game components: real-time server-authoritative networking, frustum and tree culling, scene graphs, lighting and shadows, custom 3D file formats, bone and mesh animation, building an editor, and integrating scripting with examples and documentation. All of these together will form our engine, so they will also all work together.

Where possible, I do my best to modularize components (ECS, rendering engine, scripting language, etc.) so that they could be easily replaced in the future. However, I’m sure you’ll find several instances in this code base and others where it was “good enough”. At the end of the day, the goal was to “finish” this site and make sure I covered as much ground as possible.

What is not included?

Of course, we cannot be all things to all people. First, the engine uses C++, so you should know how to read and write code. It uses bits and pieces from C++98 all the way through C++11, although the newer stuff is more out of convenience than any sort of idealism. Knowledge of C++ itself isn’t strictly required, but will definitely help.

Second, this is not a tutorial on OpenGL. I will explain how and why I use most OpenGL functions, but before starting you should be familiar with DirectX or OpenGL. If you are not, you should read the Getting Started and Lighting sections of Joey de Vries’ excellent learnopengl.com.

Third, while documentation is good, for third party libraries Stack Overflow is almost always more useful once you’re past “Hello World” and into Hello Real World. Get your Googling fingers ready and be prepared to start searching for answers to all of the Weird Stuff you’ll find as you build your own tools.


I’ve laid the site out into sections representing modules of the engine (base, rendering, scripting, pathfinding, etc.), so that you can either start at the beginning and follow along, or jump to specific sections you’re interested in (rendering, scripting, etc.). Either way, I recommend you read or review the Base classes, as they will be used throughout the site and are the mostly likely classes you would re-write yourself or use drop-in replacements for.

Leave a Reply

Your email address will not be published. Required fields are marked *