SuperFunKart http://superfunkart.wordpress.com/ Mahad Amir Alex Globus Annika Nicol Lucy Rowland Alex Weatherhead Matt Williams
Presentation Overview 1. Conceptual Architecture Revisited 2. Concrete Architecture 3. Reflexion Analysis 4. Revised Sequence Diagrams 5. Issues with Concurrency and Team Dynamics 6. Recap
Conceptual Architecture Revisited
Concrete Architecture - Derivation Process ● Dependencies analyzed for each directory ○ Each directory is assumed to be an independent module ● First Attempt ○ Rebuilt conceptual architecture in Understand ○ Missing modules caused issues ● Second Attempt ○ Least dependencies looked at first ○ Grouped modules with high cohesion together ○ Secondary priority to our conceptual Architecture
Concrete Architecture Object-Oriented
Concrete Architecture Observations ● New Components ○ Networking: Allows the system to interface with the outside world. ○ Core Systems: Includes system tools like debugging, vectors, profiling, etc. ● Relatively high coupling between Networking/Rendering and Game-specific ● Two graphics modules ○ GuiEngine handles creation of the HUD and menus ■ Uses data from states_screens ■ Needs data from items and karts etc. in game ○ Graphics provides layer over irrlicht ■ Takes in all data that should go to the screen
Reflexion Framework
Reflexion Analysis: Game Component Description: ● Known as game-specific; includes the modules that encapsulate the game world for STK. Comparison of Architectures: ● Conceptual ○ Serves primarily as a client to the layer below it, Utility. ● Concrete ○ Highly coupled with most other major components. Depended on mostly by Rendering, Networking, and Configuration.
Reflexion Analysis: Networking Component Description: ● Provides the system with an interface to the outside world. Comparison of Architectures: ● Conceptual ○ Not featured in architecture; the game was not designed to be an online game. ● Concrete ○ Highly-coupled with the Game component, as the Network needs to read changes in the game state. Loosely coupled with most other major subsystems.
Reflexion Analysis: Rendering Component Description: ● Includes the modules necessary for system display. Comparison of Architectures: ● Conceptual ○ In Utilities under GUI/HUD; low coupling with Assets layer and Input-Manager in Utility. ● Concrete ○ Highly coupled with Game component, as Rendering needs to know what to display. Also heavily dependent on Core Systems.
Reflexion Analysis: Configuration Component Description: ● Allows the game to change states based in user selected options. Comparison of Architectures: ● Conceptual ○ In Utilities layer under Configuration; loosely coupled to Assets and 3rd-Party SDKS layers. ● Concrete ○ Highly coupled with Game, which needs to get states from Configuration. Depended on heavily by Rendering and Networking. Depends heavily on Core Systems.
Reflexion Analysis: Core Systems Component Description: ● Includes a number of important tools used by the system to perform its duties. Comparison of Architectures: ● Conceptual ○ Largely ignored in the architecture. ● Concrete ○ Depended on heavily by all major components. Depends mostly on Game.
Reflexion Analysis: External Libraries Component Description: ● The libraries used by,but not a part of SuperTuxKart Comparison of Architectures: ● Conceptual ○ Known as 3rd-Party SDKS; services all higher layers and depends on the user’s Operating System. ● Concrete ○ Depended on by every major component.
Revised Conceptual Architecture
Revised Sequence Diagram
Concurrency ● Rendering ○ Updates once every frame ○ Detects changes to camera and objects in world ○ Must be running on it’s own thread ● Physics ○ Updates once every frame ○ Causes changes ○ Gets positions ● Input ○ Must always be ready to get input from the user ○ Should be running at the same time as everything
Team Dynamics ● Multiple Team Leaders ○ Project Leader: Joerg Henrichs ○ Main Developer: Marianne Gagnon ○ Lead Artist: Jean-Manuel Clemençon ● Lack of Cohesive Vision ● Poor Communication ● Conway’s Law ○ Conway’s Law states that: “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
Recap 1. Revised the our conceptual architecture and how we derived the process when breaking down the modules in Understand to re-create the subsystems. 2. Discussed our concrete architecture and what we discovered through our derivation process. 3. We broke down the subsystem and reviewed the differences between conceptual and concrete. 4. Revised our sequence diagram to correlate with the concrete architecture. 5. Discussed the importance of concurrency and reviewed the team dynamics with knowledge of our concrete architecture
Questions?
More recommend
