Blog - Design Tips: Criticism has subtext

Sunday, March 9, 2008

I'm working on compiling a list for myself of game design tips, techniques and truisms that I've picked up over the past few years.
It is to help codify the ideas not only in my own mind, but also so that when I teach at Emagination again, I can present a more prepared lecture or two on game design.
I gave a game design lecture recently for SCAD's game development club and realized that I need to internalize some of these concepts more in my head, as I had only moderate success pulling them out while winging-it mid-presentation.

Also, this quarter I've made far more games than I ever have before, so I've been able to see a lot of these ideas go from abstract lecture content to real application before my eyes.
So, it's been on my mind lately anyway.



One that just came up, though, is one I've been taught on dealing with play testers, receiving feedback or critique of iterations on your game.
The advice is this: When someone complains about something wrong with your game, find out what they're really asking for. Or as I put it in the title above: criticism has subtext.

For example, a tester might only say "I think there should be more explosions!" but explosions themselves might not be what they actually need. They could, as just an example, actually be looking for the game to give them more feedback from their actions. Their brain skipped a step, however, and suggested an explosion would work to that end, but 1.) if handled improperly, not knowing what the suggestion was really for, it could just as likely remain ineffective, 2.) Something else could provide the same level of feedback, or more, and in a way that's easier to produce than their recommendation.


This design nugget-o'-truth popped into my head because I was just the instigator of this very same problem only a few minutes ago.


A friend was having me test his game, and I complained that it needed a bit of time after the menu screen but before the enemies started pouring in upon loading the game. I felt that I wasn't getting enough time to get my bearings yet before being immediately killed some of the times that I loaded up the game.

After a while it hit me what was wrong and I had to call him back before he ran off to implement some sort of timer feature.
The problem I was having wasn't necessarily a time based problem. I realized it was due to a difference in control systems between the menu screen and the game itself:
The menu was controlled entirely by the mouse, and the game entirely with key presses.

So, when the game loaded, every time I had to look down to find my arrow keys so I could move my hand there from the mouse. In that time where I was groping for the arrow keys, I'd often get blasted.

Of course, a timer could help too, but the key-groping was the bigger culprit and one that I didn't even notice until after quite a lot of play testing. The designer hadn't apparently thought of the problem either.


So yes, listen to what your play testers have to say, but then search for what they're REALLY trying to say, but couldn't find the right words.
Especially when you have the game design training/vocabulary and they do not.

Labels: ,

posted by Brian Shurtleff @ 8:15 PM  0 Comments Links to this post