TLDR
Restructuring the FSM transition logic so that it can handle actions that could result in multiple possible next states. “Free transitions” are still kept to handle case where player can take no action. Completing the PLACE_FREE_SETTLEMENT and PLACE_FREE_ROAD cycle, so that game can start!
Main work
- Introducing the concept of
Glide’s, which handle the transition from one state to one of multiple possible next states.- The FSM structure at this point needs a wholistic review, “glide” is probably analogous to a proper term in finite automata theory.
- Working through manual testing of the initial start of the game (placing your first settlements / roads).
- Writing logic to validate where free roads and settlements may be placed.
- Updating CLI tool with
place-roadcommands.
Challenges
- The FSM logic continuous to be unsatisfying. (I’m VERY happy I did not go with Spring FSM, though.) I will need to get it reviewed by someone since I’ve been too close to the work for so long.
- Hand copying adjacent settlements/roads from the board. Attempted a long description into ChatGPT with no luck in autogenerating the mappings.
- What should I be logging as “events” (for either the user’s knowledge or my own). At the moment, it is just plain english about what actions were taken, but it should likely be more strategic / structured for later game reviewing or persistence.
- Catan uses a “snake draft” for the free settlement placements. This involves a bit of logic that isn’t as straightforward as simple iteration.
Learnings
- You have to just push through with implementation before you’ll ever catch oversights. For example, I thought my design handled states that could go to multiple different next states, yet I still needed to go through a rework.
- I’m happy I did not spin my wheels on the “perfect” design just to end up at this same issue.
- One idea for storing board configurations (e.g., the randomized locations of resources and numbers on the resources) is through compression or codifying things.
- Compression would take the N possible board states and map them to some INT of appropriate size, so that many records are not needed.
- Codifying them would be creating some structured string that represents the board, e.g.,
3o8s4w...for the first hexagon being ore and roll value 3, second hexagon being sheep with a roll value of 8, etc. - Join records would not be terrible either, since the board state doesn’t not change after the game has been initialized.