Game Design Deep Dive is an ongoing Gamasutra series with the goal of shedding light on specific design features or mechanics within a video game, in order to show how seemingly simple, fundamental design decisions aren't really that simple at all.
Check out earlier installments on the tutorial system in Rogue Legacy and the rhythm mechanics at work in Crypt of the NecroDancer.
Also don't miss these developer-minded looks at the movement system in Road Not Taken and Amnesia's "sanity meter" from earlier in our ever-growing Deep Dive archive.
Who: Michael Brough
I'm a self-employed artist working primarily in games. I'm best known for 868-HACK. Usually I work alone because I like to do all the things myself but I have collaborated a few times - e.g. with Andi McClure on BECOME A GREAT ARTIST IN JUST 10 SECONDS and with Andrew Toups on Helix (he did the sounds).
What: Helix's touchscreen controls
Helix is a touchscreen-based action game with a (to my knowledge) unique control scheme. It has the basic setup of an "arena shmup" - it's played in a single-screen arena with enemies entering from the sides, but rather than shooting, the player must complete loops around them (a comparable mechanic to enclosing regions in Qix or more recently Spirit, but subtly different). It's controlled with a single finger anywhere on the screen which essentially moves an invisible floating joystick.
Why a single-finger, "invisible floating joystick"?
Initially I was working on controls for two-player games, trying to make an ipad version of Kompendium. Glitch Tank had worked well with its simple button controls, but the other games required direct character movement. I didn't have any experience with other mobile games, so I spent some time researching what they did, but I wasn't really satisfied with any of them.
Direct controls where you touch and drag objects feel great in terms of immediacy, but aren't ideal for fast action games where you're paying attention to a lot of events on-screen, because your hand obstructs your vision (which is of course exacerbated in multiplayer when your opponent's getting in there too).
Espgaluda uses one-to-one controls, where you touch anywhere and then your character exactly follows any movement you make relative to their position. This feels pretty great but your hand can move very quickly, so the character needs to be able to keep up; if you want to limit their speed at all it doesn't work as well. Also it's impractical for large movements - your hand starts to cover the whole screen again. (You can scale it up linearly to accommodate large movements but that loses precision on small movements.)
Several games (e.g. DRM) use a virtual joystick: touch, drag, hold to keep moving in the same direction. For me this doesn't feel ideal for a touchscreen because to change course you have to move with respect to the centre of the stick and there's no sense of where that is - compared with a physical joystick that always has a force pushing it back to neutral, giving an intuitive awareness of the center.
So I wanted to make something that felt good to me and avoided these problems. I wanted this for multiplayer but I figured I should do a singleplayer game first, since it's already hard to get right without someone else getting in the way.
Helix's unique controls in action (vid credit)
How I implemented Helix's touch controls
I started with a virtual joystick under the player's finger wherever they touch. I said the problem with this approach was it lacked a force pushing back towards the center, so I added one, but flipped around: since I couldn't apply force to the player's hand I applied it to the joystick instead, making it drift towards your finger (PARAMETER 1). This feels like somewhere in between DRM's static joystick and Espgaluda's one-to-one controls: you start moving as with a stick, to keep moving you keep applying a little force but less than you needed to start.
This felt okay near the center, but when you made a large movement it wasn't quite right. Thinking about a physical joystick again, there's a hard limit on how far you can move it from the center, so I added that - again flipping it around because I couldn't limit the player's finger. If you move more than some distance from the center (PARAMETER 2) the center is dragged much more quickly to keep up.
Then the joystick's direction vector is scaled by some factor (PARAMETER 3) to get the character's acceleration, and the character is clamped to a maximum speed (PARAMETER 4) and slowed by some amount of friction (PARAMETER 5). Very sharp direction changes didn't feel quite responsive enough so I fudged it a bit by adding extra friction if the player's velocity pointed against the joystick direction (PARAMETER 6). And then it seemed like surging in a direction and letting go should leave you moving so I reduced friction when no finger was in contact (PARAMETER 7).
So now it was feeling sort of okay but I had 7 parameters to tune. I added them all to an in-game menu so I could adjust them while I played - I find it really useful to put editors inside games to minimize how far I have to go to change anything (with Corrypt, for example, I constructed all the levels on my iPad). I spent a few months fiddling with these values until I was satisfied with them.
I mostly work on iPad, but had to adjust the parameters separately for phones - it wasn't enough to just scale them relative to the screen size, because you also hold them at a different angle and have less freedom of movement in your finger joint. I also made the enemies move a little slower and spawn less frequently on phones to make up for the smaller space. (The top scores have ended up being a mix between the two devices so I'm satisfied that I did a reasonable job of balancing between them.)
The other side of controls is collision. At first I had pixel-perfect collision detection but when you skimmed an enemy and just touched one corner it felt unfair, so I made this progressively more and more generous. Every time I reduced the player's collision hull the game just felt better and better, because you'd have exciting near-misses where previously there'd have been a death. I reached a point where I couldn't make it any smaller but it was still getting better so I wanted to keep going: instead I added a small force pushing the player away from any nearby enemies. It's smaller than the force of input so it won't stop you moving straight into an enemy, but it exaggerates dodges enough to save you when you're close. This felt like a ridiculous thing to do but then the game felt better so I kept it. DON'T TELL ANYONE.
Also when spawning enemies the game pays attention to where the player finger and character are, to try to avoid making something in your blind spot and a loss feeling unfair.
I ended up with a control scheme that works both for making wide sweeps around the screen to encircle enemies and for small adjustments to dodge them, with a finger staying near the corner of the screen not covering much of it. Additionally, I think it feels fun to control - it just has a playful exuberance to it. A lot of other people have praised the controls.
The controls don't suit everyone; it seems like everyone has a different response to touch controls, different expectations for how they should work. Some people think they're perfect and others think they're completely inaccurate. (Plus I know someone who claims his skin is just too dry to play any action game on a touchscreen without friction burns.) I've had a lot of comments asking why it doesn't work exactly like "[some game]"
Are you a developer interested in contributing to Gamasutra's Game Design Deep Dive series? Email editor-in-chief Kris Graft: [email protected]