Dev log – Day 13
Summary
Today’s work focused on completing the reward and progression flow for Puzzle F in Level 2. This involved reliably spawning the Security Keycard after Puzzle E resolves, fixing state logic issues that prevented correct first-run behavior, and implementing a keycard reader that validates inventory state and unlocks the connected door. The goal was to firmly link Puzzle E completion to Room 3 access using existing systems without introducing duplication or progression breaks.
What I Worked on Today
Level 2 – Puzzle F – Lockbox Keypad Unlock + Security Keycard Reward
Intent
Implement Puzzle F’s lockbox keypad so the player can enter the code from Puzzle E, open the lockbox, and collect the Security Keycard needed to access Room 3.
What Actually Happened
A keycard spawn point was added to the Puzzle E word panel and the keycard was spawned when the puzzle resolved, with a basic ejection behavior. A spawn initialization issue was fixed to ensure the keycard wasn’t skipped on first completion, and a later branch logic issue was also corrected to restore proper spawning. A dedicated keycard reader blueprint was then created from the trigger base, given a simple physical mesh, and configured with a RequiredKey DA_Item reference. Inventory query logic was implemented and wired so interaction checks for the required key and triggers the door unlock on success.



Accomplished
- [STEP] Added SC_KeycardSpawn to BP_WordPanel_L2E and positioned it at the panel slot to define the keycard ejection spawn point and direction
- [STEP] Added KeycardClass + bKeycardSpawned to BP_WordPanel_L2E and spawned the keycard at SC_KeycardSpawn when Puzzle E resolves (single-fire)
- [STEP] Added basic keycard ejection to BP_WordPanel_L2E by offsetting the spawned keycard along SC_KeycardSpawn forward direction (with optional physics impulse if enabled)
- [FIX] Corrected bKeycardSpawned default/initialization to ensure keycard spawn is not skipped on first Puzzle E completion
- [STEP] Created BP_KeycardReader_L2F derived from BP_Trigger for Puzzle F keycard validation
- [STEP] Added simple box mesh to BP_KeycardReader_L2F to represent the physical keycard reader in-world
- [STEP] Added RequiredKey variable to BP_KeycardReader_L2F as a DA_Item object reference
- [STEP] Assigned RequiredKey to the Puzzle F keycard data asset (DA_Item)
- [STEP] Implemented inventory query logic in BP_KeycardReader_L2F using AC_InventorySystem on player interaction
- [STEP] Wired QueryInventory to check for RequiredKey with quantity 1 when interacting with the keycard reader
- [STEP] Connected BP_KeycardReader_L2F CallOnTriggered output to BP_Door trigger to unlock the door on success
- [FIX] Corrected bKeycardSpawned branch logic so keycard spawns correctly after Puzzle E completion
Why This Matters
This work ensures Puzzle E cleanly feeds into Puzzle F without progression breaks, missed rewards, or item duplication. By enforcing single-fire spawning and inventory-gated triggers, the player’s progression to Room 3 is clearly communicated, reliable, and aligned with the project’s reuse-first system architecture.

Technical Notes
- Keycard spawning depends on correct initialization and branching of the
bKeycardSpawnedflag; incorrect defaults can silently block first-time spawns. - Using
DA_Itemreferences withAC_InventorySystemallows the keycard reader to remain fully data-driven and reusable. - Deriving the keycard reader from
BP_Triggerkeeps progression gating consistent with existing door and interaction logic.
Challenges & Lessons Learned
- The Security Keycard initially failed to spawn due to incorrect state logic, highlighting how easy it is for single-fire flags to invalidate first-run behavior.
- Fixing both initialization and branch conditions was necessary to fully resolve the issue.
- Testing progression rewards requires validating not just success paths, but first-time execution specifically.
Next Steps
- Verify Puzzle F keypad UI behavior matches Puzzle A.
- Confirm correct code validation is sourced exclusively from Puzzle E.
- Final pass on persistence to ensure keycard pickup and lockbox state cannot be duplicated on re-entry.

