Flappy Bird Duo

12
Software Architecture Design: Flappy Bird Duo 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

description

Application and Architectural design for a Flappy Bird Game with two players.

Transcript of Flappy Bird Duo

  • Software Architecture Design: Flappy Bird Duo

    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

  • Software Architecture Design: Flappy Bird Duo

    2

    Table of Contents

    1. SCOPE OF WORK .......................................................................................................................... 3

    1.1 PROJECT OVERVIEW ................................................................................................................... 3

    1.2 GOALS ....................................................................................................................................... 3

    1.3 CONSTRAINTS ............................................................................................................................ 3

    1.4 ASSUMPTIONS ............................................................................................................................ 3

    1.5 AUDIENCE .................................................................................................................................. 3

    1.6 GOALS ....................................................................................................................................... 3

    1.7 STAKEHOLDERS .......................................................................................................................... 3

    2. OVERALL SYSTEM ARCHITECTURE ........................................................................................... 4

    2.1 OVERALL SYSTEM DIAGRAM ........................................................................................................ 4 2.2 OVERALL SYSTEM DESCRIPTION .................................................................................................. 4 2.3 SERVER INTERNAL ...................................................................................................................... 5 2.4 CLASS DIAGRAM ......................................................................................................................... 6 2.5 USER SCENARIO ......................................................................................................................... 6

    3. GAMEPLAY .................................................................................................................................... 7

    3.1 SEQUENCE DIAGRAM .................................................................................................................. 7 3.2 GAMEPLAY SEQUENCE OF EVENTS .............................................................................................. 7

    4. ARCHITECTURAL STYLE.............................................................................................................. 9

    4.1 POSSIBLE ARCHITECTURAL STYLES ............................................................................................. 9 4.2 CHOSEN: CLIENT-SERVER ......................................................................................................... 10

    APPENDIX ........................................................................................................................................... 11

    APPENDIX A. DESIGN PROCESS RATIONALE........................................................................................... 11

    APPENDIX B. GLOSSARY ....................................................................................................................... 12

  • Software Architecture Design: Flappy Bird Duo

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

  • Software Architecture Design: Flappy Bird Duo

    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]

    Servers 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.

  • Software Architecture Design: Flappy Bird Duo

    5

    2.3 Server Internal

    Client Server architectural style

    Client can be iOS or Android Software Application

    Web Server is Apache and SQL Database

  • Software Architecture Design: Flappy Bird Duo

    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: 0.

    4. 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 As

    total of games won, and his/her rank is calculated accordingly. Four points is added to

    Player Bs 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().

  • Software Architecture Design: Flappy Bird Duo

    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

  • Software Architecture Design: Flappy Bird Duo

    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 (doesnt matter how far you get)

    Users can tie, affects their ranking accordingly.

  • Software Architecture Design: Flappy Bird Duo

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

  • Software Architecture Design: Flappy Bird Duo

    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 resourcesit simply requests a servers 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

  • Software Architecture Design: Flappy Bird Duo

    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.

  • Software Architecture Design: Flappy Bird Duo

    12

    4.1 Glossary

    Flappy Bird mobile side-scroller game where a player controls a bird, attempting to fly between rows of green pipes without coming into contact with them

    game room a virtual place where users are matched with another user of a similar ranking

    Google Play, Apple App Store, Windows Store

    digital platforms that serve as app stores for Android, iOS, and Windows phones, respectively

    leaderboard a scoreboard showing the names and current scores of the leading competitors

    user any person who plays the game