CONCRETE ARCHITECTURE: SUPERTUXKART The Architects Jake Gibbons – [email protected] Jacob Clarke-Mcrae – [email protected] Hassan Hanino – [email protected] Ryan Tse – [email protected] Dominique Flabbi – [email protected] Athena Fung – [email protected] th November 11 , 2016 Table of Contents TABLE OF CONTENTS ............................................................................................................................ 2 ABSTRACT ............................................................................................................................................ 3 INTRODUCTION .................................................................................................................................... 3 ARCHITECTURE ..................................................................................................................................... 3 DERIVATION PROCESS ................................................................................................................................... 3 CONCRETE ARCHITECTURE ............................................................................................................................. 6 SUBSYSTEMS ................................................................................................................................................ 7 USE CASES .......................................................................................................................................... 11 NEW GAME ............................................................................................................................................... 11 DRIVE ....................................................................................................................................................... 12 DIFFICULTIES ENCOUNTERED .............................................................................................................. 13 LESSONS LEARNED ............................................................................................................................. 13 CONCLUSIONS .................................................................................................................................... 13 GLOSSARY .......................................................................................................................................... 14 REFERENCES ....................................................................................................................................... 14 2 Abstract The goal of this study is to derive a concrete architecture for the game SuperTuxKart, and then compare it to our conceptual architecture, which was designed in our last study. After comparing the two architectures, we ended up slightly modifying our conceptual architecture to be more accurate to the source code of the game. The key parts of our paper consist of our redesigned conceptual architecture, our concrete architecture, descriptions of our subsystems, two sequence diagrams for common use cases, difficulties encountered and lessons learned. We were able to derive the concrete architecture of SuperTuxKart by using a tool called Understand. We uploaded the source code of SuperTuxCart and then grouped all the entities into their respective subsystems. Understand was then able to show us all the function calls or dependencies between our subsystems. This let us build a concrete architecture based on our conceptual architecture. We found that the layered style that we used for our conceptual architecture worked well to represent the actual architecture of the game’s source code. We believe this because when we used Understand to reveal the function calls from subsystem to subsystem, the dependencies included in our conceptual architecture (that is the dependencies from one layer down to the next layer) were usually the dependencies that had the most function calls. The layer to layer dependencies would on average have many more calls than dependencies going up or skipping layers. Once we used Understand to develop our concrete architecture, we were able to visualize how the subsystems actually interacted, and then were able to make changes to our conceptual architecture, making it more accurate. In the end, we had a redesigned layered conceptual architecture, as well as our layered concrete architecture. We continue to believe that the layered architecture style is ideal for the organization of source code in the game SuperTuxKart. Introduction The purpose of this report is to demonstrate the construction of the concrete architecture of the game, SuperTuxKart, in addition to the finalization of the conceptual architecture. With the use of a program called Understand, the game’s source code was mapped into source directories of the conceptual architecture. This process allowed the conceptual architecture to be refined and finalized. In describing the derivation towards the concrete architecture of the system, the report will describe the functionality of the system and the interactions between the subsystems. The discrepancies between the conceptual and concrete architecture will be discussed, particularly the additional dependencies which exist in the concrete architecture. Further analysis of the source code allowed us to describe the interdependencies of the subsystems, notably the unexpected dependencies which were revealed. Updated sequence diagrams are used to describe two of the use cases in detail for a better understanding of how the system and the updated architecture works. Architecture Derivation Process The following diagram is our revised Conceptual Architecture. Through the derivation process of separating entities to make our Concrete Architecture, we found that many of our subsystems were not necessary. This allowed us to refine our initial conceptual architecture and simplify it. By combining some subsystems together (like taking characters and simplifying it to become a “karts” component in the Game Settings subsystem), it actually made it easier for us to map the entities from the SuperTuxKart source code, into our concrete architecture. We decided to stay with a layered style of Conceptual Architecture, because it suited our components well and allowed for a concrete mapping that made the most sense. As seen in the next figure, our Concrete Architecture adopted more of a loose-layered style, but we still think that layered is a good idea because most of the function calls are 3 in-line with the layered style and only a few calls are skipping subsystems, or connecting back up the architecture. 4 Figure 1. Conceptual Architecture Figure 2. Concrete Architecture Concrete Architecture As seen in Figures 1 and 2, the Concrete Architecture is able to be adapted to fit in with our Conceptual Architecture very nicely and allows the mappings of entities into our Concrete Architecture to make a lot more sense. Below, in Figure 3, is the Concrete Architecture mapping given by Understand. This is the diagram at the highest level and following Figure 3 and 4, there is an explanation of each subsystem, and its interactions, in more detail. In Figure 4 we have included the mappings of each entity into the subsystems of our Conceptual Architecture. In addition to the entities seen in Figure 4, there are also some entities that have been put within entities to enforce greater interaction. These entities are listed below. • Enet and Online: Both under the entity of Network within Memory Allocation subsystem • Irrlicht: Under the entity of Graphics within Game Resources subsystem • Bullet: Under the entity of Physics within Game Resources subsystem Figure 3. Concrete Architecture as given by Understand Figure 4. Entity Mappings in Understand Subsystems User Interface The User Interface subsystem controls everything to do with what the user sees, how it’s displayed, the design of all of the menus and screens, and how the user actually interacts with the game. In the conceptual model, User Interface is only dependent on Game Settings because Game Settings is dependent on the beginning of the architecture hierarchy to keep moving down. In constructing the concrete architecture, it was revealed that there were additional dependencies, including bidirectional dependencies between User Interface and most of the other subsystems. Despite not existing in the conceptual model, the bidirectional dependencies were expected and logically made sense. 7 User Interface works with most of the components within Game Settings so that it knows the options to display in terms of the game and race settings. For example, User Interface works with Race Manager within Race for its getNumberofKarts and getNumLocalPlayers functions to determine the number of karts and players under the current game settings. User Interface also works with Memory Allocation mostly for any required user configuration information or online multiplayer settings. It largely interacts with User Config within Config to determine any configuration required for the displayed information. It also works with Network to access any displays regarding the online multiplayer mode of the game. User Interface calls on Game Resources the most. From looking at the source code, it clearly depends on Game Resources for many of its utilities. One of which for example, is the insertValues function so that it can build lists for functions such as buildTrackList. User Interface also works with components such as Graphics within Game Resources for any required visual rendering.