Okay, problem with Recombobulation.
Right now when the player takes actions then the step occurs. During the step:
- Organs are stepped (tentacles grow, biomass is consumed)
- Mobs are stepped (one at a time they move / attack)
Yesterday I shifted to a setup where the player can take whatever actions they like whenever they like. It feels much better and I think it works for this game because each action doesn’t have the same impact—and therefore require the same amount of deliberation—as a game like Gloomhaven or Slay the Spire.
Issue is, I do need to limit the player actions in some ways. For example, I wouldn’t want them expanding more than 2-3 tiles within a single step. So I need to save the game state from before the player’s actions.
Similarly, when enemies are acting, they each act one at a time. That means one enemy might attack and destroy a blob and another enemy will step into the tile that opened up in the same turn. What I’d like to see is the enemies all choose their actions and then execute at the step.
There are a few ways I could do this.
I could have tiles that represent intermediate states. For the blob expansion, I could have a tile that represents a freshly expanded blob. The player can expand from other fully-expanded blobs but not these intermediate ones.
And when mobs destroy a blob an intermediate “dying blob” tile could remain until the enemies have all executed their moves.
I could also just store two copies of the entire game state. Read from one and write to the other then swap. Double buffer.
This affects enemy movement, too. If they are standing in line, the front enemy moves forward and the back enemy may or may not be able to move forward depending on whether its turn was executed before or after the front enemy.
Do I really want enemies to space themselves out by one tile rather than walk adjacent tiles?
I could probably get them to walk in a consistently synchronized manner by either a) assigning initiative based on the direction of travel or b) having a method to defer until later in the initiative queue.
…
Following up on this from the next day.
Turned out those solutions were overwrought. I actually tried implementing yet another solution where intents are recorded during a prep phase and then executed during the step phase. Having move and attack commands as data classes seemed like a good approach. However, the actions that were prepared during the prep phase often didn’t apply anymore once it got to a particular unit’s turn in the step phase. The worst offender was two mobs moving into the same location because during the prep phase it was empty.
After throwing out that code I switched to something much simpler. The model classes now emit events when they attack. When the view classes receive those events they display a brief animation (an arrow that indicates attack direction). Done. No need for separate prep and step phases to synchronize the views with the models. Much cleaner.
Adding the health bars last night also makes it easier for me to track what’s going on and troubleshoot.
