Windows Phone 7 Game Development: A Beginner’s Guide (Accelerometer)
Hello all. Keith here again, as promised. Bounce is now available, for free, on Zune marketplace. The current version contains some game-play bugs but an update will fix these in the next few days.
This is to be my first article on common problems faced by developers new to WP7. I am by no means an expert but I found that most of the articles and posts relating to the topics I will cover weren’t coherent or were too advanced for a developer new to WP7.
I will tell you the problems that I encountered, show you my solutions and provide links to other useful articles on the subjects. If you are new to WP7 development I suggest checking out the Windows Phone 7 Training Kit. Although you may not follow it exactly, it does provide a good base to get you going.
The accelerometer reads the current force of acceleration acting on the phone on all 3 axes. This data is stored as a 3D vector. While the phone is stationary the only force of acceleration is gravity. I had to do research into what the accelerometer readings would be and what these would mean. My findings were that when the phone is still, the readings due to gravity is a vector whose magnitude is near 1. This varies around 1 due to the slight variations in gravity between places and altitudes. The accelerometer also generates a lot of “noise data”. This is something to keep in mind as you may need to perform some smoothing on it (a quick search will yield lots of info.). I did not require any as the data was used in such a way that it did not matter.
Anyway a picture says a thousand words so here is a simple illustration of the readings, due to gravity, to expect. Please note the magnitude of 1 in the following readings will not be exact (as stated above). It is used for illustrative purposes only. There are far more detailed descriptions of the readings to expect but I wanted to keep this simple.
The blue rectangle represents the phone screen. The red arrow points to top of phone.
Another thing to note is that changes in accelerometer readings do not count as input to the device. This is to prevent accidental activation of the phone from user movement. This means that the screensaver may have to be disabled while your application is running. If you do this you must be re-enable it on leaving your game to pass the validation process. The code required for this is below.
Add this using statement to your game class:
Declare a bool in your class to hold the original screen saver setting:
On activation of your game add:
m_screenSaverEnabled = Guide.IsScreenSaverEnabled; Guide.IsScreenSaverEnabled = false;
On deactivation of your game add:
Guide.IsScreenSaverEnabled = m_screenSaverEnabled;
Accelerometer with the emulator:
As I am a student I could not afford a WP7 device to test on. This meant I had to rely on the emulator which has no support for accelerometer input or simulation. This was a major problem as the main user input for my game was accelerometer input.
After scouring the internet I came across a few solutions:
1. Use the keyboard or mouse to simulate input.
2. Use a game controller (Wii-mote, PS Move, etc.).
As I was only learning XNA and have a reasonable grasp of 3D vectors, I decided to use the keyboard to simulate accelerometer input. A basic implementation of this can be found in the sample game “MarbleMaze” which is part of the “Windows Phone 7 Training Kit” mentioned above. This example gives a good idea of the approach to take to this solution but is unnecessarily complicated in its implementation and somewhat simplistic in its handling of input (although it could be altered or expanded upon). It simply adds or subtracts from one of the accelerometer Vector values (x, y or z) when the arrow keys are pressed.
What I really required was an interface class, similar to this one, which was easier to understand and performed rotations around each of the axes. This would give me the simulated tilt which I was after. I ended up writing a class which checks whether it is running on the emulator or the phone and decides what input data to collect and how to manipulate it. I wrote a few simple rotation methods into the class to simulate tilting. They operate around mathematical axes, not the phones axes.
Accelerometer Handler Source: (Right-click and select “save link as…”)
For the accelerometer handler to work you must change the namespace to match your project and add references to Microsoft.Devices.Sensors and Microsoft.Phone to your project. Microsoft.Devices.Sensors allows use of the accelerometer and Microsoft.Phone allows you to check if the active device is the phone.
To add these references right-click on “References” (just above the highlighted items), select “add reference”, select the .NET tab and find them in the list.
The class works like this:
An object of type AccelerometerHandler is created. During construction it checks what device type it is running on. If it is running on the phone it creates a link to the in-built accelerometer interface, adds a new event handler to the accelerometer (to handle what to do when the readings change) and activates the accelerometer. Otherwise it just sets the readings to default values. The event handler just sets the class’ current reading to the current accelerometer data.
During your game’s update method the currentReading() method is called. If the active device is the phone the current reading is normalized and returned. If the active device is the emulator keyboard input is read and rotations are performed. The resultant vector is normalized and returned. The class provides active() and stopAccelerometer() methods to start and stop the accelerometer, though they are not really necessary as these are handled autonomously.
To activate keyboard input when using the emulator press the “page up” key while the emulator is active.
I hope you found this useful.
Be back soon…