Refactoring the Engine
It’s been a while. Things are dusty, and I have learned so much since I started the engine back in 2019.
Personal Goals in Creating an Engine
As I mentioned in my previous post, I’m jumping back into my game engine after nearly a year-long hiatus. In the time I’ve been away, I have still been writing C++ professionally, learning, and thinking about what I want to do with the game engine, and what I want to get out of it personally.
Broadly speaking, I have several goals in the creation of a game engine:
- Experiment with cutting edge C++ language features
- Experiment with design patterns and data structures that I otherwise wouldn’t have an reason to try
- Learn about the complex problems and solutions unique to game programming
- Learn graphics programming (eventually, going to start with simple sprite sheets)
- Make a game!
Pretty much anyone with an ounce of common sense would look at the above list and point out, “you know, if you’re goal is to actually make a game, then you should probably just use and existing engine,” and to be fair, that’s a good point. To me, though, creating the engine that runs the game isn’t a necessary prerequisite, it’s an opportunity to learn and grow as a software developer that I am choosing to undertake.
Technical Goals of a Refactor
I started working on the game engine back in 2019, when I was just a year and a half out of school. Suffice to say I have learned an incredible amount since then. As I look over many of the systems I built, I am proud of what I was able to accomplish, but I also see that some of them are misguided, and others are plain bad. I want to take a bit of time before I continue building out features to address some of the less than ideal systems. While I’m at it, I want to try out a few new language features and reorganize my libraries/repo structure to be more organized.
The goals for the refactor are:
- Utilize C++ Modules to improve compile times, increase modularity, and learn about this new language feature
- Allocate less in various systems at run-time
- Avoid dynamic dispatch in the hot path (no virtual method call for update/draw)
- Structure Entity Component stores in a more cache friendly way
- Rework initialization logic to allow renderer/window to be destroyed and recreated at run-time (useful for modifying graphics settings)
- Rework render system to buffer all draw calls and reorder them according to depth and break into batches to reuse assets
It’s a lot to take on, but I’m excited to get started and build something I’m proud of. I don’t want to over commit, but I suspect I’ll be writing a blog post for most of the above topics.