Saturday 18 January 2014

Indies: One Reason Why Something So Small Can Be So Impressive

Over the last 18 months I've worked almost exclusively with four-man indie developers, following on from a couple of projects put on hold at larger studios. These last two games have also happened to be two of the most successful projects I've had the good fortune to be involved with. Right now I'm working on new projects with middle-size teams, but nothing on the scale of those earlier disappointments.

Indies have tough competition these days, and they respond to it in roughly two different ways. 'First wave' indie studios like Klei, ThatGameCompany and Croteam, established around a decade ago, often chose to expand their staff and produce more work. It served them well, and remains a popular route. Increasingly, though, micro-teams and one-man bands are choosing to stay that way. In addition to Facepalm and Subset, the likes of Jonathan Blow and 2DBoy have also shunned growth in their development teams. Why?

It is probably terribly obvious to point out that a significant advantage small teams have over the big guys is radically lower costs. Who isn't all too familiar already with the path many a critically successful developer has taken from bedroom coding, to fancy offices and a staff of 40, to a crucial project being canned and there not being enough cash in the jar to keep up the payments? But I think there is another angle on the idea that is perhaps more expressive.

Suppose you're a one-man band. You've turned to indie development because mainstream games don't do it for you. You've accepted the product you're putting out is not an Assassin's Creed. You know that if income were a primary concern you wouldn't be doing this; indeed you've sacrificed some level of guaranteed income precisely to pursue this course. You'd like to get the game done ASAP, but because this is a labour of love, and because overrunning 6 months will jeopardise nothing more than your living standard, you're prepared to work on it until it's right. When you hit a creative decision in your game, the only thing you really need to weigh is what is best for the quality of the game you want to make.

Now compare with the pressures that even a team of ten put on development. A six month delay now costs you or your financier £150,000 in salaries alone, or around 25,000 full-price sales of The Swapper. Failure to meet the bills costs you and your staff your livelihoods, and kills your game. A staff also costs you the luxury of doing everything in the right order. You can't afford to have salaried staff sitting there twiddling their thumbs. If you have to build the levels before you write the story, it's too late to do anything else. Finally, when you come to that creative decision, you've got all the above on your mind. This is something I have to remind myself of when I go into meetings with larger teams sometimes. I get to waltz in, push my creative agenda, and (usually) have a guarantee of a reasonable payment at the end, as well as a new job. I have suggested that small indie devs share this advantage to some degree. But if you're at the head of a medium-size studio, each creative decision can make or break your entire business. It's easy, from this perspective, to see why those studios sometimes err on the side of safety.

Of course, there is some level of generalisation here. It is not my intention to suggest small teams suffer no financial burdens, nor that larger teams are incapable of pursuing creative ideals. Rather, I want to celebrate that we're here at a time when developers can choose the path that suites them, and make it work either way.

Me, I like a bit of both.

2 comments:

  1. Any war stories?

    I once had a 2 month to and fro with a marketing department that will remain nameless over whether or not our central character could be disabled. They eventually consented on the condition that he receive bionic legs instead.

    ReplyDelete
  2. In their defence, I see why what I wanted would terrify most marketing departments in the business.

    ReplyDelete