The code package for this chapter contains three projects that demonstrate the things we've learnt in this chapter.
This project demonstrates the use of the s3ePointer API by showing the screen coordinates pointed at by the user. If a multi-touch display is available, it will show multiple touch points.
The project also demonstrates a simple approach for detecting swipes and pinches and how it is possible to use the same gesture detection code with both single- and multi-touch capable displays.
The Slide project shows how to use the s3eAccelerometer API to read the current accelerometer values, apply a smoothing algorithm to them, and generate the angles of tip around the X- and Y-axes.
It also demonstrates something a little more game-like by allowing you to move a little red box around the screen by tipping the device.
Our skiing game becomes interactive in this chapter, allowing you to rotate the skier left and right and have him move across the screen and affect the speed of scrolling. The skier can be controlled either by key presses and touch screen or accelerometer input.
We also have more of a game-like flow with the addition of a title screen mode that allows the input method to be selected, and a game over mode, which is triggered when the player goes into the trees at the edge of the game world.
The following sections highlight some of the new classes added to the project.
Rotation of the player has been achieved by including a number of different animation frames, each showing the player at a different angle of rotation. This makes it easy to slot into our existing GameObject code, which expects to draw a square image that is not rotated.
While this solution is very simple, it is perhaps not the best option. We could instead have extended GameObject to support rotated images, which would have both saved memory (we would not have needed to store all the extra animation frames) and yielded smoother rotation results, as the skier currently steps between frames at 10-degree rotation increments.
These classes implement the title screen and game over modes of the game. These have been added to make the project feel a little more like a game, although they are very basic to look at.
More importantly, these classes show how we can switch between game modes by making them active and visible. Take particular note of the ModeGameOver class, which stops the normal game mode from updating, but still allows it to render so we can see the game world along with the game over message.
The Camera class
has been added to the project to allow us to specify a viewing point in the world. When rendering, we now use the camera position as the origin's location on the screen. So when we move the camera, the entire screen display will move relative to it. This makes it possible to do a horizontal scrolling effect without having to update the x coordinate of everything in the game world.
Another reason for making this change is to make our life easier when we upgrade the game to use 3D models in the next chapter, since this is closer to the way 3D graphics are rendered.
Three new singleton
classes have also been added to the project to make access to key, touch screen, and accelerometer inputs a little tidier. They are called KeyManager, TouchManager, and AccelerometerManager respectively.
These classes wrap the functionality provided by Marmalade into a simpler interface, which makes our game code easier to read. It also means that we can make changes to the inputs at a later date without having to change the game code. For example, the KeyManager class provides methods to indicate if the left or right arrow keys have been held. If we want to remap those keys or provide alternate possible keys, we can do so in the KeyManager code and our game code will work just fine.
In order to add a layer of abstraction between the Skier class and the various input managers, the SkierController class has been added. This class provides a "steering" value, which is an integer number ranging from—IW_GEOM_ONE to +IW_GEOM_ONE that indicates how much the user is attempting to steer left (a negative value) or right (a positive value). The Skier class can just use this value to rotate the skier without needing to consider how this value is derived.
Internally, the SkierController class generates the steering value using the selected input method from the title screen.
For keyboard input, the left and right arrow keys modify the current steering value a little bit each frame.
Touch screen input uses the horizontal position of the player's finger on the screen to generate the value; so it is -1 when the player is touching the left-hand side of the screen and +1 when they are touching the right-hand side.
Finally, accelerometer input just scales the x axis accelerometer value into the required range.