A Game - From the Ground Up
When is the last time you’ve written a project from the ground up? Every single day as programmers, we write products on already established libraries - as is sane discourse. But what happens... when we don’t - when we say, “I’m going to use the bare minimum - and write everything else myself.” I would say we learn (a lot).
I inadvertently started this project through beginning my own game framework, named clibgame. I had been writing a couple of games and I found myself writing the exact same code over and over again. I decided to instead write it once in a general format and call it a library of its own. From that point it naturally evolved into more and more of a game engine. In its current state (at time of writing), one inherits from a pre-built Entity Component System (ECP), they define behaviors through implementing their own components, and they attach them to different unique IDs within the ECP. The engine as a whole has only 4 dependencies: GLEW, GLFW, Freetype, and libpng. As it stands, all of those links are obviously libraries - as opposed to frameworks or engines of their own. They don’t provide a helping hand outside of abstracting away a little bit of nitty-gritty file parsing and kernel-or-graphics-drivers level API calls.
I learned a lot predominantly in 3 areas:
OpenGL - Of course and OpenGL-based game library is going to include something of writing code aimed at the OpenGL API. Though I had a notable amount of work in OpenGL before (through different languages and projects), writing a library is remarkably different. When writing a library your product isn’t only an application that runs well enough - it’s a library that runs optimally. I’m not going to claim that clibgame is at that state yet, but even those thoughts are enough to learn more about your theoretical limitations.
Managing a C++ Project - Prior to this project I hadn’t worked on anything of this scale in C++. I’m not trying to imply that this project is by any means large, only that it is larger than other ones I’ve undertaken. C++ is the kind of languages that has tens of ways to perform a single task - with only one or two of them being valid, idiomatic solutions. Obviously the larger a project becomes, the easier it is to slip into poor coding habits, making the code less and less maintainable. I think working on a slightly larger project taught me about managing some amount of a standard for code quality as a project grows.
Developing a C++ Library - This one is much like the former - only it applies more specifically to creating a library with C++. Much of this particular area is dedicated especially to managing code in such a way that it can be deployed easily. Throughout this process I’ve been attempting to keep the installation process simple (assuming you have all of the required libraries). As it stands there are no ‘gotchas’ regarding installation, it’s the normal process for a simple CMake project.
The next stepping stone on this journey was starting an actual videogame, jumponthings. As it stands, it’s very much so in-development. In its most recent version (at time of writing, yet again), you can run around on a piece of grass, and jump about. This project only has one dependency, clibgame. The idea behind creating this game is to only need that one dependency. If I need something that I feel ought to be in the library itself - I add it. That way future projects (both written by myself and others) will need not write the same code over again. The idea and the hope with this is that this project will urge clibgame to a place where it is a fully functional game engine. Though the goal of this project is to grow clibgame further, it has incidentally also led to some learning in and of itself.
It’s been an adventure learning to write code around a component & event based model. It is a paradigm where one does not have control over the data around it (an aside, this is not directly true in clibgame. One can go through the process of directly accessing and mutating the components of the current entity. It can also access - in a const fashion - the data of every component in the entity component system). It can only control its own data - all mutations to the world around it are handled through a global eventing system.
The next challenge in this project is more intelligent and resilient file parsing. I need this for a couple of things - namely asset parsing in clibgame and world parsing in jumponthings. In its current state it’s using a std::istream to try to match different values, but I’m looking to create more advanced parsing constructs - and as such I’ve just started parsical - a parser combinator library based off of Parsec, a Haskell library. There’s got to be a plethora of parsing libraries already made for C++, but in the spirit of this project, I want to create my own. This is just another avenue to learn about a specific piece of programming - this being parsing.
If you have the time to waste hours upon hours, I’d definitely suggest doing so with this kind of project. Pick whatever piece of programming interests you, and try to reimplement some library you depend on every day. See what you can learn!