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

2. 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

3. Original Conceptual Architecture

4. Revised Conceptual Architecture

5. 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

6. 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

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

8. Conceptual Vs Concrete

9. Reflexion Analysis

10. 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

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

12. Game Specific Subsystems

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

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

15. 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

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

17. 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

18. 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

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

20. Core Systems

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

22. 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

23. Sequence Diagram #1

24. Sequence Diagram #2

25. 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.

26. 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

27. 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

28. 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

29. 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