|

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.
(This post originally appeared on Above49)
|
I'm sure everyone would agree that a developer will have a skewered perspective on "readability" because they learn as the game is built from the ground up. But isn't it also a given that "readability" issues would not be ignored by the development team? Furthermore, isn't there is a fairly simple remedy for "readability" issues? I would think testing would do it if testing was done right.
This discussion reminds me of all the Street Fighter iteration previews I've read: the game is intuitive enough for newcomers to learn to play, but has enough of a learning curve and depth for veterans to enjoy. Isn't that already the goal of every developer? To have a game be intuitive and easy to learn (for the "casual") but hold enough depth for those who seek it (aka the "hardcore").
I'm sorry if I've missed the point of what you've written so far.
In my opinion, they're the only way to really expose all your readability problems. You can try not to do anything too crazy in the design process, but you'll always miss things. As you said, your perspective is irrevocably different from first-time players.
So don't trust yourself. Get a playtester. The playtester is always right.
As an aside, I don't think "easy to learn, hard to master" should be the gold standard for every game. Some complex games would suffer if they were made easier to learn (e.g. Dwarf Fortress) and we've all seen plenty of otherwise enjoyable games where an awkward attempt at gameplay longevity was bolted on to make it more "hardcore." Lots of games are fine w/ "easy to learn, hard to master," but I don't think that's tautological.
I realize that a lot of this is very handwave-y, but I'm going to be focusing on some concrete examples in an upcoming post. Thanks for your thoughts.
@Tynan You are always a step ahead, good sir. Post on my blog about exactly that went up this morning and it will be up here tomorrow. And indeed, the playtester is always right. Although they may be wrong about the problem ;)
@Luis Well designed puzzles should feel organic. Again, I'm not making a call for complete transparency, but for intentionality.
And, I guess instead of going for "east to learn, hard to master" the ideal should be "easy to enjoy, enjoyable to master."