On Modularity in Game Development
It’s been a bit of a soul-searching year for me, I’ve intentionally tried new things out and one of the topics that stuck with me the longest was game development.
One of the hardest problems I face every time I try to learn new technologies is the feeling of being lost. Learning without the guidance of a teacher or some kind of tutor can be quite disorientating and game dev isn’t the exception. In this particular case I feel like every tutorial series about creating a particular style of game doesn’t really translate well to the following ones, leaving me wondering if I’m wasting my time or I’m learning something.
Enter modularity!
In my perpetual search for useful guides, tutorials or really anything that I could use to improve my Godot 4 skills I’ve stumbled upon this video. I invite you to have a look at it considering it’s around 10 minutes long but the point it tries to make is that you can design pieces of your games in such a way that you could almost copy paste it in following projects. It almost felt like dreaming: I could finally bring the good pieces of a game I created by loosely following a tutorial onto the next project without having to create it from scratch again!
A few other nice things about this paradigm:
- "Code recycling" between different parts of the game
- Much easier to stay organized
- Customizing certain parts of the game isn’t as tedious
- Somewhat easier to debug
Ok but how does it work, really?
The gist of it is: everything that relates to a certain system must be in the same folder and every part of that system will be in a subfolder containing everything is needed for that specific part to work. By avoiding external dependencies as much as possible you will have a modular system that can be reused across projects! The video example is an 'ability' system but I’ve applied this principle to almost anything you can think of: ui & themes, inventory, weapon & armor, enemies and so on. In Godot 4 this almost always translates to having 2 to 4 files in each subfolder: the scene & its attached script, an image file for the sprite if it’s needed and a possible custom resource.
Recycling code
Coming from a more traditional engineering perspective, not being able to reuse any of the code I’ve written in previous projects always bothered me. It felt like having to write code without using libraries! Imagine not using requests in your python ETL/ELT pipelines or not using seaborn/plotly when trying to visualize data, madness!
Modularity solves this problem by forcing you to create self-contained pieces of logic that will be reusable across projects, kind of like generic functions.
Staying organized
The nice thing about modularity is that it’s heavily related to the file organization in memory. This means that you’re somewhat forced to use the same logic as libraries in traditional software engineering. As an example, in my current project, any 'ability' could be accessed in the root.abilities.ability_name module if it was in a python library.
One of the possible objections is that by using this structure there’s the possibility of creating too many first level folders. That’s valid criticism but the alternative is to have a lot of nested folders and that’s much worse in my opinion!
That’s all!
Some final notes: in general I’m not someone who follows engineering methodologies religiously. I consider flexibility and using the right tool for the job two of the most important skills an engineer can have, so I won’t be using modularity as if it’s the only way of designing games. Of course it isn’t! It’s been working great so far, especially for game-wide systems, those are generally composed of many different pieces that can really be thought of as somewhat independent. It’s been working less effectively for pieces of my game that have many dependencies like the player for instance.
So as always: take the good and apply it when you can but don’t abuse it otherwise the trade-offs won’t be worth it!