How long does it take to develop a game engine?

I've been getting several emails in the last couple of months from indie developers and college students interested in developing a game engine. The bulk of these emails revolves around the question: "How long does it take to develop a game engine"?

I don't know how long it will take you, but I can tell you how long it took me to go from a blank file to this:

In the beginning

When I decided to develop a 3D game engine, I knew next to nothing about C++, Design Patterns, and algorithms. I knew C programming, but I didn't feel comfortable since most of what I knew about programming was self-taught. My bachelor was in Bio-Engineering, not Computer Science. Thus, you can safely assume that my programming skills were borderline basic.

I also knew nothing about OpenGL, Shaders and Computer Graphics.

Developing a game engine required that I mastered all these concepts: C++, Design Patterns, OpenGL, Computer Graphics and Linear Algebra. So, for the first seven to eight months (Feb 2013-Aug-2013), I decided to dwell deep into these concepts. I read a lot. I spent my hours before heading to work, after work and weekends, just studying, reading and learning as much as I could.

My first attempt

It was around Aug-2013 that I started coding the game engine. Around this time I was not wholly knowledgeable about C++, OpenGL nor Linear Algebra but I decided to start coding the engine nonetheless. Unfortunately, the engine's architecture was a total mess, and by Nov 2013, I had to start all over again.

It was not until a year later (Feb-2014) that I succeeded in rendering the first 3D character on the screen.

A lot of work with nothing to show

The year 2014 was depressing. I was spending all of my free time working on the engine. I kept reading and reading about OpenGL and Computer Graphics. However, most of what I implemented would fail. I must say that it was also a year I learned a lot.

From Feb 2014 to May 2014, I worked on the Rendering Engine and added support for 3D model rendering, textures, normal maps, and multi-image. From May 2014 to July 2014, I implemented a crude Digital Asset Imported. That is, I was able to export a 3D model from "Blender" and import it into the engine.

The rest of 2014 was spent on implementing a scenegraph, fine-tuning the Digital Asset Imported, adding support for 3D animations, and learning how to use Blender 3D.

Testing a walking animation in the engine. 

You may not know this yet, but you will need to wear your artistic hat if you want to develop a game engine. It is crucial that you learn how to model 3D characters using tools such as Blender and the workflow used by 3D artists. If you do not take time to learn this, you will not be able to import the correct data into the engine from Blender.

Finally, something to show

It was not until April 2015 that the Rendering Engine showed signs that it was working. On April, I was able to complete Beta version v0.0.1 of the engine.

Version v0.0.1 The game engine is capable of rendering 3D models with textures/normal maps, animation, skyboxes, fonts, sprites and contains a digital asset importer.

The engine had support for 3D models, normal maps, buttons, joystick, shadows and 3D animations. However, most of what I had implemented was crude. Remember, I was learning and failing hard along the way.

The complicated part of an engine

On April 2015, I started working on the Physics Engine. The physics engine, along with the Collision Detection System, is the hardest part of a game engine. Trust me.

The year 2015, was also the year when my temptations to quit development was the strongest. I can't even explain how terrible it is to work on a Collision Detection System. I would work until 2 am almost every day, and every time, that damn Collision System would fail. It was not until October that I finally was able to get the engine to detect collision among convex objects. However, there was a problem with collision tunneling. Essentially, colliding objects would penetrate each other. Unbeknown to me, it was going to take me over a year and three months to get the collision system working.

I Finally Did it

