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 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. Then, the kart/controller subsystem takes each input event and updates the movement and behaviour of the kart accordingly. Output is handled by the state_screens subsystem. Any information that the game shows the player in menus and all information in the game that is not directly rendered by the graphics engine (i.e. minimap, timer, rankings, etc.) are handled by the state_screens subsystem which displays it to the player through the hardware. The actual gameplay is outputted by the graphics subsystem, which is a wrapper for the irrlicht graphics systems, through the camera class.

Use Case The following diagram is the Use Case diagram for the SuperTuxKart:

As for the player is playing the game. Anything happened in the game, the entire player’s move, online players’ move and even AI’s move will all going to the game state. The game state will

7 exchange data with game I/O. the game I/O handle all the change in the game, and go back and forth between the user interface and call the audio and graphics. Also the game I/O will allow online plays, which exchange data between different players. While the player is playing the game, the game state will always update the world information to the game I/O. Then the game I/O will return a new world to game state. After the game state receives a new world from I/O, the game state will update to the world vision. User interface get movement information in a certain time period. This period is constant and there will be player information even the player stands still. The information goes to the game states. Return what is happened to the game world. The game I/O will get the information from other players, and exchange the information to game state. The game state returns an update of the new world to player through graphics and video. Hence, gameplay foundation follows the same steps as this use case from this point on in a certain period time. Even the player did nothing this use case is still processing.

Evolution While we did add it to the architecture, in its current state STK doesn’t have a multiplayer component. It is currently under-development and it is very clear how it is going to be implemented into the game. It is probably going to get implemented in a way similar to the reference architecture. However, we aren’t sure how it is going to interact with other subsystems. The Open-source and collaborative nature of the project makes it even harder to predict the route that it going to be taken. The game’s graphics engine is also a sub-system that can see improvements and modifications in the future. Antarctica relies very little on Irrlicht. It is possible that the team decides to move away from it completely and remove Irrlicht completely. This however wouldn’t change the global architecture as the interactions between the graphics sub-system and the rest are well- defined and it would be a lot easier to simply modify the graphics engine internally.

Conclusion In conclusion, SuperTuxKart’s architecture is a hybrid object-oriented and layered style. After deriving the architecture from the reference architecture and the games major components, we were able to determine the main classes of the source and the dependencies between them. SuperTuxKart’s architecture was particularly difficult to figure out without looking at the because of its massively out-of-date website and documentation. We would often find one page that said one thing, where the next page would say something different. This probably has to do with the size of the project and the amount of developers working on it, but it very much complicates finding certain information that should be simple.

8 Lessons Learned Upon deriving the architecture of SuperTuxKart we immediately noticed that style was not exclusively object-oriented or layered as we had first guessed, rather it was a hybrid of both. The hybrid of architecture styles allows information to be passed between subsystems without alternating the order of operations. Furthermore, because the game is open-sourced this architecture style makes it simple to add modifications. As we progressed into the later stages of deriving a conceptual architecture, we learned about the specific choices the developers of SuperTuxKart made with respect to the choice of subsystems, functions, and architecture compared to other games. We also learned that open-sourced games have far fewer limitations, with regards to finding information on the architecture, compared to closed-sourced. After presenting our findings on the conceptual architecture in class, we were made aware that our presentation lacked a few important points. For the next assignment we will go through the requirements more thoroughly to ensure we cover all aspects.

9 Glossary/Data Dictionary AI – Artificial intelligence API – Application program interface Back end – A part of the game that is not viewable to the user and is used for tasks that the user does not see. Also interacts with the front end. Cohesion – The degree to which the elements of a module belong in together Collision – A situation where two distinct elements occupy the same space Conceptual architecture – A form of architecture that does not focus on details or a complete and concrete implementation Coupling – The degree of interdependence between software modules CPU – Central processing unit DirectX – A collection of APIs for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms Front end – A part of the game that is viewable to the user Game assets – Video, audio, and graphical files that are used in the game Git – A version control system that is used for software development and other version control tasks GitHub – A web based git repository hosting service GPU – Graphics processing unit HID – Human interface device Interface – A shared boundary where two components of a game can exchange information Method – A procedure associated with a message and an object OpenGL – Open Graphics Library OS – Operating system Overhead – Excess resources that are required to attain a particular objective Platform abstraction layer – A layer that handles abstraction between the game and operating system Reference architecture – A template architecture that is used as a reference for a particular use case SDK – Software development kit STK – SuperTuxKart Subsystem – A set of elements which is a component of a larger system SuperTuxKart – A free and open-source kart racing game Wrapper – Software that 'wraps' around another piece of software which adapts it for a specific platform or use case

10 References http://supertuxkart.sourceforge.net/doxygen/?title=doxygen https://supertuxkart.net/FAQ https://github.com/supertuxkart/stk-code/issues http://irrlicht.sourceforge.net/forum/viewtopic.php?t=42157 https://en.wikipedia.org/wiki/SuperTuxKart https://en.wikipedia.org/wiki/Irrlicht_Engine https://supertuxkart.net/Antarctica:_Overview https://supertuxkart.net/Antarctica:_Technical_Details http://blog.supertuxkart.net/2016/07/supertuxkart-092-is-out-and-say-hello.html

11