This is one of those high level rules that applies across a wide range of topics. It has application in everything from how you approach your user-interface, to your attitudes towards options screens and even as far reaching as API design. The basic premise is that developers often hide their inability to make the smart choice by delegating that choice to the user. Spend the time and the effort to make the smart choice so that your users don’t have to and your product will be significantly stronger as a result.

Credit

I have to credit this wonderful insight to the chapter Avoid Preferences in 37 Signal’s awesome book Getting Real. The whole book is worth (several) readings, and I can’t recommend it enough.

Preferences

Some developers pride themselves on all the customization options they offer their players. They let them adjust everything from graphical quality to which key combination fires a particular action. Who is better qualified to make these decisions? You or the player? Generally speaking, you have the skills and ability to make better decisions about player preferences than they can make themselves, so instead of delegating the choice to the player, make the right decision so that they don’t have to. I’m not against exposing the ability to let the player override this default choice, but your goal as a developer is to create the game your players want to play, not the game they need to customize to enjoy.

Case 1: Controls

Look inversion in First Person Shooters is a topic as divisive as some of today’s hottest political issues. Up until very recently, a game would make a decision, either inverted or not inverted, and (hopefully), players would be forced to dig through a bunch of settings to if their personal preference did not match that of the developer.

Recently though, several FPSes, like Bungie’s Halo for example, have started using gameplay to determine your inversion preferences. During the first few seconds of play, the game asks you to look at an object in the world. Based on how you interact with the controls to achieve this objective, the game makes assumptions about your control preferences. It even gives you the opportunity to correct it if it guesses wrong. Is that better than forcing your player to spend the important first few seconds of your game digging through menus to find a look inversion setting? Immersion wins when your players aren’t reminded that they are simply playing a game.

Case 2: Playback Quality

I am as guilty of this than any other veteran Flash developer out there. In a graphically intensive Flash game it is very tempting to give the player the opportunity to play the game in low quality rendering mode in order to squeeze maximum performance out of the Flash Player. If you think about it, that is completely unforgivable. Using a timer and some basic computations, we can make some quick estimates about the hardware capabilities of player’s machine and make the right decision far more accurately than the player. How are they supposed to know if they want 3 levels of parallax instead of just 1? The reality is we’re hard pressed for time so we opt for the easy choice rather than the right choice. In a future article I will tackle a utility class that will handle this computation on our behalf so that we don’t have any excuse to do this again.

Preference Trumps

Sound Muting

Every good rule has its exceptions. An important trump to the preferences aspect of this rule, in regards to Flash games, relates specifically to sound. There are certain standards that have been established in Flash game design, and typically these are around for good reason. When it comes to muting sound and music in Flash games, we have to understand the context, which why this rule is more of a “Best Practice” than it is a real trumping exception. Flash games weren’t popularized by people who traditionally play PC and console games. Flash games were popularized by people who were supposed to be working or otherwise being productive on their computer. People want to play your Flash game without being fired. If they can’t turn off the music and sound in your game with the click of a button at any instant, chances are they’re not going to be able to enjoy your game that much, if they even play it at all.

As I discovered in a recent game release, it is not sufficient to bury this capability in an options menu. On any screen where there is music or sound playing, you must give the player the ability to quickly and effortlessly turn off any and all sounds with a single action.

Follow Ups

Next up we will be discussing how this rule applies to user interface design, and then we will wrap it up with how this rule can make your API easier to use.