Campfire and Elite Conditional Rewards

Team 2 — Sprint 3
Contributor: Joel Zhan (@Joel9368)
Task: #270 — Campfire and Elite Conditional Event Integration
Feature: #265 — Special Events, Conditional Rewards and Campfire
Main integration: PR #361, merged 4 October 2026
Last updated: 9 October 2026

Overview

My Sprint 3 contribution integrated the Campfire encounter and a hidden reward following an eligible Elite victory. The implementation connects to the existing Map, RunState, player state, card library, and persistent PlayerDeck for the current run.

Integration Status

PR #361 merged the feature into main on 4 October 2026. It records the full Gradle suite and manual Campfire/Elite reward checks. The personal task and parent feature are closed.

Jun's later Campfire scene refinements are separate contributions: #323, #410, and #414. The latter adds a rune-altar Upgrade entrance that delegates to the existing card-upgrade flow. The scene-based Campfire and rune-altar entrance are present in frozen commit ff81a12a587472d2a90df0ae922e2d698975cfb6. On 9 October, I performed the debug-assisted manual checks C1–C4 for Rest, upgrade cancellation/confirmation, and persistence into Map or a subsequent ordinary battle. The acceptance record and screenshots document those tested paths; the later scene implementation remains attributed to Jun.

On the same frozen build, I also completed Elite and Temple acceptance E1–E5. These checks record the 79/100 versus 80/100 HP boundary, Portal/Temple navigation, all three blessing effects, and reward persistence into subsequent ordinary battles. E5 records Vitality after an earlier Focus reward in the same run.

Encounter Flow

flowchart TD
    M[Map] -->|CAMPFIRE node| C[CampfireScreen]
    C -->|Rest| H[Update player HP]
    C -->|Forge confirmed| U[Upgrade one card in PlayerDeck]
    H --> CM[Complete node and return to Map]
    U --> CM

    M -->|ELITE node| B[Battle]
    B -->|Eligible victory| P[Set pending Temple reward]
    B -->|Other result| N[Normal result route]
    P --> V[Victory screen]
    V --> EP[Elite Portal]
    EP --> T[Ancient Temple]
    T -->|Blessing of War| W[Add chosen card to PlayerDeck]
    T -->|Blessing of Eternity| E[Update run health or energy]
    W --> R[Clear pending reward and return to Map]
    E --> R

The pending reward flag matters because the Elite map node is completed at battle end, while the player claims the reward only after passing through the Victory and Portal screens. RunState carries that eligibility across the screen changes.

Campfire Encounter

Map generation places one CAMPFIRE node on the high map layer, preferring to replace a combat node so other special rooms are preserved. The node has its own map icon and is routed from MapScreen to CampfireScreen.

The player has two actions:

• Rest restores 30% of maximum HP, rounded to an integer with a minimum requested heal of 1 HP, and capped at maximum HP. The result updates the player state for the current run. Continue completes the node and returns to the Map.
• Forge / Upgrade opens the shared card-upgrade interface for the current PlayerDeck. The player may upgrade one eligible card. The shared PlayerDeckCardUpgradeCommitter changes the selected card instance; Campfire does not implement a second set of upgrade rules. Confirming the upgrade completes the encounter. Closing the selection without confirming does not change the deck.

I implemented the Campfire map routing and Rest flow in PR #285, then connected Forge to the shared upgrade system in PR #294. Jun Xu later developed the scene-based Campfire presentation in PR #323.

Elite Conditional Reward

BattleActions checks eligibility before completing the active battle node. The hidden Temple reward is available only if the player wins on an ELITE node with remaining HP at least 80% of maximum HP.

In frozen commit ff81a12a, the Portal screen uses the completed Elite encounter's background, selected through game.getBackgroundId(); it does not always use a dungeon background. The portal artwork itself is images/elite_portal.png. The Ancient Temple and Blessing of War card-selection screens use their own backgrounds, images/ancient_temple.png and images/blessing_of_war_bg.png, respectively. See the frozen Portal background source and battle background selection.

For an eligible victory, RunState records a pending Temple reward. After the Victory screen, EndBattleScreen opens the Elite Portal. Other battle results follow the normal route. The Portal leads to the Ancient Temple, where the player chooses one blessing:

Blessing	Effect
Blessing of War	Choose a card from the Card Library and add it to the shared PlayerDeck.
Blessing of Eternity — Eternal Vitality	Increase maximum HP by 20 and fully restore HP.
Blessing of Eternity — Eternal Focus	Increase maximum energy by 1 and restore up to 20 HP.

