The first main task of the day was to test that everything I'd written yesterday worked the way I expected. Of course it didn't but that's what testing is for after all.
The main gist of everything was working as expected, except that I'd forgotten to add localisation text for a lot of what I'd coded in, so all the game text just referenced my variable names. Embarrassing, but a very easy fix.
What I really got from my tests, though, was a feel for the edge cases that I hadn't been considering, or that I knew I'd need to come back to later.
Dealing with edge cases
The first edge case was non-standard empires. My code was written on the presumption that all empires in Stellaris are created equally (i.e. all go through the same setup method) but of course, that's not true at all. Some empires skip over the rules that I'd implemented, so I needed to find out where they were created, and alter their rules separately.
The second edge case, and the one that has had me pulling my hair out all morning, was the secondary species that might exist for an empire. Although the main species is very easy to scope to, because it's a vital part of an empire, the secondary sort of floats around in the background and doesn't fully exist until the game starts (by which time I'd hope to have already altered it).
I haven't actually solved this problem fully, but put together a clunky solution that works on first glance. That means more testing required. The sort of ethereal quality of secondary objects that don't fully exist until they're created (and thus can't be altered until they exist) may be more than my limited skills/tools can handle, but it's not going to stop me from trying.
DRY coding
The other use of my time today has been figuring out how to code DRY for Paradox modding purposes. Since most of what I'm doing is the same code in different places, I figured there must be a way of shortcutting it all.
Without fully understanding how the code was compiled or read, I hadn't realised that a lot of the code I was reading was already a good example of how to code DRY, but once I did, everything clicked into place, and now I can just re-use the same bits of code again and again, which will save me some headaches in future.
Scope
Of course, the core thing to watch out for here is scope: I need to always be making sure that whatever I'm writing is looking at the right objects, otherwise it's just not going to work. This has already caused a few issues for me, where seemingly functional code hasn't been working because it's been looking at a planet instead of a species. When trying to use DRY code it's going to be even more important to know where my code is being called and what it's expecting to see there.
Overall I'm enjoying a very different way of coding at the moment, and it's good experience for OOP which is likely something I'll end up doing a lot more of if I get my way.
Tomorrow is further testing, perhaps more rigorously than today, and perhaps learning to use some more useful console commands. But we'll see what problems the testing dredges up for me to solve, first.
Top comments (0)