# Design Patterns for Mobile Games Based on Structural Similarity
## 4 Design Patterns Based on Structural Similarity
### Unrelated Levels  
This design pattern may be used for level-based mobile games in which all the levels are different from each other and/or few factors may be common. 1. Intent: Separate classes with different functionalities for each level and let the super class have common functionality and control. 2. Motivation: Most mobile games have levels. When a user completes a level, the more challenging level starts next. This process continues until the last level is completed or the player fails sometime during the play session. The levels in some games are not similar and differences outnumber similarities. These differences may be in the game logic, game characters such as an avatar, non-playing characters, opponents, and rules for scoring. 3. Implementation: In this situation, it is appropriate to implement each level in a different class. If, somehow, there is some similarity or common functionality in all the levels that may be implemented in the superclass of all game levels--GameLevel. 4. Diagram: The diagram in Figure 11 shows the complete Unrelated Levels pattern. As it is obvious, only a few classes, GameLevel, Level1, Level2,..., LevelN, have to be added to Common Pattern. Ellipsis (...) between Level2 and LevelN shows that there can be any number of levels, all extending GameLevel directly (Use of ellipsis in this way is not standard in UML, but here we want to clarify our point. We will refrain from this in later diagrams, though). 5. _Participants:_ - Updateable, AbstractUpdateable, UpdateableManager, TheCanvas: These participants have already been explained under the Common Pattern category. Figure 11: _Unrelated Level_ pattern. GameLevel is the abstract superclass with subclasses at individual levels. It should be a subclass of AbstractUpdateable. It contains common properties and methods with general implementations such as pause() and resume() methods. Level1, Level2,..., LevelN are subclasses of GameLevel. The respective level's specific functionalities are implemented in these classes. The UpdateableManager class instantiates these levels based on the level's handler. * Sample Code: The Appendix A shows sample code for the GameLevel class. Though not necessary, the GameLevel class may implement all methods of Updateable interface with common to all functionalities. The levels' classes may call these methods from the same overridden method. For example, update() of GameLevel may be called from update() of Level2 using super.update(). Most of the members in GameLevel are likely to have protected access. As we can see, the update() method has been defined in GameLevel, and an individual level class may not define it by itself. However, in most cases, each level should update its calculations and graphics itself. We want to clarify that both keyPressed() and listenKeys() methods are intended to take action when keys are pressed. keyPressed() is Updateable's proxy method for TheCanvas.keyPressed(). It is intended for single key presses, e.g., selecting an option, pausing and resuming the game, and enabling power during gameplay. On the other hand, where keys' state (comprising of all keys collectively) is required, listenKeys() serves the purpose; it captures the state and takes action accordingly. For example, when the avatar has to move up, the \"Up\" key has to be pressed, when it has to move right, the \"Right\" key has to be pressed, and when it has to move diagonally towards the top-right, both the \"Up\" and \"Right\" keys have to be pressed simultaneously. * Consequences: There can be overlapping similarities among different levels. For example, in a game, a \"firing\" action can be required in the second and third levels only and \"fighting\" in the third and fourth level only. In this situation, one can argue that the game cannot have an Unrelated Levels pattern because of those similarities. If similarities are minimal as compared to differences, we may still apply this pattern.