Concrete Architecture of SuperTuxKart Team Neo-Tux Latifa Azzam - 10100517 Zainab Bello - 10147946 Yuen Ting Lai (Phoebe) - 10145704 Jia Yue Sun (Selena) - 10152968 Shirley (Xue) Xiao - 10145624 Wanyu Zhang - 10141510 1 ABSTRACT This report outlines our concrete architecture of SuperTuxKart. The main points touched in this paper include our modification of our conceptual architecture of the game, the derivation process of the concrete architecture, the use of the reflexion analysis model to guide the investigation process of the unexpected dependencies discovered, in-depth analysis of two of our architecture’s subsystems, walkthrough of a sequence diagram, observed design patterns, and lessons learned. SuperTuxKart’s source code components were mapped into our original conceptual architecture’s subsystems according to their expected functions. Three new subsystems were added in order to logically map the components into appropriate subsystems. We modeled the final architecture to have 8 subsystems: Input System, Controller, Game-specific Subsystems, Gameplay Foundations, Network, Utils, Library and Output System. Our initial architectural structure was layered then we modified it into an Object-Oriented structure in order to minimize the dependencies among the subsystems. We also identified the composite design pattern during the analysis of the config component in the Controller subsystem. The pattern enabled easy addition and removal of elements to and from the config component. 2 TABLE OF CONTENTS 1. Introduction and Overview 2. Conceptual Architecture 2.1. Modifications of Conceptual Architecture 2.2. Comparisons between Original and Modified Conceptual Architecture 3. Concrete Architecture 3.1. Derivation Process 3.2. Unexpected Dependencies 3.3. Description of high level architecture 3.4. Description of subsystems and interactions 4. Subsystem Analysis: Controller 5. Subsystem Analysis: Gameplay Foundations 6. Design Pattern - Composite 7. Concurrency 8. Sequence Diagram 9. Development Team Issues 10. Limitations of Reported Findings and the Problems We Faced 11. Lesson Learned 12. Conclusion 13. References 3 1. INTRODUCTION AND OVERVIEW SuperTuxKart also known as STK, is a free and open-source kart racing game initially released in 2004. STK’s architecture continues to be interesting to analyze and this becomes more evident as we look closer at the source code, made available through the course webpage. We revised our conceptual architecture from the first assignment and mapped the components of SuperTuxKart’s source code into subsystems (through the use of code analysis tool - Understand) to create the game’s concrete architecture. While initially expecting a layered structure, the Understand tool demonstrated that the subsystems could be better fitted into an object-oriented style. We then used the Reflexion Analysis process as a guide during our investigations on the differences between our conceptual and concrete architectures. We also carried an in-depth analysis of the Controller and Gameplay Foundations subsystems. The dependencies amongst each subsystems components with the rest of the architecture were also explored alongside the dependencies within each subsystem. Constructing SuperTuxKart’s concrete architecture did come with challenges however, we were able to overcome them and also learn a lot from the process. 2. CONCEPTUAL ARCHITECTURE 2.1. Modification of Conceptual Architecture Original Conceptual Architecture from the first Assignment With the aid of the Understand tool, we were able to analyze SuperTuxKart’s source code by mapping the source code components into each of the subsystems in our conceptual architecture. During this process we discovered some components that we did not anticipate during the derivation of the game’s conceptual architecture in the first assignment. These components include addons, config, font, replay, tinygettext and util. Although we were able to map most of the components, three new subsystems were added to the architecture in order to complete the logical mapping of the components. 4 The Network and Library subsystems were added to the architecture and we replaced the Core System with the Utils subsystem. In addition, we removed the Platform Independence ​ Layer from the structure because we decided that none of the source code components could be logically mapped into it. After mapping the source code’s components, we changed the structure of our architecture from a layered style to an object-oriented style. Finally, we modified our conceptual architecture diagram to reflect the modifications made. Modified Conceptual Architecture 2.2. Comparisons between Original and Modified Conceptual Architecture We changed the structure of our Conceptual architecture for SuperTuxKart from a Layered Style to an Object-Oriented Style. The reason for this change was to effectively represent the dependencies amongst the subsystems. As identified in the first assignment, our original conceptual architecture had low cohesion and low coupling amongst its components. However, with the modification of the architecture into object-oriented style the structure now has high cohesion and high coupling. It has high cohesion because the new subsystems added were able to reduce the amount of functionalities carried out by each component of the architecture. 3. CONCRETE ARCHITECTURE 3.1. Derivation Process We derived the concrete architecture of SuperTuxKart through the use of the Understand tool and the Reflexion Analysis model. Understand is a code analysis tool used to analyze and visualize a program’s source code. Using our conceptual architecture as a guide, we mapped the game’s source code components into the conceptual subsystems. From this, we were able to derive our first sketch of the concrete architecture. 5 Reflexion Analysis With the initial mapping of the source code components, there were a lot of dependencies between the architecture subsystems than we anticipated. Some of these connections were rational, while others were illogical. So we decided to re-group the components in each subsystem in order to improve the coupling and minimize the dependencies among the subsystems. For the second mapping, within the Gameplay Foundations we created the Graphics component to be composed of the modules that deal with the creation of the game’s graphics. We grouped the animations, font, graphics and guiengine into this component. With this new ​ mapping, the team was able to produce a concrete architecture for SuperTuxKart. Next we analyzed the code to understand how each subsystem functioned as well as the rationale behind the unexpected dependencies found in the architecture. 3.2. Unexpected Dependencies A fair share of the dependencies in our architecture were logical and easily predicted. However, there were some dependencies that were not anticipated. Upon further investigation they seemed intuitive and we ought to have expected them. Conceptual Architecture Concrete Architecture 6 Controller and Game-Specific Subsystems The first dependency to be investigated is the Controller depending on the Game-Specific Subsystem. The controller depends on the game-specific for over seven hundred class calls and this makes logical sense considering the game-specific subsystem is responsible for the objects in the game. The challenges in the controller calls on the karts component of the game-specific subsystems to unlock a specific kart whenever the player completes a challenge. The controller also contains the modes which depends on the game-specific tracks, karts, and items to obtain the track objects for the world frame. Replay in the controller depends on karts and tracks to obtain the replay event information. The game also has the config component in the controller using the conSTKconfig() method to call the KartProperties class in the game-specific to initialize a kart object. Also, race in the controller depends on karts and tracks to get the number of tracks from getNumberOfTracks(). Game-Specific Subsystems and Gameplay Foundations The next unexpected dependency to be discussed is the Game-Specific Subsystems depending on the Gameplay Foundations. The karts in the game-specific depends on every component in gameplay apart from the scriptengine. An example would be when a kart produces a sound such as a beep sound by accessing the sound file in gameplay. Also, the tracks component in the game-specific subsystem depends on all of gameplay’s components except the font module. For instance, tracks calls graphics to set the tracks materials’ texture and color. Output System and Game-Specific Subsystem The final unexpected dependency is the Output System depending on the Game-Specific Subsystems. There are over six hundred class calls from the output to the game-specific subsystem. Output mainly depends on the tracks and karts components of the game-specific subsystems. This is seen when the state_screens calls tracks to display the name of the kart next to it. For a player that's the name of the player, and for an AI kart it's the name of the driver. 3.3. Description of high level architecture The concrete architecture consists of eight subsystem: the Input System, Controller, Game-specific subsystems, Gameplay Foundations, Utils, Library, Network, and Output System. The two main components of our architecture are the Controller and the Gameplay Foundations. The Controller contains the achievements, challenges, config, modes, race, and replay modules. It is responsible for distributing