I’ve been reading Getting Real, a book about building web applications in the agile fashion that the guys at 37 Signals have done for Basecamp, Backpack, and other great apps. But while reading, I couldn’t help but come up with one central difference between building a video game and building a web app.
Web apps are permanent, games are ephemeral.
I play a game. I beat it. I’m done, and I’ll probably never play that game ever again, unless it’s my favorite game in the universe, or it has infinite replayability.
But I don’t ever finish using Gmail. It’s a utility, something that I use every day of my life, and will probably continue to use for a very long time.
Getting Real works for webapps, because it’s about delivering a limited feature set, launching early, fixing bugs as you go, and adding or subtracting features as users demand them. Which is kind of useless if a lot of your players have already finished your game by the time the first major update comes around.
Now, the difference I outlined does have some exceptions. Some games aren’t ephemeral. Online games are pretty permanent. Except they’re still different from webapps. The reason is that most online games are less fun if there are less people playing. Meanwhile, Backpack does not become much less useful if there are less people using it.
The feedback loops are different. I launch a webapp called WidgetFoo, and it has 1,000 users at launch because it doesn’t have all the shiny features people think they want. The application is pretty damn good at what it does, but it only does one thing. The users want another feature. I add that feature, but by the time it’s added… oops! There’s only 500 users. But these users tell their friends, about the cool new UI, and now we’re back up to 1,000 users with a better product and more word of mouth. The app will grow.
Meanwhile, I launch an online game called WidgetGame, and it has 1,000 users at launch because it doesn’t have all the shiny features people think they want. The core gameplay is there, and it’s good, but the users want more features. I add that feature, but by the time it’s added… oops! There’s only 500 players. And now they’re pretty pissed off because they lost half of the people they liked to play with. Which means the game is less fun, and more players will leave. It’s a positive feedback loop of doom.
Not sure where I’m going with this. I just wanted to point out a key difference. I’m still thinking of ways to use Getting Real in game development.
{ 5 comments }
I’ve come to respect replay value as a statement to the ultimate, long-lasting integrity of a brillaint game. Playing is replaying. So I don’t know about the production techniques the book was talking about, but if we want to get real with games, we need to design games that have a strong core loop and a high recombinance to content ratio. I played Baldur’s Gate, Myth and Alpha Centauri at least half a dozen times each; I believe games with a stronger core design are ultimately easier to produce, because feature creep and content balooning are less likely to creep in.
Your post echoed a statement that I made recently about what separates games from other software, while arguing with Darren about whether the rest of the software engineering world applies to games.
Games are different from other software because the burden of content in a game is on the developer. In the case of productivity software (wow, I sound so 1993) the software is a mechanism by which the user may create content. With GMail you create email, with Photoshop you create images, and with Microsoft Office you create macro viruses. This is why you use these applications over and over; your need for content is satisfied by your creation of the content.
Also, with GMail and email clients specifically, you frequently share in other users’ content, so increasing the rapid reusability of the application.
Now, games by contrast are a mechanism by which the user may experience content created by the developer. You could say that the user creates entertainment through his interactions with the developer’s content. Rarely can the user directly create content with a game (Excitebike!) and even in cases where the user creates his own content, the joy of discovery is lost.
The ways in which the world interacts with the player can be considered content. In this way, online games generally have such high replayability because of the constant contribution of the players. The other players interacting with the one player create new content for the player in the form of a new challenge.
This goes back to my original thesis about game design, that given equal development resources, more story tends toward less replayability. If you are playing a game primarily to advance the story, and the story is complete when the game is complete, there’s no reason to play again. By contrast, the games people play thousands of times are generally games without a story, especially those “casual” board and card games. You can study chess and bridge for new tactics and strategies, and thanks to the game mechanics and other players, the game will react in predictable and unpredictable ways. How virtuous a concept! We have set up narrative computer games as an adversary to players which never changes between playthroughs, never better and never worse. Is it any wonder you only feel the need to defeat it once?
Yea I say unto you, replayability is the product of your game’s initial playability (would the player want to even play it once?) and the flexibility of the game’s content (would it be different if the player started again?).
I think another difference between non-web games and web apps is the lack of any deployment or installation required.
The fact that you can jump on and play any web game just like that, without having to run installation, is quite an important consideration IMO. This is, of course, what makes web-based games quite attractive.
I also think that your comments apply not just to web apps, but to all apps in general. In fact, you seem to be drawing distinctions between apps and games. For example, Outlook is an app that I use every day, and same goes for AIM. However, I may ditch an AIM client for a while and go back to it if it’s improved (similar to your webapp example).
You need to check out http://www.agilegamedevelopment.com as it’s all about game development with agile methods. Highmoon studios has been using Agile mixed with SCRUM for a while and they’ve managed to be pretty successful.
Comments on this entry are closed.