Improving Readability: Data

I claimed in last week's post about empathy that you should never listen to your players. To better illustrate what I mean, you should watch this talk about spaghetti sauce. Unlike all those other boring talks about spaghetti sauce that you've seen, this one is by Malcolm Gladwell at TED. I have no hesitation in saying this is the best pasta-related talk I've ever seen. Seriously, go watch it, I'll wait.




There are two excellent points being made in Gladwell's discussion of Howard Moskowitz's experimentation. The first comes early, in Moskowitz's observation that the search for the perfect Pepsi should have really been the search for the perfect Pepsis. There isn't necessarily a perfectly satisfactory recipe (read: design) that will suit everyone. If something isn't working, finding the median isn't necessarily the right solution. Diverge towards two alternatives and satisfy two groups instead of serving everyone poorly.

Gladwell's second point demonstrates why you should never listen to your players. In the search for the perfect spaghetti sauce, Moskowitz tested countless varieties, none of which the market showed any indication of wanting. He was rigorous and thorough in his evaluation. Game design should demonstrate the exact same rigor.

Mike Ambinder, a Ph.D. cognitive psychologist at Valve, gave a fantastic talk at GDC about applying clinical research methodologies to create better games. He opened with the claim that game design is a hypothesis and playtesting is an experiment. Essentially, he said that evaluating game design ought to be treated like a science. This is exactly what Moskowitz did to find Prego's troika of ideal spaghetti sauces.

Leigh mentioned this on our podcast, saying some developers will treat unfavourable playtest results by saying "Those playtests were dumb and just didn't get it." Then they'll repeat until they find playtesters that provide satisfactory results. Essentially, they're looking for data that supports the hypothesis they want and disregarding any contradictory evidence. This is, of course, the worst kind of bad science. It's actually worse that not testing at all, where there may still be some doubt about the design's validity.

As I discussed in the last post, the development team is too close to the project to evaluate it objectively. Data-based analysis is vital because it provides objectivity our knowledge of the game intrinsically precludes.

While this may seem obvious, it's pretty clear that some studios lack dedication to this kind of evaluation. To be fair, few have Valve's unending wellspring of money and time that makes it much easier to perform these experiments.

Finally, when I say you should never listen to your players, I'm being superfluous (but not by much). Playtesters probably shouldn't be gagged on entering the building. Playtester surveys and post-hoc discussions are an important part of playtesting. But they're good for identifying problems, not solutions.

Watching what they do is more important than what they say. And when even successful game designers can be dead wrong about what a game is missing, the value of a random player's proposed solutions should be obvious.



In an attempt to keep this post from becoming truly colossal, I'll defer to links to provide some excellent examples of how to perform this kind of data-driven analysis. Mike Darga, a designer at Cryptic Studios, has been running a truly outstanding series about exactly this. And it's great to see we're on the same page about the importance of this practice.

This weekend I'll finish the culmination of this series and finally provide some tangible examples of my own. I'll be discussing how the adventure genre ate itself and how I believe readability issues contributed significantly to this tragic autocannibalism.

GDAotM Article for April Posted

I resisted temptation to goth-out and write about the design advantages of short horror games. Instead, I discussed different ways of looking at the content reuse that is necessitated by most short games. In retrospect, it's a little scattered, but hopefully there's still some good bits in there.

If you're interested, I believe Sande is still accepting proposals for future monthly topics and blog submissions (or both if you're ambitious). Next month's topic is trend toward simpler games, which coincidentally lines up with the readability yammering I've been doing (and will continue to do).

Improving Readability: Empathy

Last week, I claimed that game readability can be improved with increased emphasis on empathy and data. I'll be discussing the importance of the former first, but there's quite a bit of overlap between the two.

I neglected to offer a solid definition of readability previously, so I will correct that now before we progress. Consider readability to be a measure of the player's understanding of what outcomes are possible and how they can affect those outcomes. Basically, the inputs and outputs of the game's systems. We can distinguish this on both a micro, minute-to-minute level and a macro, long term level, but it's the case that problems in one often affect the other.

