Game designers really need to know a little bit about everything when applying their craft: algebra, archeology, architecture, creative writing, history, mythology, music theory, statistics — it’s far more than just knowing how to play games. Game designers also need a wide variety of skills: creative writing, technical writing, scripting, presenting, organization, teamwork. However, because game design is all about ensuring that a game is fun for other players, the most important skill of a game designer is the listening. Game designers’ initial thoughts about what will make their game fun to play are quite often wrong, and so it is critical to listen to the feedback from the play testers trying the game out during development.

Veteran game designer Greg Costikyan recently posted this on his Facebook page, and I thought it was well worth sharing.

“What is the most important skill for a game designer?” asked the interviewer.

I thought for a moment and said, “The ability to listen.”

“What do you mean by that?”

“You start, of course, with your own sense of aesthetics, your imagination, and your knowledge of game design patterns. But I remember talking over a design spec I’d written with our tech lead years ago, and he asked me ‘But how do we know this will be fun?’ I had to say ‘I guarantee that it will suck — at first.’ Problems always arise, your players don’t get it at first. Even if the basic design is sound, it’s highly unlikely you’re going to hit the target perfectly on the first attempt.”

“So where does listening come into that?”

“You have to listen — to your players, to your metrics, to your team members, to the financial and time constraints under which you operate. And you have to adjust, to iterate, to refine; to kill the things that aren’t working, to see where new things need to be added to provide balance and tradeoffs, to let go the features you’d love to have but that time and money don’t permit.”

“So… you just do what other people say?”

“No, no, no! Listening is not obedience. Much of the time you consider what people have to say — and ignore it. Or not ignore it; try to tease out what the actual problem is from the problem they perceive — quite often they are very different.”

“Can you give me an example?”

A moment for thought. “Yes. Years ago, I played quite a lot of an indie MMO called ‘A Tale in the Desert.’ It’s a crafting game, and what hooked me was that one of the first things I did was grow and harvest flax. That sounds dull, but it was enjoyable; you plant the seeds, the plants grow in stages, you must water and weed when the imagery tells you it’s time, and the flax plants themselves are beautiful, waving gently in the wind.

“Later on in the game, you spend a lot of time smelting ore. You’re staring at a kind of ugly smelter, adjusting sliders to keep some parameters within limits; fail, and you have to start over. You have to do this a lot, and it’s boring and repetitive and kind of horrible. On the forums, the players complained about it bitterly; they said that smelting ore took too long.”

“So?”

“So the developers listened, and they made the process quicker and easier.”

“Problem solved, then?”

“No, they hadn’t listened. The players SAID that it took too long, but that wasn’t the real problem. The real problem was that it wasn’t beautiful. Smelting ore needed to be as joyous as planting flax. Listening doesn’t mean doing what your players — or your boss, or your team-mates — say; it’s figuring out why they’re saying it, and what the real problem is. They solved the wrong problem.”

While designing your game, use the data your gather from surveys, interviews, metrics and observation to find out what your playtesters are saying about your game, and then analyze those results to determine the causes of the reactions you’re getting. Then go back and playtest a new version of the game that addresses those causes to find out if you listened carefully enough to what your playtesters said.