Search Results for: kld

How to write a touchscreen adventure game

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.

Viridian Room screenshot

(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.)

iPhone Riven screenshot

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.

Secret Project KLD lock puzzle

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.

Posted in Zarf on Games | Tagged , , , , , , | 12 Comments

Yet another reason Apple's feet are full of bullet holes

This is whale week for the iPhone App Store review process. Rogue Amoeba posted a tale of woe, Paul Graham posted about developer ill-will, and now it looks like Apple is checking for private API usage with less than perfect discrimination.

(All links thanks to Gruber, by the way, because where the hell else would I learn this stuff.)

As our faithful readers know, I've been working on an iPhone game for several months now. (And I have several months of work to go. Definitely a high-end project. Hope you all like it!) I can cope with some of Apple's restrictions: I have never touched undocumented APIs, for example. I have no pictures of iPhones in my game, nor cruel caricatures of Steve Jobs.

But good intentions are no cure for App Store Hypochondria. I lie awake nights worrying that I will do everything right and Apple will still bounce me. Worse: that I will do everything right, my app will be accepted, and then I'll try to push a simple bug fix and Apple will bounce me for something I haven't changed.

That's the nightmare for me, as a developer. Negative progress. The destruction of my reputation because Apple won't let me fix my released game. That's why inconsistent rules are worse than stringent rules.

You think I'm worrying over nothing? Go back to the preview screenshot I posted for my game. On the left side of the screen is a green icon labelled "Mail". That's because the story starts with you receiving some mail. Will Apple punt me for "imitating" their Mail app icon? Or faking mail functionality? I don't think so, but my opinion doesn't count, now does it? The Application Submission Feedback blog mentions a case where Apple rejected a cracked-screen effect; I have a scene in my game where an object cracks apart. Could be rejected. I don't know. I have the App Store Hypochondria bad, man, real bad.

And these aren't user interface issues I can tweak. I'm creating an interactive narrative. I can't change that cracked object to a melting object -- I'd have to redesign some later puzzles, never mind redoing the graphics. Should I change that first scene to a phone call just because Apple dislikes fictional email? (Should an ebook author do that, or a musician, in order to be accepted by iTunes?)

All of this scares developers, which hurts Apple -- indirectly. But that's not the foot-shootingness of it all. Apple is in the same boat. We know the review process is arbitrary and inconsistent; the same UI may pass one month and fail the next. But these are Apple's guidelines! Whatever Apple wants, they're not getting it either. If Apple really, sincerely wants to reject all watch icons, they lose -- their review process is failing to do it consistently. If they want to reject all ebooks with "iPhone" in the title, they lose -- it's not happening.

If they don't want these things, of course, then they're just peeing on randomly-selected developers, and they really lose.

The App Store review process: broken for everybody.

Tagged , , | 1 Comment

Another Secret Project KLD image

Back in July I posted a teaser image from Secret Project KLD. I said I'd say more in "three months, or six, or a year, or however long it takes".

Well, it's taking a while. I still don't know when it'll be done. But it's been three months, so the least I can do is tease you some more.

Project KLD Teaser

This image is actually a month old. I've done a heck of a lot of work since then. But it wouldn't be much of a secret project if I showed off everything I had.

(Note: Some of you reading this post have already seen this image, because... I like to talk about my secret projects. And show off. But I'm trying to keep it within strict bounds now.)

Anyway, see you in another three months! Unless I change my mind some more.

Tagged , , , | Leave a comment

Secret Project KLD

I've been quiet recently, and this is because -- well, it's because I'm a reticent person. But specifically because I've been working on a very secret game project.

Now, I know as well as any developer the perils of premature announcement. (Do I even need to joke-link to an example? No, I don't.) And this one is nowhere near maturity. I don't even have a complete design document, much less any idea of how long the work will take me.

Project KLD Teaser But I have mostly finished the introductory scene. And that's worth posting a teaser screenshot. I'll take a line from Andy Looney and call it: "Secret Project KLD".

What does this image mean? Only the Secret Underground knows! ...Meaning, only the people I've talked to in person about it. I'm (a little) less secretive in real life than I am online. Sorry, folks.

I will be little bloggier about KLD when I have a better idea about timelines. See you in three months, or six, or a year, or however long it takes.

Tagged , , , | Leave a comment