Getting Player Feedback: Reactions vs Comments

As a game designer, I always keep in mind that I create games not for myself, but for others. What I enjoy most is the process itself, the development. But the end product? That's for everyone else!

Keeping that in mind, I always allow myself to be open to feedback from players. The only way I can create the best experiences for people to enjoy, is to hear from them what they want. But what I've discovered is that people tend to not tell you what they really want, well not directly, anyway.

Game balancing is one of the most important, and rewarding, parts of my job. This is the process of making small (and sometimes large) adjustments to gameplay elements to tweak the game's difficulty and ease-of-use. This process is not possible without outside feedback obtained by allowing people to play the game.

There are a couple different ways that I have participated in which to receive and process this information:

• Gameplay Survey: players play through a section of the game (most often a demo or vertical slice of the game) and complete a follow-up questionnaire.

• Usability Test: Having a player play the game while the designer (and other developers) observe. In my experience, the play session is recorded and then watched later. This is usually followed by a brief interview with the player to get their thoughts and comments.

These are two very effective means of getting feedback from your game. In my experience, one has proven to be more useful to me, as a Game Designer than the other. I personally, much prefer the second option: the Usability Test, and I'll explain why.

There are outside factors that can alter a person's responses; someone may not answer truthfully because of a fear of being embarrassed, or being perceived as "dumb". This is most common when asking people if they found the game was too difficult. I've observed play sessions where a player is stuck at point and is visibly frustrated, yet during the post-session interview, when asked if they were ever stuck or had any trouble, the person answers: "Nope. I had no trouble at all!"

Because I was able to watch the player as they were playing, I was able to see the part in which they actually did get stuck (and this was seen repeatedly across multiple test sessions with different players), I was able to identify a potential problem with the design and could think about ways to improve it. The part in question was a specific puzzle that did give the player enough information to logically deduce a solution, trial and error became the only effective method to solve it. Thanks to the information from the play sessions, I was able to identify and fix a problem before release.

Game balancing and testing is a very important part of the design process that must not be overlooked. My experience has taught me that by letting people play your game and by watching how they play, you can learn more about how your game plays than by simply asking them: "So, how was it?"

As with all disciplines of development, a game designer must remain diligent, focused and proactive.