# Project Meeting 1


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


- 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