Write Your Own Game Engine
Short list of resources and tutorials for writing your own game engine in OpenGl and C++
I recently shared my Toyrenderer which I have been using for learning graphic APIs and C++. This will be a short post, where I will go over which resources I used, for anyone who might be interested in doing the same.
Github Toyrenderer page: https://github.com/IRCSS/ToyRenderer
Motivation
Why would you want to make your own game engine? I think it is an important question, because knowing your goals decide what you want to write yourself, and for what you will use libraries others wrote. Decide that for yourself before you start.
Making an engine takes a long time, you will learn a great amount from doing it, but depending on your goals, this time might have been better spend learning other things. What I can say for sure, is that if you would like to work as an engine programmer, or a graphic programmer, then learning these things is a must (at least the API stuff for a graphic programming). For others, it is still a very valuable learning exprience, you just have to weight it in versus other stuff you could be learning.
As for using your engine for actual production, it all depends on how much time you want to spend on it, and the scope of your project. Once you start writing your own engine, you will realize how much energy and time has gone in professional engines like Unity/ Unreal to support all these different formats, workflows, short cuts etc. If your goal is to make a good game, my suggestion would be to use those professional engines already out there. Less time spend remaking the wheel, and more time polishing your game.
Which Language?
I used C++ for mine. I have seen people using other languages as well. So why C++? My decision was based on the numerous amount of libraries C++ already has for most your needs. From supporting different formats to optimizing your meshes, there are some amazing libraries in the open source community. Plus C++ is nice for performance intensive codes and at the very least at the moment is an industry standard for game engines.
Which API?
I remember watching a GDC talk about Vulkan. The speaker said in the panel afterwards that students should be learning Vulkan, because that is the only hiring position they have. As I wanted to start writing my renderer, I did wonder, if I should do it in Vulkan or Directx 13. However asking for advice from some helpful senior graphic programmers, I realized that is not the best course of action. If you are writing your engine for the first time, or writing API code for the first time, you will have enough to learn. Start with OpenGL. It is easier to start off in it and has a lot of resources and tutorials. Once you have your basic engine loop in place, you can always go back, and build an rendering interface abstraction layer, which lets you create a context for any graphic API.
Resources
I will split it up in different sections. First let’s start off with C++. If you are not fit in C++, I highly recommend going through the C++ series by the Cherno, as of writing of this, there are 84 videos covering most C++ basics:
I learned C++ with his videos, he goes quite in depth for simple topics.
Next is learning the basics of the API. There are tons of books on this. I looked in to two of them, which I didn’t find all that useful. They covered the usage of the opengl specification, but didn’t say anything about how to use these in the real world, in actual game engine with production needs. There are a lot of tutorials for OpenGl. Some are out dated, and not all that relevant to what I wanted to learn.
Again Cherno came to the rescue, he has a second and a third series on Open Gl and Game engine. I didn’t look through the Game engine part all that much, because I wanted to design my own, but the open gl part was very helpful.
Next in the list are libraries. The libraries I have used so far are GLEW and GLFW for handling Open GL function calls, window creation and getting raw input from the window. ImGui for UI and Tiny Obj Loader for loading in obj mesh files. You would need to write an interface around whatever library you are using, to make it easier to switch the underlying mechanisim later, in case you decide to implement any of these yourself, or use a different library later. An example of this in my code base is the InputMaster. The rest of the code base only interacts with the Input master class to get its needed input. So I can easily switch the underlying input handling anytime.
The above will get you the bare minimum of a renderer running. The leap to a more advance engine environment is a hard one if you don’t know what you are suppose to implement and which problems a game implemented in your engine might have.
One way of solving this is to obviously making a game. For example I decided to make a demo, where I fly around in a photogrammetry scene with a transparent grid on the ground and a skybox around. This lead me to the realization that I need a proper camera setup with different rendering passes such as skybox, opaque and transparent. The need to control the camera lead me to write an InputMaster class. Like this you slowly develop bit by bit the things you need for your engine.
A short cut to the method stated above is to take a professional engine as a reference. If you have worked in Unity or Unreal before, you would already know all the features they offer you as a game developer. As you are planning your classes, you can compare it to theirs to see what methods you need to support. For example as I was writing my math classes for Vector and Matrix4x4, I referred to the Unity documentation alot to make sure I am not missing out on a utility function. This sped up the workflow later, because all functions I ended up needing, I had already implemented.
I learn alot from Unreal source code on daily basis. A very helpful page to read through is the graphic programming of the Unreal Engine. Specially helpful are the Graphic programming overview, threaded rendering and parallel rendering pages. Reading through these can give you a rough idea of the type of features your engine would need to support for optimal, AAA level performance.
The Cherno tutorials are great, but I have a feeling he doesn’t explain the camera/ perspective stuff so good. It feels like his mastery of the general graphic programming areas are not as solid as the engine development. To fill in that gap, I recommend Scratch Pixel. I has a very detailed explanation for the building of the projection matrix and matrices in general. Great blog.
If you read through the Unreal page I linked, or know the Unity Graphic pipeline really well, you will hear alot about frustum culling, pipelined main/ render thread, occlusion culling etc. But how do you implement those? Although you can simply google the name of the techniques if you already know them and find blogs written about them, for people who are just getting in to the topic, the main challenge is first to find out what to google. I have hardly ever seen a better resource than Real Time Rendering. The chapters 18 and 19 for example cover the stuff mentioned above, and in earlier chapters there are indepth methods for creating different bounding boxes and testing the camera frustum against these bounding boxes. A great resource overall.
Two last resources which I have still not read, but people keep saying are very helpful are the Graphic codex and the Fundation of Game Engine Development (part one and two). I can’t comment on them since I have yet to read them, but they seem to be helpful as reference for writing your own pbr shaders or implementing specific graphic technique.
That’s all, hope you have fun writing your engine, I had tons making mine.