BattleBalls Post Mortem

BattleBalls was the first released title for us and we had a hell of a lot of fun making it.

Starting off as a quick game to make within a week at Gamesnation we decided during that week to expand upon the initial ideas and turn it into our first full game.

A lot of things went right and a lot of things went wrong during the development of BattleBalls, below are the key things we learnt from its development.

What Went Right

1. Public game jam

The idea of creating a game in public at Gamesnation paid off in several ways.  We had tremendous fun talking to everyone who popped in to see our progress and check the game out.  It allowed us to show people the inner workings of game development whilst at the same time keeping us motivated as we gathered instant feedback to see what was working and what wasn’t.

2. Game lore

I personally love when games add even the slightest bit of lore to help flesh out their game universe or to just give something a meaning.  Without the small bits or lore we created for BattleBalls the game would still play exactly the same as it does now however creating little backgrounds and histories for the characters and locations aided with our motivation as we grew attached to each character through their story.  If it also helps players have a reason for playing the game, allows them to use their imagination to expand on the lore or even inspires them to create their own lore and stories then that’s super.

3. Keeping the right scope

Before BattleBalls we had several attempts at seeing a game to completion.  The main thing that prevented these from seeing release day (although I’m still hoping for one of those projects to eventually see the light of day….one day) was that the scope of them got way out of hand.  We were determined to implement mechanics and level scales that in the back of ours heads we knew wouldn’t realistically be possible with just a 2 man team.

After deciding to extend the development of BattleBalls past the initially planned week we stayed realistic and came to the conclusion that the core game itself probably wouldn’t be expanded on too much more and that most of it would be adding more levels and characters.  We also broke down our tasks and deadlines into much smaller details, rather than having ‘complete field level’ set as a weeks worth of work we would have sub goals such as ‘field level textures’, ‘field level models’, ‘field level environment mechanics’ etc.  These all still add up to a weeks worth of work but helped us target them as daily goals and thus give us a greater sense of progression at the end of each day.

4. Effective use of assets and scripts

From the start of development we made sure that as many scripts as possible could be used across each level and character.  This helped a great deal with reducing the amount of time it took to complete tasks.  Using a universal script for characters and another for level management cut development times of each character and level by days, possibly even weeks as it was then just a case of creating the character/level, developing any unique scripts or mechanics required (if any) then simply adjusting the variables of the manager script rather than entirely new content for each individual asset.

What Went Wrong

1. Optimising too late

Despite the universal scripts we created we still handled optimisation very poorly at the start of the project.  Our mindset was to rapidly prototype all the different mechanics as fast as possible to see what worked well and then worry about optimising it, essentially throwing stuff at the wall to see what stuck.  However, this later came back to bite us in the ass a bit as during the later stages of development we had to spend a significant amount of time going back through tons of work to ensure it was as optmised as could be and all but voiding the time saved with the universal scripts.  Even now with all the optmising we did I believe that if we had tried to keep on top of it as much as possible from the start we would’ve been able to release BattleBalls on even more lower end devices.

2. Promoting too late

One of the things we want to try and do with our games is recapture that magic games always had before release where you didn’t know absolutely everything about the game before launch and therefore each game always had several surprises waiting for you when you played.  Unfortunately, as we very quickly found out, that’s just not possible anymore if you want people to be even remotely interested in your game.  This and us wanting to make sure everything was in a ‘final state’ before showing it off meant that we left ourselves with nowhere near enough time to promote the game before release.  We didn’t have enough time to gain the interest of reviewers and press with the review copies being the first time they would’ve been able to actually play the game and didn’t leave enough time for promoting it to the public and gain their interest.

3. Public showing too late

Despite us spending the first week of development completely in the public eye we went dark after that until near release, as pointed out above this didn’t work in any way, shape or form meaning that as it came time to release BattleBalls not enough people had seen it and the majority of those who had seen it would’ve only seen it once or twice, not enough times to get the game to stick with them and gain their interest.  Another setback from withholding the game from the public for too long was that once the game was released we gained some very valuable feedback on features people would like to see integrated into the game, such as tilt controls and the option to change camera angles.  Not only did this mean that time we could’ve spent on prototyping our next project went to adding these features post release but had we shown the game to the public earlier we could’ve had these features in at launch and possibly gained more interest during the most critical time.

4. Keeping it mobile

BattleBalls was always designed as a mobile game however we didn’t decide to utilise the option to also release on PC, a task that would be very simple and consume very little time, until after release of the mobile version, mainly due to our mind set that it was intended for mobile audiences and wouldn’t be recieved well as a PC title.  Releasing on PC after the mobile version has launched rather than developing both side by side means that we will have to eat into the development time of our next project if we want to see BattleBalls on PC.

Overall, I believe the development of BattleBalls has been a very good and successful experience.  It's a relief to finally see a Curiosity Studios game to completion, we are more confident now knowing we can do it.  We’ve also learnt valuable lessons from mistakes we made during development, mistakes we are already rectifying in our next project and will continue to also build on the successes of BattleBalls.