Adding attack events to UI log With PCAttackedPCEvent events being created on the backend, I can now include them in the events list which is pushed to the frontend LiveView client. Events are filtered in the LiveView controller to only send events that have a matching format function which converts the struct to be received by the frontend. I add a new definition for the PCAttackedPCEvent struct which is all it takes to start seeing these events in the payload for the LiveView event handlers on the frontend.
The events log is now showing messages to the user for all player character moves they can see. Attack event messages are the next feature to add which should be much simpler than the move events. These events should be visible to any players with a character starting in the same hex where the attack occurred.
Starting with a test I start by creating a new feature test case to check the UI element has the expected event message displayed after registered attacks are resolved from the previous round.
To give more context to the events log messages, I will add a new type of message before all events of the same round. This will make it clear which round the events took place when reading the events log.
I want to keep the HTML rendering as simple as possible so I plan to add a new type of message to the events log store which is read by the related Alpine component.
I already decided how I want to change the move event visibility rules the other day, but I need to actually implement these changes in the code. I start by updating the existing test cases so they assert on the new desired behavior.
I also add a new test case to check that PCLeftHexEvent events are added to the events log before any PCEnteredHexEvent events for the same round.
defmodule Minotaur.
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.
Fixing event ordering bug The events logs is populating with existing move events after the user joins a game session, but they are in the wrong order. The most recent events should be rendered at the bottom of the events log component, but they are at the top. I decide to simply sort the events on the client before they are added to the Alpine store as event messages. The id property for event objects are numeric with the newest event ids being larger than older ones.
One thing I realized while building logic to handle move events on the front end is the to and from coordinates in the event details are referencing the actual hex grid coordinates while all other coordinate references on the front end are using coordinates relative to the player’s current position. An early design decision I made was to hide any absolute coordinate values from the user so they don’t know exactly how far away their character is from the center or edges of the grid.
Starting with a test My next goal is to implement move events in the frontend UI component. I start by writing a new feature test with Wallaby to validate the behavior I want to see. I write just enough of the outer test structure to get something to run, then I focus on the assertions for the expected behavior. Before constructing the scenario context for the test, I focus on the assertions for the expected behavior.
Events log UI component I add a new component for the events log which will take a list of event objects and render text elements in a reverse-ordered flexbox column. This will ensure the most recent event message is at the bottom of the log component. I configure the overflow styles so messages that don’t fit within the height of the log component will be hidden and the user will need to use the scroll feature to see older event messages.
It has been a month since my last journal entry which was just before I went on a short trip with my wife. Since then, I’ve been preparing for job interviews in my spare time by practicing coding challenges on HackerRank. I passed the Amazon coding assessment and I’m still waiting for the next phase of the interview process. Grinding coding challenges gave me a bit of burnout so I took a week off any personal programming work to enjoy playing the game Satisfactory in my free time which had just recently released.