cuttle-cards
[Feature]: Update `gameService.dealCards()` to use new GameState model
Feature Summary
We should update the function that deals the cards/initializes the game state so that it utilizes the new GameState model.
Detailed Description
gameService.dealCards() is the utility that initializes the game by creating and placing all the cards. We should update it to read from the process.env.SAILS_USE_GAME_STATE_API env var and if that is set to “true”, use a new sails helper to instantiate and save a new GameState associated with the specified game. This should make it so that we can start a game via ready and rematch.
Hey I am trying to work on this one. Do you mean, we are not meant to change the actual code, just had the possibility to instantiate a gamestate if VITE_USE_GAMESTATE_API=true Also the gamestate class doesn't exist yet, should I cretae it and where ? Does it need validation ? checking the turn ?testing if there is a gamestaterow with this id already ?
Hey I am trying to work on this one. Do you mean, we are not meant to change the actual code, just had the possibility to instantiate a gamestate if VITE_USE_GAMESTATE_API=true Also the gamestate class doesn't exist yet, should I cretae it and where ? Does it need validation ? checking the turn ?testing if there is a gamestaterow with this id already ?
This is blocked by #975, #940, #941, and #943. The individual issues aren't marked with their blockers, but they are grouped into 'iterations' in the GitHub Project for the GameState API rollout. Each iteration generally blocks the ones after it.
The first (and the current) iteration is all about setting up the basis of the environment. The next one lays the foundation of the application logic by creating the helpers that every individual endpoint in the GameState API will use (unpackGameState(), saveGameState(), emitGameState().
Then comes an iteration focused on getting the first actual endpoints which utilize GameStates, starting with this issue for dealCards().
As for this specific issue, it does require validation, as well as creating a new gameState, given the previous one. It should follow the overall outline and approach shown in the drawCards() example in the Backend Control Flow section of the spec.
This issue does entail both the validation and the execution of dealing cards, though the validation should probably be done in the endpoint, rather than in the dealcards function. It should error if there are existing game state rows, or if the game does not have status GameStatus.STARTED.
Notably, this depends on the issues listed above because the intent is that all the card manipulation logic be done on a GameState object, which is the unpacked, object-oriented version, as opposed to the GameStateRow, which using string ids because it is the database-storage version of the state.
As for the parentheses, they represent jacks that are attached to the specified card. See the Game State Array<String> Lists
for details regarding how this data is stored. But dealing the cards and all the other endpoints, should be dealing with full Card objects in the context of an unpacked GameState object, not a GameStateRow.