Tracking Player and Game state

[zatkiller]

We should decide on the specifications we need to track for a game and player, as this will be needed to track the scores and for player who are trying to reconnect to the game in offline mode.

Specifications (Outdated, see latest comment)

Game state:

• Game ID

  • Game / Room ID because there can be multiple rooms / games occurring at once
  • Can be done using the Socket ID of the host (will be unique) wish some string concatenation / hashing for lower chance of collision

• Phase (enum):

  • Following the flow of Chester's wireframe, it can be something like
    Lobby -> Awaiting Answer -> Choosing Person -> Answer Reveal -> To Next Question -> End Game

• Order of guessing

  • The order of guessing till the question # of guessers left = 1, to make our lives easier, we can generate a random order at every question

• Current Guesser:

  • Linked to previous, can be implemented in multiple ways

• Current Question

  • Linked to previous, really depends on implementation and how we want the questions to be displayed (randomized, etc)

• Player Count

  • End game when count drops below 3

• Players of the game

  • Player have dynamic IDs, determined by their socket ID

• Current Answer

  • When user does a match, n

Player State:

• ID
• Can use their SocketID, which changes every time browser refreshes
  • Switching to UUID generator for clientId
• Name
• isGuesser
• isHost
• Score
• Choice (If Guesser)
• Answer for current question

Any other specifications you guys think we can cut out, or any specification we are missing, especially the FE pros, as I only have a rough idea of how it will be implemented on FE @chesterhow @AudreyFelicio @wenhaogoh

[zatkiller]

Relational DB Performance for Tracking State

Also, something else that we might need to consider is the use of SQL for tracking the game / player states. This is because hitting the DB with queries might be too "laggy" for a game, but I'm not quite sure of this and we will only know once we try it out.

If it's too slow, we can consider moving the state tracking into a cache like Redis (I'm familiar with it) and include it in our petition if we find the performance too slow.

[chesterhow]

Looks generally okay to me! Just have a few queries:

1. From the game state, are we able to retrieve the scores and answers of all players?
   • For instance, some screens we need to show all answers, and some screens we need to show all scores
2. Will the timers be managed solely from the frontend?
3. I think we might need a flag for player state to indicate if their answer has been guessedalready, something like an isGuessed?

[zatkiller]

@chesterhow

1. Yea, if we r switching from from Relational DB to Redis, we can store all answers and scores under a common key-value pair for easy retrieval, but I've yet to think of the structure of the Redis thing
2. Timer will have to be managed from FE. The way I see it working is that when a timer is up, we can send a "Times up" event which will be read by the server. The FE side can then close that current phase, while the backend will then send another event to FE, telling them who's next
3. This one depends on gameplay flow. I remember that day when we did the trial run, someone answered twice XD. But yea we can have a player flag for that if we don't want to let the same person answer twice

[zatkiller]

Also just a heads up for FE peeps, for Frontend side, might need you to track 2 things, a client ID and Socket ID. Client ID can generated using UUID lib and the socket ID (auto generated by socket IO) for tracking on the BE side.

I realized socket ID alone isnt enough because of offline persistence.
Player loses connection momentarily (but still in game) -> connection reestablished -> new socket ID.

Will need client side to maintain a client ID and retrieve all info for particular user on reconnection, but I can settle the client ID -> scores, socket ID etc mappings under Redis which I will think of once we get approval

[chesterhow]

This one depends on gameplay flow. I remember that day when we did the trial run, someone answered twice XD. But yea we can have a player flag for that if we don't want to let the same person answer twice

Oh no I don't mean answering twice, I mean like if the player's answer has been guessed by someone else already, their name and answer should be excluded from the list of names and answers to pick from for future turns.

Also just a heads up for FE peeps, for Frontend side, might need you to track 2 things, a client ID and Socket ID. Client ID can generated using UUID lib and the socket ID (auto generated by socket IO) for tracking on the BE side.

Noted! 👍

[zatkiller]

@chesterhow

Oh no I don't mean answering twice, I mean like if the player's answer has been guessed by someone else already, their name and answer should be excluded from the list of names and answers to pick from for future turns.

Oh yea ofc, this can be managed in Redis, once the answer has been guessed i will just remove it from the not yet guessed answer list in Redis

[zatkiller]

Was setting up the web sockets and Redis storage earlier, made a little changes to the specifications.

For most events, especially room and gameplay events, the new updated game state object will be sent back to Frontend based on the event and data sent to Server. This GameStateobject data should be consistent across all clients across the game room.

The specification of the objects look like this.

Game state:

GameState attributes:

• roomCode - roomId
• phase - the phase the game is at (enum)
• host - clientId of the host
• currQuestion - the actual question
• currAnswerer - clientId of the person answering
• playerCount: num, deletes room from server if 0
• questionsLeft: num
• selectedPlayerId: string,
• selectedAnswer: string,
• players: map<clientId, PlayerState>

PlayerState

PlayerState is a json object with the following attributes, to track the state of players

PlayerState attributes:

• username - string
• connected - true
• score - number
• currAnswer - JSON object, with 2 attributes
  • isGuessed (boolean) , which becomes true when someone matches the answer to user correctly
  • value (string), which is the actual answer

This is to reduce the num of calls on Redis and I think it will be easier for FE side to map and display certain info, such as the username to scores at the end, as well as Client ids to answers.

The order of guessing and and order of questions will be handled by the backend and sent through events which I will specify later on (something like next question, next guesser events, with the next question text / guesser id being sent)

Also decided to remove the choice field from PlayerState, cause I realize that this dosen't need to be tracked before the timer / player clicks submit. (If user loses connection, then can click on the same choice again before sending to server).

Do you guys see any potential issues with the slight modifications to the specifications?

[chesterhow]

I'm not sure about the BE side, but for FE i will need a way to determine which names and answers to show (i.e. hide those that have been guessed correctly already). So I'll probably add a flag to PlayerState like isGuessed.

[zatkiller]

For BE, after FE sends the correct answer (guessed clientID + answer and client ID of who it belongs to), I was thinking that I can set the currAnswer to an empty string once it is answered correctly, in which FE can decide not to render.

E.g.
So if my answer is answered, not it becomes...

MyUserID: {
currAns:""
...
}

Will this way be better or do you still prefer the isGuessed flag, which I can add in

[chesterhow]

I think isGuessed flag better, so that we can still display the guessed answers, but just that they are grayed out

[zatkiller]

Oh I see alright, in that case, I will prob do it like this for the player state

clientID(Player ID): {
  currAnswer: {
      value: String containing the actual answer
      isGuessed: Boolean  to see if someone has guessed it
  }
}

Is this alright