Wednesday, 29 August 2012

Wednesday, 29 August 2012

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 :)


Monday, 27 August 2012

Monday, 27 August 2012

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


Thursday, 23 August 2012

Thursday, 23 August 2012

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!
Categories: ,

Wednesday, 22 August 2012

Wednesday, 22 August 2012

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

Friday, 17 August 2012

Friday, 17 August 2012

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.


Thursday, 16 August 2012

Thursday, 16 August 2012

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!


Thursday, 9 August 2012

Thursday, 9 August 2012


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


Monday, 6 August 2012

Monday, 6 August 2012

Game play sketches

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

Categories: ,

Friday, 3 August 2012

Friday, 3 August 2012

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!

Wednesday, 1 August 2012

Wednesday, 1 August 2012 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):