Zarf Updates

First-person graphical adventures -- Myst -- have become hugely successful in the past several years. Yes, even as Cyan Worlds and Presto Studios and such dinosaurs have withered in the frost. What are popular today are the tiny, casual, unbeautiful and narratively-barren games we call "room escapes". They're written in Flash, and they pour by the dozens out of our web browsers.



(Of course, some are huge, some are hardcore, some are lovely, and some are rich story-worlds -- I don't have to link examples, do I? That's not the point. The escape genre has conventions, and they're not trying to live up to what we thought all graphical adventures would be like from 1994 onward.)

When I got my iPhone, I thought "Room escape games! Perfect! Little puzzle environments to explore while riding the subway to work." (This was when I rode the subway to work.) I looked through the nascent App Store, and found... a couple. There was no easy porting path for existing games, due to the whole Flash situation, and only a couple of developers were writing for iPhone directly.

More room escapes have appeared in the past two years, but it's still not a big corner of the App Store. More important: none of the games, as far as I've researched, have really thought about the iPhone (touchscreen) interface, and what it means for first-person graphical adventures.

---

The model did not originate with Myst, of course. It's almost inevitable in a modern computer UI: you see on the screen what you would see in the world. Your mouse is your hand, and you click an object to push, pull, move, or take it.

...Except that "the modern computer UI" is the mouse and cursor UI. Myst (and its predecessors and descendants) took full advantage of the cursor to provide a graduated, explorable experience. You look; you see an object; you consider whether it might be manipulable; you move the mouse over it; you see the cursor change to a hand; you consider what clicking might do; you click and find out. It's almost a subliminal process, but it's real.

Hello, the touchscreen -- no mouse, no cursor. You're touching the scene directly. That has to improve immersion... right?

Maybe. It changes the game. Simplifying a UI can improve it, but short-circuiting a puzzle can ruin it. Do you explore the room by tapping every object in sight? That's not exploration, that's a rampage. You've just pushed every button, opened every unlocked door, and picked up every object! -- just to get yourself oriented. You might not have even realized that something is a button (or jewel, or door); it fired "all by itself" when you touched it at random. No moment of realization, no intention of agency. The pacing is all wrong.

Designers have tried to cope with this in several ways. Some games simply don't put much weight on discovery; clicking blindly is the expected path. (Not a popular path, however. Game review sites tend to frown on Flash escapers that omit the changing mouse cursor.)



In the iOS port of Riven, Cyan implemented a "shake to reveal" hint mechanism. Shake the phone, and green circles pop up (briefly) around important hotspots. It's effective, but not very immersive. The green circles come across as graffiti on Riven's classical artwork, and -- worse -- they're not much like exploration. You can't wonder about them or discover them. They're a menu, and you folks know how I dislike menus as an adventure UI.

(Down a side path we find the "hidden object" games. These have been ported to iOS in fair proliferation. Partially because they're a popular genre, of course; but also because the discovery model is simpler. The game has no notion of thinking about what to do; you see a correct object and click it. That fits perfectly on a touchscreen. The hidden-object games that include real adventuring elements -- yes, many do -- get away with a suboptimal tapping interface because that's not the main point of the game.)

---

Let us back up.

Look around; see; consider; investigate; think about results; try it. What can fill these roles? "Look" and "see" haven't changed: we display a scene. You consider an object. You investigate... surely by tapping it. Tapping is the most basic touchscreen interaction.

Now you know the object is manipulable, but you haven't done anything with it. You've gotten a hint about what might happen, and you're thinking about whether to try it or move on. Finally you try... what?

How about dragging the object? Most real-life interactions (outside of elevators and iPhones!) involve moving things, not just touching them. Myst is full of buttons, but it also includes levers and dials -- things to pull, rotate, slide, and lift.

With this, our interface comes together. Tap is investigate; drag is act. Tap a lever, and it jiggles; it is eager to be pulled. Tap a door, and it will shift slightly on its hinges -- unless you hear the sad "clunk clunk" of a locked door. Tap a key lying on a desk, and it will rock a little. Then you pull the lever, or slide the door open, or pull the key to your inventory bar.

And buttons? Frankly, we'll do without them. This is rough news for the porters of an existing graphical game, but rethinking an interface means rethinking your game design. Change them to toggles or knife switches. The good news is that dials and combination locks work wonderfully; rather than clicking "up" and "down" buttons to set digits, you drag the wheels around or spin them with a flick.



I've built a prototype of this interface. You may recall it as Secret Project KLD. I didn't build a complete game, but I built enough to prove that the UI works. The trick is to make these dragging motions continuous -- or continuous enough, anyway. When you drag a slider back and forth, it should actually follow your finger on the track. When you drag a door open and closed, it should move wiht your touch. Full 3D modelling makes this easy, but might be too heavyweight for a mobile device. I found that six or eight "keyframe" images is enough to make the illusion work. The direct responsivity of touch more than makes up for the jerkiness of the animation.

Navigation is trickier (but then, it always is). To see a close-up view of an object (if it has a close-up) you should simply tap it. Tap is investigate, after all. By extension, tapping on an open doorway should move through it, and tapping on the edge of the screen should turn around. Now tap is somewhat double-purposed (but then, it always is). I think this is acceptable; walking around a room to look at things is okay for an automatic action. It's always reversible (perhaps with some jockeying to turn around and find your way back). You won't accidentally solve a puzzle or mess up your known position, as long as the game has no step-and-die traps (which, of course, it shouldn't).

I have most of the KLD game designed, and I modelled quite a bit of it in Google SketchUp. Why did I put it aside? It turns out that SketchUp is good for modelling, but not great for placing comeras or rendering frames of moving parts. My graphics workflow was slow and painful. Also, the artwork that I did produce was sized for older iPhones; I'd have to rethink the whole plan for iPads and the new double-resolution iPhones. I may get back to the game someday, but my immediate future is pinned to text IF.

So here you go. The correct model for a touchscreen-native adventure game. Somebody run with it.