GDC 2010: Design in Detail XV

Without anyone getting kicked in the face…

You always need to listen when people don’t like something. You are too close to the game; You probably already fixed all the things you didn’t like, so you should value a fresh perspective. Keep in mind that you can always trust someone’s emotional reactions, they are always authentic and valuable, but never just blindly take their advice. The designer’s job is to separate emotional feedback from thoughtful suggestions and treat the appropriately.

Before you can interpret someone’s feedback, you need to understand the source. Feedback means “the game in my head is different” and often times your response to feedback should be to probe about what kind of game they are imagining. You don’t necessarily need to agree on the game you are making to benefit from their feedback; they probably represent some portion of your audience.

You see Development Bias a lot with the public when the development process is very open. Playtesters know the game isn’t finished, they know you expect them to provide constructive criticism, so they become a lot more sensitive and more likely to complain. Once the game is on the shelves, those small problems fade into the background and players rarely notice them.

You also need to understand the source of feedback; If you can categorize someone’s play style, it will help you understand how to react to their feedback. You can weight their comments appropriately.
Here are some examples:
(The names have been changed to protect the guilty)

I used to balance “Easy” by playing with my nose (true story) but Steve still couldn’t beat it. I miss that guy, he was incredibly useful for balancing.

Even more important than categorizing other players, you need to understand your own playstyle. For instance, I’m a “role-player”, so I tend to ignore small balance problems if the results are still dramatic. I have to recruit “pros” that are more sensitive to useless or underpowered elements.

Up, Up and Away!

Against Eschatological Design

The last few months of a game’s development is a magical time.  Ideally, everything is coming together, the team is firing on all cylinders, and the experience is getting better by the hour.  Bugs are getting fixed, the build is more stable and performs better, the art is looking polished, and playtest results begin to climb to their highest levels right as the game is locked down.  The difference between those last precious moments of post-production, where everything is happening too fast to follow, and the months (often years) of glacially slow progress at the beginning of a project are so stark, they create the perception that a switch has been thrown, that the game has suddenly become fun.  The designer’s new-found power to affect change, and the positive feedback from the rest of the team, leads to a feeling of vindication and exhilaration.  Finally, all the hard work has paid off and the game has crossed the Fun Barrier.

It is tempting, after the flush of this experience, to look back on a game’s development as a power curve.  To retroactively smooth out the experience so it fits a nice mathematical progression, making the outcome of a fun game inevitable from the start.  To pretend as if the only unknown was if the game would cross the Fun Barrier before the project ran out of time or funding.  To ensure success on the next project by figuring out how to increase the exponent on the power curve, to work harder and add features faster, to run more playtests and balance earlier, so the game has time to reach the steep end of its exponential curve.

Up, Up and Away!

Fun = (Iterations * Time) ^Talent ?

The problem is that fun doesn’t really work that way.  A player experiences fun as a binary switch, either they are having fun at a given moment or they aren’t, like a square wave.  There’s no such thing as almost fun; an experience doesn’t gradually go from 90% enjoyable to 100% fun in a continuous curve.  A game gets better because it sustains a fun experience for longer stretches at a time, with less unfun gaps in between.

Worst Line Rider level ever

Fun = Fun * Polish ?

An experienced game designer is sensitive to very short, almost subliminal moments where a mechanic is actually fun.  Even in an early prototype phase, they can detect these snippets and predict with confidence which mechanics have potential and which ones don’t.  So, instead of finding ways to be more effective at polishing hopelessly dull gameplay, they can quickly abandon mechanics that never display those glimpses of greatness and focus exclusively on eliminating or minimizing the unfun gaps in those mechanics are already fun in spurts.  This is why exceptional designers tend to produce simpler, more reliably enjoyable games with fewer mechanics that feel almost effortless to play.  And why the vast majority of average games are released with an abundance of features, but subject players to hours of tedium or frustration as they labor to find fleeting moments of fun on their own.