Sun, 13 Feb 2005
What makes a game successful
Just a quick comment on this New York Times article about World of Warcraft.
"It's the difference between an immersive experience and a mechanical diversion," Mr. Metzen said. "You might spend hundreds of hours playing a game like this, and why would you keep coming back? Is it just for the next magic helmet? Is it just to kill the next dragon?
"It has to be the story. We want you to care about these places and things so that, in addition to the adrenaline and the rewards of addictive gameplay, you have an emotional investment in the world. And that's what makes a great game."
This is wrong, wrong, wrong. Absolutely wrong. I'm astonished that a representative of a game company as successful as Blizzard could even say something like this. The thing that keeps people coming back to a game like that is the other people. Period. The only killer app in the history of computer technology is human communication. I was an early player of MUDs, way back when. The games themselves were utterly primitive, text based adventures with simple combat rules. But they were addictive and enthralling because I was interacting with people all over the country. I wasn't a sixteen year old twerp; I was Kamikaze the mighty thief. I earned respect based on my actions in the game, not on who I was in real life.
And, from everything I've heard about the current generation of MMORPGs (massively multiplayer online role playing games), social interaction is still the main attraction. Friends use it for hanging out together. Others use the game as a way of establishing an in-game reputation that they could never achieve in real life. It's not about the story that the game creators write. It's about the story that the players are creating together, the community that they are building. And any game creator that doesn't understand that will get frustrated by why the players aren't doing their uber cool puzzle area. Things never change; wizards on the MUD I used to play on would complain endlessly about the stupid players who wouldn't explore their areas. They didn't get it. It's about delivering to your players what they want. And they want opportunities to create their own story, not play yours.
posted at: 22:28 by Eric Nehrlich | path: /rants/socialsoftware | permanent link to this entry | Comment on livejournal
Experimentation Matters, by Stefan Thomke
I'm not sure where I originally heard about this book, but given my preference for rapid prototyping in my work, I thought it would be interesting. Thomke is a Harvard Business School professor who's spent the last ten years studying how experimentation is integrated into and leveraged by organizations. This book is his attempt to explain "why experimentation is so critical to innovation, underscores the impact of new technologies, and outlines what managers must do to integrate them successfully."
This is a book that's difficult for me to review, mostly because so much of what Thomke espouses is just common sense to me. Unfortunately, much of the business world does not see it that way, so books like this and Serious Play are necessary to make the case for rapid prototyping.
Thomke identifies the main business benefit of experimentation as being cost savings. By experimenting more early, unfruitful approaches can be discarded, and resources can be shifted to more successful methods. It is a matter of managing uncertainty, from "technical uncertainty", where it's unclear whether something is possible, to "production uncertainty", where it's unclear whether it's scalable, to "need uncertainty", where it's unclear what the customer desires, to "market uncertainty", as described by The Innovator's Dilemma. The earlier a company can test its assumptions about these various areas of uncertainty, the better.
One of the key culture shifts that Thomke identifies as being crucial to integrating experimentation into a company's processes is the need to reward failure. When an experiment fails, it should be recognized as just as much of an accomplishment as an experiment succeeding. Both cases provide information to the company on what will and will not work. The only true mistake in an experimentation culture is performing an experiment that provides no new information, due to poor experiment design. However, most companies punish employees whose experiments fail, thus creating an environment where employees waste months writing reports and justifying their position before actually trying an experiment to get an answer. A company that rewarded failure would get answers and find its way onto the correct track faster, as I suggest in Trust but Verify post.
Thomke breaks the experimentation process into four steps: Design, Build, Run, and Analyze. He suggests that the organizations that will be the most successful are the ones that can most rapidly perform this process iteratively. Thomas Edison apparently optimized his laboratory to maximize the number of experiments that could be run, to the point of having machine shops and storerooms located next to the actual laboratory, so that scientists could quickly get what they needed.
With the advent of ever more powerful simulation and design tools, Thomke believes that companies should be testing more than ever before. He uses the example of a BMW safety design team. By studying some early prototype crashes, "engineers on the team had learned that in crash after crash, a small section of the B pillar folded." (p.34) Aha! The engineers decided to add metal to the pillar to strengthen it. Done. Move on.
"One development team member, however, insisted on verification, pointing out that it would be neither difficult nor expensive to do this via computer simulation. When the program was run, the group was shocked to discover that strengthening the folded area actually decreased crashworthiness... reinforcing the lower part of the B pillar made the part higher up - above the reinforced part - prone to buckling... the solution to the folding-B-pillar problem turned out to be completely counterintuitive: Weaken it rather than reinforce it."
This is a case where simulation, and trying things out, led the design team to a wholly new solution, one which they would never have considered trying. With today's tools, it is often faster to build a prototype and try something than it is to discuss the feasibility of something.
I liked Thomke's discussion of how a company's processes have to change to accommodate experimentation. Beyond the ideas already mentioned (experiment early, experiment often), Thomke identifies three "Realities" that impede companies:
- Technologies are limited by the processes and people that use them.
- Organizational interfaces can get in the way of experimentation.
- Technologies change faster than behavior.
I particularly like #3. This is a common theme in my thoughts (although it doesn't really show up in my blog, oddly enough). I believe that technology determinism, the idea that technology will drive social change, is naive. Technology is only used when it can be embedded into people's already existing behavior. A company can install Lotus Notes, which theoretically enables all sorts of collaboration possibilities, and what happens? Everybody ends up just using it for email. Until there is a need to be filled, technology is just a doorstop. However, when there is a need, technology will be warped and twisted to fill that need, no matter how inadequate the technology is (this is the story of social software).
His last chapter is an exploration of the idea that companies should move "the locus of experimentation" to the customer by providing the customer with the tools necessary to do their own product development. In the normal model, the company goes to great expense to determine what customer needs are via market research, identifies the largest volume needs (because their centralized production process can only serve the lowest common denominator), and serves those customers. Thomke points out the problem with this model:
"Customers with low-volume needs have little choice but to go elsewhere... The missed opportunity, however, is that there are thousands or perhaps hundreds of thousands of potential customers out there whose cumulative volume needs for custom [work is] significant."
It's the "long tail" of customers showing up in yet another form, customers that are only accessible by throwing open the tools of production, and letting customers do what they will. Again, my social software rant demonstrates my affection for this idea.
Lots of good stuff here. Again, I think most of this stuff is pretty obvious, but it's good to get the backing of a Harvard Business School prof. It's also good, because he's done the case studies and the literature research necessary to support my bald assertions (things like providing the references to the importance of feedback in learning (p.126 note 20), that making changes late in the product development process can be 100 times more costly than early (p. 197 note 4), and that trying to maximize the capacity of a scarce resource in an organization often leads to bottlenecks for everybody (p. 236 note 2) - this is the swapping problem in computers, but it's more broadly applicable). I'm not sure I'd bother recommending this book if you already believe in rapid prototyping and experimentation, but if you have a recalcitrant MBA boss, I'd recommend this over Serious Play as a book to help change their minds.
posted at: 20:45 by Eric Nehrlich | path: /books/nonfiction/management | permanent link to this entry | Comment on livejournal
