When your profession empowers you to design literally just about anything, it’s easy to rationalize just about any game design decision. Hell, I somehow managed to rationalize that our new power up for Tilt to Live have a screeching hawk sound effect. Bad idea? You’ll have to wait and see.
When Adam and I are working on design details for how a particular system or game mechanic will work, we bring a lot of assumptions to the table of how we think people think. And those assumptions are sometimes rooted pretty deeply so it’s hard to get on the same page. What do we do then? We get into an all out brawl. Ok, not really. We usually turn to our ‘beta testing’ group to do some observation of how they play and react to our design decisions. Our group isn’t very expansive at the moment as most of them are local friends so we can bring them in and have them play our latest builds. Keep in mind I use the term ‘tester’ for anyone that seriously runs the game through it’s paces and those that play it really quickly to see how the game works. Now all this is the easy part. You have a conflict or issue figuring out some detail of a design you go to play testing to try to gather some data. Simply enough. If you aren’t doing at least this, then you’re crazy awesome at game design and you should stop reading. Now. Really.
Doing it honestly.
Like I said before, it’s easy to rationalize any creative decision. It sometimes becomes even easier to rationalize a creative decision in the light of data. “See? He did notice that you can only have pick up at a time active!” or “See? He didn’t even notice the limitations of the pick ups because he just runs through them blindly!” You have to try to stay objective as possible. You have to try to get in the shoes of the player and see what they see. Ideally, they are talking to you the entire time as they play giving you verification that your hypothesis is either incorrect or correct. Having worked on a single project a long time, the decisions you make on it almost take on a personal weight. When you find that your idea doesn’t work, you can take it personally if you’re not careful. This can become dangerous not just for your own mental well being, but testers/friends can pick up on it and not tell you what you need to hear.
One tip I found helpful in reading my data and separating myself from my idea is: Don’t think of why your idea will work. Think of why your idea won’t work. It can be seen as a negative way of going about things, but only listing the positive doesn’t help you analyze your decisions. You become blinded by the ‘happy path’ of when your idea is executed inside a narrow scenario, ignoring a sometimes large problem in the shadows. Uncovering the weaknesses in your design is far more telling than a huge list of positives. Save the positives for the “back of the box” :).
Doing it early.
One of the things that still gets me today is trying to send out builds of our game as early as possible. I always keep saying “just one more day and I’ll have feature X completed or bug Y squashed”. I have to remind myself that our testers aren’t our ‘true’ audience. Yes we want to make them happy and have fun. But better to have your helping hands tell you your game idea is utter crap than to find out it is utter crap 3 weeks after release. This one can be rather painful because you’re fully aware of all the gaping flaws in the code, art, and mechanics and you don’t want to show your work in an incomplete state. Not to mention, it’s hard to explain to your testers why the player sprite is flickering about as if it’s having a seizure whenever they press ‘jump’. Well do it anyway. And get use to it.
We’ve been getting better at this through all the game mode additions we’ve been doing to TTL. With our latest mode, Frostbite, we’ve had play testers in very early in the iteration of the game mechanic phase. They’ve seen the game grow and each step of the way have provided extremely good feedback on helping us balance the game. The actual game mode wasn’t even fully functional when we started playtesting. So what did we get out of it? We focused on the feel of the movement, controls, enemy placement. All minor things that I would spend tedious time tweaking on my own. With each new iteration we tell themwhat was new in that build and have the testers focus on it instead of being overwhelmed by “play this whole game mode and tell me what you think.” One thing to keep in mind is beta testers are there for feedback. Try not to let it turn into a ‘designed-by-committee’ ordeal. Or maybe you want to…but I’m a control freak so that’ll never happen ;).
Doing it often.
This can be a double edged sword. From my limited experience, testers can sometimes be seen as a limited, nonrenewable resource. You may have a completely different group of testers by the end of the project than when you started. I had this idea of being gung-ho about testing early so I would send out weekly builds to everyone very early in the development process. The problem? Tester fatigue. When the deltas between versions is very minimal, testers may not be interested in a weekly build. As a result, I spaced out the test builds in early development to be a little more rare so that testers had time to recover and were excited to give a new build a try. As release day got closer, this feedback loop shortened as we approached daily, sometimes hourly test buids.
In the end, no matter how you approach getting feedback for your game, it is almost always is beneficial to your game.
This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.