Martin Wakeley is a director at Crash Lab and designed and set-up the levels on Crack Attack. Prior to that he was a project manager at Free Radical Design, and a designer at Rare responsible for games such as Blast Corps and Jet Force Gemini. 

Crack Attack is available on iOS, Android, and Windows Phone.

Crash Lab was founded in November 2011. Steve and myself met back in the '90s while working at Rare, and I followed Steve to Free Radical Design.

We left Free Radical Design after the acquisition by Crytek, and set up Crash Lab where we make games for mobile devices. We've worked with Zynga and had a number one game with our The Snowman and the Snowdog series, which has won us several awards.

It was early in 2014, and we had been working hard on a couple of projects that we were looking to take to publishers.

One weekend Steve decided to try a "game in a day" challenge. I got in on Monday morning and Steve told me to run the latest build of the game. Instead of what I was expecting, up popped Super Colour Combo. It was a simple game where you had to match the colors in a sequence at the top of the screen with colors on the board below.

It was against the clock, and you earned more time by successfully completing sequences. The goal was to complete as many stages as possible. It was instantly playable and we spent the morning trying to beat each other's scores. We would have played on, but we were preparing for a publisher meeting the following day, so we put it to one side and carried on with our presentation.

As we prepared for the weeks meetings, we discussed what to do with Super Colour Combo. Our intention was to release it as a game jam-style project without any thought given to monetization, but our primary concern at this stage were the two prototypes we were working on and the upcoming presentations, but random chance took us down a different path.

Super Color Combo

What Went Right

1. We didn't have to try to sell it

Visiting publishers or investors with a new game is a very established process. As a developer, you stand up and enthusiastically demo your latest game while the publisher nods and smiles politely. They are invariably "interested" at this stage, and this may or may not lead to further meetings and eventually a deal.

We were visiting Kuju to show them two prototypes that we had spent the previous six months working on. As expected, everyone nodded and smiled politely and we arranged a further meeting. As we were packing up to leave, we started discussing their future plans for publishing and they mentioned they were looking for a puzzle game.

At this point I nudged Steve, and he somewhat reluctantly gave them his phone with our "game in a day," Super Color Combo. A few rounds of the game were played before we hurried off to catch our train, without thinking any more of it.

On the train on the way home, we were discussing how the presentation had gone and if the "interest" was likely to go anywhere, when we received a phone call from Gary from Kuju. He didn't want to talk about either of the games we pitched, but was interested in Super Color Combo. In fact, he was very interested. A few minutes later, after a few interruptions caused by loss of signal in tunnels, we had agreed a deal in principle to publish Super Color Combo.

In over 20 years of making games, this was without doubt the quickest and most straightforward deal we had ever done.

2. Collaborative development

10 people worked on the development of Crack Attack, but we've never all been in a room at the same time. All of our communication took place over email and using Google Hangouts.

We all work from home, which is great way of keeping costs down, and it means our work/life balance is excellent. We worked hard and for long hours on Crack Attack, but we didn't have to sacrifice our families or social life because of our setup.

It helps that we have a great network of contractors that we have previously worked with at Rare and Free Radical Design. It means there is an innate understanding of what is needed to produce the highest quality games, and the management overhead is minimal.

We even bartered some work with our friends at Fallen Tree Games -- Joe helped us out with some particle effects, while Steve helped out with some of their server code.

We don't use game design documents or project plans. The team is small enough to discuss what needs to be done and then we work off a simple to-do list. A screen share on Google Hangouts is as effective as walking over to someone's desk to check out a new feature. We use Dropbox as part of the build process, and to share assets and distribute builds if necessary. Progress is easy to track and visible to the rest of the team.

Crack Attack

3. We enjoyed playing the game

This sounds an obvious one, but having spent the best part of 10 years being involved with gritty FPSs where a future soldier runs around in a dystopian universe shooting people in the face, I understand what it's like not to enjoy the games you are working on.

I like King.com's games. This is deemed heresy by a large section of the game development community, but they serve a great purpose as a quick, fun distraction.

We knew that with Crack Attack we wanted to create a casual and fun game that appealed to the same audience -- people like us, who had 10 minutes to kill while waiting to pick their kids up from football training, or an alternative to the latest awful reality show that the rest of the family are watching on TV.

We know the game is fun to play because it's all we do all day. With a traditional console game, it's likely that the people creating a level will only play it properly a handful of times before the game is released. With Crack Attack, we've played each level hundreds of times, tweaking and balancing the difficulty, and setting new score targets.

