Thursday, March 6, 2014

Twenty Pixels can Kill You - 3/6/2014

There's a lesson I learned from a game that could have been very good. It was called Legend of Faerghail. Built along the lines of The Bard's Tale series, it had, as I remember, a good plot, good mechanics, and a reasonable degree of balance and variety. All in all, it should have been a fun game.

However, there was a decision made involving about twenty pixels that killed it.

In games of this style, most of the screen is taken up by informational displays. Lists of party members, active spells, a box for textual descriptions of areas, events and conversations. The remaining quarter to third of the screen is taken up by a first-person view of the world in which the player's party is traveling.

Both the Wizardry and Ultima series featured this view, and Bard's Tale capitalized on it quite well. But there was a subtle change when Legend of Faerghail picked it up. In that first-person view in the first three series, there was a bit of peripheral vision. Specifically, one could see the last few pixels of the walls on either side when in a dungeon. It didn't seem like much information until I tried playing Faerghail, which eliminated this peripheral vision.

Trying to map a dungeon became virtually impossible. Random monster encounters were generated randomly, and appeared based on a likelihood per keyclick (say, turning one's facing to the left by 90 degrees). The probability was high enough that in difficult dungeons, one was encountering monsters every three to five clicks.

After combat, the first thing the player would need to do was orient themselves, because mapping absolutely requires knowing which direction you are facing. Given the way things were set up, you were very likely to encounter another fight before you had completed the orientation process. Resulting in a game-breaking frustration, as much of it was oriented on exploring and completing some pretty good-sized dungeons.

So what was the lesson here? Interface. This was an otherwise good game killed by a seemingly minor decision in the design of the manner in which the player interacted with the game.

And I've seen it in software, hardware and general design over and over again since.

The iPod® didn't get popular because it let you play music easily anywhere you wanted to, it got popular because the interface was sufficiently intuitive for a sufficiently large number of people to find it comfortable right off the bat.

Very often, an otherwise useful device or system will fail not because it doesn't do what is needed, but because a less effective system is easier to use. This is the basic struggle that Linux faces, in its attempt to bridge the worlds of the user-friendly and the user-supportive.

And it's an important struggle. For a long time, the question was one of form over function. In other words, which was more important. Like many other A versus B arguments, the actual answer is one somewhere on a spectrum between the two named endpoints. If it doesn't do anything, then it really doesn't matter how pretty or easy-to-use it is (Art communicates, so it does do something, smartass). If it does something, but is impossible to use, what value could it have?

Finding that balance point, the point somewhere between the uselessly beautiful and the incomprehensibly effective, is the secret of good design, good craft, and the creation of successful systems of every kind.

Remember that the next time you're designing something. And read Steve Krug's Don't Make Me Think for an examination of this basic idea in terms of web design (it's an excellent book).


605

No comments:

Post a Comment