Any feedback on the ideas I present in this article? I'm especially interested in the opinions of game developers, particularly the drawbacks associated with this kind of strategy
The drawback is that for many games the most exposure and sales is going to be when it's released, so you want to polish and perfect it as much as possible to maximize that.
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.
Exactly. I hate to drag Minecraft into this, but thanks to its multiplayer nature, the release strategy was perfect. The open alpha basically said “I know this game isn’t the greatest, but hey, it’s fun, and you guys can help me make it better”. Not to mention the classic “get a discount if you buy now” manoeuvre. But most games, especially with any kind of narrative, are easier and safer to release as a whole.
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.
With all due respect, this article is dead wrong. For several reasons.
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.
I am affraid you didn't get to explain why games have to be finished, debugged and polished on day 1 of release. There are many developers (indie) that have been disrupting the industry by exactly not doing that and I am pretty sure you have heard of Notch, as an example. Minecraft was full of bugs, sold millions, 0x10c, his next game doesn't even got an alpha release and there is already a community around it and many programs for the computer architecture that will be implemented in the game.
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.
8 comments
[ 0.22 ms ] story [ 26.9 ms ] threadI 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.
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.