A model-driven framework for developing android-based classic multiplayer 2D board games

Abstract

Mobile applications and game development are attractive fields in software engineering. Despite the advancement of programming languages and integrated development environments, there have always been many challenges for software and mobile game developers. Model-Driven Engineering (MDE) is a software engineering methodology that applies software modeling languages for modeling the problem domain. In this paradigm, the code is to be automatically generated from the models by applying different model transformations. Besides, manipulating models instead of code facilitates the discovery and resolution of errors due to the high level of abstraction. This study presents an approach and framework, called MAndroid, that generates Android-based classic multiplayer 2D board games in a fully automated fashion, relying on the concepts of MDE. Structural and behavioral dimensions of the game are first modeled in MAndroid. Models are then automatically transformed to code that can be run on any mobile phone and tablet running Android 4.4 or higher. In order to evaluate the proposed approach, three board games are fully implemented. Additionally, applicability, developer performance, simplicity and attractiveness of MAndroid are evaluated through a set of questionnaires. MAndroid is also evaluated technically by comparing it to other Android game-development frameworks. Results demonstrate the benefits of using MAndroid.

A Appendix

This Appendix presents the full version of the metamodels and describes them in detail.

1.1 A.1 Game menu metamodel

This section extends the explanations presented in Sect. 4.1.1. Figure 21 displays the complete menu metamodel. The concepts that appear in the metamodel are presented next.

Fig. 21

The menu metamodel for generation of 2D board game in MAndroid

Game: It is the root of the metamodel, from which we start to build the game menu.

Designer: Every game normally keeps essential information on the game designer in this component. Such information includes the designer’s name and contact information. Although it is possible to add the name and details of the game designer as attributes in the Game class, we emphasize its role creating the Designer class. Besides, this is more convenient if we consider future extensions of our tool, such as the possibility of having several designers.

Menu: The game menu is composed of a combination of pages in our MAndroid approach. A page can either be a MenuPage or a page where the main process of the game is started.

MenuPage: Menu pages are like a canvas, so we can design their user interface by using different graphical elements. Here, the user can build as many pages as desired. The order of these pages is considered.

SplashPage: Most mobile phone games contain a page for some general information such as name, version and developer. This page opens after entering the game environment and, after a few seconds, it transfers the game execution to the next page. Such a page can be placed in the game using the SplashPage component.

GamePage: There is always a page in the game for the main process. The main game process in a board game takes place by throwing a die, or moving an element. This page is built with the help of the GamePage class. For instance, Fig. 4 shows all the pages of the Tic-Tac-Toe game developed using MAndroid. As shown in the figure, the game is built using three pages, including, from left to right, a SplashPage, a MenuPage and a GamePage.

Variable: Variables are used to give the user the ability to change desirable components placed in the game, what allows to use not only predefined settings. A Variable needs a name, a type and a desired value that could be later modified.

Resource: This component is used to add resources like images, sounds and XML files to the game. All these resources must be later materialized as separate files to be used to build the game menu. The file names are used to identify them. It is important to consider the Android OS rules when naming these files as it does not allow using repetitive names and capital letters. As future work, we plan to let the user specify any name for these files and automatically convert these names to Android valid names.

MainFrame: Every menu page consists of a main frame. As its name suggests, it acts as a frame that holds all other components of the game menu, such as control components. This frame can be horizontal or vertical depending on the game implementation patterns.

Box: MAndroid introduces a method called the Box Design Method to design the user interface of every page. This enables the user to design the user interface of every page without being involved in the technical details related to Android user interface designing such as layouts. Most of the designs that are built using LinearLayout, GridLayout and TableLayout in Android will be implementable using this method. This method divides every page into a set of columns and rows, which are placed together to build a game page. Then, a concept named Box is used to place various graphic components in the page. Every box is in fact a space in the page that can hold a graphic component. Adjusting the size of these boxes on each page is done in proportion to the display size, so that the design can be properly displayed on devices of different sizes and responsive designs can be created. Also, boxes can contain other boxes with our approach to create more complex designs. Figure 5 shows how a MenuPage is displayed using this method. The page is made up of 5 different rows and each row holds a number of boxes as well. For example, the second row from the top holds three boxes. The boxes on the right and left are empty spaces that have been placed on both sides to align the row. The box in the middle has been placed as a space to hold a button.

