robmoore-i
commented
9 months ago Mini-specification
How the game works currently
- The host creates a game, and other players join the lobby.
- Every client makes a websocket connection to the server, and the server immediately sends them back a list of all the current players in the game.
- Every player, including the host, enters a name for themselves. These names are transmitted to all the players, and held in the server. The names are important for tracking the state of the game, and a number of messages require the username to be sent by the client. Clients hold their names in memory.
- Each client advances their game state individually by receiving broadcast updates from the server, which are triggered by messages from a particular active client, or in some cases, all clients.
Problems
The name is stored in memory and not persistently
This means that upon a client refresh, the clients identity is lost and cannot be reclaimed. It means that the game cannot recover from a page refresh.
Lack of mechanism for clients to recover from dropped websocket messages
In order for a client to be able to resume from a point in time in the game, it needs to be able to immediately jump to the right point in the game. At the moment, this would require several websocket messages sent and received in the correct order, and possibly messages also coming from the client. This is too fragile to work, realistically.
Proposed lightweight solution
Store name in a cookie
Store the name as a cookie in the client, probably connected also with the game id. When a client enters a game, they look for a cookie of the form "
This will require updating GameContext so that it can read the clientUsername from a cookie, instead of from a redirection state parameter from React Router. The other data that is set by GameContext will be updated by the Game component when it creates a new websocket connection and has its state updated.
A more robust and comprehensive solution
Transmit the current state of the game when making a websocket connection
When a websocket connection is opened, send not only a list of all the current players in the game, but also the current state of the game if the game has started. This should use a new websocket message type called ON_CONNECT. If the game hasn't started, then the state should be NOT_STARTED. If the game has started, then the state should correspond to a GamePhase.
The client, upon receiving an ON_CONNECT websocket message after connecting to the server, should inspect the state returned in this message:
- If it's
NOT_STARTED, then the client should make sure that the user is on the /lobby/path by redirecting if they are not currently. If they are on the lobby page, then do nothing. - If it's a GamePhase, the the client should make sure that the user is on the /game/
path by redirecting if they are not currently. If they are on the game path, then the client should use the data within the websocket message to set the appropriate client state in order to ensure that the user is seeing the correct screen with the correct context, such as the current player, their category the current dice roll and word if applicable, and the current scores.
To fulfill its purpose, if the ON_CONNECT websocket message has a GamePhase as its state, then it should contain the following additional data:
- (Not null) Current player
- (Not null) Current scores
- (Nullable) Current category - null if the game phase is
SELECT_CATEGORY - (Nullable) Countdown time remaining - null if the game phase is not
WAIT_FOR_COUNTDOWN - (Nullable) Current dice result - null if the game phase is
ROLL_DICEor earlier - (Nullable) Current word - null if the game phase is
SELECT_WORDor earlier
Playing the game on mobile is often the easiest way to show some "look what we made!". Currently though, it doesn't work for technical reasons. The website designs works fine, but the game transitions don't work.
The core problem that prevents this from working currently is the fact that the game cannot recover from dropped websocket messages, and also can't deal with a refresh of the web page.
Sometimes, we have seen that websocket messages are lost in transit. This has the effect that a player gets stuck in one phase of the game and is left behind as the game progresses through its phases without them. This prevents the game from working correctly.
It should be possible for a player in a game at any time to refresh their browser and get a refreshed current state of the game from the server, which will take them to the game phase that they need to be in, and they should have all the correct information about the current category/dice roll/word etc. if it's not their turn. If it is their turn, then they should be take to the correct phase where they can continue with the current turn.
This will require the server to hold more information about each game. The server also needs to be able to identify when a client request is the result of a browser refresh.
Review
https://github.com/codeday-hom/hit-or-miss/pull/48
Tests