Software Architecture Design Flappy Bird Duo

Transcription

1 Software Architecture Design Flappy Bird Duo December 15, 2014 Isley M. Gao University of California, Irvine In collaboration with: Anita Marie Gilbert, Dae Kim, Samuel Mathison, and Tina Bui { gilbera1, daeyk3, smathiso, tinab1 }@uci.edu Adapted from Design Studio 4 from Informatics 121: Software Design I, taught by Andre van der Hoek, chair of the Department of Informatics at the University of California, Irvine 1

2 Table of Contents 1. SCOPE OF WORK PROJECT OVERVIEW GOALS CONSTRAINTS ASSUMPTIONS AUDIENCE GOALS STAKEHOLDERS OVERALL SYSTEM ARCHITECTURE OVERALL SYSTEM DIAGRAM OVERALL SYSTEM DESCRIPTION SERVER INTERNAL CLASS DIAGRAM USER SCENARIO GAMEPLAY SEQUENCE DIAGRAM GAMEPLAY SEQUENCE OF EVENTS ARCHITECTURAL STYLE POSSIBLE ARCHITECTURAL STYLES CHOSEN: CLIENT-SERVER APPENDIX APPENDIX A. DESIGN PROCESS RATIONALE APPENDIX B. GLOSSARY

3 1. SCOPE OF WORK 1.1 Project Overview This document describes the architecture design of Flappy Bird Duo, a new version of Flappy Bird that allows two players to fly through Flappy s worlds at the same time. This mobile game is played over 10 rounds in real-time, where players play against opponents globally, and are paired with players of roughly equal ability. Although the game is not a web application, it is connected to a web page leaderboard where players can see the top performers over various windows of time, and see where they themselves rank. 1.2 Goals Allow two users to play against each other in live time Users should have same enjoyable playing experience as original Flappy Bird Allow users to view online leaderboard of top performers and find where they are ranked themselves Game can match players to play against others with similar ability 1.3 Constraints Cannot be a web based application, must be a mobile application Features cannot deviate from original game design and structure Tapping the screen during a round makes the bird fly 1.4 Assumptions User interface looks identical to original Flappy Bird game Game structure parallels old game style Rating of application is managed by appropriate app store Users cannot pick who they play against, it is fully automated by system Game is cross platform for both Android and ios users Game may be modified or updated by system programmers 1.5 Audience Children Teens Adults 1.6 Stakeholders Game users Google Play, Apple App Store, Windows Store System programmers 3

4 2. OVERALL SYSTEM ARCHITECTURE 2.1 Overall System Diagram 2.2 Overall System Description * Client in our diagram represents either an ios client or an Android client. Clients do not interact with each other. Clients interact with users only through server. ** Data in our diagram represents data that is being sent either from the client to the server, or from the server to the client. [Represented by arrows between client and server] Server s main responsibilities are verifying user information, matching users based on their rankings, assigning a game room to matched users, transmitting data between users through server, storing user records, and providing user records upon request. The webpage is a static website with a leaderboard that displays the username and ranking of each user. Users can view the top performers over various windows of time and search for rankings by username. 4

5 2.3 Server Internal Client Server architectural style Client can be ios or Android Software Application Web Server is Apache and SQL Database 5

6 2.4 Class Diagram *startgame() in Server: This is a simulation of the startgame() in main. This is to ensure that the server will know which player has lost in case the information is obstructed 2.5 User Scenario 1. Player A clicks on the start button on the Home Screen and is matched with Player B by the server. 2. Both players are placed into a game room, and a countdown of three seconds begins. 3. The match starts, Player B runs into an obstacle and dies, and the game starts over again at the three second countdown with the score being Player A: 1, Player B: This repeats for another nine rounds (for a total of ten rounds). 5. At the end of the game, if Player A wins 6/10 rounds, six points is added to Player A s total of games won, and his/her rank is calculated accordingly. Four points is added to Player B s total of games won, and his/her rank is calculated accordingly. We envision that both app devices and the server will independently run the game with the same start time and tap data sent back and forth through the server. For example, for the server once the game begins, the gravity starts and the birds start falling, once the server receives a tap from a player the server updates its instance of the game. This continues until die(). 6

7 Reusability: we are basing our game off of the original Flappy Bird game, so we have used that game framework as the basis for the two player game. We re-used the familiar look of the UI for our version of the game; this includes the main menu style as well as in-game play. Actual physics of the game such as the bird flying, and bird impact with the tube was also kept the same to hold onto familiarity. 3. GAMEPLAY 3.1 Sequence Diagram 3.2 Gameplay Sequence of Events Player A 1. Starts app a. Downloads B username b. 3 second pause 2. Game starts moving, gravity kicks in 3. Player Tap a. Display renders the tap A b. Send tap A to Server Server 1. Receives request to Play: get player B data 2. Creates room a. Find player B : User records are matched b. Assigns players a room 7

