search

lafkob / swe681_game

Our game for SWE 681.
0 stars 1 forks source link

Persist games into the database #15

Closed lafkob closed 8 years ago

lafkob commented 8 years ago

Figure out a way to serialize the games into the database as well as restore them. Build a dao for doing this. This is how we should store the games between requests (maybe with caching in there to help with speed if we have time).

lafkob commented 8 years ago

Questions:

  1. What fields are required to start a game? I think it is a playerId and a game status. The rest should be nullable, assigned once the second player joins.
  2. What is the appropriate status for a game being started? Is it waiting_for_players or start?
StormGull commented 8 years ago

1) Do you mean ready to make moves, or putting the game into the database for the first time? At the very first startup, the game needs (per the model) board gameId playerOneId gameStatus

Everything else is nullable. The board...could be nullable, but it just seemed easier to make it right at the start. Adding a new player won't change what state it's in.

As an aside, to the longs and ints need to be wrapped so they can be nullable? As is, I keep them all as -1, as that's not a valid value for any of them.

2) I think I will remove START altogether. It would not be too difficult to add in later, and we're not going to do anything with it at the moment. It referred to players having time to move their pieces around. WAITING_FOR_PLAYERS is the state the game starts in.

lafkob commented 8 years ago

Re starting a game: I meant what is the state when we have a user click new game? I was preferring null to invalid values, but either way there will be a check. With null, I guess it is explicit in the database that there is no value, rather than one intended to mean base state.