It's never a chore to set up levels on Crack Attack. I've genuinely enjoyed every minute of it. There are enough cool gameplay features to keep the levels fresh and interesting. If I was bored of setting up a particular type of level, it would probably be safe to assume the player was bored of playing them.

Crack Attack is also probably the first game I've worked on that I have spent any significant time playing post-release. We have the game connected to our Facebook accounts, so there is a fair bit of competition between the team and our friends.

4. Focus testing

To say I was skeptical going in to this is somewhat of an understatement. My previous experience of focus testing had been that it was more random unsolicited opinions, delivered at a point when it was too late to do anything about them.

With Crack Attack, Kuju scheduled a focus test a couple of months into development. We still had enough time to make any changes that came as a result of the test. The fundamentals of the gameplay were in place and we had the audio, the background art for the first chapter and most of the UI.

We watched a group of players play the game without any prompting, and listened to their feedback. In contrast to my previous experiences of focus testing, the results were overwhelmingly positive, so we didn't need to change much.

What it gave us was a reference point to discuss aspects like the difficulty or understandability of features. It meant we could have objective opinions on particular levels without having to resort to "I found this level hard, so therefore you need to make it easier" type decisions.

It also served the purpose of building confidence with the publisher. We were able to demonstrate the game we were working on that we all thought was good, stood up when it was put in front of complete strangers with no agenda. It is a great way to validate the decisions that have been made during the course of development.

5. Using our own engine

Probably the most frequent question we get asked is, "Do you use Unity?" No, we don't. We use our own engine, which is efficient and written exclusively for our own needs. We have quick load times, no stalls, and a manageable app size.

Part of our mistrust of middleware comes from years of experience of delivering games that feature other people's tech. Games released with critical crashes caused by known issues in approved third party libraries, or even crashes and hangs that are a direct result of the platform holder's own software.

If something goes wrong with our engine, we know what the problem is and we know how to fix it. This is critical in creating a stable and reliable code environment, which benefits the developers and means builds can be made at short notice.

Being able to deploy to multiple platforms is often cited as one of the primary benefits of middleware. Our experience tells us that getting the game working on other platforms is a routine job if your engine is robust enough; the time-consuming aspect is incorporating the myriad of third party APIs. It is also these third party APIs that present the greatest risk to the stability of any game -- any bugs they have will be incorporated directly into the game and are unavoidable.

Many of the advocates of middleware haven't been through a full cycle of game development with it. The benefits of quick prototyping are undeniable, but there is a trade-off in terms of performance in the long term.

Crack Attack is available on iOS, Android, Kindle Fire, and Windows Phone. It runs at 60fps without any stalls, and has a download size within the 3G limit.

What Went Wrong

1. We spent too long in soft launch

In our past lives as console developers, and particularly before the advent of DLC, there was a defined end to the development of a game. When the game was free of all critical bugs, it was sent to a manufacturing plant and copied onto either cartridge or disc. Any issues that hadn't been found by this point could not be fixed at a later date.

Now, a game is a constant work in progress. As long as there is demand, more features and levels can be added indefinitely. The question then becomes, "at what point should we launch?"

The answer to that question is defined by two common phrases:

"Launch and learn" is about getting a game out into the hands of the public as soon as is possible, and then tweak and respond to feedback. The counter to that approach is, "You only get one chance to make a first impression," which advocates launching a product that is as complete and polished as possible.

The mitigation for this is to go into soft launch, or more specifically to release the game in a territory which best reflects the play patterns of the intended global market.

We soft-launched in Ireland in September 2014. Our full launch was somewhat complicated by the fact that Christmas was fast approaching -- the cost of user acquisition becomes prohibitively high at this point, so we made the decision to delay the launch till after Christmas.

With hindsight, this gap was probably too long. We might have been better off to push ahead in October rather than wait. Initially, the soft-launch gave us a great insight into the difficulty of the game, people's play patterns, the virality, and how they were monetizing. Once that information was established, we stopped learning anything new and in the meantime the rest of the industry kept marching ahead, with new competing games being released and production values increasing.

2. Middleware

Real-time analytics have changed the face of game development. We used to make games, package them up, and get no feedback beyond reviews in magazines. We had no idea how difficult people found it, how long they played it, or where they got stuck.

With the advent of the Internet, we began to get feedback from the noisy few who tended to occupy the extremes of opinions. It's always dangerous to make changes while ignoring the silent majority.

What analytics give us is the ability to snoop in on every aspect of players' play. We know exactly how many times it takes very player to complete a level, how long their play sessions last, when they are getting stuck, and how far through the game they are.