One of the two Eternity variants is offered during a Temple visit and remains fixed while the player chooses. Claiming a blessing clears the pending reward flag and returns to the Map.

I implemented the condition, Portal routing, Temple rewards, and run-state updates, then polished the reward presentation across PR #282, PR #285, and PR #300.

Integration and Extension Points

Component	Responsibility and extension point
NodePoolGenerator, RoomType, MapNodeActor	Define where Campfire appears and how its node is displayed.
MapScreen, GdxGame	Route the selected node or pending reward to the correct screen.
CampfireScreen	Handle Campfire actions. A new successful action must update the shared run state and complete the active node before returning to Map.
BattleActions.isEligibleEliteVictory	Keep the Elite condition check before completeEncounter, while the active node can still be identified.
RunState	Carry the pending Temple reward between screens and clear it after a blessing is claimed.
AncientTempleScreen, TempleCardSelectionScreen	Apply the selected blessing to the current run's player state or deck.

Verification and Test Foundation

• NodePoolGeneratorTest includes a regression test for exactly one Campfire on the intended high layer.
• PR #285 records formatting and automated-suite results, plus manual checks of Campfire entry and Rest, Portal and Temple navigation, and persistence of a Blessing of War card.
• Forge integration is recorded in PR #294.
• PR #361 records the final automated-suite run and manual Campfire entry, Rest, Forge confirmation/cancellation, eligible Elite Portal, Temple blessing choices, persistent rewards, and return to Map.
• EncounterSeedSaveTest covers persistence/restoration of pending encounter reward state, including the Temple flag. This does not establish correctness of every on-screen reward interaction.
• PR #414 records later Upgrade-entrance regression tests and group-suite checks by Jun. The 9 October C1–C4 manual record below checks the integrated Rest and Upgrade paths in the frozen build.
• The automated results cited above are historical records and were not re-run for this 9 October page update. The new C1–C4 and E1–E5 results below are manual checks against the frozen build.

Useful focused automated follow-ups are the Elite HP boundary immediately below and at 80%, Forge cancellation versus confirmation, and clearing the pending flag after either blessing. This page does not claim those dedicated automated scenarios have passed. The new manual C1–C4 and E1–E5 records cover the observed Campfire and Elite paths separately from historical automated results; earlier manual feature evidence remains in #361.

Frozen-build Campfire Acceptance — 9 October 2026

Tested commit: ff81a12a587472d2a90df0ae922e2d698975cfb6
Code cutoff: 8 October 2026, 15:00 AEST
Tester: Joel
Evidence: Issue #270 acceptance comment — C1–C4 and screenshots

These checks were executed after the code cutoff against the frozen implementation. Each case started from a fresh run using New Game → Skip → opening narration → Map. Existing sethealth and skipbattle commands prepared HP for C1/C2; listnodes and goto selected generated encounters. Gameplay UI performed the Rest, Close, Esc and Upgrade-confirmation actions.

ID	Actual observation	Result
C1 — Rest below the cap	Entered at 50/100 HP; Rest restored 30 HP. Continue returned to Map at 80/100 and completed the Campfire node.	PASS
C2 — Rest near the cap	Entered at 90 HP with maximum HP 100 in the guided setup; Rest restored 10 HP. Continue returned to Map at 100/100 and completed the node.	PASS
C3 — Cancel upgrade selection	Selected Strike, then closed without confirmation and returned through Esc → Rest → Continue. The subsequent ordinary battle's Card Inventory contained 11 cards, the original Strike, and no upgraded cards.	PASS
C4 — Confirm one upgrade	Selection was limited to one card. Strike's displayed effect changed from 6 to 12 damage. Confirmation returned to Map and completed the node. The subsequent ordinary battle's Card Inventory contained 11 cards: 1 upgraded Strike and 3 original Strikes, with the upgraded display matching the preview.	PASS

No anomalies were observed in these checks. Inventory inspection occurred before playing cards in the subsequent battles. C4 compares the displayed card effect; damage dealt by playing the upgraded card was not separately measured. Debug-assisted entry does not establish natural map traversal or Campfire reachability. Elite eligibility and Temple reward paths are outside C1–C4.

Frozen-build Elite and Temple Acceptance — 9 October 2026

Tested commit: ff81a12a587472d2a90df0ae922e2d698975cfb6
Tester: Joel
Evidence: Issue #270 acceptance comment — E1–E5 and screenshots

