12th Sep 2012
We’ve learned a few things over the time that we’ve been working on Bar Fight Live and one of them is just how realistic we should be about the frequency of our updates. As you may know, the plan has always been to release a new build every 3 to 4 weeks, get your feedback and then whizz out a new build in another few weeks.
Reality has bitten. We’re going to need a little longer.
Before you wail and gnash your teeth we’re only talking a bit longer – about 4 to 6 weeks. This should give us enough time to cater for cock-ups and ‘unforeseen eventualities’ (such as the version with the prototype getting rejected first time out by Apple ’cause it saved videos to the device in a way they didn’t expect) and allow us to get even more of your feedback into the game.
So please bear with us for that little bit longer between builds, to balance things out we’ll be keeping this blog updated with even more stuff so you don’t miss a thing.
3rd Aug 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!
1st Aug 2012
Yesterday we received a rather brilliant review from touchmyapps.com. Kind comments included:
“If this approach to fundraising actually manages to work, I wouldn’t be surprised if we see more efforts like this popping up all the time.”
“[Stunt Guy] gives you an idea of the production value this developer is capable of.”
A very complimentary review we think! See the post on their site here (about half way down the page): http://www.touchmyapps.com/2012/07/31/10-new-app-store-games-to-watch-july-23-29/
27th Jul 2012
A second day of good news from the App Store, as our second game Stunt Guy: The Getaway
goes live! Whilst most of our anxiety and sweating was taken up waiting for Bar Fight Live
to be approved, there was most certainly a sigh of relief to hear this brilliant news!
One quick reviewer on the App Store piped in with:
“Smashing up other cars hasn’t been as fun since the original GTA!”
Looking forward to hearing more reviews :)
For those who haven’t yet seen our trailer for The Getaway, check it out here: