DAC and PCD

We just hosted the DAC conference here at the ITU and it was, as always, great to hang out with smart, interesting folks and get to chat and hear what they are up to. There are a lot of threads that came up during the conference and you can read various coverage via links at the conference wiki. I just want to mention one theme I have been hearing more and more about recently, something termed "player-centered design."

I suppose it is still because it is being formed that I can't give you any precise definition, but I have been struck by how often I hear the term these days. It seems that it can indicate everything from what I would consider more "market research" to fascinating work (like that by Olli Sotamaa and the gang in Finland) on using cultural probes(PDF link) for game design. While I am not a designer myself I am very interested in what techniques do get used (or can get used) for the ways they tell us something about the overall landscape of user/designer relations. Of course we have lots of beta-testing & QA feedback in MMOGs (and EQ now even seems to hold a regular guild summit in which devs meet up with well-established community members to talk about the game and its future), but is there a place for things like cultural probes, participatory design, user workshops, etc. in either developing new platforms or maintaining the existing ones? Maybe this question in some ways relates to Richard's previous entry about platforms for academic research - though I think not excluding commercial ventures is important. Is anyone (any company? any commercial enterprise?) integrating something roughly called "player-centered design" into their MMOG dev processes or is that wording the kind that makes the practicing designer cringe as it seems to undermine the artistic/auteur aspect of producing a game? Microsoft's Game User Research Group seems one of the most active in trying to get players integrated into the design process (although sometimes it isn't much more than basic UI stuff) so I wonder what might the future be for extending initiatives like that to MMOGs. And, just as critical at least from my point of view, does the structure of the development process (complete with publisher demands etc.) even allow for these kinds of more exploratory or nontraditional design methods? While there seems to be growing interest in the academic community on this approach, I am curious to hear what working practioners might make of it.

[As a small sidenote, this is my final TN author post as I am turning my attention to my pro-gaming research. I look forward to continuing to follow discussions from the readers seat however ;) ]

Comments

[Mike Sellers]

1.

Before I was in the games industry I was a user interface designer and user-centered design (UCD) consultant. Among other places, you can see my work on GE CT scanners, HP defibrillators (in airports and such), and even on touchscreens for some Xerox copiers. In many ways this was compelling work -- for example I designed the UI for the first 3D graphical display used by surgeons in the operating room (and the first time I got to see it being used was on a 5yo girl with a deep brain tumor that was inoperable without our navigational tools).

Oddly enough though, games are more compelling to me. I think this has to do with an essential difference between games and other forms of software: games have no external "task" associated with them. One of the main aspects of UCD is doing some form of "task analysis." You want to know who the users are (personas, etc.), what their environment is, who is making the buying decision, etc., but ultimately what's key is what is the user trying to get done. In typical software, you're trying to replicate, automate, or augment some externally existing set of tasks; rarely are you creating brand new tasks that don't refer to something existing outside the software. UCD can be a huge help in refining the development team's understanding of the users' psychology, culture, informational load, and how to make the tools you're creating best conform to their goals and tasks.

In games, we don't have this task-based foundation. A central (if typically amorphous) part of game design is figuring out what the player will be doing and why -- the scope of their goal/task set. Moreover, since the game has no external utility (it's not "good for something" in the outside world), and since no one is compelled to play a game, the tasks and the users' approach to them have to be inherently attractive and compelling -- what we typically roll together as "fun." If they're not, people won't play the game, and it fails as a product (contrast this with software tools or products that people use because they must, no matter how aggravating they are).

What this means to me is that game developers more than anyone else should be acutely aware of UCD principles and be applying them in game development. The trick there, again, is that you can't sit down and do a task analysis with a potential player; you have to first define the goals and tasks, and iteratively hone them until they are sufficiently approachable, engaging, and challenging. Traditional UCD methods aren't sufficient for this, but I believe they are a necessary component.

Unfortunately, I don't see UCD techniques being applied in game development much. Some places use end-of-the-line usability testing (EA used to call this "Kleenex testing"), and focus groups have been as misapplied in games as in any industry. But I see little emphasis on (or interest in) viewing the game as a set of goals, tasks, and tools that can be iteratively refined to create something fun. That seems to threaten being too clinical, too paint-by-numbers for most developers.

Years ago at SIGCHI Randy Pausch made the point that games often lead the way in UI development because they are so evolutionarily stressed: no one has to play your game and it doesn't really do anything for them, so it had better be good. If it's not, the players will move on to something else. This creates an environment that is highly competitive and often highly mutative -- and thus, highly evolutionary. In such an environment, it makes sense to me to bring all the tools to bear that you can to increase your chance of success. UCD -- or as TL has said it here, "Player-centered design" -- is IMO one of the strongest set of principles and methods that can be used to do this.

[Raph]

2.

You know, I haven't gotten the hang of this whole trackback thing yet, because I feel like I want to write giant responses on my blog, but then I wonder if they'll get left out of the conversation here. :) So, follow the link to get my fuller thoughts. (oh, and btw, can we change the links to my site on the sidebar there? They point to the old site).

But my real reason is to comment on Mike's reply... I agree as to the huge vaue of traditional UCD, but as you note, it's far from being the whole picture. I disagree with Randy Pausch, for example, that game UIs have really proven to be so spectacular; one only has to look at the near total rigidity in UIs in established genres to see that. So much of gameplay is playing the UI that players are reluctant to play a familiar game with a different control scheme, even though it might actually improve the game. Given MMO history, one could even argue that fresh creativity in UI design didn't really get embraced until it got taken away from designers altogether and put in the hands of players via UI modding. Talk about more player-centered...

The thing that UCD doesn't give you is "figuring out what the player will be doing and why -- the scope of their goal/task set" and yet, that's what the game industry seems to keep trying to apply crude player-centered design to.

[Dave]

3.

Wouldn't the ultimate UI be one that was entirely player created and modded? WoW, when modded with some amazingly well done addons, can have the perfect UI for you as an individual. While there are always complaints about what Blizzard has done, making the UI accessible to add-ons by design was brilliant.

They should certainly take better care to avoid breaking all add-ons with major patches, so there are lessons to be learned from them, but I don't think I could ever play a game of that type that DIDN'T let me have my own UI.

Of course you can't do this with every type of game, and yes, the basic UI has to be good, because not everyone is going to mod it. But the ultimate PCD is to let the players do it themselves. Then, as Blizz does, "steal" those mods by incorporating the favorites back into the core UI.

Would it be feasible to design the alpha and beta tests of most games to have a highly flexible, user configurable interface? Then use the most popular configurations in the final product? That is probably idealistic, but the concept is pretty compelling.

[Michael Chui]

4.

I don't know enough details or nuances of how graphical things work to say anything about it, but in textual, all you really need is an XML document as the message to the client about what you can see.

If you build a client that parses the XML and throws it up as a pretty useful thing...

[Olli Sotamaa]

5.

First of all, I want to thank TL for the nice words concerning our work. It is obvious that I find it fascinating but you can never be too sure if other people do.
Our approach (PDF link) is designed to shed light on the fuzzy-front-end of the design process. As our experience and the discussion here shows other kinds of methods have to be used in other phases of the process. Have to go now, I will continue once I have the time.