Bar Fight Live Vote #2: Back to the Drawing Board?

When we launched version 0.2.0 of Bar Fight Live we were hugely excited as it included the gameplay prototype, which let you get to grips with a punching, kicking Stunt Guy for the first time.

Bu what did you think of it? Alongside this initial demo we asked you to give us your feedback by voting on the following question:

Q: What do you think of the demo’s touch controls?

  • Just right (same again in the next update)

  • Getting there (I’d like to see the controls develop more)

  • Try again (I would like an alternative)

The results were something of a surprise - and another notable landmark in democratic development:

You voted for "Try again"


  • Just right - 5.7%

  • Getting there - 45.7%

  • Try again - 48.6%

That’s right, nearly half of you asked us to ‘try again’ which pretty much means ‘go back to the drawing board’!

Well, that’s the deal. The winning vote decides what we do next and so we’re beginning the process of coming up with new controls for you. The downside to this is that it’s going to push everything back a little and we want to take extra care to make sure the next version of the prototype gets a resounding thumbs up from you. We’ve got some thoughts on how we might get this to you quicker but please be patient – we’re starting again!

Kempt Game Hijacked by Ling Valentine

It's said that imitation is the sincerest form of flattery and we all enjoy spotting 'influences' in the latest releases.

What you don't often see is a game grabbed by the throat and hacked into an astounding new form by a Chinese car super-saleswoman. That's exactly what happened when Ling Valentine - the car lease phenomenon and Dragons Den-defying marketing one-off - got her hands on our very own Stunt Guy - The Getaway game.

For those not yet up to speed with Ling's unique approach it's well worth checking out her website,, an object lesson in doing it your own way. And that's exactly what she did to our game!

So what happens when a legendary stunt man meets a Chinese typhoon? Predictably enough, total nuclear destruction - check it out:

BIMA D-Day Schools Challenge

We were fortunate enough to be part of yesterday’s BIMAD-Day schools initiative, a national event aimed at closing the skills gap in the digital industry. Across the country digital agencies attended local schools to mentor a day of digital creativity with the students.

Our welcoming hosts were Chaucer Technology School, here in Kempt’s home town of Canterbury and appropriately enough we were to mentor a class taking up the Mobile Apps challenge with the aim of submitting the results to be judged in this national contest. Right up our street!

After getting over the shock of being back in school (so much has changed, so much is exactly the same!) we settled into our roles of pseudo-supply teachers to a room full of thirty Year 9s - “Year nine, YEAR NINE!!!” became a regular refrain throughout the day! Fortunately the class seemed to respond well to the day and were genuinely engaged.  

Like most schools the suite of computers wasn't the most current but the creative process isn't just about the speed of your processor and the version of your software. The ideas began to fly around the room from the word go, fuelled by a strong understanding of how apps work and a freedom to think up new possibilities. We had ideas from the practical - very useful medical and personal security apps - to the fantastically fanciful - pet translators and open-ended games that tapped into your dreams!

One thing that struck us was how much time was actually spent on the class PCs - just an hour in the afternoon. To us this seemed like a good balance as what makes this industry so exciting isn't the technology itself but what the possibilities it creates. However, we also left the students with a Flash demo app to pull apart and recreate. It's when you understand technology that things get really interesting - it fuels your imagination and turns brilliant ideas into brilliant products. 

Sneak Peek: Bar Fight Live Level Art

Whilst you've been pondering the gameplay prototype and how you'd like that to progress we've been busy with other aspects of the game.

In particular we've been looking at the game environment - after all, every Bar Fight needs a bar!

Here's a sneaky peek at what we've been working on - a classic saloon bar. Note that it's ACTUALLY a movie set, built on the Hollywood back lot that Stunt Guy calls home:

As ever we're after your input, let us know what you think in the comments below - or get in touch on our contact page.

Reality Bites: More Realistic Release Schedules

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.

Bar Fight Live - v.0.3.0 Changelog

In our third release of Bar Fight Live, the following items and changes were made to the App:

  • Improvements to game play prototype

  • Improved layout & navigation

  • Improved vote & results

  • Implemented Ping notifications 

  • New vote every Friday - alerts user using Ping notifications

  • Changelog feed added

  • More images of artwork added to the gallery

  • Fixes for App Store rejection

  • New revision of the Bar Fight Live logo

  • New app icon

  • Made with more blood sweat, tears and caffeine :)

Animation Prototype

The last you heard from me about animation was when I was talking about the animation for a prototype, using cool round squashy dudes!

However, we've rapidly moved on since then, hopefully towards something you guys can play, so now we have REAL-SHAPED PEOPLE. I drew these to get an idea of how the animation works and to give us a timing template for when Kit comes in and redraws the art to make it awesome.

One thing I've learned about animating for games is how important it is to get a feeling of context while you're making the animation. For example in the past I would animate a walk cycle, a jump animation and a falling animation independently of each other, and feel perfectly happy with it. But when I saw it in the game, the walk cycle may be too slow for the rate the character is moving at, the transition from jumping to falling may be clunky, or the animation of the jump just doesn't feel as fast and energetic as the actual jump is.

