Case Study #3: ZiGGURAT

I had coffee with a friend several months after we released our debut game ZiGGURAT. His website had spoken favorably of the game, though, as my friend admitted, he "didn't really get it." I asked him to open the game on his iPhone and show it to me. He complied. "Give me your best performance." There it was: He was just tapping his finger all over the screen. "I can't see the guys," he said. "My finger gets all over the screen."

Of course, he'd skipped through the (merciful, exceptionally brief) tutorial. So I showed him how to play: Slide your finger along the bottom of the screen. Touch the middle, and the character standing on top of the pyramid points straight up. Touch the right, and the character points down and to the right. Touch the left, and the character points down and to the left. This way, you can slide to aim your shot.

Some reviewers had said the game was "Just like Missile Command." These reviewers had probably never played Missile Command. (Note: I love Missile Command.) "The game would be better with buttons," another review had said. Not that I cared about those reviews; EDGE gave us a 9 out of 10, so whatever. The whole point of ZiGGURAT had been to make a game that was for touchscreens.

In ZiGGURAT, you hold your finger on the screen to charge a bullet. The bigger the bullet, the straighter and faster it flies. Bullets grow and shrink as they charge. You'll have to deeply understand the feel of the charge timing to get the parabola you want.

We designed eight unique enemy types (many of whom are constantly jumping up and down) to keep the parabolas maddeningly varied and thus interesting. And the enemies' heads are growing and shrinking at a rate that's just different enough from your gun-charge speed to defy muscle memory: The bigger the enemy head, the bigger the bullet, the bigger the explosion, the bigger the chain reaction, the longer you stay alive, the higher your score.

At the center of all this is the player's ability to always be in control of exactly where the gun is pointing. You're not just charging and releasing shots, you're also aiming the gun left and right, and every point your finger travels through correlates exactly to a position the gun can be pointing.

Moreover, the bottom of the screen is a negative space: the silhouette of a pyramid. Your finger doesn't get in the way of anything, and the "control pad" on the screen is both contextualized and practically invisible.

I feel pretty clever for thinking of all that: I wanted to do for a first-person shooter what Canabalt had done for Super Mario Bros., except we had to stop at Japanese 1980s arcade games and StarCraft along the way.

Not everyone loved the controls. A couple of iTunes reviews were livid at the lack of "offset controls." They wanted an invisible virtual analog stick wherever they put down their finger. I feel like this would have ruined the game: They'd get what they want, and then, unable to aim in literally every angle, their scores would suck, and they wouldn't get it, and then those emails would start coming again.

Case Study #4: Mac OS X

Taking ZiGGURAT's control style over to FASTERBLASTER was a nightmare. Luckily, I had a backup plan. I feverishly typed a long email to programmer Michael Kerwin, in which I explained controls that'd work "like an old-fashioned stereo knob except not really." He said he'd need a couple hours to think it all through.

A couple hours later, he came back with the suggestion that the controls I mentioned were "like the iPhone alarm-setting wheel." "Oh," I replied. "Yeah."

If you ever meet my parents, they can confirm this: I have, since childhood, had perhaps unnecessary amounts of fun with unlikely things. Recently, one of those things is the multiple desktop switching on the more recent Mac OS X versions. Sometimes, I'll put four fingers on the trackpad and record-scratch between two spreadsheets in time with the music I'm listening to.

The best thing is, of course, "natural" scrolling in OS X. I just spent 30 seconds scrolling up and down through this document. This scrolling possesses such charismatic friction in its coasts and turnarounds. It's as finely honed as Super Mario Bros., but it's smooth in its nuanced complexity to allow for perfect natural usability.

Natural scrolling accelerates to a set point relative to the speed over distance of a two-finger swipe. To halt the scrolling immediately, just touch one finger to the trackpad. I have watched many Mac users scroll and halt, and they always use two fingers for the halt, even though one finger will do. This is important: "Two fingers" is attached inseparably from any action related to scrolling. This is as close to "proof" of an interface's intuitiveness as we can get.

The most important aspect of natural scrolling is the natural deceleration. Somebody working at Apple loved that action. OS X's two-finger trackpad scrolling is to a mouse scroll wheel as Netscape is to Google Chrome. So here's where we have to talk about "friction": Without some quirk to snag an action and pull it away from "perfect usability," an "interface" cannot become a "game." The soul of game design, after all, is in assigning rules to objects.

Natural scrolling in OS X halts immediately when I put a finger back on the trackpad. What if the finger on the trackpad were brakes? What if to halt the scroll, I had to input a reverse of the gesture -- matching the speed over distance of my previous swipe, only in the opposite direction? Now we might have made a game: You have 10 seconds to scroll the scroll bar up to a touchdown zone; you have to land it precisely between two lines. Swipe up to accelerate. Swipe multiple times to accelerate higher and faster. Now keep your distance over time in mind when you start applying the braking swipes.

We've just started designing the Per-10-Seconds experience of a stupidly abstract train simulator or an Atari-2600-like curling game. It's probably not very fun. That's okay, because we're not actually going to make that game.

Instead, imagine you have your smartphone in landscape mode. Now imagine we're making Super Mario Bros. Your character is facing to the right, and located just a bit left of the middle of the screen.

Slide your thumb up and down on the left side of the screen to move right and left. Double- and triple-swiping dials in multiple accelerations. You're controlling Mario with a scroll gesture: Swipe X distance in Y time and then release to accelerate Mario up to top speed for Z seconds, after which he starts to slow down again. Swipe X distance in Y time and then leave your finger down to keep Mario at that top speed. Touch (and hold, and release) anywhere on the right half of the screen to jump.

Now try prototyping this. So, uh, why do people use virtual buttons, again?