Due to my position as a programmer, it was only a matter of time before I encountered the dreaded “blindly look for the bug” part of coding. This week was it!
The Job
The task was a fairly simple one, though it once again had me working with new tools. I was to make a quest early game for to player to defeat one buzzer through entertaining it. After a bit of snooping around in the project folders, I got a pretty good sense of how to approach it. I made the quest, set up the nodes for the pass/fail conditions, added counters to track the player’s actions, and set up some code to send out a message when the player successfully entertained an enemy. I finished the entire thing in good time, taking up only a little more than a day.
The Bug Hunt
When I test ran the program, I discovered a large problem in my quest: I couldn’t complete it. No matter how many enemies I defeated, I couldn’t get the success or fail conditions to activate. Naturally, the first thing I checked was my quest nodes and my counter incrementors. After thorough analysis from both me and my peers, it was deduced that there was nothing wrong with it. No typos, no syntax errors, not even a mismatched value type. As far as we could tell, nothing was wrong with my construction. I even reorganized the nodes in the ORK system event handler (the thing that tracked the player-enemy interactions) to make sure everything was hooked up correctly. Sure enough, it was.
From that point, it was a wild goose chase for the bug. We hopped over to the combat scene to check that the enemies weren’t missing any specialized code. Nothing amiss. We compared it to previously existing quests to see if I missed any steps. No difference. We added debug messages to make sure the code was actually playing at the right time. It was. As far as we could tell, it should’ve been running seamlessly, making the hunt for the bug even more frustrating.
The Breakthrough
After days of fruitless hunting, we finally found our mystery bug. Turns out that the event system simply wasn’t saving the message, resulting in it never being sent. I never though that this could be the issue, given that there was a node at the end of the event that DID EXACTLY THAT, but apparently there was a scene change or something before that node was activated, leading to the message being purged before it could be saved by the recording node. With this newfound information, extra recording nodes were added in, and it finally allowed the quest to be completed.
This whole experience has been my first real programming challenge, and it reminded me of what makes coding such a tough job. There’s never a clear-cut solution when things go wrong. You simply must investigate every possible nook and cranny for errors, hoping that you can find that random chunk of missing or broken code. There are certainly strategies to make things easier, such as making debug messages and double checking syntax, but there is no guarantee that the problem will be able to be detected through such methods. It’s a frustrating experience for sure, but at the same time it gives me much more pride in my pursuits as a programmer.
Next Week
There are still a few programming jobs to do, and since this quest debacle took up so much time, I’ve fallen behind on my personal art quota. This upcoming week, I plan to make up for lost time.
This Week’s Media: Cookie Run 5th Anniversary
Cookie Run is a mobile gacha game that is sort of a guilty pleasure of mine. I’ve been playing this game way back when I was still a kid, and I still enjoy it to this day. Simple gameplay, great character design, and free-to-play friendly… a perfect mobile distraction whenever I’m bored. Right now they’re celebrating their 5th anniversary, which means free rewards for everyone!