Match Screen

[jjPlusPlus]

Overview: Time to build some game logic. We can further break this into sub-issues

• [x] Remove all the old Firebase code/logic
• [x] Round "Timer"
• [x] Dev tools
  • [x] As a <Drawer/>
  • [x] Match information
  • [x] Round information
  • [x] Move game configuration settings (dev mode, round length, min players, etc.) to environment variables
• [x] ~Lock orientation to portrait for the entire application~ Moved here
• [x] Round "Leader" View
  • [x] Pre-selection: text input, start round
  • [x] Post-selection: round word, players list + submissions, "accept submission" buttons
  • [x] ~Move the "accept submission" logic (currently called end_round in matchUtils) to an edge fn~ I am fine with this being where it's at
• [x] Round "Player" View
  • [x] Pre-selection: "Waiting for Round Leader to pick a word"
  • [x] Post-selection: Phase I, II, III
    • [x] Phase I: text input
    • [x] Phase II: Camera, submit image
    • [x] ~Phase III: Live camera feed + image recognition~ (In a new issue)
• [ ] Different state after player "submits" their submission
• [ ] Notification when a Player wins a Round
• [ ] Notification when a Round times out with no winner
• [ ] "Spacing" around round start/end
  • [ ] Show a countdown before a match
  • [ ] Show a pop-up message when a round ends with winner information
• [ ] Server logic
  • [x] Automatic round progression when round timer hits zero (database function?)
  • [ ] Automatic round progression if (n) seconds goes by without the round leader picking a word
  • [x] Setup next round (pick next round leader, set status)
  • [x] ~Move Edge Functions to Database Functions (where applicable)~ Will tack this on later...
  • [x] ~Go back and re-implement RLS for storage bucket and database rows~ (in this ticket)

[jjPlusPlus]

We're at the stage where we need to start thinking about how we store the Player submissions each round. There are three paths we could take to do this with varying levels of difficulty to implement. We don't want to spend too much time on this because it is really just an intermediary step before we get WebRTC going.

1. Store the image as a base64-encoded string (varchar) in one of the database tables.
2. We could store it on the players table (which is a JOIN table between Matches and Users), but there are two problems with this approach. The first issue is that we (might not?) don't want to convolute a JOIN table. I'm generally fine with this if it were a good solution. The second and more pressing issue is that the players rows live for an entire Match, not just a single round, so the submissions would persist from round-to-round.
3. Store the player submissions as a structured JSONB column in the Rounds table. The format would tie the submissions for that round to the player ID's. I don't know if the base64-encoded images would be feasible here because of their long character lengths. This strategy might then need to be paired with a hosted image solution (via Supabase storage which uses s3 under the hood). We can talk about this down the road but for scalability reasons we would want to run a daily job to delete images older than (n) hours
4. We could create a new JOIN table called submissions (between Players and Rounds, player_id, round_id, created_at, uri). Again, a join table with "extra" columns.