neo tux
play

Neo-Tux Group Members: Latifa Azzam - 10100517 Zainab Bello - - PowerPoint PPT Presentation

Feb 01, 2024 •597 likes •922 views

Neo-Tux Group Members: Latifa Azzam - 10100517 Zainab Bello - 10147946 Yuen Ting Lai (Phoebe) - 10145704 Jia Yue Sun (Selena) - 10152968 Shirley (Xue) Xiao - 10145624 Wanyu Zhang - 10141510 Presentation Overview Conceptual Architecture

  1. Neo-Tux Group Members: Latifa Azzam - 10100517 Zainab Bello - 10147946 Yuen Ting Lai (Phoebe) - 10145704 Jia Yue Sun (Selena) - 10152968 Shirley (Xue) Xiao - 10145624 Wanyu Zhang - 10141510

  2. Presentation Overview ● Conceptual Architecture ● Derivation Process - Reflexion Analysis Concrete Architecture ● ○ Subsystems Overview ○ Subsystems Analysis Unexpected Dependencies ● ● Sequence Diagram ● Design Patterns Concurrency ● Limitations of Reported Findings ● ● Lessons Learned ● Conclusion

  3. Initial Conceptual Architecture

  4. Final Conceptual Architecture ● Derived the modified architecture after mapping the source code components into the architecture subsystems. Added three new subsystems ● Removed the Platform ● Independence Layer

  5. Mapping of Subsystems ● Input System: input, io Controller: achievements, challenges, config, modes, race, replay ● Game-Specific subsystem: items, karts, tracks ● ● Gameplay Foundation: audio, graphics, physics, scriptengine (graphics: animations, font, graphics, guiengine) Library: lib ● Utils: tinygettext, utils ● ● Network: network, online, addons ● Output System: states_screens

  6. Comparison between Original and Revised Conceptual Architecture ● Architecture style modified ● Original Conceptual architecture was layered. Revised architecture is now Object-Oriented ● Low Cohesion and Low Coupling observed in the original architecture ● High Cohesion and High Coupling observed in the revised architecture

  7. Reflexion Analysis

  8. Derivation Process ● Grouped components from the SuperTuxKart source code into subsystems (using the Understand tool) Derived the first sketch of the concrete architecture ● ● Compared the conceptual architecture and concrete architecture ● Investigated the gaps observed from the comparison Decided to perform a second mapping, in which three new subsystems were ● added: utils, library and network. ● Also removed the Core System

  9. Concrete Architecture

  10. Subsystems Overview ● Input System Controller ● Game-Specific Subsystems ● ● Gameplay Foundations ● Utils Library ● Network ● ● Output

  11. Input System ● Components: input and io ● Input: responsible for obtaining input from the user. IO: transfer data to or from a computer. ● Controller Components: race, mode, config, achievements, ● challenges and replay ● responsible for distributing data to the appropriate subsystems depending on the user’s input stores data on the game challenge and the player’s ● achievements.

  12. Game-Specific Subsystems Components: items, karts and tracks ● ● Items: contains the powerup obtained from the giftboxes ● Karts: contains 3D Kart model and the properties of the karts. It also contains several animations such as the rescue animation for a specific kart Tracks: contains information about the various tracks in the game ● Gameplay Foundations ● Components: audio, physics, graphics, and scriptengine ● Audio: controls the sounds of the game Physics and graphics: shows the collisions between the game objects ● Scriptengine: responsible for the game code ●

  13. Utils ● Components: game utils and tinygetext ● Game utils provides facilities such as management of protocols in the game ● Tinygettext deals with the language options in the game Library ● Collection of the precompiled routines the game uses ● Contains bullet collision and dynamics, irrlicht engine, angelscript and zlib. ● Angelscript is the scripting language used in the game ● Zlib is used to compress files

  14. Network ● Components: network, addons, and online ● Responsible for player profiles, storing online related properties ● Addons: downloadable extensions ● Online: HTTP(s) requests, sign in process Output System ● Components: state_screens ● Responsible for generating output depending on the player’s input

  15. Subsystem Analysis: Controller ● Race and Mode - works with all the other subsystems Replay - communicates with gameplay foundations and game-specific ● subsystem ● Config - interacts with gameplay foundations and network ● Challenges - transfers data between gameplay foundations and game-specific subsystem. Output system also depends on challenges Achievements - Output system obtains data from achievements ●

  16. Subsystem Analysis: Controller

  17. Subsystem Analysis: Gameplay Foundations ● Graphics ● Physics ● Scriptengine ● Audio

  18. Unexpected Dependencies Conceptual Architecture Concrete Architecture

  19. Controller and Game-Specific Subsystems ● Controller components: challenges, replay, config, race, modes, and achievements Game-Specific components: tracks, karts, items ● ● Unexpected Dependency: controller depends on game specific subsystem ● Challenges, Replay and Race depend on karts and tracks Modes depends on tracks, karts and items ● Config depends on karts and items. ●

  20. Controller and Game-Specific

  21. Game-Specific Subsystems and Gameplay Foundations ● Game-Specific components: items, karts, tracks Gameplay components: audio, physics, scriptengine, Graphics (animations, ● font, graphics, guiengine) ● Unexpected Dependency: game-specific depends on gameplay ● Karts depends on every components in gameplay except scriptengine Items depends on physics, graphics and audio ● Tracks depends on evey components in gameplay except font ●

  22. Game-Specific Subsystems and Gameplay Foundations

  23. Output System and Game-Specific Subsystems ● Output components: state_screens Game-Specific components: tracks, karts, items ● Unexpected Dependency: Output depends on Game-Specific ● ● State_screens depends on every components in game-specific

  24. Sequence Diagram

  25. Design Patterns ● Composite design pattern identified from the analysis of the source code

  26. Concurrency Concurrency in SuperTuxKart includes multiple computations performed at the same time. While the game is running: ● graphics and audio are executed simultaneously ● physics exists concurrently with animations ○ e.g the swatter needs the angle calculations (from the physics component) to get the location of the area the kart will be flattened ○ e.g the physics and animations create the kart motion space in the 3D world

  27. Development Team Issues ● Team size: SuperTuxKart needs more contributing developers, testers, and artists to work on the game ● The team had limited influence on the styles of the game Karts since they were created by various artists ● Unfinished work by various contributors to the development of STK Limitations of the Reported Findings ● Not all of SuperTuxKart’s source code were well documented The Understand tool crashes due to bugs ● ● Understand isn’t a real time collaboration tool ● Understand also gives an unclear representation of the dependencies between the concrete architecture’s subsystems

  28. Limitations of the Reported Findings

  29. Lessons Learned ● Using a tool to analyze code is more efficient Ways to analyze a given source code using the Understand tool ● Modifications were made to the conceptual architecture after analyzing the ● source code ● Use of Reflexion Analysis to derive the Concrete Architecture

  30. Conclusion ● Conceptual architecture changed from layered to Object-Oriented added and deleted components ○ ● The Conceptual architecture has high cohesion & high coupling ● Used the Understand tool to extract SuperTuxKart’s concrete architecture Analyzed the architecture’s subsystems ○

  31. References http://freegamer.blogspot.ca/2012/02/developer-interview-supertuxkart-team.ht ml http://supertuxkart.sourceforge.net/doxygen/classIntUserConfigParam.html

Recommend

More recommend