A slower week this time around, mostly serving as a follow up to the tasks of week’s past.
Updating Files
I don’t believe I ever went into detail about this, but a large part of being an efficient programmer is keeping up with all the changes to the game files. This is mostly done through SourceTree, a program that allows multiple programmers to download, edit, and upload versions of the game code, allowing for multiple people to work on different areas of the game. It’s not necessarily the most riveting part of the job, but it’s very important; falling behind on project versions can lead to your edits and changes being inapplicable to the game, after all.
For me, this job can sometimes be quite a hassle, especially with merging two project versions together. Because of my laptop’s struggle utilizing certain aspects of the project, I have to know which files to update and which files to keep the same. I usually enlist another set of more experienced eyes to help me out with this, as not to break the project or miss out on important changes.
Same Tune, Different Verse
The main part of my task this week was sort of a continuation of one of last week’s jobs. Once again, the quest HUD was appearing in a place it shouldn’t have been, this time being the pause menu. Because the circumstances were ever so slightly different, I had to workshop my solution several times before it worked.
At first, I simply tried to have the same kind of code I used for the main menu be triggered by the pause menu button press. For some reason, however, this led to the code to be triggered twice, effectively locking the HUD to either an active or inactive state. It took ages to find the source of the problem, due to the fact that the code was apparently only being read once, despite the fact it triggered twice. The issue was eventually discovered to originate from the nature of the activating boolean statements, which didn’t work in the way I thought they did; turning them on was more like activating a state change than actually switching between states, if that makes any sense.
The next issue wasn’t nearly as troublesome to solve once some thorough pondering. The button trigger was not activating when the pause menu was open. At first, it bewildered me, but testing it showed that it worked when the pause menu was down. I was able to surmise that the script I put it in (the Player Input script, to be exact) probably gets deactivated when the pause menu is up, and therefore the issue could be solved by simply creating a new script. Lo and behold, the fix worked.
I think this task does a good job of showing how workshopping works in programming. Sometimes, its a wild goose chase that can lead you all over the place searching for a solution. Other times, a vital clue to the nature of the problem is handed to you on a silver platter. And though this inconsistency can occasionally be grating, the feeling of satisfaction you get from squashing a pesky bug is more than enough reward.
Next Week
I have been assigned to work with battle animations this week. I’ll be honest: this job seems like a toughie. Once again, I will be dealing with a new section of the game I have had little to no prior experience working with. But if I’ve been keeping up so far, I imagine I’ll be able to handle this just fine.
This Week’s Media: One Step From Eden Patch v1.7
One Step From Eden is an indie game released back in 2020 that has quickly risen to be one of my favorite games of all time. It’s a fast paced deck building rouge like with gameplay reminiscent of the Mega Man Battle Network games. Recently, a new update released that gave some some major overhauls to some of the sprites in the game. They used to be a little meh, admittedly, but these new sprites really showcase how good pixel art can be. In fact, it’s inspired me to dabble in some pixel art animations myself!