Reviewing Move Event Logic

- 3 mins read

After playing around with movement scenarios and checking the events log, I found some scenarios I want to address. These are the current rules for determining which move events players have visibility to:

  • PCEnteredHexEvent can be seen by moved player
  • PCEnteredHexEvent can be seen by players in destination hex and didn’t move
  • PCLeftHexEvent can be seen by players who started in origin hex

The scenario where these rules make the event log potentially confusing to moved players is when two players (Player1 and Player2) who start in the same hex move to the same destination hex. Both players will see the other has left the origin hex and in which direction they moved, but neither will see an event that the other player arrived in the same destination hex. This can be simply remedied by removing the condition that PCEnteredHexEvent is seen only by players who didn’t move that round.

The moved player does not see their own PCLeftHexEvent as their PCEnteredHexEvent is sufficient to convey their movement. I realize that mulitple players moving from the same origin hex and arriving in the same destination hex also don’t need to see both event types.

The replacement rules I want to implement are the following:

  • PCEnteredHexEvent can be seen seen by players in destination hex post-move
  • PCLeftHexEvent can be seen by players in origin hex pre-move, excluding players in the destination hex post-move

For the previously mentioned scenario using these rules, Player1 and Player2 will both see an event message for each players entering the destination, but not the event of leaving the origin hex.

Before implementing the new rules in the backend code, I simulate this scenario on paper and find a new problem with the ordering of events. At the end of a game round, move actions are processed one at a time and any related PCLeftHexEvent and PCEnteredHexEvent events are added to the global events list. In the case of Player1 and Player2 moving from the same origin hex to the same destination hex, events will be added to the global events list in the following order:

  1. Player1 left origin hex
  2. Player1 entered destination hex
  3. Player2 left origin hex
  4. Player2 entered destination hex

When Player1 sess these events in their frontend UI log, they would see Player2 left the origin hex after Player1 already arrived in the destination hex. Logically, the events of leaving an origin hex should be listed before any events of entering a destination in the same round. This will be the second problem to address with a new test case, but I’ll focus on the new visibility rules first.

I don’t have time to implement code changes today, but at least I’ve knocked out out the intial thought process of solving the problem. Next time, I know exactly where to jump into the code to get things going.