Making Lean Startup Tactics Work for Games
gamasutra.com
gamasutra.com
Agile development only works in very niche development circles. You couldn't write an AGILE operating system, for example (or rather, shouldn't). Similarly, writing an AGILE game is equivalent to setting sail for fail.
Consider this: a potential customer can purchase an older AAA title on steam for 5-10 bucks. They can purchase a brand new AA title for about 15 bucks. They can purchase an extremely polished indie title for 5-10 bucks. As a developer, what's your bottom line here?
Games HAVE to be finished, debugged, and polished on day 1 of release. AGILE development works for incremental software development, not for games. I don't think you realize how many one-man development teams out there release extremely polished and innovative indie titles and STILL don't make it on Steam (or other marketing platforms). There is absolutely no way a half-assed AGILE-released game will make it on the Apple Store, let alone Steam.
Furthermore, gamers in general are a cynical bunch. Release a bad/unfinished game, and you're done. To reiterate, I completely agree with the prototyping idea - i.e. hey this seems like a fun mechanic lets make a quick prototype - but not releasing the prototype to the public (unless we're talking open source projects here).
I think there's a difference between lean and agile development. Lean startup essentially means testing and learning from a basic prototype for everything that you do. New feature? Test it. New level? Test it. Agile development, to the best of my knowledge (I am not a programmer), is focused more on being adaptable and changing course quickly. Lean startup is focused more on using scientific method to determine decisions rather than indiscriminate opinions of the internal team. It includes agile development but is not agile for the sake of being fast.
I agree with your point that games HAVE to be finished on release. My counter to the prototype argument would be that you can launch the game as a MVG in an unbranded, low-fi way that wouldn't jeopardize your actual game's launch. Instead, you'd just have a crappy game that people would test, and then you'd kill it and launch the new game without any association to the test game at all.
The thinking that things can't change because they won't work without explanation is pretty weak, so I wouldn't make such bold claim that the article is dead wrong.
The minimum-viable is going to have to be a free game. It may be of demo length, and it is not supposed to monetize. The goal is simply to maximize early feedback and find your customers. If it's in the zone you're looking for, you can announce the big followup and aim for monetization. This path is taken by countless indies.
Gamers are not disappointed by bad games, they just ignore those and move on. They're disappointed if their expectations are already high. With free games, you can fail as many times as you like.
I think the strategy works better for games that are intended for longevity and re-playability, like free to play games and multiplayer games. If it's the type of game that people are only going to play through a couple times, then it doesn't really work.
Another thing is that it's easier to get all the bugs out for a single release than to have to QA again for every release(how much of an issue this is depends on the platform/type of game).
Also "controlling the experience" is a big deal. Many games are just not going to be good or worth playing until they are far into development and polished.
My counter to this argument would be that you can launch the game as a MVG in an unbranded, low-fi way that wouldn't jeopardize your actual game's launch. Instead, you'd just have a crappy game that people would test, and then you'd kill it and launch the new game without any association to the test game at all.
Still, I’d like to make a game with new levels released weekly as episodes in an ongoing narrative. Maybe after I gain some ground with my current project…stupid reality.