 |
|
|
| |
Blitz Games' Swan On Decentralized Development's Double-Edged Sword
by Staff [PC, Console/PC]
|
|
| |
|
January 6, 2010
|
| |
Droplitz was one of UK independent studio Blitz Games' biggest efforts yet to cultivate its own IP, and the Xbox Live title was greenlit thanks to a "crucial" black and white prototype, says the studio's Chris Swan, explaining the development journey in a new Gamasutra feature postmortem.
One process element that worked in Droplitz's favor was a decentralized development structure built on the concept that "people trump process". The game's staff was thin on available managers thanks to the time of year and other projects, so Blitz chose an agile approach:
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.
But this approach had disadvantages, Swan says -- with so many people moving on and off of projects at short notice, Droplitz took longer than usual. Decentralized development had its own 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...
You can now read further detail in the full Droplitz postmortem at Gamasutra.
|
| |
|
|
