Valve have done some interesting stuff around this: their patch for Half Life 2 Episode 1, to ease the difficulty of a particular section, came out of their stat-tracking on Steam. They’d tested the game and believed it to offer fair challenge; when they saw that a drop-off in play correspond to a high level of deaths on a particular map, they rebalanced the game in a patch. That’s very weblike thinking, but that’s a good thing. It improved the quality of the game for the end-user.
The communities in successful social software applications start at the developers and radiate outwards; there are few Web 2.0 properties which aren’t consistently cared for. Part of this is cutting down the time to live – single-command deployments, automated test suites, placing ownership for feature into dev’s hands. Part of this is learning to relax a little and forget the boxed product, the release date, in favour of the long-term relationship that you seek to establish with the user or player.
Of course, one has to be careful. The rules of a game are a contract between the player and the game, and changing them without the player’s knowledge could be considered unfair, or even harmful. It’s also worth considering at what point the game might have changed so much as to be unrecognisable. Breaking that contract with the player is a very, very bad thing to do, and you shouldn’t be using patches to do that. Also: consider that almost nobody reads release notes, or EULAs. Given that, what are appropriate changes, and what aren’t? What’s logical growth, and what’s radical rebalancing?
I’ve been thinking a lot about this section of the presentation since I first delivered it at NLGD, and I must admit, my perspective has changed somewhat, especially when it comes to contracts. This is perhaps the section where I convince myself the least – but I think there’s something in it, so I’m going to keep thinking on it and pursue it.