So after that I would repeatedly hassle a programmer to put them in the game and see how they looked, then I'd go back to my desk, try to fix it, hassle the programmer again and again until I've iterated enough to have got it right. Then I decide we need a "landing" animation when the character hits the floor and the programmer throws his keyboard at me.

Argh, right? Wouldn't it be much better if I could just program a rudimentary controller so I can play back and swap between animations myself? This is where Flash really shines, I can get a test rig together in a matter of hours, programming and drawing in the same environment, and really get a feel for what the game may require. While the code I write in these animation demos most likely won't be used at all in the actual game code, I can at least give Max a good idea of what I'm likely to expect the animations to be and likewise help define the feel of the game earlier.

Here is a GIF of it! :D

App Store Refusal!

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!

Bar Fight Live - v.0.2.0 Changelog

In our second release of Bar Fight Live, the following items were added to the App:

  • Basic game play prototype!
  • Improved voting system - means more things to vote on, more often!
  • New video for supporters - video profile on Paul, our master animator.
  • More gallery images of artwork added
  • Some very clever video caching 
  • Minor tweaks based on user feedback
  • Tweaked design of the App navigation and layout

Video Profile: Paul Fryer!

I'm just in the process of editing our latest team profile video for the next release of Bar Fight Live. This one is of Kempt animator extraordinaire, Paul Fryer. With an official job title of "fun-gineer", he sits between the Artists and Developers and is responsible for some of the juicy parts of game development: animation, sparks, explosions, sound effects, music and of course skid marks.

This video will be walking through how Fryer crafts and hones the animations for Bar Fight Live, and also some secret recipes he uses to add extra spice to game play.

This video will be available as a piece of featured content, in the next release of the App.

Bar Fight Live Vote #1: The Results Are In!

Today is the biggest day so far in the short but incredible life of Bar Fight Live.

This morning we counted your votes to determine the core direction of the game.

As a reminder, we asked you to vote on what kind of game Bar Fight should be:

  • Touch-based fighting (swipe to attack etc)

  • Turn-based strategy (choose targets, type of attack)

  • Arcade melée combat (Gauntlet-esque)

The results were as follows:

With nearly two-thirds of the vote you have told us to build a touch-based fighting game! There's certainly wisdom in this as we can be sure that Bar Fight is perfectly suited to a mobile device.

If this wasn't the way that you voted don't despair, we're still listening to you. And if you haven't voted yet pleased do! It might sound strange now that voting is closed but we still want your input - every vote, every comment, every email gets taken into account - Bar Fight is your game!


A big part of making games fun is making them understandable. You don't want players getting hit by something they couldn't really see, or getting stuck on an item of scenery that doesn't look like they get stuck on it; those aren't the fault of the player and therefore aren't fun things to have happen!

One easy way to differentiate between different objects and their affect on the player is with colour, for example; red = baddie, green = pickup, yellow = impassable wall etc.

But I also like to try to use the tone of an object to communicate its importance to the player.

Referring to the image above, let's start with the least important part in the gameplay heirachy;

  • The background! In the above image the background is dark and muted; the player has no limitations in this area.

  • Second is the objects that the player can interact with. These objects do not hurt the player, but may impede movement or have a non-critical purpose, like smashing into bits when someone is punched into them. These are tonally brighter than the background to make them more noticeable than irrelevant objects.

  • The next brightest thing is the really important stuff; baddies! Things that can hurt you or that you should be especially aware of are tonally bright, to set them apart from the background and non-baddie objects. Baddies pose a threat to the player and their position is very important information for the player to know, so they'd better be easy to spot!

  • Finally, Stunt Guy himself! As the player character, he's the most important item on the screen, and so should be tonally brightest; the player should always know where he is. Particularly as how as a touch game the screen may be covered in fingers, you may need to find him again after briefly obscuring him.

Of course, this is only a guideline. There can be bright background objects, and dark baddies! And of course adding colour hue and saturation messes it all up again... But by setting out this principle in the first place it gives the art a yardstick to measure against; it keeps the game easily communicable, which is half the battle in producing an enjoyable game.

For fun (well, fun if you're me :D), do an image search for black & white GameBoy screenshots, and see which games you can make sense of at a glance and which ones you can't! If it's a maze game, what differentiates a wall from the floor? If it's a platform game, what's the difference between a background object and a platform you can jump on? The original GameBoy only had 6 shades of grey to work with, so it's really informative to look at what they did, what works and what doesn't. Mario is an interesting example, there's a very clear difference between the background and the foreground tonally, but the character sprites are neither light, nor dark. While this contradicts my theories for the Stunt Guy heirarchy and does make Mario harder to spot, it does mean that the same character sprites are as visible on the bright outdoor levels as they are in dark caves!

Cool huh? :D

Bug Spotting - Thank you Brandon!

This one goes out to Brandon Cowan from 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! review

Yesterday we received a rather brilliant review from 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):