Estudio de recubrimientos de nanocomposites de matriz epoxi

In order to communicate the software architecture with as many stakeholders as possible I decided to use Kruchten 4+1 views [30] aided with the use of UML diagrams. The archi-tecture used in this prototype builds upon the archiarchi-tecture designed for the first prototype, however there are several changes and additions that needed to take place due to the new functionality added to the game.

Logic View

With the use of this view I describe the functionality of the system, which was described previously in the requirements listed in Section 10.2. Since some of the diagrams are too extensive, I present here a simpler version with only the most interesting modules. A complete version of the diagrams can be seen in Appendix D.

Chapter 10. Game Prototype 65

Figure 10.6: Subsystems composing the game.

The logic view is separated into subsystems for better understanding.

Game Subsystem This subsystem is in charge of the initialization of different variables that are necessary for the game. The most important characteristics are described as fol-lows, the complete diagram can be seen in Appendix D.2.1.

Figure 10.7: Simple version of the game subsystem.

• The KinectController module is responsible of starting the Kinect device. It is de-signed as a singleton class because having many instances of it would create perfor-mance problems due to the amount of resources that the device consumes and the amount of time it takes to start and stop the device.

• The GameConfiguration module is responsible of loading all the game elements specified to run in the game in the corresponding language. This configuration is used in all the parts of the application, hence it is contained in the GameVariables module, a singleton class which encapsulates other important variables to be used in the game sessions.

• Most of the game logic takes place with the combination of the Player, GameLogic and Difficulty modules. They establish the players in the game and the actions to be taken inside the game that modify the game elements that are part of the Player

66 10.3. Game Architecture

instance. Having the game elements being part of the player eases the addition of different players in the game in contrast as being part of a screen.

Screens Subsystem The screens subsystem contains all the different screens used in the game. As mentioned earlier they are controlled by the Screen Management code sup-plied by Microsoft. Of the screens that represent the different parts in the game, the most important characteristics are the following. The complete diagram can be seen in Ap-pendix D.2.2.

• The KinectScreen is a module that inherits from the GameScreen module developed by Microsoft. The main characteristic on this screen is that it contains important fields for receiving input from the Kinect device and gestures recognized by the Gestures Subsystem. Since all the screens of the game have the possibility of using Kinect, all of them inherit from this module directly or indirectly.

• The game mode screens (ArcadeModeScreen, CooperationModeScreen, Versus-ModeScreen) contain different variables needed for gameplay such as players, timers, messages and specific actions that can take place during gameplay such as pause or the activation of a bonus item. The main difference between these screens is the amount of players they manage and the interaction between them. They override the game loop in order to have a specific set of logic actions that need to take place.

• The game manages different kind of menu screens such as the options menu, pause menu, save score screen and the main menu, which inherit from the MenuScreen module that in turn inherits from the KinectScreen module. The reason behind this inheritance is the way in which the player interacts with these screens is different than in gameplay. The navigation actions are predominant over other kind of actions.

• Screens as the GameOverScreen, MessageBoxScreen, ScoresScreen and Waiting-ForPlayersScreen inherit from the KinectScreen module. However, they have a more informational or dialogue nature which reduces their interaction with the player to single commands in order to exit them.

Figure 10.8: Simple version of the screens subsystem.

Chapter 10. Game Prototype 67

Sprites Subsystem The sprites subsystem contains all the visual game elements that are required for gameplay.

They contain the definition of the object and a controller for each of them in order to keep the separation of concerns proper of the MVC pattern. All of the game element models or their visual parts inherit from the Sprite module which has important information regarding the scale, position, texture and even an animation in case it is wanted. The diagram can be seen in Appendix D.2.3.

Gestures Subsystem This subsystem is in charge of declaring and recognizing the ges-tures performed by the players. It builds upon the gesture recognition code made by Cy-berlab. The main contribution here is the creation of the specific gestures used in the game.

The diagram can be seen in Appendix D.2.4.

High Scores Subsystem This subsystem (see Appendix D.2.5) was created by Cyberlab but was modified by me in order to adapt it to the game. It is in charge of saving and retrieving the scores of the players by communicating to the database through a set of PHP files. They parse and encode the information regarding the players and their scores.

Localization Subsystem This small subsystem was created in order to localize the game.

It only contains two small modules that are in charge of using and selecting the correct string resource file according to the language wanted. The rest of the localization, such as game elements happens in the configuration files. The diagram can be seen in Ap-pendix D.2.6.

Process View

Figure 10.9: Flow during gameplay.

68 10.3. Game Architecture

The process view can be seen in Figure 10.9. The process depicted there can describe the behavior of any of the three game modes available in the game. Those events that do not happen in a certain mode simply are skipped over by the logical flow of the game loop.

This diagram is useful to detect possible performance problems that could occur due to a high demand of resources.

Development View

Even though the project was developed only by me, a development view with all the mod-ules is useful to show the separation of the system. The modmod-ules are separated according to their function and degree of independence towards the game. For instance the game logic is the most domain-dependent because it is tightly coupled with the game concept, while modules such as localization and high scores manipulation can be reused in other projects with no modifications done to them.

Figure 10.10: Development View.

Physical View

Most of the necessary resources for the game exist in a single host where the different subsystems described previously can be found. However the game has a common database for all its instances, hence an external database, to which the system communicates through the high scores subsystem. This external device can be considered part of the system.

Chapter 10. Game Prototype 69

Figure 10.11: Physical View.

Scenarios

Through the use of scenarios, the main functionality of the game and its main actors can be seen. While the player actor can perform different actions related to the visualization of the screens their navigation and the actual playing in the game, the game actor reacts to these actions and gives an appropriate response to them. The use of this view is useful to communicate the game idea to all the different stakeholders.

Figure 10.12: The different scenarios in the game.