---
# System prepended metadata

title: Project Meeting 1

---

# Project Meeting 1


![](https://i.imgur.com/928mTGW.png)


## Overall Preview
A platform for user-modifiable games
We feature games which can be played on multiple platforms and where users can change the house rules of existing games

## Overall Preview (for Team's eyes)
- Has base set of games
- Automatic role assignment (depends on game)
- Customization (for us first and not for users)
    - Future Development (Maybe)
        - if Users, then we need a gameID to save settings under database that will be retrieved and stored(favorite a game)
- Users
    - Firebase Login
    
- Room 
    - Room ID (autogenerate)
    - Password (autogenerate)
    - AuthorID 
    - GameID (retrieve rules)
- Kill room if inactive or no user.

## Feature Set
- (min 3) Implemented Games 
- Truth or Dare for first game
- Game Select
- Room Creation
- Track activity in room
- Shutting down inactive rooms 
- Persistent Scoreboards 

Other Todos:
- Automated Testing


## Objective of Proposed System
A web-based platform for a suite of party games that is easily accessible to users.

## Use Cases

#### Creating a Game Room
| | |
| -------- | -------- |
| Name     |  Creating a Game Room  | 
| Objectives | Providing a space that is available for users to congregate |
| Pre-conditions | - Available server<br />- User creating room is not in a current game room<br/>- User is logged in<br/>- User has a profile|
| Post-conditions | **Success**<br/>- Game room is created<br/>**Failure**<br/>- User is told to try again<br/>- Game room has not been created  |
| Actors | **Primary**<br/>- User  <br/>**Secondary**<br/>  - Server   |
| Trigger | User     | 
| Normal Flow | - User makes request to Server to create game room <br/> - Server checks if game room with hashID exists. - Probes for next hashID till return null <br/> - FreeID is found <br/> - Creates game room with new hashID and returns ID to application <br/> User will receive gameID and password required to join <br/> Server will immediately redirect user to join room setting his/her userID as AuthorID  |
| Alternative Flow | - User makes request to Server to create game room <br/> - Server checks if game room with hashID exists. - Probes for next hashID till return null <br/> Server is full or encounteres error <br/> - Fails and returns null to user <br/>  User will not try receive gameID and password required to join   |
| Interacts With | Joining a Game Room     | 
| Open Issues     | - How much must Server respond to User request to join      |

#### Customizing Profile
| | |
| -------- | -------- | 
| Name     | Customizing Profile     |
| Objectives | User is able to change and update their own details.     |
| Pre-conditions | -User has a profile <br/> -User is logged in     | 
| Post-conditions | **Success** <br/> -User profile is updated. <br/>-Updated profile is displayed to other users <br/> **Failure**<br/> -User profile is not updated <br/> -Return error message to user     | 
| Actors | **Primary** <br/> -User <br/> **Secondary** <br/> -Database / server(?)    |
| Trigger | User clicks on "edit profile" button in the app     | 
| Normal Flow | -Server checks if user exists </br> -Server takes user information from database </br> -User updates the info they wish to change </br> -Server checks if user information has changed </br> -If user has edited something, server updates database</br> -Server sends success message to user that profile has been updated </br> -UI changes to reflect the profile update for both user and other users| 
| Alternative Flow | -Database is not updated </br> -Server sends error message to user </br> -UI shows error message that updating of profile failed     |
| Interacts With |  -Checking game history (?)</br> -Displaying of user rank   | 
| Open Issues     | -Limit to how many times a user can update his own profile in a day?     | 
#### Joining a Game Room
| | |
| ---------------- | ------------------------------------------------------------ |
| Name             | Join a Game Room                                             |
| Objective        | User is able to view detailed information about game room, game room contains added user |
| Pre-Conditions   | - User is logged in<br />- User has a profile<br />- Game room is created<br />- Game room is not full |
| Post-Conditions  | **Success**<br />- Game room contains user<br />- User is able to see detailed information of game room (other users, game details)<br /><br />**Failure**<br />- Game room does not contain user<br />- Error message is displayed to user<br /> |
| Actors           | **Primary**<br />- User<br /><br />**Secondary**<br />- Game Room Manager<br />- Existing users in the game room |
| Trigger          | User clicks on "Join Room" button on app                     |
| Normal Flow      | - User makes request to Game Room Manager with user ID to join game room with game room ID<br />- Game Room Manager checks if game room exists<br />- Game Room Manager checks if user exists and is unique<br />- Game Room Manager retrieves user data<br />- Game Room Manager adds user to game room<br />- Game Room Manager sends response to User with success message<br />- Game Room Manager notifies all users in room of User joining the room<br />- User receives success message, User updates User Interface to display game room details<br />- Other users in game room update User Interface to display updated game room details |
| Alternative Flow | - User makes request to Game Room Manager with user ID to join game room with game room ID<br />- Game Room Manager sends response to User with error message, or no response is received from Game Room Manager<br />- User Interface displays error message to the user |
| Interacts with   | Creating a Game Room, Playing a Game user cases              |
| Open Issues      | - How quickly must Game Room Manager respond to User request to join room? (maybe can set authority to join in automatically?) |


#### Checking Game History
| | |
| -------- | -------- | 
| Name     | Checking Game History at user profile     |
| Objectives | User and other users are able to view the user's game history     |
| Pre-conditions | -User exists </br>| 
| Post-conditions | **Success** </br> User's game history is displayed by UI</br> </br> **Failure**  </br> Error message is shown </br>User's game history not displayed| 
| Actors |**Primary** </br> User </br> **Secondary** </br>-Database </br> -Other players checking the game history     |
| Trigger | -A user's game history is clicked on    | 
| Normal Flow | -User requests for game history data </br>-Server checks if user profile exist </br>-Server checks for game history on server </br> -If game history exists, server sends success message to user </br> -User's app receives game history data from databse </br> -UI updates to show game history </br> -If user does not have any game history, show message "No game history"     | 
| Alternative Flow | -User request for game history data </br> -Server sends error message to user, or no response from server </br> -UI displays error message to user |
| Interacts With | -     | 
| Open Issues     | -Game history data is too big (how to display / clear after a certain period?)    | 
#### Display Global User Ranking for Game
|                  |                                                              |
| ---------------- | ------------------------------------------------------------ |
| Name             | Checking Global Ranking for a particular game                |
| Objectives       | User is able to view number of wins in a particular game, on a scoreboard against all players globally |
| Pre-conditions   | User has played game before                                  |
| Post-conditions  | **Success**<br />Scoreboard is displayed for game, with user's score and ranking in focus<br /><br />**Failure**<br />Scoreboard is displayed for game, with message showing user has not played game before |
| Actors           | **Primary**<br />User<br /><br />**Secondary**<br />Server   |
| Trigger          | User clicks "view ranking" for game on app                   |
| Normal Flow      | - User makes request to server for scoreboard information<br />- Server checks if user has played game before<br />- If user has played game before, server sends user scores for top 3 ranking players and |
| Alternative Flow | Text                                                         |
| Interacts With   | Text                                                         |
| Open Issues      | Text                                                         |

#### Customizing of game (?? may be too complex)

## Classification of Requirements

### Functional
- User should be able to create rooms and Server will allocate space from rooms via Firebase login
- Server shall connect to APIs of social to perform account logging to retrieve UserID for profiles
- Server shall provide faciliation of game from start to finish
- Every game room will be allocated by server to a unique identifier which user can join

### Non-Functional
- Scalibility
    - Client-Server Architecture Style
    - must be able to host multiple rooms
- Extendibility
    - Features can be enriched thorugh dev iterations
- Modularity
    - Seperation of Business 
### Other (Business Model, etc)

## Process, Constraints, Risks
Chosen Software Development Process: **Agile Scrum**


- Periods of work will be done in 2-week **sprints**

**Before the sprint:**

- Goals of each sprint will be determined at the start of the sprint in a **sprint planning session**

**During the sprint:**

- On the first day of the sprint, create a **sprint backlog** in the form of **user stories**, which are short descriptions of functionality described from the point of view of the user
- Afterwards, no new items are added to the sprint backlog, they can only be removed
- Design, coding, testing and integration are done concurrently during a sprint.
- Team members works on one backlog item at a time, items are not pre-allocated

**After the sprint:**

- **Sprint review** at the end of each sprint session, demonstrate to product owners (i.e. project meetings, demos to potential users) to collect feedback for improvements / modifications to the feature set
- Note down product backlogs and identify opportunities for improvement

**Why Agile Scrum?**
- Flexibility in changing requirements from sprint to sprint according to user feedback
- Visible features / improvements built at the end of each sprint
- Maximizes use of a cross-functional team - the work of one team member should be inhibited as little as possible by the work of other team members

### Constraints
- Time constraints - quiz / exam weeks can disrupt sprints - some sprints will inevitably be less productive due to these factors
- Quality: we will all be learning as we are building the project, so the overall architecture might not be clean - in fact it's expected to be a bit messy
- Scope: over / underestimating the productivity of the team might require some rescoping of the project - something we hope to mitigate with by using the Scrum methodology 

### Risks
- Security issues might demand rescoping of project / bug fixing / huge refactors
- Architecture needs to be refactored to support key functionality
- APIs used to build our service may not have all the functionality we want - more refactors


### Deliverables
- one big fkin platform



## Project timeline and distribution of workloads

![](https://i.imgur.com/fPvaSb7.png)

- Project Meeting 2 (Week 6)
    - Updates and changes in requirement
    - Use case diagrams
    - Design of different subsystems via UML diagrams
    - Basic features demo
    - Testing plan
    - Set up of Database with basic integrations
    - Evidence of commit record

- Project Meeting 3 (Week 9)
    - Updates and changes in requirement
    - Design of different subsystems via UML diagrams
    - Demonstration of features (wrt Project Meeting 2)
    - Demo of basic test execution
    - Evidence of commit record

- Project Meeting 4 (Week 11)
    - Updates and changes in requirement
    - Demonstration of features (most features)
    - Demonstration of unit tests and system tests (includes user study and crowdsourcing?)
    - Peer Review Report 

- Final Presentation (Week 13)
    - Detailed description via use case diagram
    - Design of different subsystems via UML diagrams
    - Description of Implementation Challenges 
    - Report on Testing
    - Report on software development process
    - Evidence of commit record

- Testing
    - horizontal scaling (ddos)
    - selenium for automating clickthroughs (change to flutter's own test suite?)




# Timeline
- Week 4 
    - Game 1 Design
    - Develop Testing Plan
    - __Sprint 1 (Week 4 - Week 5)__
    - Login
    - Game Select
    - Room Creation
    - First Game for Demo
- Week 5
    - User Testing / Validation
    - Sprint Review
- Week 6 (Proj. Meeting 2)
    - __Sprint 2 (Week 6-8)__
    - Second Game
    - Automated Testing
        - APIs 
        - UI testing with flutter 
    - Clear sprint 1 Backlogs
- Week 7 (Recess Week)
    - Break? (This is a lie )
    - Update Documentation for all APIs and Development of Platform
- Week 8
    - __Sprint 3 (Week 8 - 9)__
    - Misc. Game admin (shutting down inactive rooms, admins leaving rooms, etc)
    - Scoreboards
    - Clear sprint 2 Backlogs
- Week 9 (Proj. Meeting 3)
- Week 10
    - __Sprint 4 (Week 10 - 11)__
    - Third (Fourth?) Game
    - Additional Social Features (outside of game interactions)
    - Clear sprint 3 Backlogs
- Week 11 (Proj. Meeting 4)
    
- Week 12
    - __Sprint 5 (Week 12 - 13)__
    - Tidying up of features (Refinement)
    - Clear _all_ backlogs (final)
    - Prep for Final Presentation
- Week 13 (Final Presentation)
    - Update Documentation for all APIs and Development of Platform



## Technnical Stack
- Flutter(Front-end)
- NodeJS (Express)
- SocketIO 2.0 (Backend Event Handler)
- Storage (Preferably noSQL)
    - GCP (//TODO: Caleb can test)
        - CloudSQL
        - Storage
    - Firebase (//TODO: Caleb can test)
        
## Technical Workload Distribution

- **Caleb (Front-end Engineer)**
    - Designing & Implementing UI layouts with flutter
    - Front-end integration 
    - State manipulation in application
    - Handling all flare animation and illustrations for design
    - Game UX design
    - Integration of Firebase login(front-end)
    - Implementating Google Analytics(?)
    - Developing Tests for frontend
    - Design Company logo
- **Xin Tong (Front-end Engineer)**
    - Building front-end with flutter
    - Integrating front end with real-time features using socket.io 
    - Game UX design
    - Calling of Game platform APIs
    - Social Features UX
    - Testing front-end
- **Lowen (Back-end Engineer)**
    - Demo game logic
    - Game platform APIs
    - real-time communications using socket.io
    - Back-end integration
    - Developing Tests for APIs
- **Shijie (Back-end Engineer)**
    - User accounts and logins (back-end)
    - Designing Social Features (scoreboards, outside of game user interactions, etc.)
    - Developing Social Features APIs
    - Designing database schemas 
    - Developing tests for APIs

Demo
- Adaptibility to games
- Walkthrough

Games
- Truth or Dare
    - generate questions
- Role Assigment
    - actions that role can take
    - facilitation of phases
    - actuals
- JackBox/Cards against humanity
    - Facilitation of phases
    - question can come from user/database
    - User input
    - present Actual/best answer
    - point system to implement
