Below is the Glide Factor design document. A picture is worth a thousand words.
Actually, it's just the instructions screen that you can access from the main menu. We wanted to be able to convey the full use of the game without using a single word, just a few nice looking icons.
The top part of the instructions screen explains the controls. The fact that the only movement instructions are the direction towards which you have to tilt the device has some implications. It does not specify how the device is held or its angle towards the ground, which means that from a usage standpoint, the player would be correct to assume that they can play Glide Factor in whatever position they are comfortable in; whether that is sitting in the Metro or lying on the couch. For us to be able to accommodate this correct assumption meant that we had to do some extra work behind the scenes.
No manual calibration
Many tilt based apps get around this "player position" problem by adding a calibration screen. This places an extra usage burden to the player by requesting them to perform an additional action, possibly multiple times. Nonetheless we tried it, and early play tests, my girlfriend and my friends, hated it! So we decided to automate the calibration process in the background, and at the start of each level. The lack of a visible calibration process makes things faster, easier and invisible. As far as the player is concerned it just works.
The shake bomb
While gliding through a level, oftentimes power ups will pop up to help you out. One of them is the shake bomb. Upon collection of the shake bomb, a player has five seconds to shake the device in order to make all on screen obstacles disappear. I can imagine the shake bomb being quite useful in the situation below:
In this case, the code must be able to differentiate between regular gliding movement, and shaking; all from the same signal input. It could be tricky but it was actually one of the easier problems to solve during development.
The technical stuff
If you are a developer, I hope you will find this useful.
Glide movement using the accelerometer
The work below is located in the accelerometer callback function. Set the frequency of the callback to whatever is most suitable to your application. Glide Factor runs this at 20Hz.
On entry gather the raw x, y and z acceleration values. Because Glide Factor is a left oriented landscape application, we assigned the value of x to y and vice versa, as the accelerometer does not adjust, and rightly so, to changes in the screens orientation.
Check if the direction towards which we are accelerating to has changed. For axes x and y get their direction, which is the sign of the raw accelerometer value, and the acceleration direction which is the opposite sign of the velocity of the axis. For each axis x and y if the signs of the direction and the acceleration direction match, then the acceleration value for each axis will be the sum of its previous value, plus a constant, multiplied by the sign of its previous value. Adjust the value of this constant in order to increase viscosity.
Apply the change in acceleration to the current velocity of each axis. The velocity for each axis will be the product of the acceleration, the raw axis value and a constant. Adjust the value of this constant in order to increase/decrease velocity. Once we have the velocity, for our implementation, we add it to a pair of screen coordinates we maintain for the glider, and draw the glider.
If you apply the above methodology to your own code, you will get fluid accelerometer control on a 2D plane albeit on a fixed angle to the ground, depending on the values that have been assigned to the constants. This means that the z axis movement has not been calibrated to a comfortable user position/angle as mentioned above. I will, of course, be talking about auto calibration in a future post.
The shake bomb
In order to detect that the device has been shaken apply a high pass filter to the raw acceleration values. Then take the square root of the sum of the squares of the filtered values to compute the intensity of the current acceleration. If the intensity is above a certain threshold then the device has been shaken!
Hopefully, I will be able to post some code soon. If you would like to follow up on this, just leave a comment here or on twitter
, or drop us a line at firstname.lastname@example.org
We are hard at work on our next game; All I can say for the moment is that we will attempt to augment the methodology described in this post, and apply it to 3D space, instead of a 2D plane. This has its challenges, but early testing has given us some valuable feedback. In short, to make tilt work in 3D space forget about mapping specific tilt actions to specific on screen behaviour. In this case it's all about context and the players preceding tilt action.
Thanks for reading! Soon, we'll be working on a post that focuses on the graphics of Glide Factor, the graphical style and how we used OpenGL. Hope to see you then and enjoy playing Glide Factor!
Labels: games, Glide Factor, glidefactor, iphone, ipod touch