The Bug Squashing Process
99 little bugs in the code...
Infinite Level game discussed: The Future Project
I lightly touched upon my bug fixing methods during the last dev blog, but given that I'm officially in the polishing stages of The Future Project I thought it would make sense to describe exactly how I'm going about said polish. Perhaps this will be useful information to any fellow indie developers out there, or maybe one can even give their own feedback on my methods. As for the players, admittedly this is going to be more of a "behind the scenes, under the hood" kind of blog. If you're curious about new information on the game or its progress, I'll let you know now that this won't be the focus of this dev blog. But, you may still be curious to know the process a game developer takes when they go to clean up their work and make it presentable. Or maybe you just want to hear a funny story about a bug I encountered, in which case...well, I hope you enjoy some of these upcoming gifs.
Fact is, The Future Project is the biggest game I've ever made, with larger levels, a lengthier campaign, and a plethora of player abilities among other things. The number of things that can go wrong are quite high. So, it should perhaps go without saying that playing the game multiple times if something of a requirement. I don't know how many playthroughs of the game I'll do before release, but I suspect it will be quite a few. In the last blog I had mentioned my playthrough methods. There's standard, where I simply play normally, a gathering mode where I see how powerful I can get before a given fight, speedrunning, trying to break the game, and one I didn't mention before simply called minimum percent. As of this writing I've not fully gone through all modes yet, but nobody says I have to stick strictly to a single mode. Breaking the game and standard play often go hand in hand, as do minimum % and speedrunning. But in general, I approach a playthrough with one of those as the "main mindset". With this, I can play through the game with a variety of perspectives as well as uncover bugs and glitches under many different circumstances.
This is a somewhat long way of saying that first, you simply have to play your game. But I suppose that's rather obvious. Of course you have to play the game to know if bugs exist! However, it's worth noting that it's not enough to just play the game. You have to play almost like you're a customer trying this game out for the first time. When you're a developer, you get used to a lot of the quirks and oddities of your game. But if you take a step back, you'll see that those quirks probably need addressing in order to make a more enjoyable experience. Furthermore, this is why it's good to play through your game with a handful of different potential perspectives. In my game, collecting upgrades is a significant part of the experience. But what exactly happens if somebody simply ignores those items? How enjoyable is the game for those kinds of people? That's what me playing through the game using a minimum percent build is for. Likewise, given that this is a metroidvania, it'll be important for me to speedrun my game a few times since these kinds of games tend to be enjoyed by people who like speedrunning. You'll get a good feel for the game's balance in doing so, while also finding a variety of glitches that may only come about in scenarios such as speedrunning.
So, now that you've played the game, you should have a sizeable list of bugs and adjustments to make. If your list is small, then congratulations, you are a god among men (and maybe you should go ahead and just replay your game)! But then you have to ask yourself what's most important. I break down items I find like so: there's major bugs that negatively affect a player's experience, minor bugs that don't look great but aren't a big deal, balance adjustments, and minor features. Major bugs is the area to focus on, as a game with bugs that can cause crashes, softlocks, or otherwise make a game not fun need to be addressed. These are probably the bugs you have to look at first. Minor bugs aren't as urgent, but they're still worth doing for the sake of your game looking complete and polished. As an example, everyone has picked on The Elder Scrolls V: Skyrim for its plethora of bugs. Though these days they're considered fun and cute, situations like enemies flying into the sky, characters sitting in the air, and more give the game a mild feeling of being incomplete. Thankfully, most of these bugs don't negatively impact the experience of playing the game, so for most people they won't be a problem. But you can't help but imagine how much more immersive the game could be if they weren't there, and that's why it's still important to clean up as much of these minor bugs as possible. Additionally, I lump in visual "errors" in with minor bugs. It's hard to call these "bugs" necessarily since they're not the fault of any programming logic. They're usually small things like needing to move a rock a little to the left or adjusting the landscape. Again, not really bugs, but I treat them similarly to minor bugs.
The other two kinds of fixes fall into a much different category. While the major and minor bugs tend to be objective problems with a game, balance changes and minor features are a lot more subjective. With these, you have to be mindful of the domino effect you can cause on a game's balance or feel. Nerfing or buffing an enemy, for instance, can make for surprising changes to the overall difficulty of a level. Changes to how powerful the player is can be even more risky in a game like The Future Project since you can make the entire game easier or harder depending on your change, all with the change of a single variable. For me, I often test out my balance changes with my wife, who's been helping me playtest the game. She's been great for getting that perspective of someone who hasn't been staring at the project for years, and since she's right there I can often get some quick feedback on a change. Minor features are debatably the most drastic of changes, as you're essentially adding whole new game elements to the game. I reckon in larger studios these kinds of late developments are rare, but for a solo dev such as myself I'm guessing making additions to the game even in beta isn't so surprising. These minor additions are usually in the mold of a player convenience, not necessarily a major change like a new player ability or enemy type. For instance, I've been putting together a system that shows the remaining items to find after the player has reached the final boss. I wanted a tool to give completionists a way to easily know where to go to find remaining items and cut down on the pointless wandering. I still make sure that they're hidden during the main game, but once you've reached the end it makes sense to me to just let you have at them and enjoy the challenges you stumble upon going from one item to the next.
With the issues broken down, now you just have to start fixing them. Unfortunately, I can't really tell how to fix a given bug. Everyone's bugs are different. Sure, maybe two devs both had an issue like mine where an enemy suddenly sinks through the floor, but their specific game circumstances mean that the solution for one developer is going to be very different from another. In game development, there are very few absolutes. That said, there's plenty of general issues that you can look up online to progress towards some greater solution. In the above example, maybe you just need to know how to stop applying gravity to the enemy when it dies, or maybe you simply need to adjust some collision areas. It really depends on your game at that point. As for what to work on, I already mentioned that major bugs should probably be given attention first. I often then go to balance adjustments after, followed by minor bugs. Minor features are something I tend to work on over a period of time which can vary depending on what's being implemented. Of course, with any change, I'll be playing through the game to see that the change fixes the bug or overall makes the game better.
Perhaps it goes without saying that having additional playtesters helping you out is a useful thing to have. The more people that play your game before release, the more perspectives you get on the game, which means you don't have to do as much playtesting in, say, a completionist's mindset. Depending on your game's complexity you can also get a variety of people's perspectives based on difficulty, go-to tactics, and a lot more. You definitely want at least a few people to playtest your game if you can. Some people are naturally able to get this, whether it because of a Discord server they made for the game or have a sizeable social circle. Others, such as myself, may have a harder time of this if they don't have a lot of friends or, to be frank, are just generally shy people. But if you can get even a few people to play your game, you're already doing yourself and the game an important service. So, in addition to your own playtesting and bug fixing, take time to reach out to people and see if they'd be willing to play the game for you. They'll help you find even more ways in which your game can be improved.
And with that, that's the broad strokes of bug fixing and improving the game. This doesn't even begin to get into the process of sussing out what's causing a bug or how to know a balance change is a good one. My focus today was more on the process of discovering things to work on. Hopefully it's useful to anyone who may be starting out, or interesting to those who may not know much about game development. If nothing else, maybe you had fun giggling at the bugs I've shared in the gifs above. Some of these were pretty involved to fix too, but once they were finally addressed I could breath a little easier. As of now, I'm still going through my own little mountain of bugs and adjustments, not to mention a handful of minor features to. By the end we should have a nice, polished game for you to enjoy. Till then, I best get back to eating this giant pile of bugs one bite at a time. Hmm...it sounds kinda gross when phrased that way.
Until next time!
-Lance T.