Acorn Heroes

Got skillz?

Any good software developer is always on the look out for new techniques or tools. But when was the last time you actively cultivated your social skills?

Does this sound unecessary? We’re coders after all, dealing with syntax and pixels, right? Well consider this. Our games are nothing until we’ve put them into the hands of our players. It’s a social contract we have with the players to offer them a fun and engaging experience.  And most importantly, if they don’t like it, you’re up the proverbial creek without a paddle.

If we’re going to make our game great, we need to see it’s effect on potential players. For the best results, we need to do it early and often to avoid wasting time on ideas and implementations that just aren’t good.

So, assuming you’re buying into this argument so far, the next step is to get some feedback from players. Giving and receiving feedback is very difficult to do well, and it’s a skill that continually needs to be trained and refined, alongside your other mad skillz.

Giving feedback

Giving feedback can be difficult – you need to let the game developer know what doesn’t work, but without leaving them whimpering in a corner when you’re done. The trick here is to think of a hamburger’s fluffy buns. The idea is that you wrap the “meat” of your concerns in between a nice couple of “fluffy” buns to soften the blow.

Example:
“Your game crashes all the time and is unplayable.”

Example:
” I like what you’ve done with the art style, and I can see a lot of promise in your game Mega Zombie Ninja Defense HD. However, I’m having trouble with the game quitting unexpectedly on me. It happens fairly regularly at the start of each level and is making it difficult to get into the game. I’m keen to get further into the game, please let me know if I can help in tracking down the problem.”

So, both of these comments say basically the same thing right? But which would you rather receive from a beta-tester? Here’s a few key points:

• The first example comes across as a personal attack on the developer, mainly through the use of the word “Your”. It’s the written equivalent of stabbing your finger at someone to make a point. The recipient of this comment immediately becomes defensive and unwilling to take on board your comments.
• Also in the first example, the phrases “all the time” and “is unplayable” are absolute (rather than subjective) statements about the game that may not be true. “Crashes all the time for me“ may be true, but can you really speak for all the other testers playing the game?
• In the second example, the initial compliment puts the developer in a receptive frame of mind, ready to listen to your concerns – establishing a dialogue. Talking about “the” game rather than “your” game makes for an objective discussion, rather than an emotional one.
• Expressing the problem in terms of “my experience” means you’re open to the possibility that it’s not the developer’s fault – perhaps you’ve updated to a new OS reveision that they haven’t had a chance to test yet, or perhaps you’re jailbroken phone running a Linux kernel may have something to do with the issues you’re having.
• You’ve knocked the guy down and given him a kick in the guts, telling him his code crashes (even if it’s true, it’s not nice to hear), so wrap up by saying something nice to pick him up off the ground again feeling positive about what needs to be done.

There’s more at stake here than just being all new age and caring. It’s about being able to get to the heart of a problem and fixing it. The fact that it can help build a stronger relationship with someone is just a nice side effect.

It is better to give than to receive

OK, so let’s say your the king of fluffy bins, and people love you as a beta tester because you give honest, helpful feedback. Now it’s your turn to send a build out to a handful of testers.  It’s hard.  You’re feeling a bit nervous – hoping they love the game, terrified that they won’t. And then you get this:

“Man this sucks, couldn’t you do any better?”

Ouch. What can you do? First off, try not to take it personally. You asked for peoples opinions, you have to be prepared to take the good with the bad. If people only offer praise, you’re game will suffer for it. Just watch American Idol some time if you don’t believe me. All those poor people who can’t sing to save themselves.  I can just imagine their well meaning family telling them “You’re fantastic, you can do anything you want to do”.

OK, so we’ve gotten over the initial shock of the feedback. Now it’s time to ask yourselves “Why did this person have such a bad experience?” There’s obviously a problem here, and you need to develop the skill to find out what’s going on. This is where the “Five Whys” technique comes into play. Let’s imagine how the conversation could go:

“Man this sucks, couldn’t you do any better?”

“Wow, I’m sorry it didn’t go so well for you, can you give me an idea of what went wrong?”

“I just couldn’t get into it.”

“Why was that, was it too hard? Did the controls make sense?”

“It was OK until I reached the first platform, I just couldn’t get up onto it.”

“Why was that, were you double jumping?”

“Double jumping? You can do that?”

“Yeah, just triple tap the player again after he’s jumped. Did you read the instructions at the beginning of the game?”

“Oh those, I kinda skipped through the last seven pages.”

“Fair enough, maybe I should look at shortening them down a bit. Triple tap may be a bit tricky too, I guess I could look at using a tap and hold or something. That shouldn’t take too long to fix. If I sent you a new build, would you give it another go?”

“Sure, sounds good”

Wonderful, a happy ending. With a little effort on our part, we’ve turned a flippant, unhelpful response into some valuable information:

• If a player can’t master double jumping, the game is unplayable.  Is it really that important a skill for our game?
• Triple tapping is a pain.
• Our “how to play” instructions are too long.
• Maybe we should put the first time the player is required to double jump further into the first level?
• Perhaps we can shorten the instructions and break them up into smaller chunks, delivered as needed rather than all at once?

All that from “Man this sucks, couldn’t you do any better?” . The idea of “five whys” is to strip away the superfluous and get at the heart of a problem.

Wrapping up

A bullet list to wrap up:

• Avoid being personal (using “you”), unless you’re talking about yourself (“I think”).
• Think of it as a puzzle to solve objectively.  The answer is there, you just need to develop the techniques to find it.
• “Never attribute to malice that which is adequately explained by stupidity.” A person who’s gone to the effort of offering criticism may have a valid problem they don’t know how to communicate.
• Your harshest criticism is also you’re greatest opportunity for improvement.
• Be wary of feedback from friends and family – avoid asking what they think – rather ask them for ways to help you improve and fix the game.

So, maybe there is something to being nice after all. Mastering the art of giving and receiving feedback may seem unimportant at first, but it’s one of the most valueable tools you have.

What do you think?