Petards (and Notably the Hoisting of Oneself On Them)


So anyway, I’ve been working on this game called Snek. for the last roughly six weeks, since I put the Mumble Indie Bungle out there into the world. It’s been an adventure chiefly because it’s a game for iOS devices and has meant I’ve been learning both Objective-C and the Kobold2D library and the general weird hardware stuff of interfacing with accelerometers and gyroscopes. The central premise of Snek. for me is the idea of an iPhone game that super awkward to play and thus the opposite of a “proper” iPhone game. And that is the petard which I’m writing this blog post from the top of.

The whole iOS experience is generally very smooth and silky. You focus in on your little (or slightly larger) device and move your finger around and things happen seamlessly and without much effort on your part. It’s actually a very seductive system of interaction, and I found myself trying desperately to make a game that fit that model for a while, even though I’d started out explicitly not wanting to. Eventually I came to my “senses” though.

So now Snek. is back to what it’s meant to be, which is that it’s really hard to play because you have to use the phone in unusual ways in order to get the snek in the game to turn. You have to rotate it physically in your hands, or tilt it (possibly away from you, occluding the screen), or kind of whip it around in the air. In all these cases there’s a tension between being able to see what you’re doing, and doing something, which is what I like about it.

But the problem with that is that you give it to someone to play, and they find it super hard to interact with. And it’s not just that it’s embarrassing or awkward, it’s that there’s no one “natural” way of, for instance, turning a phone rapidly to make the snek turn. So some people quite reasonably adopt a “flicking” motion, where they rapidly rotate the phone and then return it to a “neutral” position. But this particular motion confuses the underlying code that turns the snek and may actually recognize the “returning” part of the flick, causing the snek to turn the opposite of what you want.

So this means I end up stuck in a position where I’ve made a game that’s hard to use, but which I want to “usable” in the sense that people understand how to use it (in the hard way required). So I want the game to be “unfair” in the context of normal games, but “fair” within its own system and reality. This almost-contradiction has caused me all kinds of pain and, to be honest, I haven’t solved the problem at all. The best I’ve been able to do is just change the language in the tutorial screens subtly to try to encourage a particular motion, and hope that works.

I also think another line of defence/post-hoc rationalisation is to class the game (and all games to an extent) as a kind of instrument or piece of equipment: they only work if you do it “right”, and to do it right you have to spend time with the system and learn how it responds. Just like a golf club doesn’t inherently make you hit golf balls well, Snek. doesn’t inherently let you rotate your iPhone well – you have to practice and learn. (Whether people will bother or not is a whole other thing, but that’s not so much my concern. Or it’s less my concern anyway.)

So, that’s the petard of choice for today.

(In other quite fun news, I discovered while testing with people today that you can control the game by holding the phone still in the Turning mode and just do pirouettes to control the snek. Kind of cool!)

31 May 2013
← next words previous words →