SuperFunKart http://superfunkart.wordpress.com/ Alex Globus Annika Nicol Lucy Rowland Mahad Amir Matt Williams Alex Weatherhead
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; Evaluate Architecture. 2 5. [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?
More recommend
