web(docs): nicening for submission + doc new scripts

This commit is contained in:
Mark Joshwel 2025-02-02 04:39:32 +08:00
parent b90c86bc98
commit 00349f1b85

View file

@ -3,7 +3,7 @@
for the Developing Dyamic Applications module as part of the Year 2.2 for the Developing Dyamic Applications module as part of the Year 2.2
Integrated Project for Ngee Ann Polytechnic's Diploma in Immersive Media Integrated Project for Ngee Ann Polytechnic's Diploma in Immersive Media
## Game and Data Model ## Game, Stack, and Data Model
### Gameplay ### Gameplay
@ -18,29 +18,51 @@ current storyline/gameplay description:
> daily tasks, which slowly reveal the layers of the teens struggles. The > daily tasks, which slowly reveal the layers of the teens struggles. The
> narrative emphasizes realism, empathy, and awareness. > narrative emphasizes realism, empathy, and awareness.
but because we also are presenting this via a booth-based viva voce ### Stack and Usage
demonstration, we are prentending as if we are the partner Ngee Ann companies
that will presumably be at the booth, and as such this website is more for the
booth runners than the players themselves
as such, the "flow" of backend interaction is as follows: ##### Stack
- Booth Laptop (via this website): make an account to play the game - **Firebase Auth:** for authentication
1. make an account (supabase auth) - **Firebase Realtime Database:** for player data
2. record a message for 'someone going through a tough time' - **Firebase Hosting:** for hosting the website
- upload to supabase storage - **Supabase Storage:** for storing the recorded messages
- store url in firebase realtime database
- Meta Quest: ##### Usage Flow
1. play the game
- with every ingame decision, their choices are recorded in the firebase because we also are presenting this via a booth-based viva voce demonstration,
realtime database we are pretending as if we are the partner Ngee Ann companies that will
2. at the crux of the game, the call from the players 'friend' is actually presumably be at the booth, and as such this website is more for the booth
the recorded message from the booth laptop runners than the players themselves
- fetch from firebase realtime database
- download from supabase storage TODO
- play in-game via unity
3. finish game 1. **Booth Laptop:** show a registration qr code (firebase hosting)
- ending is recorded in firebase realtime database 2. **Players Personal Device:** make an account (firebase auth)
3. **Players Personal Device:** post-sign up, they are innocently asked to
"record a message for someone with mental health struggles"
(stored via supabase storage)
4. **Booth Laptop:** booth runner via a dashboard sets the user as the
"currently playing user" (firebase realtime database)
5. **Meta Quest:** player plays the game, the game using the UID of the
"currently playing user" to record the players choices
(firebase realtime database)
6. **Meta Quest:** at the crux of the game, the call from the player's 'friend' is
actually the recorded message from the booth laptop
1. fetch url from firebase realtime database
2. download from supabase storage
3. play in-game via unity
7. **Meta Quest:** finish game, ending is recorded in firebase realtime database
8. **Booth Laptop/Players Personal Device:** can see the player's choices and ending via their profile page
- players can send their profile page to their friends to show if they want to,
i'll probably this via url parameters (e.g. `profile.html?uid=...`) like the
last group project i was in because we're not using any fancy frontend
frameworks (firebase hosting)
9. **Booth Laptop:** via the same dashboard is able to see:
- the current players' real-time progress
- all past players
- their emails
- and profile pages
- maybe some global statistics if there's time
### Data Model ### Data Model
@ -64,18 +86,45 @@ user
└── callUrl: <supabase storage link> └── callUrl: <supabase storage link>
``` ```
## Technology Usage Overview
- Supabase Auth: for player authentication
- Firebase Auth: for booth manager authentication
- Firebase Realtime Database: for player data
- for players who signed in via Supabase Auth to write persistent data on
sign up, a JWT token from supabase is used to authenticate with Firebase
- Supabase Storage: for storing the recorded messages
- Firebase Hosting: for hosting the website
## Development Setup ## Development Setup
bun is used as the package manager for this project, but npm can be used as well ### Local Development Setup
all you really need is to be able to run `@tailwindcss/cli` and `firebase-tools` [bun](https://bun.sh/) is used as the package manager and bundler for this project,
but npm can be used as well for tailwindcss
**note:** firebase-tools does not work well with bun,
so you will need to use npm for that
everything you need to do is available as a script in the `package.json` file
use `bun run ...` or `npm run ...` to run the scripts
| script | description | bun | npm |
|--------|-------------|-----|-----|
| `css` | build css from tailwind | ✅ | ✅ |
| `build` | buiild css and bundle the website | ✅ | ❌ |
| `dev-css` | build css and watch | ✅ | ✅ |
| `dev-build` | bundle and watch (this does not watch build css on filesystem change, please run `dev-css` separately) | ✅ | ❌ |
| `deploy-live` | deploy to firebase hosting | ✅ | ✅ |
| `deploy-staging` | deploy to firebase hosting on a staging channel | ✅ | ✅ |
| `deploy` | `build` + `deploy-live` | ✅ | ❌ |
### Cloud Development Setup
- Firebase Project
- Authentication
- Email/Password Provider
- Email/Password: enabled
- Email link (passwordless sign-in): enabled
- Realtime Database
- Security Rules: (TODO; if i have time to define them before submission)
- Hosting \
(not strictly necessary)
- Supabase Project
- Storage
- Bucket
- named it `telephonies` but like i don't think it matters
- Enable connection via S3 protocol: enabled (TODO; might not even use this way of uploading)
- Policies: (TODO; if i have time to define them before submission)