SuperFunKart http://superfunkart.wordpress.com/ Alex Globus Annika - - PowerPoint PPT Presentation

SuperFunKart

Alex Globus Annika Nicol Lucy Rowland Mahad Amir Matt Williams Alex Weatherhead http://superfunkart.wordpress.com/

Presentation Overview

1. STK Architecture - Revisited 2. Enhancement Proposal 3. Software Architecture Analysis Model 4. Possible Approaches to Implementation 5. Impact Architecture 6. Limitations on Findings 7. Issues with Concurrency 8. Lessons Learned and Team Issues 9. Recap

STK Architecture - Revisited

Enhancement Proposal

• Our proposed enhancement is two-pronged; it entails both:

○ Creating an in-game currency, called TuxCoins, which players can earn from racing, and can store in a ‘wallet’ in their local profiles. ○ Developing an in-game auction house, wherein players can, alongside the SuperTuxKart racers (controlled by AI), place bids on community generated add-ons. (Requires creating a new state screen object, and an actual auction sub-system).

Software Architecture Analysis Model

Software Engineering Institute: SAAM - A five-step model used to determine how specific quality attributes were achieved in a system and how possible changes to said system will affect these attributes.1 The steps are as follows: 1. Identify Reference Architecture; 2. Map Reference Arch. to Structural Decomp.; 3. Identify Criteria for Evaluation; 4. Provide Test Cases; 5. Evaluate Architecture.2

[1] https://dzone.com/articles/software-architecture-analysis [2] http://www.sei.cmu.edu/library/assets/ICSE16.pdf

Software Architecture Analysis Model

Quality Requirements Relevant Stakeholders Performance Developers, Players, Modders, Open-Source Community Evolvability Developers, Players, Open-Source Community Integration Developers, Open-Source Community Security Developers, Modders

Approach #1: Client/Server

Description:

• Auction actions do not take place locally
• All actions the client wishes to do are sent to an external server
• The server keeps track each player’s bid and other auction variables
• Information is sent to and from the central server
• Eventually the client is informed of a win or loss and an end of auction signal

Approach #1: Client/Server

Advantages:

• Auctions are more secure; cannot be easily won by modifying memory
• Sending the actions to an external server lifts the computational load from the client
• Keeping track of bidding history online allows modders see which addons are more popular; greater

integration

Disadvantages:

• Requires a client-server sub-architecture
• Reliance on a server architecture to access the auction house could lead to performance issues if

the server has poor uptime

• Concerns with scaling the server side architecture arise with lots of concurrent users

Approach #2: Object-Oriented

Description:

• Auction house is implemented locally
• An auctioneer object and corresponding bidder objects hold implementation logic
• No information is sent to any external server; all calculated in-house
• Winning the auction immediately triggers the add-on module to fetch the winning add-on and place it

in the player’s add-on library

Approach #2: Object-Oriented

Advantages:

• Faster and easier to implement as a prototype
• Does not require an external server
• Reusability; addons are already implemented and a well-working system
• Better integration with existing source code; no RPCs

Disadvantages:

• Auctions are susceptible to modification à la memory editing

Test Cases

System Testing:

• Measure load time of End Screen pre and post TuxCoin addition and compare
• Have the system send an update notification after auction has ended to confirm that subscription

has ended

• Check Player Profile before and after an auction purchase to confirm valid connection to Config

Unit Testing

• Run through Loop Testing with Auctioneer to confirm functionality
• Run Path Testing on AI to confirm behaviour

Impact Architecture: Overview

Impact Architecture: Design Patterns

• One-to-many relationship

○ One overseeing auctioneer object has a relationship with many bidders (multiple AI-controlled and one human)

• Observer pattern allows all dependent objects to be notified of a state change

○ When one bidder’s bid is updated, the auctioneer notifiers all other bidders of the state

• change. The AI players will algorithmically decide whether or not to usurp the other bid while

the player manually decides

• Reduction of Coupling

○ There is little coupling between the bidders, making it easy to add new types if online bidding is implemented

Sequence Diagram

Limitations on Findings

• Approach 1 requires great deal of extra work and a redesign of the game’s

architecture

• Approach 2 is not secure which is concerning to developers and modders
• Auction house method could become stale or appear as a gimmick
• Possibility of running out of items
• Add-ons rely on content-creators

Issues - Concurrency

• Impact Architecture has 3 threads
• Graphics

○ Updates once per frame ○ Already exists in threading model

• Network

○ Already exists in threading model

• AI

○ Needs to be updated constantly as new information is presented ○ Must have knowledge of add-ons as they come in ○ Running on it’s own thread

Lessons Learned & Team Issues

• While integrating our enhancement:

○ Have a better understanding of the how the subsystems interact ○ Inserting new modules in an existing subsystem can be easier than creating a new one ○ Different implementations benefit NFRs differently while being detriment to others

• STK Developers

○ Large project for the amount of developers they have ○ Difficult to integrate the enhancement with the lack of commitment of contributors

Recap

• We proposed an enhancement, and two possible approaches of implementing

said enhancement; the first of which being a client-server approach, and the second an object-oriented approach.

• Both implementations would affect the Game, Networking, and Configuration

subsystems fairly heavily; we chose the second approach, and explored it more thoroughly than the first.

• The effects of our new subsystem were discussed in relation to team

dynamics and concurrency.

Questions?