Blitz Games Studios is one of the largest independent developers in the UK, focused on creating high quality games for the majority of gaming platforms. Best known for our original Blitz Games family entertainment division, we also have our Volatile Games division, focusing on mature titles, TruSim, which creates serious games, and Blitz Arcade, which specializes in downloadable short-session content.

As a studio that works mainly on commissioned titles, we wanted to do more to develop our own IP and further encourage creativity and imagination within the company. Blitz Arcade was founded in 2006 with a remit to develop and commission a wide portfolio of game genres, from hardcore shooters to casual puzzlers and everything in between -- and always of high quality and great replayability.

Alongside this new division, we established a greenlight chart within the company; the idea is that anyone can submit a game concept design and that these original designs are then voted on by everyone else who works for BGS. The most popular games can then be prototyped and either sold to publishers or self-funded to completion.

Droplitz -- which eventually debuted for Xbox Live Arcade, PSN, PC and iPhone in 2009 -- was one of the first designs to hit the greenlight chart. Crucially, the designer who came up with it also created a black and white prototype which proved invaluable in selling the idea. As simple as the game concept is, it was incredibly hard to explain it to anyone else. I'll come back to this...

What Went Right

1. Utilizing Staff

One of the biggest challenges for independent developers is fluctuating manpower requirements. Given that many commissioned games are released for the Thanksgiving and Christmas markets, that means that there are often people available in the autumn waiting for new games to be signed, and this can be a very costly time.

Most of your teams finish their projects at around the same time of the year (mid to late summer). Depending on the vagaries of pitch and contract-signing, that can mean that more than half the company has no immediate paid work; this is serious and can be a company killer, particularly for smaller independents.

One of the ideas behind our Arcade division was that it would develop small projects that could be worked on between larger paying projects, enhancing developer skills and increasing the utilization of our staff.

This was the approach that was applied to Droplitz for the majority of its development. To begin with, we had one and a half programmers working on the game. Then a graphics artist was able to help; then we lost the first programmer but gained three more. Then work stopped completely for a couple of months... and so on.

Clearly, this can only work for certain types of games -- particularly one in which you have control over the timeline and whose underlying concept is already proven. For reasons we'll come to -- and which some of you can probably already guess -- it would be incredibly hard to iterate and discover evolving gameplay with a fluctuating team.

That said, it's a great way of giving people something interesting and different to work on, and can also be an opportunity for them to learn new skills or polish existing ones, without the pressures of an external deadline such as a movie release or a holiday sales window.

2. Decentralized Development and "People Trump Process"

If you're at the time of year when some of your staff are coming off projects, then you're also at the time of year when most of your games are finishing, which means that you're going to be very thin on available managers. Such was the case with Droplitz for most of its development.

We therefore took stock of what we were attempting to create: a game that had proven fundamentals developed with frequently changing staff. We therefore chose a very Agile approach, focusing on the "People Trump Process" mantra.

What this meant is that we fully trusted the staff on the project to make the best decisions, and the only management that we employed was to agree on the next set of delivery dates.

Two negative outcomes might have been predicted from this very unstructured approach: the team members themselves could have argued constantly, achieving little other than bad blood; or perhaps even worse, they could have done everything possible to avoid conflict, resulting in a wholly vanilla game. In fact, neither of these happened.

The ever-changing team remained focused and fiery, relishing their freedom and absolutely passionate about the game, but also more than prepared to give and take to achieve the best possible outcomes. They were incredibly productive at this point, and content poured in at a rapid rate. People often stayed late to get the work that they had committed to done, but this was never any kind of death march.

Whether this experience was due to the particular individuals involved, or simply because they were all highly experienced developers with a deep understanding of the blend of commitment and compromise needed to create a great game remains to be seen. It's an experiment we're definitely keen to repeat, however!

3. Partnering with a Publisher

Once the game had reached a certain level of polish, we began approaching publishers. We were extremely fortunate to develop a partnership with Atlus U.S.A., Inc., who really bought into the project and showed great commitment and enthusiasm both to the game and its marketing.

In 2009, they showed Droplitz off at E3 and gained some great press coverage, and once they started mailing their fans, they were reaching tens of thousands of people with direct information on the game. There is no way that a small-scope game such as Droplitz would have been picked up so fast and reviewed by so many review sites without having Atlus on board.

4. Short Deadlines

Although we were very hands-off on the management of this project, there was one other trick regularly employed: to take very small baby steps when drawing up the next set of deliverables.

