Ok, that title is kind of misleading. But for those who caught the reference, *high five*. I actually pulled gyroscope support from our latest Tilt to Live update. I had it implemented into the game at one point but through beta testing eventually killed the feature. I just wanted to go over the details as to why it went the way of the dodo bird.
Gyroscope != Accelerometer
Alright this a biggie. With the gyroscope on iPhone you can detect the orientation of the device in any position. This is great and actually not a limiting feature. You can calibrate the device in any position. Hell, you can calibrate the device while hanging upside from a jungle gym on a pre-school playground and it will work without a hitch. But there is a subtle difference as to how your tilt offset is calculated. The gyroscope offsets are calculated off of absolute orientations, where as using the accelerometer offsets are calculated off of relative orientations to a gravity vector.
Before I go any further, let me explain why I went down this dead path for tilt controls. When you calibrate a device off of the accelerometer there is a ‘gymbal lock’-esque problem when the device is 100% vertical. Any horizontal tilt cannot be detected because you’ve lost this degree of freedom since one of your tilt axis is aligned with gravity (what the accelerometer works off of). When the gyroscope was announced I naively thought, “Hey we can probably make the perfect tilt controls now that work in any position!” I got the ‘any position’ part down, but it was far from perfect.
Complexity in the UI
Another ding against gyroscope was due to the nature of how it worked, I couldn’t find a way to automatically turn it on and off without a large chance of the user becoming confused. As a result, I needed to create some UI interface to enable gyroscope controls. And wow, it was a hard one. Trying to explain the nuance of how the gyroscope works, without getting technical so that the user can make an informed decision as to whether they want it or not was…a bit weird. How weird? When you have to write up text that says this:
You’re probably doing it wrong.
We found it pretty funny and in line with the rest of the humor of Tilt to Live. But it just wasn’t easy to explain. Complexity in the UI was actually one of the main reasons we decided to pull it. We didn’t want Tilt to Live’s calibration to become this screen of knobs and switches, even when you’re doing a custom setting.
We weren’t kidding. Cars = bad
Step 1. Calibrate using gyroscope
Step 2. Play the game. (You so happen to be in a moving vehicle)
Step 3. This vehicle takes a right hand turn
Step 4. Owned.
The handset, in “real world” space is actually rotating when the car turns, but in local space relative to the car it isn’t. Bad news for people who are now wondering why their little arrow turned suicidal after they got off that exit ramp from the highway.
This issue ultimately clinched it. Having to calibrate not only the orientation but the actually direction a player is facing was too much. There was too large of a margin for error.
Gyroscope is awesome, we just weren’t meant to be….
With all that said, playing around with the gyroscope was awesome. It allowed me to play Tilt to Live in one-handed portrait mode because of the freedom it provided with calibration. But that freedom is very short-lived as soon as I get up, turn in my chair, or any other minor movement.
In the end, if you’re making a tilt-based game mechanic gyroscope may be of a more limited use when you actually stop and think about it. Unlike me, who did very little thinking and went ahead and tried it :). I did have a period in there where I was completely convinced that there was an elegant solution to combining the accelerometer data and the gyroscope data to create a fully working “hybrid” of sorts. It never came to me, but I’m sure someone out there much smarter than me that could write a proof proving or disproving this problem and make my head explode.