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?

A Commitment

Which brings us to today…

Faerie

So, let me introduce Faerie (a working title).  It’s still in the very early stages of development, but it’s had encouraging feedback so far from people who have seen it.

Goals

Theme

Art Style

Mechanics

Faerie began as a desire to make a game that my kids could play that still felt challenging to play as an adult.  Combining Bejewelled style scoring with geoSpark (App Store link) style action was the plan, although I’m happy to say the resulting mechanic is quite different now – including elements from Tetris, Whack-a-mole and Bejewelled.  This is perhaps the most sensitive area for me, so I’ll leave it at that.

So when’s it ready?

So, not quite the ‘Full’ Monty, but now you know what I’m working on, please bug me to get it done before my kids grow up!

Some days it’s hard to think of something to write about, and other days something just falls in your lap. Happily this week it was the latter. It all started with Miguel (as these things often do) – a.k.a. @mysterycoconut on Twitter – posting this article about connecting to an iDevice via telnet while running your App. Using this technique it becomes possible to rapidly tweak parameters on the fly or in fact do all sorts of crazy stuff.

Needless to say I jumped on this idea to aid in tuning my current game prototype. I’ve just reached the stage where rapid tweaking of variables is going to help focus and refine the game play. Miguel suggests hooking a Lua scripting engine into your code, but I thought it would be fun to create my own, plus most of my code is C++ (rather than Objective-C) and I’ve found binding Lua to C++ to be a fiddly process in the past.

The corresponding code for this article can be found here. Note that the DebugServer code comes from Miguel’s article, and the AsyncSocket code comes from here.   I’ve added a minimal amount to Miguel’s code to pass received commands on to the DebugUtils functions found in Debug.[h|mm]. I haven’t had time to create a complete sample project, but the code provided should drop into any existing code base with minimal fuss. If the coding style looks a little strange, you may want to also read this and this.

So, let’s start at the end and work backwards, which I often find to be an effective technique. When tuning a game we spend a lot of time tweaking variables and constants – maximum speed, rate of fire, gravity, item prices, animation durations etc. Wouldn’t it be nice to open up a telnet session to your App and enter a command like “gravity = -8”? Alternatively, maybe there’s a set pattern of enemies that causes a rare bug. Wouldn’t it be nice to enter a “SetupWeirdEnemyPattern” command for easy testing?

So, we have two common scenarios – tweaking a variable and executing a function that alters the game state in a slightly more involved way. The code below allows us to do this. Variables and functions can be “registered” and given a name, which we can then use to adjust values or execute functions via our telnet connection. To make it simple to pass in parameters to these functions, we pass in a set of text parameters using argc and argv, just like the main() function of a C++ program.

Let’s have a look at the public interface to this code:

typedef bool (*DebugCommandFunc)(int argc, char *argv[]);

namespace DebugUtils
{
    void Initialise();

    bool ProcessCommand(const char *command);

    bool RegisterCommand(const char *commandName, DebugCommandFunc commandFunc);

    bool RegisterVariable(const char *variableName, bool *var);
    bool RegisterVariable(const char *variableName, int *var);
    bool RegisterVariable(const char *variableName, float *var);
}

Not much there, is there? The guts of it is in the ProcessCommand() function, where we pass in a string, and magic happens. Or, to provide an example:

bool ResetGameCommand(int argc, char *argv[])
{
// Do stuff here to reset the game state
}

DebugUtils::RegisterCommand(“ResetGame”, ResetGameCommand);

And later, through a telnet connection, we enter “ResetGame”, which in turn calls:

DebugUtils::ProcessCommand(“ResetGame”);

And, just like magic, we reset the game state.

Or as another example, we could register a game variable, say…

DebugUtils::RegisterVariable(“gold”, &gameState.pileOfDubloons);

And then, through the telnet connection, we can tweak this value mid-game, by entering:

“gold = 10000”, or “gold *= 2.0”

I’ve intentionally kept this system as simple as possible, but there’s a lot of power here. It’s very simple to register variables or add short pieces of code that can be run as needed. Just a few examples – turning on debug drawing to see bounding boxes of physics objects, changing the value of gravity or a jump pack’s thrust, loading an arbitrary level, turning off collision detection – the sky’s the limit.

The key thing here is to let you spend as much time as possible refining and tuning your game, because as Jesse Schell describes in his excellent book The Art of Game Design: A book of lenses:

The Rule of the Loop: The more times you test and improve your design, the better your game will be.

In other words, by removing the code-compile-run stage from tuning our game, we can create a better game in less time. Hopefully this code, combined with Miguel’s will provide a simple way to help you refine and debug your game.  Happy tuning!

P.S. I was planning to include a description of how I used TDD (Test Driven Development), but figured this post was long enough. If it’s something you’re interested in though, leave a comment or drop me a note on Twitter (@GeorgeSealy) and I’ll put together an article.

P.P.S. Yes, there’s a few things that could be added to this code to make it even more useful. At the moment it’s not possible to pass a parameter that’s a string with spaces or new lines in it. To do this, you just extend the tokenizing code to respect quoted parameters like “This is a string”.

P.P.S. I’ve resisted the temptation to allow more complex calculations such as “percentComplete = 100 * itemsFound / totalItems”. Most of the time all you want to do is tweak values. If you need this much power, hook in Lua as Miguel suggests, don’t roll your own as it becomes increasingly difficult to maintain as a project matures.

P.P.P.S. I’ve also just realised one of the more useful things I’ve left out – if you just supply the name of a variable on its own, then the variable’s value should be either returned via telnet or printed out using NSLog or similar.  There’s nothing worse than finding the perfect value for something and then being unable to see what it is!

P.P.P.P.S. The observant amongst you may have noticed that the link to Jesse Schell’s book is an Amazon Affiliate link, meaning if you follow that link and subsequently purchase something I may get a small commission. I will only ever put such links to books that I have bought myself or at least read cover to cover and would recommend.

Perhaps I expect too much?

I was playing the demo of Torchlight the other day.  It’s a beautiful game – art and game play honed to near perfection.  So why after a couple of hours of playing did I feel hollow inside?  What was I doing?  Why?  Was this even fun?  I love this sort of game – I lost vast quantities of time to Diablo, and enjoyed it.

So what’s the difference here?  Here I was, avidly collecting loot, leveling up and so on, flying through enemies with happy abandon.  I think that ultimately that’s all there was to it.  Fight / loot / fight / loot.  Where was my motivation and back story?  Where was the momentary pause to plan my attacks before diving through a door to tackle the nasty boss monster?  Half the time I didn’t even register that I was fighting a boss until I was picking over his corpse.  What level was I on?  What made this one stand out from all the others?

I’ve felt this way before, playing Bunni Bunni, designed by Danc, who’s blog is an inspiration and well worth reading.  I found myself playing it to completion, but was left with nothing of value to take away from the experience.  It’s a carefully constructed task / reward structure, tuned to the point where conscious thought dissappears.  It’s akin to grind in MMO’s.  Don’t even get me started there.

When designing games, we talk about addiction as if it’s a good thing – the ultimate goal.  If that’s the best we can do, I need to find another hobby.  Fortunately, there’s still plenty of scope for story telling (Dragon Age), exploration (Small Worlds) and deep strategy (Galactic Civilisations II) and simple beauty (Braid, Aquaria).

I guess what I’m saying is that with a family and work, my spare moments playing games are precious to me.  Playing a game ‘just to fill in time’ is pointless.  I want to have an experience, one that I’ll reflect on later as worthwhile.  I really wanted to like Torchlight, but I just can’t.

Or is it just me?  Let me know what you think…