Technical Architecture - Fixing Bugs without Coding

Hey Skaters! This is the fourth entry in our series of devlogs that take a deep dive into several aspects of Beat Skater’s development. In case you missed our last devlog, which gave a brief overview on how the Beat Skater art style was decided upon in addition to how it has evolved, that can be found here. For this devlog we’re bringing back the Programmer, Carter Costes, to discuss his process for debugging and how multi-role specialization creates more space for programmers to experiment, increasing the likelihood to push the design further. As a disclaimer beforehand, this discussion can get pretty technical with some specific terminology.

“Hey Skaters, my name is Carter Costes. I wear a lot of different metaphorical hats on the team but for this you can refer to me as the programmer. You might remember me from our previous technical devlog about some game programming quirks. I’m back here today to discuss some more of our technical and design architecture, specifically how I go about fixing bugs without always fixing bugs. 

Now, anyone who’s been anywhere around game development knows that bugs are as certain as the sun rises. High quality code and adherence to proper code standards can do a lot to ward away unnecessary bugs but with the technical gymnastics that games do to achieve all that they do, at some point bugs just become an inevitability. With that in mind, the techniques by which a game is debugged is guaranteed to have at least some effect on development.

"Bug fixing" can really be broken up into two categories. There’s finding the bugs (generally referred to as troubleshooting), and then there’s resolving the bugs (generally referred to as fixing), Getting started with troubleshooting, a plethora of options are available to developers and they’ll likely need to use most of them. When troubleshooting, developers aren’t actually looking for specific bugs and are instead looking for the triggers behind those bugs. This might seem obvious, but pointing out this distinction creates more space for all potential bug-causing systems to emerge. With that in mind, developers can discover and narrow in on these triggers through either*:

1. Playing the game as a finalized build and experiencing the bug as a player
2. “Playing” the game in the editor while watching the profiler
3. Consecutively editing the game environment and running it to isolate the issue

Once a bug’s trigger is isolated, then the next course of action is to then “fix” the bug. I don’t personally like to use that word, as “fix” implies that removal of the bug itself is a necessary move to make, which just isn’t always the case. I much prefer the term “resolve” a bug as it provides the most space for creative options in development.. As an example, let’s say there’s a bug that’s causing the screen to randomly shake when the player object parents itself to a rail object for a grind. Playtesting reactions to this bug are mixed, where some players find it jarring and others seem to think it’s intended. The mindset of “fixing” the bug dictates that the camera shouldn’t shake when this happens, so the bug is “fixed” and development continues without a second thought. The next round of playtests, players report that grinding feels a lot more smooth, but doesn’t carry any weightiness or grittiness anymore. The mindset of "resolving” the bug dictates that, based on playtester response, there seems to be a divide in reception to the bug itself where the nonfunctional component seems to be enhancing the experience to some. The source of the screen shake is pinpointed and instead of full removal, a script is added, with the goal of broadening that reported enhanced experience, that slightly restricts the movement that can occur to the camera object when a board is on the rail. The next round of playtests, players report grinding feels slightly more smooth, with a satisfying weighty drag of the board. 

“But you said script! This was supposed to be how to fix bugs WITHOUT coding”

Yes, I know. Given my own personal background, I’m much more inclined to hard code a resolution to a bug. With that in mind however, the mindset of bug “resolution” directs developers to use more of the tools provided by your game engine of choice in contrast to coding. Instead of a script, I could have just attached a Joint Constraint on the camera, or manipulated the hierarchy of objects in the editor. Obviously this example is highly specific, but the principle can be applied to bug resolution across a variety of development teams. 

This concept of playing into the feel of the game, regardless of its source, is widely known in the field of game development and has resulted in plenty of phenomenal games. The goal with this was to give some insight into our design principles and hopefully give other developers more methods to create great games. 

*Notice how all the means to discover and narrow bugs involve PLAYING the game. Getting the game in a playable state as early as possible is the best chance any developer has to discover bugs, and by extension have a more polished release”

Carter Costes

Game Programmer

Thanks for that Carter! That’s all we had planned for this devlog, but come back in two weeks for a brief dive into the design origins behind the game’s controls and the high yield that the iterative process had on it. Please leave any questions or comments you have for Carter or the team overall below and we’ll respond! To keep updated on Beat Skater, make sure to follow our Twitter and Instagram. If you’re interested in trying the game, it can be downloaded for free on the Google Play Store or the Apple App Store. Thank you for the time and playing!