View: This component is used to display the Android user interface components in a page. Every view needs to have a unique identity in the model, which is used to identify it in the entire model. To enhance the understandability of users, the real names of Android components are used in the menu metamodel.

According to the concepts mentioned earlier, it is possible to define the relationship between the game’s menu metamodel and the Game, Menu, MenuPage, MainFrame, Box and View components so as to build the user interface. This approach makes it compulsory for every game to have a Menu component that may contain one or more MenuPages. Every MenuPage needs to have a main frame, represented by the MainFrame component. It is possible to place as many Boxes as we want inside the frame. Additionally, every box can contain a number of boxes or View type components. This provides a convenient way for the user to generate the user interface for each page.

Since the game menu does not require too many View components, we have used and defined only a selected number of Android Views in this metamodel, including Button for creation of buttons, ImageButton for creation of images as a button, ImageView for showing images, TextView for showing text, EditText for getting input data from the user and Space to create blank areas inside a box.

Then, to present visual features in the metamodel, we have defined three classes, namely DisplayStyle, TextStyle and PositionStyle. These classes are separated, as some Views may not need all styles.

The remaining metamodel components are defined next.

DisplayStyle: The display properties of every part of the user interface page can be defined using the DisplayStyle component. Examples of these characteristics are the background image or color.

PositionStyle: This component is used to organize and align all properties related to placing the boxes or other graphic coordinates like width, height, and margins, among others, in the page.

TextStyle: In order to define properties like color, font or size, which are related to displaying text in components such as EditText or TextView that use text, the TextStyle component is used.

Behavior: It is possible to assign behavioral properties to graphical components in the game menu metamodel so that the considered action is performed on user interaction, such as pressing a key or a button. Executable behaviors are defined under the Action component.

Action: This component is used by a graphic component after an event is called in order to define the needed behavior. For example, when a key on the menu is pressed, the “clicking” event is called and naturally the behavior defined to respond to this event is accrued. In MAndroid, only very common actions in games have been defined. For instance, UpdateImageViewAction is used to change the image of a display component. SoundAction allows to perform audio actions, such as reducing or increasing the volume and playing/pausing music, while DialogAction is used to display an “about” window or a message in the game menu. Regarding updating actions, UpdateVariableAction is used to update and refresh the value of the variables defined in the game menu, for which it needs to receive the corresponding updated value from the user using an EditText component, while UpdateTextViewAction may be used to change the text displayed by a TextView component in the game page. Finally, since this approach is based on a set of pages, one of the most important requirements is the possibility for shifting between pages. This can be a shift between the current page and the next or previous ones, or to a specific page number, to the GamePage or exiting the game. This is managed by the TransitionAction component.

1.2 A.2 bGame structure and behavior metamodel

This section extends the explanations given in Sect. 4.1.2. Figure 22 displays the complete metamodel proposed for the game behavior and structure according to the MAndroid approach. In the following, explanations for the different components of the metamodel are provided.

Fig. 22

The game structure and behavior metamodel in MAndroid

Game: Similar to the game menu metamodel, modeling is started from the most basic component, which is the game component. This component provides integration between the menu and game metamodels to have a uniform understanding between them.

GamePlayFeatures: Some general features of the game, such as the number of players, use of dice and the type of dice in the game are defined with the help of this component.

UIFeatures: As mentioned earlier in the game menu metamodel, the declaration of a user interface related to the process of a board game is performed in the GamePage page. Because of the differences between the implementation techniques in static and dynamic user interfaces, all the graphic coordinates in the GamePage have to be drawn completely independent from other pages and in a dynamic way using the graphic libraries of Android. However, the user interface in the game menu pages are of a static form based on XML files. To be able to create diverse GamePage pages, some features of this page are abstracted and are placed in the UIFeatures component. This enables the user to personalize the game page display by allocating desired quantities to these features.

For instance, Fig. 7 represents the general pattern designed for the GamePage in MAndroid. The design is made up of three parts or panels. Top Panel contains the menu button and two spaces for displaying information of the two players. These spaces are provided depending on the number of players playing the game, and are called Player Box. The middle panel, declared as the Board Panel, contains the required space to place the board component. The Bottom Panel can contain the throw dice button and two other spaces to display the information of two additional players, depending on the number of players and game style. Every Player Box contains two different spaces to accommodate desired texts, which might be the player’s name, points, turns, etc. This space is separated by a line that passes through the box. Every Player Box is made up of an internal and an external space, which may have different backgrounds.

