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.
23rd Aug 2012
Today we got the unfortunate news that our latest submission of the Bar Fight Live app was refused. This was down to a simple technical issue with the way we were handling video caching. No doubt the way we wrote it was too intelligent for Apple, after all Max’s changelog does say “Some very clever video caching “. Instead of making it less intelligent, this time we gave it some social skills to boot – hopefully this time it’s Apple friendly!
6th Aug 2012
Here are some very early concept sketches of gameplay and how the Bar Fight game might look. As things stand now it’s up to you to let us know how the game will look and play! So get the app and get involved so you can have your say!
Done with: Pencil, pen and photoshop
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!