Guest Post: Game Usability Lessons from Vanessa Saint-Pierre Delacroix & Her Nightmare

Introduction

My studio’s latest game, Vanessa Saint-Pierre Delacroix & Her Nightmare, recently earned a Best Design award in indiePub’s 3^rd Independent Game Developers Contest.  Our team believes that the graceful usability of Vanessa was a contributing factor to our success.  This brief article outlines some of the best practices from our development process.

Before diving into the lessons we learned, an explanation of our game is in order.  Vanessa Saint-Pierre Delacroix & Her Nightmare is a 2D puzzle and platform game mapped to a 3D cube.  In each level, players must guide the titular character to an exit.  In order to do so, they must use Vanessa’s ability to rotate any face of the cube she occupies.  In a way, Vanessa Saint-Pierre Delacroix & Her Nightmare borrows from the best parts of Super Mario Bros. and Rubik’s Cube.

[wp_youtube]twOBUIhi55k[/wp_youtube]

Why does Vanessa play so effortlessly?  I have identified three key components of the game’s design which I believe contribute to its usability.  They are: a subtractive approach, polished difficulty, and a focus on early testing.

A Subtractive Approach

In The Elements of Style, E. B. White writes, “A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.”  This philosophy applies to game design.  Vanessa works well in part due to the subtractive approach taken during development.  Any element out of place was cut.  Those that remained created a strong, central core for players to enjoy; they are unburdened by clutter.

For example, early versions of Vanessa included functionality for manually rotating the game’s camera.  By controlling the camera, players could adjust Vanessa’s puzzle cube to see each face.  As a result, our testers became fixated on trying to solve every puzzle before making any moves.  They grew frustrated, and for good reason: studying isn’t fun.  So, the manual camera was cut, forcing players to explore the cube in order to find a solution.  Exploration is far more satisfying than planning, and it better reflects the nature of our game.

Subtractive design provides developers with an added benefit: it simplifies a game’s controls.  As I write, an Xbox 360 gamepad sits in front of me.  It has thirteen buttons and three different ways of indicating direction.  Feel free to use as few of these options as possible when designing your games.  Your users will appreciate the ease with which your project operates.

Vanessa requires five buttons and one thumbstick – the bare minimum specified by the game’s mechanics.  Overwhelmingly, players have noted that Vanessa is an easy game to pick up and play.  A manual camera, weapons system, or any other unnecessary mechanic would have required more buttons, more training, and more cognitive resources.  In short, it would have been less usable.

Difficulty

Most players (and many developers) view difficulty as a linear path from easy to hard.  This model is incomplete, and incompatible with good design.  In general, difficulty should increase slowly at the beginning of a game, rise significantly once the mechanics have been established, and taper off towards the end (well before challenges become punishing).  Along the way, modest dips in difficulty should be included, to allow the player time to demonstrate their mastery of the system.

I recommend introducing new mechanics or challenges individually.  Give the player time to acclimate.  Vanessa Saint-Pierre Delacroix & Her Nightmare features thirty-six levels, and new mechanics are launched in levels 1, 2, 3, 7, 10, 12, 15, 19, and 26.  Notice how, after the initial tutorial levels (1-3) play out, there is increasingly ample space between additions to the game’s complexity.  In those levels, difficulty increases modestly, and occasionally drops.

Why should difficulty decrease every once in a while?  The idea is simple: games should be fun.   Once players have figured out how a mechanic works, they need opportunities to revel in their mastery of the system.  So, if your game is about destroying vampires, introduce your player to a single vampire, then force them to battle two vampires at once, then three.  After that, let them go to town on a single vampire again.  After the challenge of defeating three bloodsuckers at once, the slight reprieve will be a welcome break for the player.  Likewise, the player will compare and contrast their first encounter with a single vampire to their most recent encounter.  How will they measure up?  A good designer will want their players to feel satisfied and empowered, not unfairly punished.

Of course, what works on paper rarely works in practice.  There is no substitute for thorough testing.  Developers should listen carefully to feedback from players, and – here’s the kicker – suppress their egos.  When someone criticizes your work, it’s easy to dismiss that point of view as uninformed, incomplete, or just plain wrong.  But by protecting your ego and clinging to your own opinions, you may be dismissing information that could improve your game.

Developer as Tester

I firmly believe that a game’s developer should be its first and best tester.  During production, no one will play your game more than you will.  This has both advantages and disadvantages.  On the one hand, you will become intimately familiar with every facet of your game.  On the other hand, you may fall into testing patterns or become comfortable with certain idiosyncrasies.  Remember, just because you know the critical path through a level doesn’t mean you should take it every time.  Be thorough, and make every effort to break your game.

I never release a game for testing unless I have exhausted my bug list.  If I can no longer find errors, then I need more people looking for them.  After submitting the Beta version of Vanessa to indiePub’s 3^rd Independent Game Developers Contest, only one critical bug surfaced: in some countries, decimals are stored as commas instead of periods.  This formatting issue prevented some foreign gamers from fully enjoying our game.  The bug itself was easy to fix, but it demonstrates the need to conduct deep and thorough tests of your game.

Final Notes

If you are unfamiliar with interface design, I highly recommend studying Jakob Nielsen’s Ten Usability Heuristics, available from his website, useit.com.   These ten practical suggestions will help ensure that your game offers a more satisfying experience for players.  For example, Nielsen suggests that “every extra unit of information… competes with the relevant units of information and diminishes their relative visibility.”  For this reason, Vanessa’s in-game interface consists of only the most important information: a level number, the number of rotations the player has triggered, and the amount of time that has elapsed since the level began.

Conclusion

The ideas expressed in this article worked for Vanessa.  However, every game is different, and independent developers should never cling too tightly to a single design philosophy.  However, by carefully considering these concepts, you are bound to think more critically about your own games, and arrive at an approach that best suits the project at hand.

David J. Sushil is a professor of Game and Simulation Programming at DeVry University.  He is also the owner of Bad Pilcrow, an independent game studio in Orlando, Florida.  His most recent game, Vanessa Saint-Pierre Delacroix & Her Nightmare, was awarded Best Design in indiePub’s 3rd Independent Game Developers Competition.