will2dye4 / jeopardye Goto Github PK

When a new player joins the lobby, they see the default game settings instead of the current settings seen by the other players (if they are different from the defaults).

If the creation of a new game fails, the game settings should be shown again to allow the host to attempt to create another game. Currently, the "A new game is starting, please wait..." message never goes away if a game is not created successfully.

The flag button to mark a clue as invalid currently does not work. (This is because the JService API uses HTTP instead of HTTPS and the browser prevents the request from being made.)

If a player switches between two rooms they have access to by changing the URL in their browser directly, the player and rooms will not be correctly updated in the database to reflect the current state. This can cause errors for the player.

For categories that have appeared on multiple shows, the game creation logic will always choose the same clues each time the category is randomly chosen for a game. Instead, if there are more than enough "valid" clues for a category, the set of clues should be chosen (semi-)randomly from the set of available clues. The clues should still be sorted in order of increasing value.

The "proper" solution to this would be to keep track of which categories/clues have been played for each room in the database and to avoid repeating the same categories/clues (within a certain time period), but choosing a random subset from a large category should be good enough.

The result is that the user must create a new player. If the user had created a room using their previous player, they are no longer the host/owner of the room.

There needs to be a way for a user to recover their previous player after clearing cache (or when visiting the site from a different device, etc.).

The game board should (maybe?) be constrained to a certain aspect ratio. The daily double image can also be cropped depending on the aspect ratio of the window, and sometimes the bottom/side of the board can be seen behind the active clue.

If the player in last place at the end of a round goes inactive during the round, that player will still be chosen to start the next round. Only active players should be eligible to receive control at the beginning of a new round.

Creating a game doesn't work if there are more than the maximum number of players (6). When a player joins a room, they should become a spectator automatically if there are already 6 players ready for the next game.

Sometimes (it's unclear when or what triggers it), the countdown timer does not get reset back to 100% and shows as empty (0%) instead of counting down as it should. Refreshing the page typically fixes the issue, but this should not happen in the first place.

The sample font size should be decreased if the player's name is too long, similar to how the podiums work.

Testing creating issues.. Close and burn after reading.

Any audio events (sound effects, etc.) that are triggered when the tab is not in focus seem to be queued by the browser and will play when the tab is refocused. Investigate ways to prevent this from happening.

Clues may be marked as invalid using the JService API if they require an image or audio/video clip that is not available. The game creation logic should check this field in the API response and exclude clues that have been marked invalid more than some minimum number of times (2?).

If a player buzzes in (clicks the active clue area) after the answer has been revealed, it is treated as an early buzz and the player is locked out for the next clue. Buzzing after an answer has been revealed should be handled gracefully.

This may also happen if a player who isn't in control clicks on the board (e.g., tries to select a clue).