With only a little over a day left in the Touch the Stars Game Jam, it's time to find those bugs! And squash them. But how do you get the most out of your bug testing? Read more to find out.
Nothing will kill your game, or your chances of winning a Game Jam, faster than a game-breaking bug. Not only that, but it makes you look unprofessional… and likely feel like a chump. After all, every community out there always preaches “test your game”, “test the deployed version of your game”, and “test your patched game.” But how do you test quickly and accurately, you ask as you prepare your favorite excuse about not having enough time. The truth is that bug testing, like everything else, is just a matter of knowing how to segment each task into a sizable, workable chunks. Listed below are three ways to test your game in a short amount of time for a Game Jam.
This one is the most obvious. Play your entire game, from start to finish, testing for problems the entire way. Every time you fix a bug (game-breaking or otherwise), record what it was, where it was, and how you fixed it (for Halo Testing later). Then play through your game again, fixing all the way. Then play through it a third time, checking every nook and cranny, every possible combination, for something that breaks. Only when you can play your entire game, hitting every combination of moves and actions you can think of without it crashing, do you move on.
Systems clash, even when there are compatibility patches. The best choice would be for you to create every feature yourself, so that you know what is influencing what at any time. However, that is not always an option, so anytime that you want to use Features created by another (such as a Plugin), you want to test it, not only to make sure that it works, but that it works for stuff you’ve already implemented. Go through each feature, listing out what they do. Then look at how each feature could interact with another. For example, your combat system could interact with your screen filter system, or your menu system could interact with your gamepad support. Once you know how each feature can interact, test that as exhaustively as you can, with every conceivable combination, until you’re sure that they won’t break each other.
This is the most difficult and intensive part of the testing phase, and the reason why we always recommend that projects for Game Jams be as simple as possible. Fixing a bug will often create a new one, such as fixing a font-display problem crashing a menu. Therefore, every single time you fix a bug, especially a game-breaking bug, you need test everything around that fix. For example, if you fixed an issue where an animation sequence makes the game crash, your fix may cause a problem with your feature of linking attacks with a QTE sequence. In that case, you’re going to want to test everything involved with the animation sequence that you fixed. Don’t just assume that fixing the one thing solves all your problems. Be as thorough as humanly possible.
Testing is not glamorous or fun. It’s a lot of work and can be very stressful. However, it doesn’t have to be more than any developer can handle. By following the above methodology, you can take as much into account as possible, even when under a tight schedule, and make your game as bug-free as you can before submitting.
Click below to read the full rules and how to submit your game!
MZ’s default animation style uses Effekseer to create incredible animations, but it can be tough to get used to using it. And what if you prefer cell-based animation creation like in previous RPG Makers? Let’s take a look at how to make some MV-style animations in MZ thanks to the 1.4.0 update.