To be clear, readability is a quality, not a value judgment. Some games are intentionally quite complex and unclear. Internalizing the game's systems is the primary source of satisfaction (and even they can often improve upon some unintended obfuscation). But when the readability of a game is diminished, it needs to be deliberately and with great care, which is rarely the case.

This is related to the concept of visibility that Donald Norman discusses in The Design of Everyday Things. The distinction in the interactions Norman presents are almost never explorative in nature. The object in question provides a specific function (or set of functions) and it is the designer's responsibility to communicate these things as clearly as possible, i.e. "If you want to achieve X, do Y." Readability in games more takes the form of, "If you do X, Y will happen. If you instead do A, B will happen." Visibility is about objectives, readability is about decisions.



Finally circling back, what does readability have to do with empathy? Creating a readable game system requires empathy for the player, namely the acknowledgement that your perspective as a designer is completely and irreconcilably different from the players. Readability is about the speed and accuracy at which the player can internalize the game's systems. For the designers, and just about anyone else involved with the project, some amount of this knowledge is already present. This makes their perspective on the game's readability completely inaccurate.

Empathy means acknowledging this truth, which is not isolated solely to games. Anyone involved in any sort of interaction design is simply too close to what is being designed to evaluate it objectively. Having one year of experience or twenty does not change this fact (although ideally a veteran designer has come to grips with this). In my life before games, I worked at a mobile media startup and saw this error made time and time again, to disastrous effect.

Bill Moggridge wrote a fantastic book called Designing Interactions, where he compiles essays from dozens of interaction designers. Suffice to say, it begins with Doug Englebart discussing the invention of the mouse and goes from there. It's very interesting reading for anyone interested in how good interactions are created, and game designers should count themselves amongst that group.

One commonality between most of the book's contributors is the importance of empathy for the user. Time and time again, the designers interviewed discussed how essential a user-centric approach was. Keeping the user's perspective consistently in mind and evaluating possible solutions are the building blocks of creating excellent interactions.

The evaluation part is as important as empathy, and that's the data bit I discussed prior. I'll be addressing this next, and explain what it's important to never listen to your users.

The Importance of Readability in Games

Several folks have been talking about The Design of Everyday Things in the context of games, and this excites me tremendously. I am a big fan of Norman's book, as evidenced, but what I'm really excited about is what interest in this book represents. I believe there is a growing interest in improving the usability in games, and more importantly, improving their readability.

Why does this matter? I believe that one of the most interesting aspects of games is the interactive system that emerges from the collaboration of the game's individual mechanics and dynamics. This is a characteristic unique to games (at least amongst activities we engage with for enjoyment) and perhaps the most emblematic of games' potential for true artistry. But there is an inseparable peril here as well, namely that being able to understanding the system is at least partially a precondition to enjoying it. E.g. there is a lot of time that needs put in before Dwarf Fortress becomes truly enjoyable.

This is a bigger problem than many people think.

Since their inception, games have been trending toward richer simulations, greater graphical fidelity, more varied interactions and more consequential decisions. But it seems a peak was reached and recently there has been a bit of pushback, calls for reducing complexity and making games simpler. I think this is really an acknowledgment, perhaps subconsciously, that we're becoming more aware of the readability issues in our games. By reducing the elements at play in our systems, we can expedite the player's internalization of a system's behaviours.

Certain studios are incredible systematic in their approach to readability and it shows. Oft-touted, but for good reason, Valve has demonstrated how much they value creating games that are as readable as possible. I asked my fiancée to give Portal a try, even though she basically never plays first-person games. Her tastes skew towards social games, be they intrinsically so (The Sims, Animal Crossing) or merely circumstantially (Mario Kart, Mario Party, Rock Band). I was curious how she would engage with Portal. The gameplay style wasn't particularly to her taste, and she found the controls a little wonky. But once the control issue was ameliorated, she was able to quickly parse and solve the puzzles, even though the game's interactions were almost totally foreign to her. Listening to the developer's commentary, in coordination with reflecting on Randy Smith's GDC talk, it's clear this is no coincidence. It's the result of a dedicated and thorough process that behoove most developers to emulate as appropriate.


