MVP client flows

[bwong858]

Room creation

• A user must be able to create a room
• A uuid and corresponding URI for sharing must be created for others to join the room

Team delegation

• There must be at least two players (one spymaster) per team before a game may begin
• Users must be able to move between teams
• Users must be able to delegate one and only one spymaster per team
• There must be an option to randomize teams and spymasters

Game / Board

• Boards must be generated with randomized words from the word bank
• A board map must be randomly generated
• Red or blue is assigned 8 words, and the other 7 words, at random. The team with 8 words goes first.
• The spymaster submits a clue and a number of words for the clue
• At least one guess must be made per turn
• A player whose team's turn it is must double-click a tile (so as to avoid accidental single clicks) in order to submit a guess for their team
• If the guess is correct and the team has N + 1 guesses remaining, where N = number of words for the clue, the team make another guess or decline to make additional guesses
• etc; standard rules

Starting new games

• Users must be returned to the Teams page with the delegations from the current game

[bcspragu]

I did a few things:

• I checked off the items in your list that already exist (most of them in web/web.go or boardgen/boardgen.go)
• I wrote up this state diagram, which outlines what I plan to add for joining rooms, starting games, and getting updates. The basic idea is that all actions (joining, starting, sending guesses, etc) happen as standard HTTP/JSON POST requests, and all read-style updates (game has started, clue has been given, guess has been confirmed, game is over, etc) come in over WebSockets as JSON-encoded messages. None of that exists yet, but I'm working on it now.

One unknown is how to confirm guesses among a group of people. E.g., if there are five operatives on the red team, how do they make a guess? I'd like to model it on how some of the Jackbox games work, where users can indicate where they're thinking of voting, and then 'confirm' their vote to lock in. Folks would see the tentative votes on the board, and once a majority had locked on a single one, it gets selected. I'll spec out the API for that once the above stuff is done.

[bcspragu]

Okay, another update. The majority of the game is implemented at this point, including tentative + confirmed guesses for players, requiring a majority to actually send the guess in. The only things missing from the list above are:

• At least one guess must be made per turn - It's more state to manage, so I'm happy just letting people chicken out for now if they really don't know what to guess.
• Anything related to changing roles - Right now, folks select a role when they call the joinGame endpoint, but I agree with the concept of having a game 'lobby' where roles don't get assigned until the game starts.

Edit: The last thing I need to add (aside from unit tests, play testing, and probably some tweaks as frontend stuff comes online) is a few outstanding WebSocket messages (e.g. clue given, guess made, game over, etc)

[bcspragu]

Okay, with 8e61450 and 9628615 we now support a full 'lobby mode' and randomized role assignment, and the game flow works like this:

1. A user creates that game (POST /api/games)
2. That user, and other users, join that game (POST /api/game/$GAME_ID/join)
3. The game creator starts assigning roles (POST /api/game/$GAME_ID/assignRole)
4. The game creator starts the game (POST /api/game/$GAME_ID/start)
   • If they don't want to assign roles to everyone, they can specify "random_assignment": true in the request, and any unassigned players will randomly be assigned to unfilled roles.
5. People play the game.

I think the only missing thing that a frontend would need is a way to list the players in the current game/lobby, so I'll add a new GET /api/game/$GAME_ID/players endpoint that does that, as well as update the assignRole endpoint to return the updated list of players as well.

[bcspragu]

• 7963ebf adds the list endpoint
• 0cdf154 updates assignRoles to return an updated player list

With that, I'm pretty sure the backend has everything needed to make/play a full game.