Overview
Build Unity card roguelike battles with visual content and rule editors. Use GCSApi and battle events to connect your game's UI, progression, and saves.
The image follows a card from its definition in Game Card Editor to its Behavior in FlowGraph. When you play that card, Game Card Monitor shows the state changes and execution history. Use those records to adjust the card or its graph.
Enter the complete workflow through scene initialization
The diagram starts with Initialize System, which connects the scene to the Manager and content databases. After you create and play an Encounter, inspect it in Monitor or read the same battle through GCSApi and events.
| Capability | Core scale | Direct value to your project |
|---|---|---|
| Visual content authoring | 6 editing modes | Create cards, decks, players, enemies, statuses, and encounters in one window |
| Visual gameplay authoring | 148 available nodes and 103 mechanic recipes | Combine nodes to express card, status, and enemy behavior |
| Runtime and code integration | 176 public GCSApi member names and 48 built-in events | Read, control, save, restore, and extend battles while connecting project flows and custom UI |
| Play Mode diagnosis | 7 Monitor tabs | Check live state, wait sources, Flow execution summaries, and event history |
| Included finished content | 13 battles across 2 database sets | Play the 12 single-character battles or open the Party Showcase to try shared turns and ally targeting |
Build battle content on the scene foundation
Open Game Card System and click Initialize System. GCS creates or reuses GameCardManager and GameCardEncounterBootstrap, adds the battlefield, hand, HUD, and presentation objects, and registers the six preset database types. Once initialization finishes, you can author content or start a fixed Encounter.
When the Manager, six database types, and Bootstrap are all ready in the panel, the scene has a working battle entry point. Battle scenes explains each object's responsibility, while Starting a battle distinguishes fixed and dynamic entry points.
Game Card Editor keeps List, Inspector, and Preview synchronized around the current content. List manages databases and entries. Inspector edits the definition and its Behavior. Preview checks appearance, composition, behavior summaries, and direct references. All six modes also share search, filtering, sorting, Undo/Redo, Validation, and Used By, so after completing one content type you can follow its references into the next.
| Content | Main definition | Responsibility in battle |
|---|---|---|
| Cards | Name, description, cost, type, Target, keywords, art, and Behavior | Player actions, card lifecycle, and resolution rules |
| Decks | Card entries and copy counts | Content sources for the Starting Deck, Reward Deck, and Master Deck |
| Player units | HP, energy, starting deck, Prefab, and resource display | Player units, starting resources, and character presentation |
| Enemies | HP range, Tier, Prefab, Intent, and Behavior | Preview and execute enemy actions |
| Statuses | Buff/Debuff identity, stacking, cap, decay, icon, and Behavior | Persistent effects, rule changes, counters, and turn responses |
| Encounters | Player, enemy lineup, reward deck, and Battle Rules | Assemble existing content into a battle that can start and resolve |
The single-character Demo database has 80 cards across 5 types and 4 rarities. Party Showcase uses a separate database with Strike, Defend, and four cards that target allies. The cards cover attacks, skills, bursts, support, and curses, with examples of cost changes, multi-hit attacks, status application, card generation, pile movement, and ally targeting.
In Player, set a unit's HP, energy display, Starting Deck, class tag, Prefab, and preview art. The Demo includes Warrior, Mage, Hunter, and Priest.
In Enemy, open the Behavior to see how an opponent chooses and performs its Intents. The 16 single-character Demo enemies cover normal, elite, boss, and summon roles.
In Status, set stack and decay rules, then use Behavior to respond to battle events. The 30 single-character Demo statuses cover damage over time, shields, reactive damage, regeneration, and Hook-based rule changes.
These six content types are stored as ScriptableObject sub-assets in their databases. When a battle starts, GCS creates independent card, unit, status, and pile instances from those definitions. Runtime values such as HP, cost, and status stacks change only on the instances and never write back to the source assets. Database management explains how content is organized and activated. Definitions and runtime instances covers the boundary between static definitions and runtime data.
Game Card Editor defines which objects exist in a battle and how they reference one another. The actual behavior of Cards, Statuses, and Enemies belongs to their FlowGraph Behaviors.
Combine gameplay behavior with 148 nodes
Cards, Statuses, and Enemies each have their own Behavior but share the same nodes, ports, and execution context. Entry nodes determine when execution starts. Control connections organize order and branches, while data connections carry units, cards, sets, and calculated results. When a fixed field cannot express a dynamic rule, you can turn it into a port and accept upstream data.
The image shows cards, statuses, and enemies on the same FlowGraph canvas. Cards start from a play or lifecycle Entry, statuses respond to battle events through Entries and Hooks, and enemies choose actions through Intent Patterns. Use the library's 146 core nodes and 2 Demo FX nodes to build these Behaviors, and group related nodes without changing their execution order.
| Node family | Count | Main responsibility |
|---|---|---|
| Entry | 33 | Start a Behavior from battle, turn, card, unit, status, energy, or event timing |
| Hook | 18 | Modify or cancel damage, armor, healing, energy, draw, cost, and other results before commit |
| Action | 27 | Modify HP, armor, energy, cards, statuses, variables, turns, and units |
| Operator | 22 | Compare, calculate, filter, sort, select, combine, and convert data |
| Get | 20 | Read units, cards, piles, statuses, variables, and event arguments |
| Flow | 10 | Organize branches, loops, sequences, Choice, Switch, Wait, and Gate |
| FX | 7 + 2 Demo | Request VFX, SFX, animation, floating text, movement, flashes, and camera feedback |
| Intent | 6 | Build enemy intent leaves, sequences, random patterns, and HP-threshold patterns |
| Event | 2 | Raise internal GCS events or optional GES events |
| Group | 1 | Organize a complex canvas without changing its real execution relationships |
FlowGraph basics explains control flow, data flow, context, and evaluation. Node overview provides an entry point for every family. The three recipe libraries organize common mechanics into 103 editable FlowGraphs.
| Mechanic range | Recipe entry point |
|---|---|
| Multi-hit attacks, X-cost cards, draw and discard, discover, replay, transform, cost, and card lifecycle | 52 card recipes |
| Poison, burn, strength, vulnerable, thorns, barricade, silence, revival, equipment, and global rules | 30 status recipes |
| Intent sequences, weighted random behavior, boss phases, summoning, splitting, escape, deck disruption, and cross-system events | 21 enemy recipes |
These recipes use only production nodes and runtime systems. After copying one, you can continue changing ports, fields, and target sources. Once the Behavior is complete, it produces cost changes, target selection, damage, statuses, pile movement, and presentation requests in Play Mode.
Execute and verify rules in Play Mode
When a player plays a card, GCS checks the current Phase, hand ownership, effective cost, target, keywords, and Hooks. Once the action is accepted, it executes the Card Behavior and uses the Controller to update damage, armor, statuses, and piles. The card then enters Discard or Exhaust. A Behavior can use Choice, Wait, or Gate when it must pause for a player selection or a specific process. Ordinary VFX, SFX, and animation requests do not block the phase automatically.
The player and enemy HP, card costs, energy, pile counts, enemy intents, and current turn shown above all come from the same battle state. Encounter defines the initial lineup and rules. Behaviors resolve mechanics, while the battle state machine advances turns, enemy actions, Choice, Reward, and victory or defeat.
| Runtime scope | Responsible result | Read next |
|---|---|---|
| Battle lifecycle | Initialization, player turns, enemy phases, victory, defeat, Choice, and Reward | Battle flow, Battle lifecycle |
| Cards and piles | Draw, Hand, Discard, Exhaust, and the Master Deck across battles | Card and pile lifecycle |
| Target selection | Self, Opponent, All, Selector, random targets, and player choice | Target selection |
| Statuses and Hooks | Stacking, decay, sources, Behaviors, and modification before commit | Status lifecycle |
| Presentation and waits | UI, VFX, audio, animation, Wait, Gate, and Choice | Custom UI integration, FX nodes, and Flow nodes |
| Scene and startup | Manager, Bootstrap, Battle Board, Hand, HUD, and Presentation | Battle scenes, Starting a battle |
| Save and continue | Run and settled battle checkpoints, local slots, existing save providers, and scene restoration | Save and restore |
Verify results with Game Card Monitor
Start with Battle, Pile, or Unit to check the current state. Use Phase, Gate, Flow, or Event to trace how the battle reached it.
| Tab | What you can inspect |
|---|---|
| Battle | Encounter, Phase, Turn, player, enemies, Pending Intent, and wait state |
| Pile | Hand, Draw, Discard, Exhaust, and Master Deck |
| Unit | HP, armor, energy, status stacks, alive state, and Pattern Walk |
| Phase | Phase transition history and Choice Pending |
| Gate | Holder, Active Reasons, and Acquire/Release records |
| Flow | Behavior Owner, Trigger, visited node count, and synchronous execution time |
| Event | Event timeline, Payload summary, and subscriber count |
Game Card Monitor explains every field and the inspection order. Problem index starts from startup, card play, status, event, and presentation symptoms and leads to the matching repair path. Monitor confirms what happened in the battle. GCSApi lets project code read that result and submit the next action.
Integrate the project through GCSApi and extend it further
GCSApi is the entry point for project code that accesses a battle. HUD, map, quest, save, and development systems can use it to start battles, submit player actions, read and safely update state, and subscribe to events. These calls and the visual Behaviors operate on the same battle state. A minimal integration only needs to select an Encounter and submit player actions. The content assets and Behaviors define the battle rules.
using TinyGiants.GCS.Runtime;
GCSApi.StartBattle(encounter);
bool played = GCSApi.TryPlayCard(card, target);
GCSApi.EndPlayerTurn();
GCSApi guide shows how to submit actions, and API reference lists signatures. Use Event guide to subscribe and Event reference to check when each of the 48 events fires.
Connect Save and Quit and Continue through GCSSaveController. The player resumes with the saved piles, units, statuses, Hooks, enemy plans, delayed effects, and reward choices. Save and restore also shows how to store the checkpoint with your game's own data.
When a project needs its own mechanics, extensions continue to use the same FlowGraph and runtime contracts.
| Extension point | Use case | Documentation |
|---|---|---|
| Custom nodes | Add gameplay actions, data sources, selectors, operators, or presentation requests | Custom nodes |
| Custom ports | Infer field inputs or declare result outputs, choices, and control branches | Custom ports |
| Execution context | Read inputs and targets, mutate state through the Controller, and publish results | Execution context |
| Types, tags, and description tokens | Add project classifications, filter dimensions, and dynamic card text | Card types, tags, and description tokens |
| Copyable samples | Start from seven family templates and seven matching finished nodes | Custom nodes |
Four registries discover nodes, card types, tags, and description tokens that follow the contracts, so you do not maintain a manual registration list. If the project also uses GameEventSystem, GES integration creates a two-way channel between FlowGraph and the external event system.
Inspect complete finished content in the included Demo
Open a Normal, Elite, or Boss scene for Warrior, Mage, Hunter, or Priest. Open Party Showcase to play three members with one hand and energy pool. Each battle's assets and Behaviors are editable in Workbench and FlowGraph.
| Demo content | Count | Composition |
|---|---|---|
| Playable scenes | 13 | Twelve class battles plus Party Showcase |
| Single-character database set | 12 Encounters, 12 Players, 16 Enemies, 80 Cards, 16 Decks, 30 Statuses | The original four class lines and their complete reusable content |
| Party database set | 1 Encounter, 3 Players, 3 Enemy definitions, 6 Cards, 1 Deck, 5 Statuses | Scout, Squire, and Apprentice share Party Tactics against a Normal, Elite, and Boss Hunter enemy |
Demo overview explains the databases and content scale. Demo battle scenes shows every lineup and live battle view. Demo content reference and Asset layout connect the scene results back to the content assets and their file ownership.
Engineering boundaries for production projects
| Engineering area | Included foundation |
|---|---|
| Unity and render pipelines | Supports Unity 2021.3 LTS from 2021.3.18f1, Unity 2022.3 LTS, and Unity 6. The Demo supports the Built-in Render Pipeline and URP |
| Runtime dependencies | The GCS runtime has no third-party dependencies. Transitions and procedural animation use TinyGiants' own TGTween |
| Content stability | ScriptableObject sub-assets store definitions, Unity references connect content, Active Database controls active discovery, and GUIDs support content lookup |
| Authoring safeguards | Game Card Editor provides Undo/Redo, Validation, Used By, and cross-database copy. FlowGraph Editor checks node identity, Host, and port structure |
| Runtime consistency | The Controller submits mutations, Hooks modify or cancel them before commit, events broadcast changes, and explicit Gates wait for presentation work |
| Diagnostic access | Monitor displays Battle, Pile, and Unit snapshots and records Phase, Gate, Flow, and Event history |
Installation and initialization gives the supported versions, import result, and first scene check. Project structure explains the boundary between package content and project data. Once both are clear, enter the tutorial, authoring guides, references, or troubleshooting section that matches your current task.
Choose the next step
When evaluating GCS, start with the first battle or a Demo scene. When integrating it into a project, continue with the second battle, content authoring, or code integration. Use the remaining sections according to the task at hand.
| Current goal | Recommended entry point |
|---|---|
| Play one complete battle | First battle |
| Build a custom battle from an empty scene | Second battle |
| Understand content, Behaviors, and runtime mechanics | Database management, FlowGraph basics, Battle flow, and Runtime overview |
| Create cards and battle content | Cards, Decks, Player units, Enemies, Statuses, and Encounters |
| Find a node or existing mechanic | Node overview, Card recipes, Status recipes, and Enemy recipes |
| Integrate UI and project code | GCSApi guide, Custom UI integration, and Event guide |
| Save progress and continue later | Save and restore |
| Extend nodes and content types | Custom nodes, Custom ports, and Execution context |
| Diagnose authoring or runtime problems | Problem index, Authoring problems, and Runtime problems |