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

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
• Derivation Process - Reflexion Analysis
• Concrete Architecture

○ Subsystems Overview ○ Subsystems Analysis

• Unexpected Dependencies
• Sequence Diagram
• Design Patterns
• Concurrency
• Limitations of Reported Findings
• Lessons Learned
• Conclusion

Initial Conceptual Architecture

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

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

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

Reflexion Analysis

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

Concrete Architecture

Subsystems Overview

• Input System
• Controller
• Game-Specific Subsystems
• Gameplay Foundations
• Utils
• Library
• Network
• Output

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.

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

Utils Library

• 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
• 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

Network Output System

• Components: network, addons, and online
• Responsible for player profiles, storing online related

properties

• Addons: downloadable extensions
• Online: HTTP(s) requests, sign in process
• Components: state_screens
• Responsible for generating output depending on the

player’s input

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

Subsystem Analysis: Controller

Subsystem Analysis: Gameplay Foundations

• Graphics
• Physics
• Scriptengine
• Audio

Unexpected Dependencies

Conceptual Architecture Concrete Architecture

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.

Controller and Game-Specific

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

Game-Specific Subsystems and Gameplay Foundations

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

Sequence Diagram

Design Patterns

• Composite design pattern identified from the analysis of the source code

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

• f the area the kart will be flattened

○ e.g the physics and animations create the kart motion space in the 3D world

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

Limitations of the Reported Findings

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

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

References

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