Existing listnodes and goto commands select generated encounters, while sethealth and skipbattle prepare exact HP conditions and exercise the existing victory flow. Ordinary victory rewards are Gold. Portal entry, Pray and blessing claims use gameplay UI. E1/E2/E4 use the guided fresh-run setup; E3 continues E2. E5 uses a run where an earlier Elite reward had already granted Focus.

ID	Actual observation	Result
E1 — Below the threshold	At 79 HP in the 100-max-HP setup, Gold claim returned directly to Map at 79 HP, without a Portal or Temple. The Elite node was completed.	PASS
E2 — Exactly at the threshold	At 80/100 HP and energy 3, Gold claim led to a Portal whose background matched the preceding battle. The Portal opened the Temple; Pray displayed both blessing choices, with Eternal Focus offered.	PASS
E3 — Focus persistence	Claiming Focus returned to Map at 100/100 HP. The subsequent battle began at 100/100 HP and 4/4 energy; the next player turn had 4 energy. Its Gold reward returned to Map without another Portal or Temple.	PASS
E4 — War card persistence	Blood Price was added to the initial 11-card deck. The subsequent battle's Card Inventory contained 12 cards: exactly 1 Blood Price and all original 11 cards. Its later Gold reward returned normally without another Portal or Temple.	PASS
E5 — Vitality after Focus	HP changed from 80/100 to 120/120 on Map. The subsequent battle began at 120 HP and 4/4 energy, consistent with retaining the earlier Focus bonus. After that battle and Gold claim, Map HP remained 120/120 and no Portal or Temple reopened.	PASS

No anomalies were observed in these checks. E1/E2 are debug-assisted victories rather than natural combat completions at the threshold. The later ordinary victories provide observable evidence that the consumed Temple reward does not reopen; the pending flag was not inspected directly in memory and repeated-click races were not tested. E4 checks acquisition and deck persistence, not Blood Price's combat effects. E5 checks Vitality together with an existing Focus reward rather than a fresh-run energy-3 case.

Reflection

The first Campfire implementation provided Rest while Forge awaited integration with the shared card-upgrade system. Connecting Forge through the existing selection and deck committer avoided duplicating upgrade rules and made the change apply to the run's PlayerDeck.

The pending reward flag solved a similar integration problem in the Elite flow: the battle node must finish before the player moves through the Victory and Temple screens, but reward eligibility must remain available until the choice is resolved. The 9 October frozen-build checks now retain concrete Campfire evidence: Rest from 50 to 80 HP, the 100 HP cap, cancellation without a deck change, and one confirmed Strike upgrade persisting into a later battle. The Elite checks now retain the 79/100 versus 80/100 boundary and subsequent ordinary-battle returns after each blessing. E5 also showed why the starting state matters: Vitality claimed after Focus should preserve 4/4 energy while changing HP to 120/120. I recorded that reward sequence instead of treating it as a fresh energy-3 case. Remaining validation gaps include rapid repeated UI actions and natural traversal to the tested nodes.

Implementation Evidence

PR	Contribution
#282	Joel: Elite eligibility, Portal routing, Temple rewards and persistent run-state changes.
#285	Joel: Campfire Map/Rest integration and Elite reward presentation.
#294	Joel: Forge integration with the shared persistent card-upgrade system.
#300	Joel: Portal/Temple presentation, blessing controls and card-selection UI polish.
#361	Final group feature integration into main, with recorded automated/manual verification.
#323, #410, #414	Jun: scene-based Campfire presentation and later refinements, preserving integration ownership above.

Related Pages

• Non-Battle Encounter Framework — encounter lifecycle.
• Map to Encounter Lifecycle — Map entry and completion.
• Card Upgrade System — upgrade rules reused by Forge.
• Player and Battle Deck — deck receiving upgrades and War cards.

AI Assistance Disclosure

ChatGPT assisted with drafting and reviewing this Wiki page. Technical descriptions were checked against issue #270, the cited pull requests, and the relevant main/feature integration records. The 7 October documentation update checked the later group source at 3f880bd8. For the 9 October update, ChatGPT helped prepare the manual check instructions and evidence wording; I executed C1–C4 and E1–E5 on frozen commit ff81a12a, reported the observations and E5's prior Focus state, and uploaded the screenshots in the linked acceptance records. These are focused manual checks, not a new full automated-suite run. Implementation ownership is attributed separately above.