Getting the measure of your players

So much of game design is about second guessing the player. To create an element of surprise in a game, you need to know what the player is expecting, and what they’re not expecting.

Setting the difficulty levels involves estimating how well a novice player will cope with your game’s challenges, and how fast they will master your controls. It can be hard to separate the rational game planning part of your brain from your own experience playing the game.

You’re far from a typical player when you’ve been working on a game for months, regularly playing it through to test it, or just marvel at what you’ve built (go on, admit it – you do that too!).

One of the strengths of the app model is that it makes it easy to measure how real players use your game. You can instrument your code so that you can identify which sections of the program the player spends most time in.

Because the devices are connected, you can collect this information and use it to refine your game.

Clearly, that’s not an excuse for making a mess of your launch. You need to test your game thoroughly before launch, to make sure it is both bug-free, and playable.

You need to get the difficulty levels right, make sure that people understand how to play the game, and make sure that it doesn’t throw up any errors, even when players do things they’re not supposed to (which is what players always do, eventually).

But you can use the information you get to refine your game, and challenge the assumptions you made when first developing it. What is it acceptable to refine?

There’s good support from players for updated app versions, but I think it’s difficult to justify changing the initial levels or adding features that dramatically change the gameplay of those levels, because that changes the game into a completely different game.

Those who have struggled through a difficult level will feel cheated if you introduce a super blaster weapon that makes it a breeze. (This is one reason it’s essential that you do your testing before launch.)

You can learn, though, which features of the game people like most, and offer more of those in downloadable content or in updated versions of the app.

I remember back in the 80s, a friend had a Commodore which had an amazing loading screen with a playable game on it.

While the cassette whirred and the main game loaded in squeaks and squawks, this mini game kept the player entertained and warmed them up, like a support act at a gig.

Many people actually preferred this mini game, and stopped the tape so they could play it indefinitely. Are you sure you know which parts of your game people like the most and come back to? If you have a puzzle game with different challenges or play modes, do you know which ones people return to most often?

Instrumentation can also help to diagnose potential problems with the app. It’s more of a safety net than a recommended way to manage quality control, but if there are problems with an app, it’s good if you know about it early and avoid being reliant on people complaining to find out about it.

When your app runs across lots of different hardware platforms, you can also use instrumentation to measure the performance of the app on different devices.

This is going to be increasingly important because there is a huge amount of fragmentation in the mobile devices market, and developers increasingly want to develop one app and have it run on multiple devices.

If you do plan to use instrumentation, it’s important to make sure it’s not intrusive: it’s about measuring your game, not spying on its players. You should ensure that any data gathering is fully disclosed and that users have opted in to it.

If you’re creating apps for distribution through the Intel AppUp developer program, you can find documentation on instrumenting your apps here.

This blog post is written by Softtalkmobile, and is sponsored by the Intel AppUp developer program, a single channel for distributing apps to multiple devices, multiple operating systems, and multiple app stores.

You can find documentation on instrumenting your apps here.