Game Scheme

[sdg9]

Placeholder to discuss (is this how we want to structure things?)

[sdg9]

I know they favor denormalized schemas

Here is my brain dump of a potential starting spot. I think it will be helpful to put together all our stories on what functionality we want so we can figure out at more of a low level what exactly we want/need to query.

{
    "players": {
        "userA": {
            "name": "Link",
            "games": ["AB6R2"],
            "lastGame": "AB6R2"
        },
        "userB": {
            "name": "Samus",
            "games": ["C3GR2"],
            "lastGame": "C3GR2"
        },
        "userC": {
            "name": "Fox",
            "games": ["C3GR2"],
            "lastGame": "C3GR2"
        }
    },
    "scoreboard": {
        "C3GR2": {
            "questionnaire": "assortmentA",
            "scoreThroughRound": 2,
            "scores": {
                "userB": 1,
                "userC": 1
            },
            "players": {
                "userB": {
                    "answers": [{
                        "response": "red",
                        "isCorrect": true
                    }, {
                        "response": "green",
                        "isCorrect": true
                    }, {
                        "response": "bowserr",
                        "isCorrect": false,
                        "adminOverrideAsCorrect": true
                    }]
                },
                "userC": {
                    "answers": [{
                            "response": "red",
                            "isCorrect": true
                        },
                        {
                            "response": "blue",
                            "isCorrect": false
                        }
                    ]
                }
            }
        }
    },
    "games": {
        "AB6R2": {
            "questionnaire": "assortmentA",
            "status": "lobby",
            "players": {
                "userA": true
            }
        },
        "C3GR2": {
            "questionnaire": "assortmentA",
            "status": "playing",
            "currentQuestionIndex": 2,
            "totalQuestions": 4,
            "hasSubmitted": {
                "userB": true,
                "userC": false
            },
            "players": {
                "userB": {
                    "isConnected": true,
                    "lastHealthcheck": 1509491928
                },
                "userC": {
                    "isConnected": true,
                    "lastHealthcheck": 1509491950
                }
            }
        }
    },
    "questionnaires": {
        "assortmentA": [
            "asdjfaisef",
            "egtasdf",
            "asdfasdf",
            "asdfasdfase"
        ]
    },
    "questions": [{
        "id": "asdjfaisef",
        "question": "What color does Mario wear?",
        "answer": "red"
    }, {
        "id": "egtasdf",
        "question": "What color does Luigi wear?",
        "answer": "green"
    }, {
        "id": "asdfasdf",
        "question": "Who is this?",
        "image": "https://www.mariowiki.com/images/thumb/7/7e/Bowser_-_Mario_Party_10.png/250px-Bowser_-_Mario_Party_10.png",
        "answer": "Bowser"
    }, {
        "id": "asdfasdfase",
        "question": "Which of the following characters shoots eggs?",
        "options": ["Peach", "Yoshi", "Birdo", "Koopa"],
        "answer": "Birdo"
    }]
}

[sdg9]

Some questions

1. Should we hold off on updating points until round is complete, or score as users submit? (in db, regardless of how we display to user)
2. What type of questions do we want to support?
   1. Fill in the blank
   2. Multiple choice
   3. Identify a picture?
3. Are we displaying anything on project during gameplay?
   1. Score up until previous round?
   2. If anyone has disconnected.
   3. If anyone hasn't refreshed healthcheck in x seconds (browser/app running in background or phone screen off)

[sdg9]

So far only thing that doesn't seem straight forward is submitting an answer. Done for tonight I'll let you take a look.

List of actions requiring db interaction

1. Admin
   1. Creates game
      1. Admin client generates random 4-5 character code.
      2. Inserts to scoreboard[code] and games[code] with appropriate initial state.
   2. Starts game
      1. Moves game[code].status to "playing" from "lobby"
   3. Marks incorrect answer as correct
      1. Marks scoreboard[code].players[user].answers[index].adminOverrideAsCorrect = true
   4. Shows scoreboard
      1. Query scoreboard[gameCode].scores
      2. Will need to query each players[player].name for readable name.
2. User
   1. Joins game
      1. Updates players[user].lastGame = gameCode and games[gameCode].players[user] to initial state
   2. Disconnects (or loses connection) from game
      1. Update games[gameCode].players[user].isConnected to false
   3. Submits an answer UGLY, FIX
      1. Pushes to scoreboard[gameCode].players[user].answers
      2. In order to properly do so will need to query
         1. scoreboard[gameCode].questionnaire to get key
         2. Then questionnaires[questionnairKey][questionIndex] to get question key
         3. Then questions[questionKey] to get answer
   4. Submits a healthcheck?
      1. Update games[gameCode].players[user].lastHealthcheck to epoch time
   5. Reconnects to game
      1. Update games[gameCode].players[user].isConnected to true
   6. Waits for next round to complete after submission of question
      1. Awaits for games[gameCode].currentQuestionIndex to increment and/or look at games[gameCode].hasSubmitted[myself]
         1. The former only works if we're maintaining local state, the later if we disconnect/reconnect
   7. Is told game over
      1. When games[gameCode].status is "gameOver"

Out of scope

1. User undoing answer submission

[wsguede]

I like many of these points. This repo was originally intended for the spring/websocket api -- but with firebase i think this repo will die away.

For the time being, i think it can be used to discuss project level requirements and documents (as we cant share issues across apps -- i dont think).

I think we should come up with some mvp features and milestones to add features. We can iterate over them to add more functionality. I agree with you though that getting the full product line or "release" planned out would benefit not having to do rework later.

thoughts.

MVP 1 -- players MVP 2 -- teams, which have players -- tracking over multiple sessions? -- (username/password)? -- sso?

Should we hold off on updating points until round is complete, or score as users submit? (in db, regardless of how we display to user)

Initial thought -- yes. But this was when we owned the backend code. I dont know how easy this will be when we just have a DB to play with. There are 'functions' but i am not sure about that. MVP 2?

What type of questions do we want to support? Fill in the blank yes MVP 1 Multiple choice yes MVP 1 Identify a picture? firebase does allow storage, so i figured maybe yes MVP2

• Identify a music? Release 2?
• Identify a video? Release 2?

Are we displaying anything on project during gameplay? (projector(sp)???) Score up until previous round? If anyone has disconnected. If anyone hasn't refreshed healthcheck in x seconds (browser/app running in background or phone screen off)

I figured to show the Question, just so people NOT on a phone have an easy way of seeing it. ++ maybe the timer for the question? Watch this to see a jeopardy game using react + firebase.

it might be easy to see if someone connects/disconnects from the socket.

when we think Admin we should think WEB (react) when we think 'Player/Team' we should think PHONE (react-native) I dont envision letting players use a webui -- as it would be too hard to detect them looking at another site.

In this aspect -- I think I agree with you that we could start creating stories for the functionality of the 2 components -- and then rehash how we want the DB to look. -- When we create those stories, they should probably live in the correct project.

[sdg9]

I like many of these points. This repo was originally intended for the spring/websocket api -- but with firebase i think this repo will die away.

One thought is to rename this to backend and leave it for zenhub stories (ones that involve firebase + anything else we do that client can't take care of)

[sdg9]

Also do we largely want MVP 1 to be a solution to the xmas party jeopardy?

[wsguede]

MVP 1 to be a solution to the xmas party jeopardy?

yes. Thats what i figured.