Making these complex systems readable is important, and not just because it might save the world. Players need to understand all the inputs and all the outputs to make interesting, informed decisions. These are the mechanisms through which we express our will in the game. This is the machinery that transforms our medium from passive to interactive. It's what makes games interesting and might well be what makes them art.

This is a multifaceted (and as far as I'm aware, relatively unexplored) issue, but we can begin making inroads. Making games more readable begins with two things- empathy and data.

I'm going to discuss both in the next few posts, culminating with thoughts on how poor readability contribute to the adventure game genre more or less eating itself. I hope this will be of interest and, as always, I welcome your thoughts.

A Pod Was Cast

Michael Abbott was kind enough to invite me onto his post-GDC wrap-up podcast. There are four different segments with various guests and mine was in the company of Leigh Alexander and David Carlton. I was greatly esteemed to be amongst such company, and it was fascinating hearing what non-developers found engaging about GDC. The other segments have guests easily as interesting and on the off-chance you're not reading Michael's site, correct that immediately.

One thing we touched on briefly was classic Lucasarts-esque adventure games. I may sound a little down on them, but (as I tried to clarify) these are some of my favourite games ever. I'll post about this in more detail soon, but the short version is I'd like to see adventure games move from the domain of the patient and persistant to something far more folks can enjoy. More on that soon.

Perspective Bias: Zeno Clash (Tactics)

This isn't really a complaint, but one of the ... challenges of GDC is that there is simply so much to see and do. I spent the majority of my time in talks and panels (deciding which of those to attend was work enough), which meant I didn't have much time to check out the IGF Pavilion. I was only able to sneak down there with Steve just before a session on Wednesday, where we checked out Mightier and Zeno Clash. I had already decided Mightier was awesome, with its interaction between the physical world and the game world, but was less sure about Zeno Clash.

I'd seen the trailers, etc. for Zeno Clash and while its non-traditional fantasy art direction was very interesting, I didn't have much interest beyond that. I'd becoming increasingly soured on melee-based first-person games (I think Dark Messiah was the guiltiest culprit of late), and with such a small team, I was a bit skeptical that Zeno Clash could manage all the complexities of creating a compelling first-person game while making the melee combat enjoyable.

My concerns were alleviated by a single five-second screen that appears before combat starts.

Before each combat, there's a "Versus" match-up screen that shows the player and their opponents. Here's an older screenshot; in the GDC version the colouring made the match-up even more explicit. It's basically the kind of match-up screen you'd expect in a 2D fighter. I hadn't seen this before and it really was one of those lightswitch moments. I got what Zeno Clash was and wasn't attempting to do.

The problem was that I had made some assumptions about Zeno Clash there were wholly incorrect. I had assumed it was a traditional first-person action game, that focused on melee with lighter ranged combat (with crazy weapon at that, a la the fish gun). I expected fully fleshed out environments, perhaps linear, maybe more open world. But Zeno Clash isn't that game and it's not trying to be that game. It appears that the entirety of the game is the first-person arena combat.

In short, I thought they were making Final Fantasy VI, but they were really making Final Fantasy Tactics. It's a series of connected, but independent, combat encounters. That single versus screen immediately shifted my expectations. By focusing exclusively on arena combat (and the standout art direction), Ace Team can make those parts of the game sing. Some of them were actually at the booth discussing it. I asked one of them (maybe Andres?) about the FF Tactics similarity and he immediately and enthusiastically acknowledged it.




Of course, this is speculative, since Zeno Clash is not available for about another month. But I've never had my perception of a game altered so dramatically in such a short time. I think many games struggle to convey their aesthetic goals (which is a broader topic for another day). It's interesting and worth study that Zeno Clash has managed to convey this, at least to me, with just a single screen that isn't even interactive. I went from ambivalent about a melee-based first-person action game to very excited about a first-person arena combat game.

Plus, if exploding rats are really a weapon in Zeno Clash, I'm sold.