Hello Unity Community! 
After releasing GameEventSystem, I am excited to announce that my second Unity tool, Game Card System (GCS), is now officially available on the Unity Asset Store.
GCS is a visual, FlowGraph-powered framework for building deckbuilding and card-battle games in Unity. It provides a complete foundation for cards, decks, statuses, enemy intents, encounters, turn-based combat, and the many systems that connect them. Common gameplay mechanics can be created directly in the editor, without writing a separate effect script for every piece of content.
Gameplay Showcase
See the complete GCS Demo in action across 12 playable battles, four hero classes, Normal, Elite, Boss, summon, and multi-enemy encounters.
Product Overview
See how GCS takes a project from visual content authoring and FlowGraph Behaviors to complete, playable card-battle gameplay.
Release Status
Game Card System is now officially available on the Unity Asset Store!
Get GCS here:
A Note from the Creator
I am developing an indie card roguelike, and as the project moved into mid-production, I could feel the battle logic gradually slipping out of control.
Each card, status, and enemy intent needed its own control logic. Turns, card piles, units, statuses, UI, and animation all maintained their own data and execution rules. A mechanic might work perfectly on its own, but once it interacted with energy costs, targeting, Hooks, status modifiers, enemy intents, summons, rewards, and presentation timing, unexpected dependencies began to appear everywhere.
Debugging became equally difficult. Many problems could only be discovered by repeatedly playing full battles, and even after reproducing a bug, it was often difficult to determine which rule, phase, condition, or waiting process had caused it.
At the beginning of the project, when there were only a few cards and mechanics, this was still manageable. Modern AI agents were also advancing rapidly, and during prototyping they were extremely useful. They could write scripts, complete missing logic, and turn an idea into something playable much faster than before.
The situation changed as the project grew.
With more cards, stacked statuses, changing costs, draw and discard rules, enemy intents, summons, rewards, and presentation flows all interacting with one another, an AI agent could still generate code quickly, but it could not reliably retain every changing dependency across the entire project. A small modification in one system could cause several unexpected reactions elsewhere.
That experience taught me something important: AI can accelerate development, but it cannot replace a mature, stable, and maintainable framework.
If the underlying architecture is unclear, generating more code only makes the project harder to control. The AI may solve the immediate task while adding another special case, another hidden dependency, or another script that becomes difficult to maintain several months later.
The opposite is also true. When an AI agent is given a clear data model, fixed operating boundaries, documented tools, and results that can be inspected and validated, it can become much more than a temporary code generator. It can participate in real content production while working inside a structure the developer still understands and controls.
This realization became one of the main reasons I created GCS.
GCS first had to solve the problems in my current game, but I also wanted it to become a reusable foundation for the card roguelikes I may build in the future. Instead of asking an AI agent to invent another battle framework from scratch, I can let it work within the structure provided by GCS.
It can help configure the content databases, create cards, statuses, enemies, and encounters, assemble or modify FlowGraph Behaviors, adjust values, inspect references, and analyze verifiable runtime results. The content it produces becomes part of the same visible and editable assets that I use myself, rather than another collection of temporary scripts hidden throughout the project.
GCS does not include or require a particular AI model, and using AI is completely optional. Its purpose is to provide the stable structure that both developers and modern AI agents need in order to work on a growing commercial project without continuously rebuilding the foundation.
For me, the value is simple. Developers should be spending their time deciding whether a card is enjoyable, whether the numbers are balanced, whether two mechanics can create an interesting combination, and whether an encounter produces meaningful decisions. We should not have to spend most of that time maintaining another turn system, rewriting pile logic, adding special-case scripts, or tracing invisible dependencies.
GameEventSystem taught me how valuable it is to make invisible systems visible. GCS takes that idea further and applies it to the complete development workflow of a card roguelike.
Happy deckbuilding,
TinyGiants, from China
What is GameCardSystem?
GCS is a ScriptableObject-driven card-battle framework. You author cards, decks, units, statuses, and encounters in a six-mode Workbench; you define what cards and statuses do in a visual FlowGraph; and the battle runtime β turn phases, card piles, targeting, rewards β runs out of the box.
flowchart LR
A[Workbench<br/>edit content] --> B[FlowGraph<br/>wire behavior]
B --> C[Play Mode<br/>run battle]
C --> D[Monitor<br/>inspect live state]
D --> A
Four editor surfaces cover the full workflow from setup, content editing, and behavior wiring to Play Mode inspection.
| Window | Open from | Job |
|---|---|---|
| Game Card System | Tools/TinyGiants/GCS/Game Card System |
Initialize scenes, check environment support, open tools, and jump to demo or custom folders. |
| Game Card Editor | Tools/TinyGiants/GCS/Game Card Editor |
The six-mode Workbench where the card roguelike battle content is authored and configured. |
| Game Card Monitor | Tools/TinyGiants/GCS/Game Card Monitor |
A live Play Mode inspector for battle state, piles, units, phases, animation gates, flow runs, and events. |
| FlowGraph editor | Edit FlowGraph on a Behavior field |
The node editor for card, status, enemy behavior, and reusable group graphs. |
Author Everything Visually
| Feature | Description |
|---|---|
| 6 Database Families | Encounters, Player Units, Enemy Units, Cards, Decks, Statuses β GUID identity, refactor-safe |
| Embedded Effect Graphs | Card, Status, and Enemy behaviors live on the asset itself β no separate behavior files |
| Six-Mode Workbench | List / inspector / preview editing with drag-reorder, copy/paste, validation, and full Undo/Redo |
| FlowGraph Editor | Node search, snap-to-grid, align/distribute, auto-layout, groups, host-aware validation |
| Smart Dropdowns | Value fields aggregate built-in defaults and in-use values β extensible by free text |
A Visual Effect Engine
The built-in node set covers more than 140 nodes across entries, actions, selectors, operators, flow control, intent patterns, hooks, events, and presentation. In practical card-game terms, that means the visual system can express the common mechanics expected from full deckbuilders:
| Mechanic family | Examples GCS can express visually |
|---|---|
| Damage and defense | Single-target damage, area damage, multi-hit attacks, armor gain/loss, bypass armor, kill, revive, delayed damage. |
| Cards and piles | Draw, discard, exhaust, retain-style flows, shuffle, move cards between piles, add generated cards, transform cards, upgrade cards, remove cards. |
| Cost and energy | Gain/spend energy, temporary cost changes, card-specific cost rules, energy-per-turn hooks, playable-card hooks. |
| Status systems | Poison/burn-style ticks, strength/dexterity-style stat changes, shields, thorns, regeneration, control statuses, stack caps, stack decay. |
| Conditional logic | HP thresholds, status checks, card/pile checks, variables, event arguments, math, comparison, branching, switching, filtering, sorting. |
| Randomness and choices | Random targets, random cards, weighted enemy patterns, player choice branches, generated collections, shuffled collections. |
| Enemy behavior | Sequenced intents, weighted random intents, HP-threshold phase changes, once-per-battle moves, every-N-turn specials, summoned units. |
| Reactions and hooks | Modify incoming/outgoing damage, armor, healing, status application, draw count, hand size, card cost, and card playability. |
| Events and integrations | Raise internal events, listen to custom events, optionally bridge to GameEventSystem when GES is installed. |
| Presentation | VFX, SFX, floating text, unit slides, flashes, camera shake, animation wait gates, and visual feedback blocks. |
| Feature | Description |
|---|---|
| Rich Node Library | Damage, healing, armor, energy, piles, statuses, targeting, randomness, loops, choices, VFX/SFX/camera β connect, donβt code |
| Unified Targeting | Every action picks its units from source/target collections β no per-card selector types |
| Cross-Turn Effects | Schedule delayed effects to turn start, turn end, or the enemy phase |
| Card Choice & Discovery | Built-in βpick one of threeβ popup with a pluggable presenter |
| Animation Gating | Effect execution waits for your visuals β timing stays clean without coroutine plumbing |
A Complete Battle Runtime
| Feature | Description |
|---|---|
| Full Phase Lifecycle | BattleStart β TurnStart β Player β Enemy β TurnEnd β BattleEnd, with pause/resume |
| 6-Pile Model | Draw / Hand / Discard / Exhaust, plus run-level MasterDeck and post-battle RewardPile |
| Post-Battle Rewards | Three-choice rewards: cards, energy, permanent cost discounts β tracked per run |
| Dynamic Battlefield | Summon and remove enemies mid-battle; two-phase bosses out of the box |
| 30 Built-In Statuses | 15 buffs + 15 debuffs (Strength, Vulnerable, Poison, Burn, Thorns, Lifestealβ¦) with stack & decay rules |
| Pattern-Based Enemy AI | Sequence / Random / Conditional / HP-threshold intent patterns with next-turn intent preview |
Presentation Included, Not Imposed
Drag-to-play fan hand with hover lift and targeting arrow, unit HP/status/intent widgets, energy and pile HUD, choice popup, reward screen, result popup β shipped as a demo-layer reference you can reskin or replace entirely.
Built to Be Extended
Everything user-facing goes through one documented API entry point (GCSApi) β battle control, live state, events, and content discovery.
The public API surface is organized into six practical areas:
| API area | What it gives you |
|---|---|
| Battle control | Start a battle, play a card, end the player turn, apply or skip rewards, and dispose battle state. |
| Live state reads | Read current phase, battle view, hand, piles, player unit, enemies, rules, and runtime values. |
| Events | Subscribe to battle, card, damage, armor, energy, status, reward, pile, unit, and flow events. |
| Content discovery | Enumerate and find cards, decks, units, statuses, encounters, and active databases. |
| Authoring registries | Discover registered card types, card tags, description tokens, and FlowGraph node types. |
| Integration surface | Drive custom UI, map screens, save systems, encounter selection, and project-specific runtime glue. |
[Serializable]
[FlowNode("Action", "Heal If Below Half")]
public sealed class HealIfBelowHalfNode : MutatorNode
{
public UnitSource TargetSource = UnitSource.Self;
public int HealAmount = 5;
public override void Execute(IExecutionContext ctx)
{
int amount = ctx.PullInputOr(this, nameof(HealAmount), HealAmount);
foreach (var target in ctx.ResolveUnits(this, TargetSource, nameof(TargetSource)))
{
if (target.IsDead || target.CurrentHp * 2 > target.MaxHp) continue;
ctx.Controller.GainHp(target, amount);
}
}
}
- Custom nodes: subclass an authoring base, add one attribute β the node appears in the editor menu with ports inferred automatically
- Custom card types, tags, and description tokens via the same attribute-driven registries β zero manual registration
- Copy-paste samples and a node template included
Playable Demo Out of the Box
Hit Play and youβre in a battle β prebuilt hand, HUD, targeting, choices, rewards, and results, with a full audio & VFX pass.
- 4 player classes (Warrior / Mage / Hunter / Priest) Γ 3 tiers = 12 player units
- 16 enemies across Normal / Elite / Boss / Phase-2 summon forms
- 80 cards, 30 statuses, 16 decks, 12 themed encounters
- 12 battle scenes playable immediately β two-phase bosses included
- All demo content doubles as reference templates: clone and modify without touching plugin source
Platform & Compatibility
- Unity 2021.3 LTS+, including Unity 6
- Built-in Render Pipeline supported today; URP adaptation lands before release
- Zero third-party runtime dependencies
- Optional GameEventSystem bridge β GCS battle events on the GES event bus if you use both
Road to Release
Core systems, editor toolchain, effect engine β complete- Playable demo with full audio/VFX pass β complete
URP pipeline adaptation β in progress- Final QA sweep across all 12 demo scenes
Asset Store submission
Full documentation (English Β· δΈζ) ships with the release at tinygiants.tech.
Official Links
Community & Support
Discord (Recommended)
Want to influence the launch feature set or get beta access? Discord is where the roadmap happens.
Join Discord
Direct Support
support@tinygiants.tech β Response within 24-48 hours.
Lifetime License
Like GES, GCS will ship with lifetime updates. No subscriptions.
Professional tools for professional developers.
[TinyGiants]