In all honesty, this was often simply a result of reacting to stakeholder requirements, but we also advocated the use of short, tight iterations so that the current team could pretty accurately work out how much they could bite off in the current cycle. If we hadn't had these tight iterations there would have more than likely been a lot of unnecessary drift during development -- something we definitely didn't need!

5. Greenlight Chart

When we first launched the Arcade Division we pretty soon established our internal greenlight chart. It was through this democratic approach that Droplitz appeared, along with the initial prototype that the designer (James Parker) had been working on.

Via the internal voting process, Droplitz immediately shot up the green-light chart to the number one spot, whereupon the company stakeholders agreed that this was a game we should start to develop internally.

The entire process here was very empowering for everyone involved. The fact that the game went to number one meant that a lot of people within the company were already fans of it, and would be willing to support it throughout development. By having such transparency it was also inspiring for people to see that their games can be realised at Blitz in a completely fair selection process, as we have proved with several others.

What Went Wrong

1. Utilizing Staff!

Even with a small game and a well thought out design that did not need iteration, having a fluid development team did have its share of problems. Artists, programmers, and designers moved on and off the project, frequently at very short notice, as the larger commissioned paid projects took priority and consequently the handovers were often not as well-managed as they could have been.

From a cost perspective the changing of hands and re-learning that frequently had to occur meant that the game took many more man-months to create than it would have done with a static team.

2. Decentralized Development!

The wonder that was decentralized development also provided its own set of issues. With this very empowered team focused on delivering the most bang for buck with every tight iteration, the last thing that people really wanted to do was hold off on delivering a feature and instead tidy up the code base. This approach worked, but only just, as the code is now creaking pretty badly from the amount of rapid hacks that were made to it.

By the end of the project, seemingly simple changes became bogged down in crufty legacy code; in many ways it was like going back in time to the early days of game development when this sort of thing was the norm -- and it wasn't any more enjoyable this time round...

3. "Politics Trumps People"

The flip side of empowering our fluid teams and adhering to the "People Trump Process" ideal is the almost equally famous saying: "Politics Trumps People". The game's requirements were very visible, and the team were fully aware of what was needed by when, but that still didn't mean we were impervious to external attacks.

During the course of development there was much catching of curveballs as the team had to change course to cope with changing requirements from stakeholders and platform providers. They did a sterling job at coping with this, but the politics definitely called the shots over everything else.

4. PC Version

Of the four versions of Droplitz that we developed, the PC version gave us the most trouble. Perhaps this was to be expected, since for the last several years BGS has focused mainly on console development. In many ways we were just not set up for PC development (although this has now changed).

In addition, as mentioned above, although Atlus gave us excellent QA support, we struggled with compatibility issues; audio in particular proved problematic with some sound cards bizarrely playing at double speed! Although we did our utmost to support the PC version, we're very aware that it was the least reliable of the formats and this is something we are improving for future projects.

5. Difficulty

It's tough to admit it, but we knew from the start that the game was perhaps too difficult. This goes back to the beginning of both this post mortem and the project itself; the prototype was crucial to getting the project greenlit because it was too hard to describe.

Is this a problem when trying to make the game successful in the marketplace? Yes, it can be; to put it another way, how do you successfully market a hardcore puzzler?

Here again, the way this project was developed comes to the fore; while the game progressed in short bursts -- and when people were available this meant amazingly high levels of commitment and morale -- it also meant that we could never schedule the time necessary to create a tutorial.

Many people pick Droplitz up and get it immediately, but conversely many face a huge block in understanding what's being asked of them, and panic in the face of those rapidly falling drops! Given our time again, we would definitely make it a priority to build in a tutorial or training level.

And We Learnt...

From Arcade's point of view, we learnt a heck of a lot from the development of Droplitz, not least that sometimes you can use the wisdom and creativity of your company's crowd to find a rough gem and turn it into a polished diamond with little overhead -- but a lot of enthusiasm!

When we go through this process again, we'll be a lot more prepared for the downsides and will definitely force ourselves to "tidy up" and document more as we go along. On balance though, the passion and commitment that the project generated, and the new practices we learnt, made it worth it 100 percent.

Developer: Blitz Arcade

Publisher: Atlus U.S.A., Inc.

Release Date: June 2009

Platform: Xbox Live Arcade; iPhone; PC (Steam); PSN

Number of Full-Time Developers: 3-8 depending on stage

Number of Contractors: None

Length of Development: 26 months (with large periods of inactivity)

Development Software: Visual Studio, Photoshop, Maya

Technology: BlitzTech middleware