Platos Revenge is an almost pure OpenglES2.0 game. It uses the Android system to set up the OpenGL view, handle incoming touch and motion events, and store save games into the sqlite database. Apart from this (and some minor uses) the game is handled completely from the Renderer and the model classes.
The main activity creates an instance of a custom GLView class and Renderer class. It then configures the GLView and passes in the custom renderer before setting it as it's content view. The GLView acts as a switch board passing on touch and motion events to the renderer, which translates it and passes it on to the model for handling. The majority of the user interface is within the 3D system of the GLView, the only real exception being the system back button which is used for navigation. This is because the Android developer guidelines recommended that developers use the system buttons and not replace them.
The 3D scene contains many labels and buttons. These are created using the billboarding technique. The texture for the billboards are created using the Android Canvas/Paint/Bitmap method
The general form of the interface is to have a title bar at the top with, for playable games, a score bar below it, a button bar at the bottom with a short line of instructions above it. The middle of the screen contains the solid or solids.
The games class hierarchy consists of once root class which contains most of the functionality of the games, two intermediate classes which define the two main types og game, selection and playable, and the individual games. Games hold one or more instances of the Solid class, as well as all labels and buttons used in the game.
Selection games are screens which show multiple solids, each solid linked to a new game. Selection screens ignore motion events but respond to touch events by checking eac solid in turn. If a solids reports that it has been touched, the game creates an instance of the game associated with that solid and reports victory to the model. The model will then retrieve the new game.
Playable games are the actual games. Each playable game holds one solid. When the playable game is created it will set the solid to its starting condition, normally randomising the colours and then keep the game in a paused condition until the first touch event is received. It will then handle touch events by first checking the labels and buttons of the interface, and then, if none of those report handling the event, checking for victory. If no victory is reported, it will pass the touch event to the solid. If the solid has handled the touch event, the game will ask the solid if it is solved. If so the game will set a victory condition and create an instance of the next game to be played. If the games initial check on the touch even has shown a victory, it will return the instance of the next game. After each touch event, the model checks the game for victory. The game responds by returning either the next game, or null. If the game returns a new game, the model will replace the current game with that. This means that after a victory, another touch event is required before the next game is started.
