From Chris Kempt's Blog
- ► 2014 (11)
- ▼ August (10)
- ► 2011 (31)
- ► 2010 (19)
- ► 2009 (33)
Friday, 3 August 2012
Friday, 3 August 2012
This one goes out to Brandon Cowan from http://www.crazydogapps.com for pointing out that Stunt Guy - The Getaway had a pretty heinous graphics scaling issue on iPad1 & 2, and to all those of you with an iPad 1 or 2 I am very sorry, this was my fault - I will explain how shortly.
Brandon, being an App Developer himself, very kindly sent us multiple screenshots of the issue and video of it in action which enabled us to quickly work out what the problem was and squash it flat. The fixed version will be available as soon as possible.
The problem was caused by a fundemental change in the programming framework we use to create Stunt Guy which occurred shortly before release. I then failed to re-test the game on my iPad2, assuming that because it worked on our other non-retina devices that it would work properly on the iPad - but it didn't.
This brings up one part of the game development process that is very important - testing and bugfixing!
When testing games before release they must be tested extensively across all platforms and in as many different directions as possible. Menus should be navigated backwards and forwards, buttons should be tapped as rapidly as possible, or while animations are playing. The game should be tested extensively; what if the player crashes and dies, and then the time runs out immediately after, or vice versa? What if you can clip a wall or object in a certain way? Can you manage to die before the game has even begun? Testing is all about being very creative and pushing the game into situations it isn't designed for; you're *trying* to break it, so you can fix it! Because no matter how unlikely the scenario, no matter how weird the cause, it WILL happen to someone out there in the world playing your game. Even if the cause is something that the player is not supposed to even think of to do, like jump backwards into a barrel repeatedly, if it happens and it breaks the game it shouldn't be in there, because someone will think of it, and do it.
When you do cause one of these issues (and you will!), it's then very important to properly document the issue. I know that Max will have his hands full all the time, he'll be implementing new features or running down other bugs that we have already discovered, and he doesn't need to spend 15-20 minutes trying to work out how to recreate an issue that I've found. So I send him a bug report, with a step-by-step description of what happened and everything I did to cause it to happen. A hypothetical example;
Start Menu, pressed button through to Main Menu, hit play game, played the game, died by crashing into a car, exit screen, score on gameover screen doesn't exist
I then back this up with screenshots of the issue, or like Brandon so kindly did, with a video of the whole process.
This is because the bug could be caused by anything. It could be an error in the code on the Start Menu button that somehow causes the score to break later in the game. Or it could be a bug in the "car crashes into another car" code. I don't know this, but Max does! He can look at my breadcrumb trail, relate that to what he's done, and find the problem quickly. It takes me an extra minute or so to properly document the issue, but it can save potentially hours of him trying to find it himself if he knows exactly what I did to cause it.
Of course, bugs can still get through. There's a LOT to test in a game. One thing to remember however is that bugs are not caused by computers; they're fundementally a human error. In this case, the error was mine in not testing the app on ALL devices instead of just the ones I thought were relevant. I tripped up on one of the eaisest things to test, and for that you all have my sincere apologies.
Thank you again Brandon for bringing this issue so expertly to our attention, we really appreciate it!