Hello everyone!
After all these years of learning to program and doing game development, I identified three ways or coding modes I usually do depending on the situation. These three ways aren’t exclusive to each other and all of them have their good and bad things in my opinion.
The way of haste
One of the things I am usually proud of is the speed I usually code. Furthermore, I enjoy trying to make things work as fast as possible mostly in game jams or making personal prototypes.
My main goal, when I code like this, is to have the most content working as fast as possible without thinking too much about performance or code sustainability. For example, I may abuse the Singleton pattern to make references between objects in the fastest way possible. I already wrote a blog post with some nasty tricks I usually do when coding like this. You can read it here: 4 Horsemen of the Game Jams.
A small detail about this one, I try to keep my code as clear and legible as possible. Although my main goal is the speed in the short term, I try to don’t abuse these because in the long term I don’t find viable this approach. It is also something dangerous to do if you are working with a team, unless everyone knows the general structure of it, it can become a peril for the team.
The way of endurance
I find it difficult a way to label this approach. The goal of this one is to follow clean code rules for legibility and think always in the long term. The code should be scalable. Following S.O.L.I.D principles and doing TDD should be the main focus.
At my current job, we are used and asked to follow all these practices to have products that will be able to last in case they succeed. Of course, this approach is not perfect, it takes a bit longer to create something from scrap, but on the other side, it becomes easier to make changes during late production and bugs are less frequent than using another approach.
In my projects, I had been using this approach but I try to avoid it during game jams where the development cycle is way too short against these other projects with big teams working on them for months.
The way of performance
In Asterash, Witchcraft, the experience of Firenze VR, and other projects, I had been in the need to focus on performance in some particular cases or even in the whole project.
Even once, working with Lua and Defold I needed to remove comments and shorten scripts because we were aiming to a really low file weight and sadly, even the comments were included by the compiler in the build.
When I work focusing here, I still care about legibility but speed is basically out of the table. I profile the game and search for each heavy process, from code to art, and try to lower its consumption as much as possible. This is not always possible but my goal here is always to make it at least a bit better than it was and always profile to see that the difference was there.
Wrapping up
There isn’t just a way to code or pay only attention to the way thing regardless of what you are doing. These three ways are just a fancy way to name in what at least I put most of my efforts. But take in mind, you can’t just work the whole project thinking about only one of them.
During game jams, if I just try to code as fast as possible I will lose a lot of performance or my code will become so illegible I won’t be able to finish the game during the last hours of the game jam without having a lot of troubles.
In my work, for example, we don’t put extreme effort into TDD if something is not going to be changed or is something hidden in the code for one case. Even there are different opinions on what should be tested and what shouldn’t.
In Firenze VR we didn’t focus on performance right at the beginning. We started focusing on it as soon as we have issues and we stopped focusing on it as soon as we had something working on.
The moral of the story is that basically everything depends on the context, it is a good thing to know what should be your main focus each time you start coding.
Thank you for reading!