Agile Game Development
However you’re making your game, you’re doing it wrong.
In our young industry, that’s one simple fact: nobody’s figured out how to efficiently make successful games. Competition means that no one will ever have a perfect formula, either, but right now we’re just really, really inefficient when it comes to development. Huge architectures are built for features that never make it, while important features are hacked in at the last minute and at high cost. We spend tons of time polishing minor features, while our products ship with major flaws. Frequently we labor for weeks over something that actually makes the game less enjoyable. This is all just the tip of the iceberg.
Of course, if this were easy to solve, it’d be solved: these problems don’t exist because we’re stupid, but rather because the problems themselves are complicated, and resistant to quick fixes.
One solution people are trying to bring over from other parts of the software industry is agile development (often in the form of Scrum). Remember what I just said last paragraph, though: these problems are resistant to quick fixes. (Or remember what I said at the start: you’re doing it wrong.) I’ve talked with a lot of people trying out agile methodologies for their next game, and every single one of them has hit a lot of problems. Sometimes it just doesn’t seem suited to game development: we have too many teams, and they’re too interconnected, to use a method based around fluid, small-group, non-dependent work.
One of the best resources I’ve seen for working through these issues is the Agile Game Development Blog, run by Clinton Keith, the CTO at High Moon Studios. One thing you’ll notice if you spend any time reading the blog is that there are a lot of unsolved problems. Why don’t their metrics of development (”story points“) correlate to fun? Why are they still crunching near milestones? How do you even know how much work is remaining, when “done” isn’t even a known quantity?
All of those unsolved problems are a good sign: they’re the sign of an honest blog. Everyone trying agile in game development is going through some or all of the issues Clinton Keith discusses. As I read through the archives, I kept having realizations: “oh, that’s what you’re supposed to do there!” “Hey, I didn’t realize that’s what was going wrong.” “Yup, we had that problem too– comforting to know you haven’t solved it, either.” I highly recommend it.