In fall of 2019, I started to learn C++. How? Through a large project in a field I had no experience in. Needless to say, I was in over my head. I started by watching the Hazel Engine tutorial series made by TheCherno. It is actually a pretty great resource, but most of my code was a line by line copy of what he wrote. Even though I enjoyed following along with someone else, I eventually realized I needed to learn C++ if I wanted my game engine to be actually any good.
My first attempt at a game engine was named Timid. Most of these early engines are lost, but rest assured, it was a rebranding of Hazel Engine. I was so new to C++ that I couldn't figure out how to compile my code on macOS. Since I didn't have a Windows 10 PC, I installed a virtual machine on my laptop to use Visual Studio. I got about as far as opening a window using GLFW before I abandoned that project for my next project.
While there were many copies of Timid made, almost identical in the codebase, The next significant project I worked on was called Outlaw Engine. This project didn't make it as far, only successfully implementing a logging library, but it built using Xcode. This was actually a huge milestone because it meant I was beginning to understand the vast world of C++ and how it worked; I began to learn more about compilers and linkers and the general C++ ecosystem.
Next on the list is NeptuneGL and Neptune. The idea I had here was that I would create a library for platform specific API calls (NeptuneGL), and one for everything else (Neptune). Surpisingly, NeptuneGL is actually a rather nice repository. It was heavily based off of GLFW, but when I wrote the code I understood what I was doing. I also learned more about build systems and wrote a Makefile to compile the libary. Neptune is where this project falls apart. This project taught me why it's important to plan ahead when I work on a large project. I designed the system with the intentions to create an XNA/Monogame style framework but the API was clunky and not well though out. I still didn't have a great understanding of the features of a game engines at this point and my design reflected that.
The final failure is Apollo. I had accepted defeat and cloned Hazel Engine again, just trying to grasp the design techniques needed to build a game engine. I was still too lazy at this point to read a paper or learn about game engine architecture. I wasn't proud of it, and I didn't learn much, so it's another failure.
Papaya is my most recent attempt at a game engine and definitely the most thoroughly thought out. Rather than just blindly copying or writing sloppy code, I've spent time learning about the architecture of modern game engines. Papaya uses premake to build project files for Xcode, Visual Studio, and GNU Make. It uses native API calls through the OOP Factory (Interface) design pattern to handle platform-specific code. At the time of writing, I'm working on implementing a 2D Batch Renderer. I'm going to add more formal blog posts from time to time discussing important matters such as threading, rendering, an editor, and other issues I encounter.