Battle flow

🧠

Guide

Build the battlefield from an Encounter, move between player decisions and enemy Intents, and continue until victory, defeat, or rewards resolve

When you start a GameEncounter, GCS creates an independent battle from its player, enemies, deck, and Battle Rules. The player makes decisions through the hand, while enemies act according to the Intents they have already shown. Both sides alternate until the battle has a result.

The diagram above shows the complete relationship between the Encounter, player turns, enemy turns, and the battle result. Initialization first creates an interactive battlefield. The player and enemy phases then use that state in a loop. After every damage, status, or action resolution, GCS checks whether the battle should continue.

A battle starts from the Encounter

GameEncounter selects the player unit, enemy order, reward deck, and Battle Rules for the current battle. GameCardManager, the board, hand area, and presentation components in the scene host the battle, but they do not replace the content configured on the Encounter.

Startup produces five visible results in order:

• Creates independent unit state from the player and enemy definitions.

• Creates the card instances for the current battle from the Starting Deck or persistent Master Deck.

• Draws the opening hand according to Starting Hand Size and prepares the initial energy.

• Plans the first Intent for each living enemy.

• Enters the first player phase and allows card play and target selection.

You can verify these results in the battlefield UI and Game Card Monitor. See Definitions and runtime instances for the difference between authored definitions and live state.

Player and enemy turns alternate

Phase	Result visible to the player	Main configuration source
PlayerTurnStart	Armor, energy, statuses, and draw rules prepare the current turn	Status, Hooks, and Encounter Battle Rules
PlayerPhase	The player reads the battlefield, pays energy, selects a target, and plays a card	Card fields, Card Behavior, and current battle state
PlayerTurnEnd	The decision window closes while remaining cards and end-of-turn statuses resolve	Card, Status, and Hand Discard
EnemyPhase	Each living enemy executes the Intent shown earlier, then plans its next action	Enemy Behavior, Intent Pattern, and Status

The opening hand is created during initialization, so the first player turn does not perform the normal draw again. Starting with the second player turn, the system applies Draw Per Turn during PlayerTurnStart.

Result checks and process waits

GCS checks for victory or defeat after cards, enemy actions, and other important resolutions. When the victory condition is satisfied, it enters the victory flow. When the player can no longer continue, it enters the defeat flow. If neither result has occurred, a phase transition waits only for three types of blocking work submitted explicitly by FlowGraph:

• Wait pauses the current execution path for its configured duration.

• Gate waits for the project presentation layer to finish and release it explicitly.

• Choice waits for the player to submit a valid selection.

Ordinary VFX, SFX, and UI refreshes do not block a phase automatically just because they are still playing. When gameplay must wait for presentation, use Wait or Gate explicitly in the Behavior. See Flow nodes for Wait parameters and Runtime overview for how Gate affects phase progression.

Battle results

Victory first executes battle-end timing, then offers candidates from the Encounter's Reward Deck according to Card Reward Count. The battle ends only after the reward is handled. Defeat skips card rewards, ends the current battle immediately, and passes the result to the project's defeat flow.

You can verify the complete process from initialization to rewards in First battle. For exact phases, events, and abort conditions, see Battle lifecycle.