27th November 2011
On the importance of feedback
Advert
Recently I received this comment from a play-tester:
That should be producing coins when I bump it and it's not - so that's a bug.
The object here is actually a stagecoach, in a humourous game where you play as a highwayman.
The thing is, for it to give out coins at every collision was game-breaking;
it was very easy to bump a lot in a short space of time, and collect the coins later.
I had added code which gave it a gradually replenishing pool of coins.
Gameplay feedback
My immediate reaction was that this was 'not a bug, but a feature'.
However, on reflection, I now consider that this was a bug - just not a programming bug.
We could call this a didactic ('teaching') or expectation bug.
The behaviour of the interaction was not what the player expected -
and in general casual players will interpret this as a fault with the game, not
their understanding.
So am I saying that this misunderstanding is the player's fault? No, absolutely not.
The empty stagecoach already had a visible indicator (the door changed colour) and played
a different sound effect on collision. But both were rather more subtle signals than originally
intended - the visual change wasn't particularly noticeable in practice, and music added later
in development masked the bump sound.
I propose that the most important part of any game is feedback.
It is how feedback is delivered which makes a game enjoyable. In most action
games this will in general be very straightforward - there should be immediate,
clear and obvious information given on every event.
It is certainly true that it can be desirable to withhold information from the player
for many reasons - to hold some sort of mystery, for 'fog of war', or simply to hide the
calculation mechanism so that players must learn the dynamics through play.
However, for casual, free-access games on the internet, players have invested virtually
nothing in the game, and are very quick to abandon it for the next. This is partly down
to the prevalance of broken and buggy games, but it's just something to live with if
that's how we're releasing games.
Hidden information is more important either for long, 'once through' story based games
(i.e. role-playing games), or when many plays are intended for skill to develop
(hard-core games, particularly action games).
Furthermore, in some more procedurally generated games there can be things happening all
the time, independently from the player. Whether these are relevant or merely distracting
can depend on many factors, including proximity, frequency, whether anything can be
done about it and so on. These boil down to whether it matters to the player, or
game-play significance.
I think the rule to derive from this is clear.
Emphasise every game-play significant event in your game from the very start, in a blatant
way if possible.
Conversely, try not to bug your player with irrelevant details, or
have common events upstage more important, rare and useful information.
If you do want to use hidden variables, refrain from doing so until the player is familiar with the basic game. - And perhaps counter-intuitively, when you do so, emphasise the fact that the player is receiving incomplete information.
For the example I gave above, the empty stagecoach now produces moths
when bumped, and the sound effect has been replaced by a louder and more sustained one.
I am now confident that while players may not immediately understand the hidden details
of what's going on, they will at least know that the effect is intentional.
Serendipitously, getting a load of moths to fly out is hilarious.
Advert
Comments