A “Hands-Off” Look at Supertuxkart

A “Hands-Off ” Look at SuperTuxKart Unnamed Group Adam Gough (10207902) Alperen Aydin (20038328) Howard Song (10141478) Larry Sun (10054473) Zaid Mohmand (10103319) CISC 326: Game Architecture Professor Ahmed Hassan 1 Table of Contents Abstract 2 Introduction and Overview 2 Architecture Hypotheses 3 Initial Hypothesis 3 Revised Hypothesis 3 Major Architecture Components 3 Graphics 4 Physics 4 Gameplay Foundations 5 Resource Manager 5 Operating System 5 Diagrams 5 Dependency Diagram 5 Sequence Diagram (Boost) 6 Sequence Diagram #2 (Starting a Race) 6 External Interfaces 7 Use Case 7 Evolution 8 Conclusion 8 Lessons Learned 9 Glossary/Data Dictionary 10 References 11 2 Abstract This report details our attempts to understand and analyze the conceptual architecture for the game SuperTuxKart. We used the subsystem documentation that was provided to try and get a better understanding of how SuperTuxKart is structured. This report starts off with an introduction and overview of the game and our findings. It then moves to explain how we came to our conclusion that a layered architecture fitted best. Then, the report goes over select major subsystems and explains how they are connected to each other. After a detailed description of the subsystems, it then analyzes how the game deals with external input and output. Afterwards, it goes over a sequence diagram of the event where the player grabs a speed boost power up. The report is then wrapped up with an overview of the game's evolution, a conclusion, and a review of the lessons we learned while researching this topic. Introduction and Overview SuperTuxKart is an open source, cross-platform, free racing game that was first released in 2004 as a reimagining of the original TuxKart game. Its gameplay is reminiscent of Mario Kart but it has developed its own distinct style over time. In 2015 it moved to the graphics engine irrlicht and just recently it further upgraded to the Antarctica graphics engine which allowed the game more graphical options like ambient occlusion and dynamic lighting. Online play is expected to be released with the next stable version which is 0.9.3. We were tasked with the job of analyzing the conceptual architecture of the game and detailing a sequence diagram. This report consists of 4 parts: the evolution of our hypothesis, investigation of the game’s module documentation through an in depth look at the workings of the major subsystems, the external interfaces of the system, and the use case. Initially, we had believed that the architecture of the game was object oriented. However, this hypothesis was incorrect. Through careful investigation of the game’s module documentation, we concluded that the game’s architecture was a hybrid of an object oriented and a layered architecture style. Through looking at the interactions between different subsystems we managed to achieve a better understanding of the workings of the game. From the management of the item system to the interpretation of the input, we learned many things that challenged our initial understanding of the game. The use case diagram, the sequence diagram, and the dependency diagram helped us visualize the system and better understand how it works so that we could provide concrete evidence to support or hypothesis. As an extension of the games subsystems, we took a quick look at external interfaces in the system. Things like the keyboard and screen are entities outside of the scope of the system that the game uses to interact with the player. How the system parsed information from the user and how the game renders objects to present to the player is crucial in understanding a game. We then conclude and review the lessons we learned over the course of our investigation. 3 Architecture Hypotheses Initial Hypothesis After initially playing the game for a short while, we thought that the architecture style the game developers used was surely an object oriented one. With many widely different subsystems needing to trade information with one another, this made sense. If one subsystem needed to get information from another, it would call one of the second subsystems' functions and it would return that information. However, this hypothesis started to break down when we found information on the game website and development blog that suggested otherwise. We found additional diagrams that supported this theory and decided that an object oriented style alone would not suit the game very well. Revised Hypothesis Taking a closer look at the developer's documentation (located on their website) revealed that a hybrid style (taking parts of two different architecture styles) would make more sense than a single style. In this case, we think that a combination of the layered and object oriented style would be ideal. In our derived architecture, the majority of it would suit the layered style. Inside each layer, the object oriented style would be used. The forms a great base for structured communication between all subsystems in the game. This base allows easy communication between components in the same layer, but requires more checking and compliance if the component needs to communicate to a different layer. The downside of this approach is that it requires increased overhead. However, the upside, structured communication, outweighs this. This style works particularly well in the "game specific subsystem" part of our architecture diagram. Major Architecture Components Graphics The graphics component deals with the creation of animations and effects that the player will be seeing on screen. It has a dependency on the ‘Physics’ subsystem because it uses the physics and collision information of the game session in order to render accurate animations. The graphics component also depends on the ‘Resource Manager’ layer so that it can retrieve other game resources like the 3rd Party SDKs. Physics The physics subsystem encompasses all collisions and interactions a player makes in game. Colliding with an object in game is completely dependent on the physics of that game session. Physics processes signals from the Player I/O component regarding player actions and sends appropriate data to the graphics component so it can update what the player is seeing. The main subsystem that the physics component depends on is the gameplay foundations layer. This is so physics can retrieve all data associated with any scripting that must happen concurrently. 4 Gameplay Foundations The Gameplay Foundations component gathers all processed data and makes it accessible to the lower level subsystems. It accesses the graphics and physics component to link the animations of specific actions carried out in the game. Resource Manager The resource manager contains the game's 3rd Party SDKs and resources. This component depends on the platform independence layer as well as the OS component because the 3rd Party SDK’s need to be able to access the hardware on any given platform. Operating System The OS handles the abstraction between the software system and the hardware it's running on. It uses a hardware abstraction layer/component to act as an intermediary between the OS and the system. The benefit to this is that the game can be accessed on multiple platforms because of the limited amount of changes needed to the architecture. Diagrams Dependency Diagram When the user’s control is received from the OS, the user interface sends an event to the Player I/O subsystem. The player I/O subsystem will exchange data online and sent the changes to SuperTuxKart. The Kart system checks that the item exists and passes the changes to the Physics subsystem to change the model of the Kart, in addition to playing any relevant animations. A new map with changes will be built. The Audio and Graphics subsystems will be called and subsequently shown to the user. 5 Sequence Diagram (Boost) This sequence diagram explores when the player uses the Boost power-up. They begin by pressing the bound key for using a power-up (in this case, the space key), which the User Interface picks and decides is the button for using a power-up. This is relayed to the Item subsystem, which checks to ensure the Kart has a valid item and then proceeds to tell the Physics to use that item. The Physics subsystem then forwards a message to the Kart saying that the power-up has been used, which triggers the Kart to update the graphics (call to the Graphics subsystem) and play a sound effect (call to the Audio subsystem). Those last two actions are performed and rendered to the screen, and output to the hardware (respectively). Sequence Diagram #2 (Starting a Race) 6 This sequence diagram explores what communication is happening when the user starts a race from the menu screen. They begin by clicking on a start race button. The user interface recognizes this as the button for starting a race and sends the mouse event to be handled by the Player I/O subsystem. The message is then forwarded onto the World subsystem, which is told to load the world. That subsystem the loads the Kart, recalculates the Physics, and updates all of the respective graphics before rendering it all to the screen. Lastly, track music is triggered from the Audio subsystem, which is output to the User Interface, and then the hardware. External Interfaces SuperTuxKart deals with external information in a couple of scenarios. They are from the input devices and outputting to the computer’s monitor through the state_screens subsystem. The input devices that SuperTuxKart supports are the keyboard and gamepads with more than 6 buttons. The inputs that are received from the devices are first handled by the input subsystem which checks that the input device is supported. All the key events that goes through the input subsystem are then directed to the GUI engine subsystem which handles interactions with menu elements.

Load more