Weekly Wisby 12: It took me 3 years and an exchange to learn good code

API Design and Best Practices is the programming course I’ve always wanted and every darn programming course should be exactly like it from now on oh my god! Studying to be a game developer, most of your classes will be focused on “make the thing work”. And don’t get me wrong, ‘making the thing work’ is a great paradigm if your game consists of 5 scripts written for a 2-week project. API Design is the first programming course that asks me to “make the thing airtight and self-reliant” and I love everything about it.

In the past, I’ve fallen victim to the pitfall of writing unnecessary tools. My general rule of thumb nowadays is that they should only be created if they save time. After all, saving time is a tools primary purpose. Luckily, the Celestial Clock Tool has already paid back its time loss tenfold!



Quick recap from last week: the tool lets me change the time of day inside the scene view. With this, I can quickly iterator over our day-night cycles. Making sure that golden hour looks just right becomes a cinch! It also allowed me to easily spot bugs and annoyances of using 2 different skylights: Unity has a bit of trouble there.



The video shows how the sky jumps from one color to another when it decides to change what light is affecting it. We can sidestep this issue by waiting for the sun skybox to fade out before we have our night skybox fade in, so that’s what we’ve gotta do. That seems like an easy decision to make now, but think of how much longer we would have needed to prototype and debug stuff if we hadn’t used this easy little tool for it!

The same jumps happen with shadows and cloud lighting, bugs that I’m fixing as we speak. Without the proper tools, neither of these issues would have been easy to identify, let alone mend. This bit of tool work now is saving me a lot of development work I would have otherwise spent testing and crying.

For a few weeks I’ve been teasing that art posts will be coming soon, and it wouldn’t sit right with me if I didn’t address that these posts might happen at a slower pace than I may have led you on to believe.

The reason for this is that, whilst I was under the impression this would be left up to me, deciding what to show and what not to show is going to be an internal discussion. It’s better since this way we are all involved in the posting-process, but as we’re setting it up and finding our foundation things might be coming out slower than expected. All we have to show right now is a little atmospheric temp-picture of our desk.

See how the frost is creeping onto the window.

When asked what I do as a programmer, my response is that I break stuff until things work. And the description fits; if I want the player to jump, my first attempt will probably allow the player to jump on air (yes, this is actually a common issue).

Now imagine that that little jump issue is within a 500-line character movement script. Solving this issue gets a lot more complicated when it’s hidden in a haystack. And even once you’ve solved it, you may not realize what else it broke.

API Design and Best Practices addresses these kinds of issues, even though it’s about C++ instead of Unity. It’s about keeping your code manageable so you don’t hate yourself later, which slots right into my coding style. As with the Transparent Wall Effect I made (see week 9) the effect makes sure that it manages all its resources from creation until deletion. In laymen terms: if the effect needs junk to do its stuff, the effect cleans up that junk when it’s not doing its stuff. Rules like this are important: they ensure that if something breaks it’s not the fault of the Transparent Wall Effect. So there you go: one less script to debug, forever! You can see how, in a project with ten, one hundred or even one thousand scripts, that is a big plus.