The problem we had is that there are a lot of analytics solutions, each with their own strengths and weaknesses. We underestimated the impact in terms of time and resources of trialing and implementing these various solutions across all our supported platforms. They were never the "quick and painless" integration that was promised by the salesperson, and we were often left without vital pieces of information.

With hindsight, we would have benefited greatly from a good recommendation from a developer who had worked on a similar product who could share their experience, or possibly we could have written our own solution that we tailored exactly to our needs. Also, it might have been better to add them at a later stage on some platforms.

3. Too many platforms too soon

Another thing we underestimated was the cost in time and resources of maintaining multiple versions of the game.

Crack Attack runs on iOS, Android, Kindle Fire, and Windows Phone. The game code itself is manageable; what hit us hard was the middleware and third party APIs.

Updating to the latest version always took longer than expected, and there was an inevitable QA overhead, testing against various versions of the OS and across multiple devices.

One casualty was the web version of Crack Attack. It required the most bespoke work out of all the versions, so we quickly put out on the back burner to focus our resources elsewhere. The benefit of cross platform availability for the game is clear, but with hindsight we would have been better focusing our limited resources elsewhere.

4. Opinion overload

Everyone has opinions, and the games industry is not short of people willing to vocalize them.

We found the forum of focus testing was a great way to gauge opinions from a representative audience, without any agenda being followed.

The least useful opinions were from people who don't understand the market. There is a well-documented skepticism from "traditional" console developers towards the mobile market.

The danger is when these opinions begin to shape decisions made as part of the development process. One issue we came across early on in development was regarding the difficulty of the game. People who are used to playing console games were looking for a smooth difficulty curve, but consumers of free-to-play games are used to the "sawtooth" difficulty found in games like Candy Crush Saga, where the 20th level could be the same difficulty as the 500th level.

This is partly due to the nature of chance that is involved in the game, and also a reflection of the constantly evolving nature of the games, where there is no fixed end-point to ramp up to. Once a player understands the rules of the game, then they are looking for a consistent challenge as they play through -- not the console experience of getting more difficult until the game ends.

We came to Crack Attack as players of F2P games. We spend money on in-app purchases, and we understand how the system works. When you are dealing with people who don't understand the market, there is an inevitable amount of time spent going over the same points to bring them up to speed.

The solution would be to only show the game to people who are familiar with the mobile market and understand how F2P works -- but unfortunately given the crossover between the two sectors, I don't think that would be realistic.

5. Bugs

Bugs will always creep in to any software. It's inevitable, and in the most part they are fixed before the game is put in front of the consumer.

As a result of feedback from our soft launch, we reworked some of the game's tutorials. Unfortunately, as a consequence of this, in the subsequent game update, it became impossible under certain circumstances to finish a tutorial that we hadn't reworked, but which shared some common code.

We noticed the issue when the stats showed there were an unusually high number of people stuck on a particular level. The fix was a single line, and we were able to fast-track an update to address the problem.

What this incident highlights is the fine margins on which Indie developers exist. How thoroughly a game can be tested is entirely dependent on time and resources. We have a test plan that is optimized to have the greatest coverage for the resources available. Unfortunately, it is the edge cases that tend to cause the problems.

On console games, the monthly budget for QA is greater than the entire development budget for some of our games. We tend target our testing on the areas of the game that have recently changed. There is no real mitigation other than to increase the scope of the test plan. The problem is exacerbated when covering multiple devices and operating systems.

Also, unique to Crack Attack is the sheer volume of play the game takes to complete. The element of chance means that levels may need to be played multiple times before they can be completed. In our console days, we would task up the most accomplished player to do a lighting quick playthrough of the game to run in parallel to the full testing pass. Most games could be completed in a couple of hours; that wouldn't get you past the first chapter in Crack Attack.

Conclusion

My overriding memory of Crack Attack is that it was a fun game to make. It seemed to take longer than it should, but that is often the case.

It's our first casual F2P game, and as a result it's probably reached more of our friends than any other game we have worked on. It's great seeing friends and family on our Facebook leaderboards.

It's a great achievement for a small team and a small budget -- it proves what you can do if you work in an efficient and focused way. It's polished and fun to play.

We have more levels in the pipeline. We are currently tweaking chapter 7 for our first update, and then we have several more chapters in the pipeline. Based on our soft launch statistics, we will likely introduce a new chapter of 25 levels every 4-6 weeks.

We hope to carry on supporting Crack Attack for as long as people keep playing it. We've been really pleased with the iOS launch; we were featured in the "Best New Games" section, which has a big impact on downloads. It's a great motivator to see so many people playing the game and having fun.