sensible chuckle supertuxkart concrete architecture report ...· sensible chuckle supertuxkart...
Post on 01-Sep-2018
Embed Size (px)
Sensible Chuckle SuperTuxKart Concrete Architecture Report Sam Strike - 10152402 Ben Mitchell - 10151495
Alex Mersereau - 10152885 Will Gervais - 10056247 David Cho - 10056519
Table of Contents Abstract ...... Page 2 Architecture Derivation Process ......... Page 2 Conceptual Architecture
Original Conceptual Architecture ..... Page 3 Revised Conceptual Architecture .... Page 3
Concrete Architecture Concrete Architecture Overview ...... Page 4 Conceptual Vs. Concrete ...... Page 4 Reflexion Analysis ...... Page 5
Architecture Subsystems Game Specific Subsystems ......... Page 5 Graphics ..... Page 7 Controller .... Page 7 Physics ....... Page 7 Audio ...... Page 8 Core Systems ........ Page 8 Network ..... Page 9 Libraries ....... Page 10
Sequence Diagrams Sequence Diagram #1 ........ Page 10 Sequence Diagram #2 ... Page 11
Concurrency ...... Page 11 Division of Responsibilities and Development Team Issues .... Page 12 Lessons Learned ...... Page 12 Conclusion .. Page 12 References ..... Page 13
As a free, open-source game project, SuperTuxKart has seen a wide variety of talents and contributions since its release in 2004. A racing game created in the style of the Mario Kart series, SuperTuxKart has players controlling one of a multitude of karts, vehicles in which they race other player- or AI-controlled karts on various tracks.
As with any piece of software, SuperTuxKart s inner workings can be mapped to a layout known as a software architecture. In the previous assignment, we created a conceptual architecture based on what we thought SuperTuxKart s functionality would best fit. This time around, we utilized a program known as Understand to create a concrete architecture, drawing directly on the function calls and interconnectivity of SuperTuxKart s actual source code. We then compared both diagrams and did an analysis on their points of convergence and divergence. Architecture Derivation Process
The first step in the formulation of our concrete architecture was to evaluate our original conceptual architecture from assignment 1 and see if it still held, based on the feedback we received and our new ideas. We revised quite a few aspects, such as introducing the new subcomponents Core Systems and Controller, while eliminating User Interface and Player Manager, among others.
Once we were happy with this new layout, it was time to move from conceptual to concrete. We used Understand to map the source directories of SuperTuxKart to subcomponents in our conceptual architecture, and examined the resulting dependency graph. If we discovered dependencies between subcomponents that just didnt make sense, we traced these connections back to their sources. We either re-mapped directories/files to different subcomponents that might produce more logical results, or we labelled said dependencies as unexpected in our comparison between our two architectures. The dependency graph was then re-examined, and the process was repeated until we felt that no further changes to our concrete architecture were necessary. The result of our efforts is pictured below.
Conceptual Architecture Original Conceptual Architecture
Revised Conceptual Architecture
Modifications we made to our original architecture include the removal of User Interface and the relocation of Player Manager to inside Game Specific Subsystems. We decided that our concept of User Interface in our original architecture was more of a hardware implementation, which did not fit inside the software architecture. We
also decided that the Player Manager was actually too low level; a component of a subsystem rather than its own subsystem. Furthermore, some of the features of Player Manager, such as achievements and config, have a close relationship with other components inside Game Specific Subsystems (and Network, which interacts with Game Specific Subsystems), so it made the most sense to combine the two. Concrete Architecture Concrete Architecture Overview
This is the outcome of our use of the Understand tool with our revised conceptual architecture as a baseline. Conceptual vs. Concrete
As shown in the diagram above, the concrete architecture consists of many unexpected dependencies that were defined from a source code level. Weve taken a look at the origin of these dependencies to find the rationale behind such interactions, which are further explained in each subsystems section. Reflexion Analysis
Reflexion Analysis is a mechanism used to measure the differences between a conceptual architecture and a concrete architecture. This process allows one to define what is absent or misplaced between the architectures by examining the dependencies in the concrete architecture that were not anticipated in the conceptual architecture. This is then followed by an investigation of these unexpected dependencies to decide whether architectural changes need to be made. Architecture Subsystems Game Specific Subsystems
Game Specific Subsystems makes up the core of the gameplay entities that users interact with while playing SuperTuxKart . It stores information about the game state and properties about game objects, such as a kart's speed or weight. It also stores game unlocks and player scores.
An unexpected dependency that we found was that Game Specific Subsystems depended on Network. This is because, when an addon is downloaded from the Internet, the data contained in the addon must be loaded into the game files.
Game Specific Subsystems Internal View Game Specific Subsystems can be broken down into five subcomponents:
Game Structure, Game Objects, Player Management, Scripts and States. Game Structure consists of the race data and different race modes that help contribute to the overall gameplay of a race. Game Objects are the dynamic objects within the race world, such as karts, items, and tracks that are subject to change within the world. Player Management deals with all the achievements and challenges a user can unlock from the game. Scripts holds the script engines for all the dynamic game objects. Lastly, States handles all the various screens a user can encounter while playing SuperTuxKart .
By splitting Game Specific Subsystems into five subcomponents, each
subcomponent was dependent on each other, and coupling was very high. Game Specific Subsystems Full View
In the overall architecture, each subsystem is dependent on most of the five subcomponents within Game Specific Subsystems. This results in a difficult maintenance process for this subsystem because, if the development team wants to make a change, then it will affect many other parts of the architecture. Graphics
The Graphics subsystem renders the animations of the game, and handles graphical processes of the software, such as particles, meshes, special effects, shadow and lighting. Graphics depends on Controller because the input manager is called when new resolution settings are applied. It depends on Audio because sound effects are mapped to specific graphics properties.
An unexpected dependency we found was Graphics depending on Physics.
This is because, when they render a post-processed scene, the code would call for the world's physics directly instead of calling for the game state from Game Specific Subsystems and retrieving physics information from that. Controller
The Controller subsystem handles user inputs with two different manager codes: input and device manager. It also holds information about different types of hardware that could be used to play the game, such as normal keyboards, gamepads, and even wiimotes.
An unexpected dependency we found was Controller depending on Graphics. This is because when a user supply inputs for camera control, Controller is required to call functions inside Graphics, such as getLinearVelocity and applyMouseMovement, to complete the requested camera command. Another example is, while using Irrlicht, the printScreen button would call for requestScreenshot command inside Irr_driver code file, which belongs inside Graphics, to take a screenshot. Physics The Physics subsystem deals with all the physics calculations and properties of a dynamic game object. It receives information about the game state, and changes it based upon the information it has on how all the various game entities should interact. Physics depends on four other subsystems: Game Specific Subsystems, Libraries, Core Systems, and Graphics. Physics needs to receive information about the game's state from Game Specific Subsystems. It also needs to communicate with bullet (SuperTuxKart s physics engine) which is in Libraries.
An unexpected dependency that was found was Physics depending on Graphics. The reason for this is that within the physics source files they would
sometimes check the animation type of a kart in order to set its physics properties. For example, if the animation type of the kart is a flattened kart, they slow the karts speed. Audio
The Audio subsystem handles the overall execution of audio content, handling the triggering of sound effects and background music and the coordination between both. Audio, as expected, contains the audio directory, and depends on the Game Specific Subsystems for information as to the status of the games current state; if an event happens that requires a change of music, such as starting a race on a new track, then the Audio subsystem will step in and make it happen. Audio also depends on Core Systems for debugging and error handling, and is depended upon in turn by the Libraries system due to the presence of third party graphics engines (ir