Concrete Architecture of SuperTuxKart Group Name: Sensible Chuckle Members: Sam Strike, Michael Spiering, Ben Mitchell, Alex Mersereau, Will Gervais, David Cho

Overview Conceptual Architecture Original Revised Concrete Architecture Derivation Process Conceptual vs. Concrete Architectures Comparison Reflexion Analysis Subsystem Analysis Sequence Diagrams Concurrency Team Issues Problems We Faced / Limitations of Reported Findings Lessons Learned Conclusion

Original Conceptual Architecture

Revised Conceptual Architecture

Concrete Architecture Derivation We used an understand to map source directories to our conceptual architecture components Observed the resulting concrete diagram Compared conceptual to concrete, add or removed subsystems Remap source directories that caused unnecessary connections Repeat process until we arrive at our finalized version

Considered Alternatives We considered a layered style but the level of coupling led us to reaffirm our choice of object oriented Including guiengine state_screens in the Graphics subsystem Using a player manager subsystem from our original conceptual diagram Including addons in the Core Systems subsystem

Concrete Architecture Cohesion: Relatively low Strange inclusions of Audio inputs Coupling: Very high Near complete graph

Conceptual Vs Concrete

Reflexion Analysis

Controller Handles user's input Holds information about different hardware controllers (keyboard, gamepad, wiimote) Depends on: Core Systems Libraries Game Specific Subsystems Graphics Physics Hardware Devices

Game Specific Subsystems Stores the game state Properties about game objects Depends on Physics Network Controller Audio Graphics Core systems

Game Specific Subsystems

Game Specific Subsystems Very High coupling, almost a complete graph Results in a difficult maintenance process

Physics Calculates where karts should be moved to Depends on: Libraries Game Specific subsystems Graphics Controller Core Systems

Graphics Render animations of the game and handles graphical processes of the software such as particles, meshes, special effects, shadow and lighting. Depends on: Core Systems Libraries Game Specific Subsystems Physics Controller Audio

Audio Coordinates the playing of sound effects and music Depends on: Game Specific Subsystems Controller Core Systems Libraries

Libraries Third-party tools developed outside of the SuperTuxKart project Relied upon by every software subsystem Depends on: Controller Graphics Core Systems Controller for Wiimoting Graphics for Irrlict Core Systems for error handling

Network Handles player profile management and acquisition of addons Depends on: Core Systems Libraries Game Specific Subsystems Graphics Controller Source code contained the beginnings of online multiplayer support Libraries for irrlict GSS for addons

Core Systems Error handling Synchronise output GUI engine Depends on: Libraries Game Specific Subsystems Graphics Controller Physics

Core Systems

Core Systems utils: crash_reporting, debugging, logging guiengine: event_handler, screen_loader states_screens: all possible game screens io: file_manager

Hardware Devices Separate from the software parts of the architecture The physical device(s) operated by the users that identify user input and display content Depends on: Audio Graphics Audio for playing content Graphics for displaying content

Sequence Diagram #1

Sequence Diagram #2

Concurrency Multiplayer game, multiple hardware input devices that must be handled simultaneously Game State updates track of all player’s karts, power ups, and race stats in real time Audio must be concurrently managed alongside game conditions, not just as background music Download requests take place in a separate thread so they can be interrupted without stalling the game.

Team Issues Difficulty in syncing sound and animations High coupling between subsystems creates potential for failures to propagate Third-party tools and addons need to remain compatible and reliable

Problems We Faced / Limitations of Findings Understand had a few technical issues (pictured right) For some, it wouldn’t even download Some elements of the source code are not being used by the live game (preliminary online multiplayer code) Created increased complexity of architecture diagrams As an outside party, we can only say so much about the rationale behind certain architecture decisions Sometimes guesses can only be guesses

Lessons Learned Once we got a good grasp of Understand, the project came together much more easily Tracing dependencies to their source(s) helped lay some groundwork for Assignment 3 We utilized software to share our architecture and diagrams between group members as it was being developed

Conclusion Heavily revised conceptual architecture Created concrete architecture within Understand and tweaked a few categories Compared revised conceptual architecture with concrete architecture and investigated irrational dependencies Updated sequence diagrams for architectural changes