|
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.
|
1. "agile" without the requisite programming practices falls on its face. Scrum may be an easier sell, due to it's hands-off approach on the development side of things, but nearly all Scrum teams I have worked with reach a point where the code isn't keeping up with the rate of evolution
2. Some of the staffing issues could have been helped with pair programming, with one person in the pair being an "anchor" who has worked on a couple of iterations prior. That way, most staffing changes are relatively smooth, and you can do this kind of "cross-country race" style of programmers hand-offs quite successfully.
3. In iterative projects, ruthless refactoring is absolutely key. Keeping complexity (measurable with open source tool pmccabe) and duplication (measurable with open source tool CPD, part of PMD) are crtitical. Having other safety nets such as compiler warnings and PC-Lint can also be a huge boon to make sure your refactorings haven't introduced a bug.
I got Droplitz on PSN, and while it is difficult, is still enjoyable. The most disappointing aspect for me was the lack of 1080p and lossless audio. Critter Crunch, Braid, and several other PSN games have delivered on those HD gaming capabilities, and now I've come to expect it. For instance, I love the PixelJunk games and their 1080p @ 60hz graphics, but prefer some of the other titles that have those native HD graphics *and* 24-bit lossless audio.
I'm looking forward to your next offering!
I've been involved in development of dozens of XBLA games for 5 years in a row before quitting this oversaturated dead platform where 12+ month release cycles are inevitable due to lame waterfall acceptance process and a title will be easily thrown onto halo 3 release time frame. I respect the patience of developers who are still brave enough to waste their time on anything where a platform holder fucks up their minds with naming, usability and other tcr/trc guidelines.
Online and social games are a way to go. They free the mind of game designers, allow iterational development, immediate feedback cycles and free form of monetization.
tldr: go online, use flash.
Make a Flash version of your game first, iterate with millions of players, get instant feedback and produce a full-featured monetized version.
Publishers? Meh, no thanks.
Your resident Gamasutra online evangelizer (or troll).
You wrote:
"agile" without the requisite programming practices falls on its face. Scrum may be an easier sell, due to it's hands-off approach on the development side of things, but nearly all Scrum teams I have worked with reach a point where the code isn't keeping up with the rate of evolution.
Good insights, but I'd like to add a few things.
I haven't seen it "fall on it's face", but it does highlight the need for writing better tested code and associated practices to keep the "continual improvements" going. This applies to art and design practices as well. How well the team keeps improving "how" they make the game will stall without addressing discipline practices. Scrum is an easier sell because of it's hands-off approach to programming specific practices, which makes it ideal for game development since we have so many non-programmers.
Cheers,
Clint
You'll have a game ready and understandable by players having spent a very little budget. Then it's a matter of porting, which is a straightforward technical process where every approach from ad-hoc to planned works. I remember we've ported and released couple of games to XBLA within 3 month non-stop crunches and it was really worth it.
@Clinton and @Matt I'm pretty much in agreement with your comments. At the beginning we took stock of the fact that the project had pretty well known requirements and minimal technical risk, which is why the people-powered approach made sense. We *did* pull it off, but had there been a bit more scope to the game we would have been forced into a big refactoring session to tidy up the code and some of the art assets. Pair-programming would no doubt have helped at times, but there were lengthy periods where we only had one programmer on the project!
Personally I think a lot of issues with pretty much any methodology come down to how you define 'done'. Is a programming task done once the specific task/story is up and running in-game? Or is it only done when it has then been completely tested and refactored? (This applies to art & audio assets too). For Droplitz we definitely opted for the former definition as we raced to get as many features & as much polish into the game as possible.
@Mike Many thanks, and I hadn’t heard of the term Paizogogy before – I’ll have to read up on that one :-)