iPhone platformer. Controls?

Question

I was thinking of porting an old ZX Spectrum platformer game to the iPhone. How are the controls implemented in iPhone platform games? is it the accelerometer or they draw buttons on the screen that correspond to the directions and the firing?

Answer 1

I considered many of the same options as you guys. I had decided against using semi-transparent buttons from the get-go because I've always hated them as a player of iPhone games. This is mostly because, without tactile feedback, my fingers tend to slip off the buttons. There's nothing worse than thinking you are going to jump and falling into a ravine. Also I felt that by having a D-Pad I would be clinging to an outdated notion of how these kinds of games are supposed to be controlled. If the iPhone is not about having joysticks (and it really isn't seeing as Apple has prevented anyone from developing a true external controller for iOS), I should really be relying on the things that it does have to its advantage–namely the touch screen and the accelerometer.

With those concerns in mind, I decided to develop multiple control systems and let the user choose. I should mention that in my game the player is always centered on the screen (the entire world pans) and there are no other actions in my game other than running and jumping. Here are the controls systems I've come up with so far:

1. Simple Touch: You touch and hold to the left of the player sprite to move left, to the right of the player sprite to move right. To stop, you pick your finger up off the screen and friction/inertia brings him back to a standstill. You touch above the player to jump (either directly above or within a 45 angle of the y-axis). I (as the game's developer) found these controls to be totally intuitive and was somewhat dismayed when the first two people I showed the game to instinctively tried to swipe the screen and, you know, nothing happened. Maybe they would have gotten used to my simple touch system and learned to love it, or maybe I'd just lost perspective and what seemed intuitive to me wasn't as universal as I had thought.

2. Tilt Walking: You tilt the phone to the left to walk right, you tilt the phone to the right to walk left, and you tap the screen to jump. That's right, the player actually runs in the opposite direction from the way you're tilting. It's as though he's always running uphill. This is what felt natural to me. In fact, in some ways, this felt even more natural than Method #1 (Simple Touch), but the accuracy was pretty horrible. The player always did what I expected him to, but I found that I just couldn't use it to actually play my game (even when I monkeyed with the physics, the player almost always overshot the platforms).

3. Flick Walking: This was my first attempt at detecting swipe motions. The user would flick (swipe quickly then pull their finger off the screen) anywhere. The player would run in the direction of the flick with a velocity proportional to the speed of the flick. This felt somewhat intuitive to me, and the game was definitely playable, but it had some drawbacks. For starters, flicks can only be detected once they're over. This means that there's always a delay between the user's behavior and the onscreen reaction. Secondly, when I presented it to my wife to get her thoughts on it, the first thing she did was slowly drag her finger along the screen without letting up, and the little player sprite stood perfectly still. Which leads us to the fourth and final version...

4. Touch-and–Drag Walking: When the user puts their finger down on the screen, that point is recorded. When the user drags their finger away from the point, the player sprite runs in the same direction as the finger drag at a velocity proportional to the distance of the users finger from that original start point. In other words, if they drag far from that original point, they run fast, if they drag only a short distance they run slowly. Jumping is achieved by tapping above the player and/or swiping upwards. I will update this comment once I know how this system worked out for my game.

Answer 2

The best games let you choose either tilt or touch in an "Options" menu. Some people may prefer tilt, but might be lying down or riding in a car, so want to use touch instead. Or they may tire of their thumbs blocking the screen and long for more precise analog input, so then desire tilt. They'll love you if you let them select for themselves!

Which is preferable also depends on the type of game and what type of controls suit that game. The accelerometer does a great job emulating an analog stick, but you still have to tap if you want to "fire" or "jump" etc. Your retro game's input was probably arrow keys or a digital joystick (4 or 8 direction), so you'd want to set thresholds as to how much tilt in a given direction triggers a directional input. It'd be nice to let the player set a "tilt sensitivity" option for this to. (Also, you could allow a "default down vector" to be set when the game starts up or the user changes it in options... so the user doesn't always have to hold the device parallel to the ground to play your game. That may also require different sensitivities per axis, based on angle, but I won't get into that here.)

On-screen directional controls (virtual buttons) are really common in iPhone games, and easy to implement, but they have some drawbacks. First, your thumbs are obscuring part of the screen! Second, the button images, even if semi-transparent, can obscure in-game elements (some important) anyway. Third -- and this is a little harder to understand -- they can be more difficult to use, since they don't provide any tactile feedback. More specifically: you're stuck with the developer's positioning for the "center point" -- which may fit his thumb's natural resting position, but not necessarily yours! So it's hard to re-center your thumb after you've been moving. Also, it can be difficult to tell how much to move your thumb (too much or too little) to register movement in a particular direction.

To remedy those just-mentioned drawbacks, I recommend a different approach. When the player first touches the screen, treat that as your "center point." Then as the player slides his thumb and keeps it on the screen, treat that as his "end point." The VECTOR between center and end points should determine his direction. It would work great for digital (8 position inputs) and it works great for analog inputs too (take the vector's length). For taps to jump or shoot, let the player tap wherever he wants! If you need more controls than a simple "fire button," the user can touch top half of screen to fire, bottom half of screen to jump, for instance.

Hope some of this helps. As you can see, it's a complex issue... but a very important one. There's nothing worse than an unplayable control scheme ruining an otherwise good game! Good luck!