8 3. Sends player B username 4. Wait 3 seconds 5. Starts play: gravity starts Player A - Repeat 10 times 1. Wait 3 seconds a. Starts play: gravity starts b. Player A tap c. Render A position on display d. Send Player A tap to Server i. Server 1. Receives Player A tap 2. Stores Player A tap 3. Updates game play 4. Sends Player A tap to Player B e. Request Player B tap from Server i. Server 1. Receives Player B tap 2. Stores Player B tap 3. Updates game play 4. Sends Player B tap to Player A f. Download Player B tap g. Render Player B tap 2. if (Die) a. Render Death Display i. Server 1. if(die) sends Death to Player 2. Send Leaderboard data to Player b. Receive Death from Server c. Receive Leaderboard data from Server d. Render Leaderboard Display Webpage 1. Request Leaderboard data from Server a. Server i. Send Leaderboard data 2. Render Leaderboard Leaderboard: Shows user score on top. Shows top rankings today, past week, month, year, all-time. Based purely on how many rounds you win (doesn t matter how far you get) Users can tie, affects their ranking accordingly. 8

9 4. ARCHITECTURAL STYLE 4.1 Possible Architectural Styles Data flow Conceptually does not have a program counter - executability and execution of instructions is solely determined based on the availability of input arguments to the instructions, so that the order of instruction execution is unpredictable Why we did not choose this: Only successful for specialized hardware (e.g. graphics processing, database engine designs, and parallel computing frameworks) Unnecessary for how simple our program is Shared memory Multiprocessing design where several processors access globally shared memory Several processors sharing same memory allows for simplicity and load balancing Why we did not choose this Costly, limited extensibility (limited to up to 16 processors for best efficiency given cost constraints), and low availability Unnecessary for a small mobile app to use shared memory Flappy Bird - Duo s memory requirement is not large enough to benefit from load balancing to complete tasks Peer-to-peer A distributed application architecture that partitions tasks or workloads between peers. Peers are equally privileged, equipotent participants in the application Clients both provide and use resources Unlike client-server systems, the content serving capacity of peer-to-peer networks can increase as more users begin to access the content Why we did not choose this: Flappy Bird - Duo does not allow users to connect peer-to-peer. It uses main server to exchange game data and user information through the server. Implicit invocation System is structured around event handling, using a form of callback Implicit invocation system components use events to communicate with each other Announcement of events causes a second set of handlers to receive calls Why we did not choose this: Although Flappy Bird - Duo is an event-based game in terms of the tapping event causing the bird movement, the only event that our system needs to have handlers for is when the bird collides with a pipe, thus it would be unnecessary to structure our entire system based on event calling 9

10 4.2 Chosen: Client-Server Architecture Style: Layered Client-Server Definition: A distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Our client does not need to share its resources it simply requests a server s content or service function. A client initiates messages to the server, which waits for a request from the client. The server cannot send messages to the client on its own. Web Server: Apache, SQL Database Apache Open sourced and free Well documented Software is available for a wide variety of operating systems, including Unix, FreeBSD, Linux, Solaris, Novell NetWare, OS X, Microsoft Windows, OS/2, TPF, OpenVMS, and ecomstation Supports a variety of features, including: Server-side programming language support Authentication schemes Popular compression methods Configurable error messages SQL (Structured Query Language) Database Compatible with Apache Well documented Designed for managing data held in a relational database management system, or for stream processing in a relational data stream management system New databases such as Mongo are used for large amounts of data, which is out of scope for our product 10

11 APPENDIX Appendix A. Design Process Rationale We decomposed this system into three actors. These components were chosen as actors for our design process and we used them as we talked through the project. Client: we assume 2 clients per game as users requesting and updating the server. Server: mostly passive. Webpage: similar to a client, but with limited scope to just pull Our classes evolved as we used these actors in our sequence diagram to play the game. Here you can see the pseudo-code to the right being developed along with the object classes as we consider the interaction. A cleaned up version of the sequence diagram. 11

12 4.1 Glossary Flappy Bird game room Google Play, Apple App Store, Windows Store leaderboard user mobile side-scroller game where a player controls a bird, attempting to fly between rows of green pipes without coming into contact with them a virtual place where users are matched with another user of a similar ranking digital platforms that serve as app stores for Android, ios, and Windows phones, respectively a scoreboard showing the names and current scores of the leading competitors any person who plays the game 12