It was not until July 21, 2016, around 2 am, that I succeeded in developing the basic framework of the game engine. Trust me, when I saw the engine working, I screamed, I jumped, and I started dancing Salsa (I'm Latino. Salsa music is in my blood).

It took me a little bit more than three years to develop the basic structure of the game engine. And I have to emphasize the word "basic.". The engine had a basic structure, but it was not ready for prime-time. There was a lot more work to do.

The First Demo

I knew the engine needed a lot more functionality. However, I couldn't wait to develop a simple demo. So, a month later, I developed the demo shown below:

Development started to pick up

After the first demo, development started to go by faster. By October 2016, I had improved the collision detection and fixed issues with 3D animations.

In this beta version v0.0.3 of the engine, animations and collision detection can work simultaneously. The BHV algorithm was improved helping the engine make better decisions when pairing up 3D models for collision detection. The MVC (Model-View-Controller) flow of information was also improved.

By Dec 2016, I developed the second demo which focused on showing the collision-detection features of the engine:

By Jan 2017 I implemented a very primitive particle system. The particle system was so rudimentary that I completely rewrote it later on.

In this beta version v0.0.4, I implemented a primitive particle system, thus allowing explosion effects to occur once a missile hits the asteroid. I also enabled multi-touch, this allows the spaceship to turn as it speeds up. I also set up collision filters among object types. For example, object A and object B can collide; object A and object C can collide, but any collision among object B and Object C is ignored.

A huge learning moment

From Jan 2017 to Jun 2017, I wasted my time developing a soccer game. The idea was to create a soccer game so that I could improve the engine. However, I soon found myself spending more time coding the gameplay, rather than spending time fixing other issues in the engine.

And this was a huge learning moment for me. I realized that I should not waste my time coding a gameplay. And more importantly, that each game I develop, must serve a purpose towards the improvement/testing of the engine.

Porting to Metal

By Sept 2017, the game engine got a total makeover. From Jun 2017 to Sept 2017, I worked on porting the engine from OpenGL ES to Metal, Apple's Graphics API. The porting was not hard at all; I have to say that Metal is a lot nicer and cleaner to work with than OpenGL. I was surprised that I ported the engine in less than four months.

This video shows the game engine using the Metal API for its rendering operations. The game engine no longer uses OpenGL.

Since I already had the soccer game demo, I used the same game (with different 3D models) to test the engine with Metal.

Why render what you can't see

By Oct 2017, I worked on a feature that I should have worked on years ago. For most of the development, I had put Frustum Culling aside. The idea of Frustum Culling is that there is no point for the engine to render entities that the camera can't see. Implementing this feature improved the engine's FPS (frames-Per-Second).

Improved the rendering efficiency of the game engine by implemented Frustum Culling + BVH tree algorithm.

A true Particle System

Earlier, I had mentioned that I developed a primitive particle system. Well, by the end of Oct 2017, the time had come for me to implement a real particle system. I had fun working on this feature.

Added particle system to the engine. The engine can generate smoke, explosions and other particle types.

Memory Leakage is not acceptable

And finally, by Nov 2017, I fixed several memory-leakages in the engine and a rendering ordering issue with the engine.

In version v0.0.8 of the game engine I fixed some memory leakage issues and improved the rendering-ordering algorithm.

In Conclusion

I've been working on my game engine for more than four years now. It took three years to develop a basic framework. And an additional year to improve the engine. And I'm still not done with the engine.

I hope that this post can give you a sense of what awaits you if you decide to develop your game engine.

Thanks for reading.

Game Engine v0.0.8

Is hard to believe but the game engine is getting better and better as time passes. This month I focused on fixing two significant issues related to memory and rendering.

Here is a demo of v0.0.8 of the game engine:

In version v0.0.8 of the game engine I fixed some memory leakage issues and improved the rendering-ordering algorithm.

Substantial memory leaks were happening all over the engine. The leakage was something I could no longer ignore, so this month I focused on fixing this issue. I used Xcode's Instrument app to help me locate the memory leakage throughout the engine. I'm now happy to say that the engine is 99% leakage free. There is a small leakage that is happening when using the Collision Detection System. Unfortunately, I caught the leakage after I created the video demo for v0.0.8. The good thing is that is small, and I will fix it in v.0.09.

I also added Ordering functionality in the scenegraph. As you may know, entities such as text, skyboxes, and images, must be rendered last due to Blending requirements. Unfortunately, it meant that I had to add these objects into the scenegraph in a particular order. Naturally, such restriction is not acceptable. So, I added functionality into the scenegraph that orders these entities depending on their Z-Depth value.

I also found another issue related to Shadows. I noticed that the Shadows in the game engine have aliasing problems. I will fix this issue in v0.0.9.

Thanks for reading.

Game Engine Beta v0.0.7

I believe the engine is almost complete. Most of the functionalities expected in a game engine have been implemented. For example, the engine is capable of:

• Rendering 3D models with textures/normal maps
• Supports Shadows
• Supports 3D model animations
• Supports Skyboxes, Text, and Sprites rendering.
• The engine contains a Physics engine with a Collision Detection System
• It makes use of BVH algorithm in its Frustum Culling algorithm
• among many other minor implementations

However, it lacked one crucial element found in every game engine, i.e., a Particle System.

Back in beta v0.0.4 of the engine, I did implement a particle system. However, it was rudimentary and basic. I wouldn't consider it a particle system, per se.

So this month I decided to scrap the original Particle System I had written back in v0.0.4 and focused on implementing a real Particle System.

Implementing a particle system is quite simple. I will write an article how to implement a Particle System soon, but if you are dying to know how to write one, this site has an excellent post on it. After reading this article and other books, it gave me a good idea how to implement a Particle System.

Well, here is a video showing the Particle System currently employed in my game engine.

Added particle system to the engine. The engine can generate smoke, explosions and other particle types.

What I need to do soon, is to write a Particle System editor similar to 71 Square Particle System, but for 3D particles.

That way, YOU, can easily import your particle effects into the engine.

Thanks for reading.

Game Engine Beta v0.0.6

Hi there,

These past two weeks I've been working on implementing a Frustum Culling algorithm for the engine. Here is a video of beta v0.0.6 of the engine with Frustum Culling.

In the previous beta version of the game engine, I had 20 soccer players on the screen. And I noticed that the game was a bit choppy. I recall the Frames-Per-Second (fps) being below 30. The engine was rendering all 20 players, the two goals, and soccer field at every frame without analyzing if the camera was able to see these models or not. You can agree that this is a problem.

The logic behind a Frustum Culling algorithm is essentially this:

"If the camera does not see the 3D model, then the engine should not render it".

Implementing this logic, allows you to have 100 models in a game, but only 10 or so many models being rendered at any time. Thus, improving the game experience.

For example, the minimum acceptable fps in a game is 30 fps. With Frustum Culling, the engine was able to render the entities at 60 fps and the lowest it got was 49 fps.

If you are entirely new to Frustum Culling, keep reading. I'm going to give you a brief tutorial on how Frustum Culling works.

What is a Frustum

A game engine requires a camera. During initialization of a game, the engine computes a Frustum. A frustum is a chopped pyramid. And 3D models within the frustum are visible by the camera and by YOU.

Notice how the frustum is composed of six planes.

What is Frustum Culling

A Frustum Culling Algorithm tests which 3D models lie within the frustum. If the 3D model lies outside the frustum, then it is ignored by the rendering engine. If the 3D model lies within the frustum, then it is rendered.

Frustum Culling Test

Testing if a 3D model lies within a frustum is quite simple. First, the 3D model is wrapped within a box, in this case, with an AABB (Axis-Aligned Boundary Box).

Then, the eight vertices of the AABB are tested against a plane. In a Frustum Culling algorithm, the AABB's vertices are tested against all six frustum's planes.

If all vertices lie on the negative side of the plane, then the model is considered being outside the frustum. Otherwise, it lies within the frustum.

And that is it. You repeat the process for all game entities in your game.

Improving the Frustum Culling Algorithm

Frustum Culling improves the efficiency of a game engine, but it is not enough. If your game only has ten 3D models, the engine can quickly do a Frustum Culling on all these entities. However, if your game has 200 or 1000 objects, then Frustum Culling by itself may not improve the efficiency of the engine.

What you need is an algorithm that can analyze the spatial area seen by the camera. For example, if the camera does not see the upper-left quadrant, then the engine should not perform Frustum Culling on the entities that lie on this quadrant. There are many algorithms that you can use. In the engine, I implemented a Boundary Volume Hierarchy (BVH) tree.

The image below shows the idea. I recursively wrapped the game entities in an AABB, until there is only one model per AABB. Then, starting from the root node, the engine test if the camera sees the AABB node or not. If the camera does not see the AABB node, then all the children node, containing the 3D models, are not rendered.

If the camera does see the AABB node, then it keeps performing Frustum Culling on the next AABB child node, until it reaches the leaf node.

In the example shown above, the algorithm rejects the red AABB box and does not need to test if the red and gray car is seen by the camera.

The camera does see the blue AABB box. Thus it tests the children nodes of the blue AABB box. It does this on and on until it reaches the leaf nodes. In this case, it sees the blue and orange car, but not the yellow car.

And that is Frustum Culling. I hope you learned something.

Thanks for reading.

Game Engine Beta v0.0.5

In version v0.0.5, I ported the game engine from OpenGL to Apple's Metal API.

Initially, I planned to keep working on the 3D soccer game using v0.0.4 of the engine. However, I decided to port the engine once I saw an Augmented Reality demo. I realized that Augmented Reality (AR) is the future of gaming and it may be a good idea to have this feature available in the engine. However, the AR framework only works with the Metal API; it does not support OpenGL.

To be honest, my goal was to port the engine to Metal in a year or two. I was not planning to port it so soon. Part of it was that I feel I'm still learning Game Engine development and didn't want to overwhelm myself. The other reason was that porting a Game Engine from one API to another is not an easy task. When I saw the AR demo, it was the push that I needed.

To my surprise, porting the engine to Metal was quite simple. In less than two weeks I had ported the major components of the rendering engine. I also became aware of some misconceptions I had with computer graphics and OpenGL; essentially with Normal Maps and Shadows. Metal is so simple to use that it highlighted some errors I was making with OpenGL.

Overall, I would say that the porting took about a month to complete. It does not include the time it took to learn Metal, which it should take you about a week; assuming you know computer graphics.

Here is a video showcasing the 3D soccer game with Metal. In my opinion, it looks better than when I was using OpenGL, but then again I am using better 3D models.

This video shows the game engine using the Metal API for its rendering operations. The game engine no longer uses OpenGL.

So, the engine now runs entirely on Metal.

Goodbye OpenGL

Hola, Metal

Thanks for reading.