GameVariable: Undoubtedly, designing a game requires declaration of many variables. Although many of these variables are declared in our MAndroid approach as prerequisites, the GameVariables component allows to declare further variables.

Board: The most important and basic concept in the structure of a board game is the board. In board games, the board is the place that accommodates all the components of the game. Naturally, every board game needs to have one board and the game cannot be executed without it.

Tile: In the MAndroid approach, every board is made up of several matrix components called tiles. These tiles are locations in which game elements can be allocated. Since the board has to be a rectangular or square space, every tile can be easily identified using its row and column index number. The numbering of rows and columns is started from the top left corner with zero. The attribute number is used to calculate the row and column of tile, which makes it more simpler for the user and also it is more dynamic in the process.

Player: Since MAndroid aims to generate multiplayer games, we need the concept of player in our metamodel. It is not possible to declare more than four players in order to consider only those games that can be displayed on a single screen. Additionally, by defining more than four players, the displaying limitations for presenting all the details of the game may happen.

Element: The element is an important component in board games. The progress of a board game is highly dependent on the movement or position of elements. Every element belongs to only one player and must always be in a tile. In every board game, players may have multiple and different elements; for instance, in chess, a player may have elements like the pawn, knight, bishop, etc. Generally, the structure of board games in MAndroid is formed by the board, tiles and the elements. Figure 11 displays this concept in the Othello game. In the figure, the board is made up of 8 columns, 8 rows and therefore 64 tiles. MAndroid supports both structural and behavioral features. It is possible to assign any image to an element, in terms of its structural aspect. Additionally, it is possible to modify the behavior of the element. Thus, elements move between tiles, get visible and hide, and are added or removed from the board. These are the required operations for an element in a real board game.

Behavior: The most challenging part in designing a game is defining its rules. UML structural diagrams such as class diagrams do not provide all necessary features to model the behavior and rules of the game. Therefore it is necessary to use UML behavioral diagrams, such as state machines. For this purpose, a new method has been proposed in the MAndroid framework that combines the concepts used in class diagrams and state machines in order to model the game behavior using Ecore diagrams.

The game behavior in MAndroid is made up of three components including condition, action and event. Events are executed by the player during the game. For example, throwing the dice is an event that is called by pressing on the dice icon. If an event component is reached during the game flow, the flow will be stopped until the event is called. Condition is another component of the game used to check the correctness of statements and, in turn, decide on the continuation of the game. For example, after an action by the user, in case the element lands on a tile with even number, the game will continue on path A; and if the element lands on an odd number tile, it will continue on path B. Action is another component used to perform several actions that have been defined under the domain of the game. For example, deleting an element from the board when hit by an enemy element is an action. Figure 12 displays the principles of behavioral modeling in MAndroid. According to the figure, the game starts at a singular point and ends in another point. After the game starts, at every point of time, it is at a specific point called State, which can be either an event, action or condition component. A concept named Sequence has been used in this approach to ease the modeling and prevent the implementation of repetitive states. Every sequence is made up of a set of states and does not create any change in the game by itself; instead, it is used to organize and keep in order the states to be used. In case the need to use a sequence more than once arises, the RepeatingSequence component can be used. Figure 12 shows a game that uses 3 sequences and 12 different states. The game enters a state in the form of an event. The flow of the game stops until the intended event is called by the user. Then the game reaches a state or condition where the game can be either directed to the right or left. Finally, if the game is directed towards its ending point, it will end. All behavioral states and rules of the game can be modeled using this method.

Sequence: As mentioned, every sequence is composed of a set of events, conditions and actions. In this approach, the game needs to have one or an unlimited number of sequences to hold the game states. The sequences may be identified and used later for a particular operation with the help of their unique identities. In case there is the need to use a sequence repeatedly, the concept of RepeatingSequence can be applied.

State: In this approach, every state is a unique and effective point in the game that helps to guide the game from its starting point to its ending point. The game flow starts from a point where the isFirstState attribute is true and then the game keeps moving forward with the help of the event’s nextState attribute, which stores the unique identification of the next state, until one of the ending points of the game is reached.

Event: Events are elements that are executed by players and change the flow of the game. The flow of the game is stopped until an event is called by the user. In the MAndroid approach, all events that can possibly occur in a board game have been covered. Examples of these events are throwing the dice, moving an element form an origin tile to a destination tile, touching an element, clicking on it or pressing a tile.

