Internal Indies

Established game dev studios could learn a thing or two from the indie revolution. Here's how one studio set up its own internal "indie" group (from Game Developer's May issue).

Someone far more clever than me once said, "Creative endeavors are abandoned, not finished." Anyone who has worked on a large game knows that game development can often be filled with both conflict and compromise. I've worked on my share of commissioned games, and I know that these projects are tough. Big games are expensive to make, and that raises the already high stakes for everyone involved -- which, in turn, makes everyone involved far more risk-averse. Were the stakes substantially lower, most devs would want to take on more creatively ambitious projects, with no boundaries or restrictions getting in the way of making what we want to make.

In other words, we'd want to be indies -- but without the terrifying risk of failure. So, six months ago, I asked this question: Are there lessons from indie development that can be utilized in a larger, established studio setting? In order to answer this question, we set out a simple studio experiment. We changed our contracts of employment, invited five of the most senior developers to form a new team, and gave that team complete creative freedom.

Changing the Contract

The first step was a relatively small but significant change to our contracts, so that people could develop their own projects in their own time and retain the IP themselves -- that is, own their own game designs. Our aim was to free our staff to be more creative and for both them and the company to potentially profit from that. The reason many companies seek to control their developers' IP is an understandable fear that some of them will go on to make great games and leave the studio to pursue their own projects full time -- and in fact, this has already happened to some degree to us.

Allow me to let you in on a little secret: If you work for a reasonably large-sized studio, there will be people who are working on cool stuff on their own time whether their contracts allow it or not, because people who make games are inherently creative. They can't stop themselves. We just formalized this and turned it into a positive.

We found that this risk is worth it; when developers feel like they own their work, they feel more creative and more motivated to develop new skills. For example, one of the programmers on our team learned new shader techniques on his own time, while another learned a lot about Facebook integration through developing their own game. Our current game directly benefited from the new skills and knowledge gained through outside-of-work creativity, as will future games developed by the team.

Building a New Team

By chance, a small number of our most senior developers had finished their company projects and had around eight weeks before their next projects began. As in many studios, people between projects are often asked to undertake research into various areas, and this group had been tasked with learning more about the mobile market. They decided to do this in a more practical, hands-on sense than the company had initially envisioned -- that is, they wanted to make a game to prove out the issues about which they were learning. Because they were some of our most senior devs and we trusted their abilities, we gave them free rein to make a game in that eight weeks. They repaid this trust with a completed game, Kumo Lumo, which has since been published by Chillingo and received over one million downloads just 10 days after launch.

The Goals for Kumo Lumo

This team was very commercially minded during the whole process; they not only wanted to make a game that had its own voice and personality, but also create something that would help us understand the mobile market much better. They also wanted to learn as many practical lessons about the process as possible.