Hullo friends, your friendly neighbourhood BALLS developer here, giving you a quick update which is hopefully less panicked than what I wrote previously.
So yeah, what’s been going down?
The Big Refactor
I’ve already learned a huge amount whilst attempting this solo-game-dev thing, largely because I’m doing everything for the first time.
My biggest code change was breaking down my application architecture into a more Humble Object pattern. This seems like a good fit for indie (or small) game development, particularly when working with an established game engine (in my case, Godot).
Why, tho? Well, because game development is complicated. Game engines do the best they can to provide as much necessary functionality as possible (which is awesome, thank you for that) - but you’re essentially building a complicated application on top of another complicated application (one that you didn’t write).
This means you have to trust that the engine (and its much-smarter-than-me) development teams are doing their part, and you have to make sure you’re structuring your own code in a sensible (and testable) way.
Essentially, you’ll want to keep your main Godot nodes (objects with Godot engine functionality baked in) as “humble” as possible, abstracting all your own logic away to pure objects (POCO - Plan Old CLR Objects in my case).
The reason is that these simpler classes are agnostic of whichever framework they might be used; they don’t need to care, and are therefore easier to reason about, and most importantly, unit-testable.
Anyway, I’ve gone from having a few scattered NUnit tests to having 800+.
That’s not to say unit tests will cover all potential problems (they absolutely won’t), but they do give a stronger foundation to build upon.
Localisation
Something I’ve never really had to consider before, coming from a web development (i.e. modern browsers) background, is localisation. Web browsers will know your preferred language and try to automatically translate web pages, whereas game engines won’t. They don’t know what audiences you’re catering for, so it’s up to you to do some grunt work.
Godot does provide some helpful features, like a language server that is built to take any translations you provide (usually via a .csv file) and automatically switch them out when identifying a matching key, but that still leaves you with creating the translations themselves.
Given I can’t afford a professional translator, I’ve had to do the best I can with Google Translate. I’m sure there will be some terrible translation gaffs, but hopefully they’ll be more humorous, rather than... infuriating.
One of the biggest benefits of this translation process has been that it’s made my UI more robust. Languages don’t tend to follow the same character count, so the same translation may be much longer or shorter depending on the chosen language.
This has meant tweaking/chopping/changing some of my UI to allow it to be more flexible and less prone to UI breakages and clipped text. Turns out even simple games tend to carry a lot of text, all of which needs translating.
Essentially, localisation for a tiny indie game might be overkill, but it’s been a worthwhile learning experience.
Shop/Store
Slightly more interesting - at least visually and gameplay-y - has been building out an in-game store/shop.
This isn’t a microtransaction trojan horse (because f*** that); instead, it's a way to reward successful gameplay. Skilful players can earn extra coins/gems when choosing their ball-rolling strategy, and successful, accurate rolls will earn more coins/gems.
These currencies can be redeemed in the shop/store to unlock Buff functionality (which are essentially tactical advantages during gameplay), or just interesting cosmetic upgrades, i.e. more interesting ball-skins (is there a better way to describe that?) or ball trails.
Hopefully, it’s a way to keep the gameplay interesting, and if I get brave enough to attempt online play, each player can show off their own styles.
Anyway, I’m going to go eat.
Until next time!