TLDR
No direct coding, just drawing / diagramming how the state of games could be persisted and queried. A Finite State Machine is my first thought.
Main work
- Considering how board state could be represented in a relational database.
- Considering how player actions can be validated and shared with other players.
- Working through game flow and considering possible states.
- Considering payload properties - does user really needs an entire state update or some kind of state diff?
Challenges
- Want to send events to users rather than constantly poll for game state.
- Designing the system with some unknowns still is difficult (e.g., web sockets vs REST and state machine vs standard business logic).
- At some point, have to just start building and remain nimble while scrapping original ideas.
- Tempting to design the system for non-MVP features. e.g., making a table to store all previous moves so that games can be replayed.
- I could do go through this thought experiment indefinitely, and then never develop anything.
Learnings
- Perfection is the enemy of progress.
- Considered using Spring State Machine, but it seems like a surprisingly bad fit for this application.
- General use cases seems to be for maintaining the java services state, rather than the state of an entity (e.g., game from the game_table).
- There are examples in the docs about restoring state machines from persisted records, but it is not intuitive.
- Likely will create a poor man’s version of a state machine for MVP.
- Authentication will certainly be a problem for after game logic is functional. Do not want to complicate development by doing too many things in parrellel.