Condition: Sometimes it is necessary to guide the flow of a game to different paths based on the execution of certain events and states or upon satisfaction of certain conditions. The Condition component is used to accomplish this task in the MAndroid approach. Condition is the only state in the game whose output leads to two different paths, whereas all other states have only one output. The condition component has an expression attribute that is a logical statement and can acquire true and false as its value. If the expression is true, the game is guided towards a path whose trueNextState attribute is true, otherwise it is guided to the falseNextState feature. To write an expression in a condition, one must follow the grammar rules of Java, reason why these three attributes are of type EString. Also, it is possible to use predefined as well as user-defined variables. Another conditional component is the CollectionCondition, which is used for writing complex conditions that are applied on a collection of components such as the elements or the tiles.

Action: The action component is used to undertake an action in the game. The actions have been designed by considering the domain of board games, so that all needed actions are possible. All possible actions in the MAndroid approach are explained as follows:

• DoSequence: This action is used to start a sequence from any point. This ability may be used to easily search the predefined sequences for a desirable point from where to start the game.

• RepeatSequence: This action is used if repetitive sequences are needed. With the help of this action, the desired sequence is executed once again from the start.

• UpdateVariable: This action is used in case it is required to change the value of the defined variables.

• StartGame: The action can be used to start the game with showing a welcome message to users.

• ShowDialog and ShowMessage: One of the most important needs of a mobile phone is the display of required messages to the players. These messages can be reminders about the game rules, error displays and displays of players’ scores. Dialogs are separate windows that open on the current page and stay on the screen until their window is closed. Messages are also a form of information that stay on the screen for some time and disappear shortly after. Figure 13 shows an example of a Dialog window and a message window in MAndroid.

• InitialTurnQueue: Applying turns is an important concept in board games. The process of identifying the turns on the starting point may be different depending on the game. In our approach, it is possible to implement it as desired using the InitialTurnQueue component. This action determines the initial turn as the game starts such that all players are placed sequentially in a queue. Every player gets in the end of the queue after their turn.

• ChangeTurnQueue: If the need arises to change the turns sequence while playing the game, this action is used. For example, we might want to relocate or completely remove a player form the turn queue. The ChangeTurnerQueue is used in such circumstances.

• NextTurn: This action is used to shift the turn to the next player in the queue.

• HideElement: Every element has a property called isVisible, which determines whether the element is visible on the board or not. Invisible elements cannot be seen on the game screen, although they do occupy the position in a tile. To hide an element, the HideElement action is used.

• ShowElement: It is used to make an invisible element visible on the board, i.e. it is directly opposite to HideElement.

• DeleteElement: It can be used to remove an element from the game; for example, in case of defeating an opponent element. This action is irreversible and, in order to remove the element temporarily, it must be hidden.

• CreateElement: This action is used to create a new element on the board. The four latter actions, i.e., HideElement, ShowElement, DeleteElement and CreateElement actions cover all the needed operations to be applied on elements in the game.

• MoveElementToTile: This action is used to move an element from a tile to another. To perform this task, the unique address of the element and the addresses of the initial and final tiles are needed.

• DisableTile: Every tile on the board has an isEnable property that shows whether the tile is active or not. In the tile is inactive, it cannot be used to store an element. To make a tile inactive, this action is used.

• EnableTile: This is the exact opposite to the DisableTile element and is used to activate a tile.

• NonMovableElement: All elements have an isMovable property that describes whether the element is movable or not. This action is used to deactivate the movement of an element.

• MovableElement: This action is the exact opposite to the former action and is used to activate an element’s movement.

• UpdateElementUI: Every element can be identified on the board using its image. If needed, the image of the element can be changed using this action. This would result in a change in the appearance of the element on the board.

• UpdatePlayerBoxInfo: This action can be used to change the text displayed by the player boxes in the top or bottom part of the screen.

• PlaySound: This action is used to play a soundtrack or audio in the game, thus resulting in making the game more attractive. In MAndroid, it is possible to play sounds/audios during the game.

• EndGame: This action is used for the end of the game. The moment the game reaches the EndGame action, the final window is displayed and the name of the winner is announced. After this action, game processing is not possible anymore and the game comes to an end.

ExtraAttribute: The player, element and tile components contain a number of predefined properties that cover all the qualities needed to define the structure of a board game. Besides, there is the possibility for defining new properties during the game. This is achieved by the ExtraAttribute component.