The life of a software product is a continual stream of feature additions, enhancements, and even removals. But a great product doesn't (usually) outshine its competitors because of the sheer number of features, it's because those features are really useful or work well together. It's a difficult balance that requires a lot of iteration and experimentation.

For advice on tackling this difficult problem, you might try looking to Batman.

No, I'm not suggesting that the comic book character Batman is a great software developer (though he does have a knack for designing some seriously cool gadgets). I'm referring to Batman: Arkham Asylum, the recent video game developed by Rocksteady Studios and published by Eidos Interactive. What's interesting is that Batman is a game based upon a comic book - and it's good. Great, in fact, and it's a bit of an anomaly in the field.

Games based upon intellectual property such as movies or comic books have historically been bad games. With hard release date deadlines tied to a box office opening or other media release date, software development teams often end up rushing to complete development. Not all finish*, and those that do manage to finish development in time often feel rushed - uninspired gameplay, too short, not enough variation - or way too much variation without enough polish.

What made Batman: Arkham Asylum great was that the core aspect of the game - playing as Batman - felt polished, varied, and fun. The developers chose to find out what made Batman an interesting character, and then focused on building a game that emphasized his core strengths: stealth, combat, gadgets, and a rich history. It also meant the team had to decide what features to keep out of the game, such as a driving section.

In an interview with Gamasutra, game director Sefton Hill of Rocksteady describes the process of creating Batman: Arkham Asylum. I found it to be an interesting read, not just as a history of the Batman game, but also as an inspiring story about building a product. For example, I found this quote about deciding what features to develop very relevant to other software projects, not just games:

When it comes to features, they're always a very quantifiable thing. It's very easy to sit there and go, "Where are all these features?" Quality can be a little bit harder to quantify, especially at the start of the project when you're talking about, "How big is it going to be?" I think it's easier to say, "All these features are going to make it great," rather than, "We're going to have less features, but those features are going to be really good." It's harder to convince someone that that's going to be the case.

It's easy to see how people fall into the trap of having so many features. It's natural to equate features with quality, because that's all you've got to go on at the beginning of the project. I think what you need is confidence, and it can be hard. It's harder for publishers to give developers that confidence when you're in a catch-22 situation.

You don't want to overstretch. You want to do less, but do amazingly well, rather than do more and have a load of average stuff at the end of the day. There are too many games out there that deliver lots of average content.

 

* One game that never shipped was an adaptation of the movie "The Dark Knight", which suffered many technical and management challenges. The game missed the theatrical release of the film, then the DVD release five months later, and finally was cancelled when EA's ownership of the Batman license expired. Read more at Kotaku.