# Design Patterns for Mobile Games Based on Structural Similarity
## 2 Literature Review
### Research on Design Patterns Related to Computer and Mobile Games
Its implementation in mobiles is a form with a retrieved item displayed in a text field that allows the user to enter new entries and save them. This pattern applies to any JME application with or without customizing to accept specific parameters. Though the authors identified only a few design patterns, there may be tens of them. However, the authors have given us another starting point for further research. Following their work, we can think of such patterns for mobile games. For example, we can think of a \"Move Avatar\" pattern, which could be used to move a game avatar using arrow keys. That pattern could be used in any game where the avatar has to be moved using arrow keys. There can be numerous such patterns. Figure 1: Integrated behavior structure for Phone Book [40]. Figure 2: One-function structure for Edit [40]. In this paper, the objective is to develop similar programming patterns at the generic level without going into detail. For example, all those games in which some levels are different only in the number of enemies will have the same structural design pattern. (However, the demo games developed along with this paper also consider some detail-level patterns. Thus, demo games can be used as templates to develop similar games.) [PERSON] et al. [41] demonstrated the use of design patterns for mobile games using J2 ME. Initially, they used design patterns for single-player Sudoku game. Then, they demonstrated that the same design patterns could be used for other board games with little modification in interfaces. At the top, they have used Model-View-Controller (MVC) architecture. Then, the patterns such as Change Screen, Singleton, Game State Observer, and Game Memento have been used preferring interfaces rather than concrete classes wherever possible. The use of interfaces assures that the same set of patterns may be used for other board games. Figure 3 shows a top-view diagram of this structure. The model part has been implemented as an interface GameModel, leaving implementation for concrete classes of games. SudokuGameModel is a concrete implementation of this interface. It has interactions with Storage-related classes. The view part has been implemented by GameView, BoardView, and CellView classes. Moreover, its draw() method is open for extensions, thus enabling safe modifications for other games. The GameMidlet class (entry point into any java MIDlet) and GameController interface constitute Controller part. Again, GameController is an interface to achieve loose-coupling and high-cohesion in modules. The concrete implementation in the Sudoku game is SudokuGameController. Patterns used in this sample game that may also be used for other games are Change Screen, Game Memento, Game Controller Choice, Game State Observer, Drawing Template, and Singleton. All of these patterns are self-explanatory. The pattern suggested by [47] separates displayable objects for a menu. This style supports the system's standard menu interface, but another practice is to implement a graphical menu (including images), which is one of the playability heuristics as mentioned by [47]. The MVC-based architecture can be reused with little modifications for other board games. The authors have outlined three example cases: GameCanvas. 1. Same Game with Different Settings: Standard Sudoku has 9 \(\times\) 9 cells, while the authors have implemented an option of Junior Sudoku, which has 4 \(\times\) 4 cells. The changes required to implement this option are to make the game model independent of puzzle size (using Strategy pattern) and that the game store class has to implement an interface in which both puzzles should be implemented in concrete classes. 2. Number Game Puzzle: Almost the whole structure along with its internal relations are preserved except changing the text menu and other classes to reflect this game. Additionally, the main model class SudokuGameModel has to be replaced with new a class (which should also implement GameModel interface) containing mechanics related to the new game.