Over the past weekend, I released the beta of BOUNCE iT, the first game I develop. The game started with a series of prototypes that I discussed in my last post. Once I was happy with the prototypes, I started actually working on the engine and building the game itself.
In this series of blog posts, I will discuss some of the work I did to go from these prototypes to releasing the beta version. In the first post, I will discuss how I approached building the game engine.
Game-or-engine dilemma
When developers start building game engines, they tend to follow one of two approaches. Some developers prefer to start building full-fledged engines that work in a similar way to the well-known “general-purpose” engines such as Unreal, Unity, Godot, etc.
I am using the term “general-purpose” here with a bit of caution, as, out of the box, most of these engines tend to be more suitable for specific types of projects, even if they can be used for others.
In this approach, the developer spends a good chunk of their development time building and structuring an engine that could support a wide variety of future projects, before they get to writing the game code.
The benefit of this approach is that it gives the developer a good foundation for future game projects. It also opens the chance to release that engine as its own product.
However, it has its downsides. A generic game engine that supports a variety of projects is a complicated beast. A developer embarking on a project like that would have to dedicate serious time to building it. They would also have to make a lot of complex decisions on how to structure the code to make sure it is usable and efficient for a variety of projects.
For this reason, I find this approach to be more suitable for experienced developers rather than beginners. This experience would enable them to build the engine faster and more efficiently. It would also protect them from the decision paralysis that could plague a beginner embarking on such a project.
Writing a game, not an engine
Since this is my first ever game, I didn’t think that the first approach is ideal for me. I didn’t think that I have the required experience for this approach. I also wasn’t interested in eventually releasing my “engine” as a product that can be used by others. Therefore, I chose an approach inspired by this article and this video.
In summary, these two resources advocate focusing on building and releasing games rather than engines, especially for beginners. This way, a developer won’t waste time into writing an engine that might become obsolete by the time they finish their game. In fact, an inexperienced developer may even end up with an engine that isn’t very suitable for the game they are trying to build.
Building on these ideas, I decided that I won’t spend too much time trying to build “reusable” components. The only “reusable” components in the codebase of my game are the components that I felt, during the prototyping phase, would probably be common to any game I might develop. These include the Window and Renderer objects and the data structures that manage the objects and assets of the game. In fact, even these components aren’t fully generic as I would most likely heavily tweak them for future projects.
On the other hand, I have components like a collision system and an event system that only work with this game. Many developers would argue that these components should be generic, and they can be of course. However, I decided that it is not worth spending the time building them in that way. It was a lot more efficient for me to build them to only work for this game for now and then I can see if it makes sense to generalise them a bit more, so they are reusable for future projects.
In this sense, the “reusable” components of my code don’t even constitute what most people would call an engine. They are more like a starter project that I can reshape and tweak for future games depending on my needs.
This is probably enough for today. In the next post, I will go into more detail about various aspects of the code.
