Card Authoring

🃏

Guide

Define what a card costs, how it appears in your UI, and which FlowGraph runs when the card resolves

Open the editor:

Tools > TinyGiants > GCS > Game Card Editor

then default choose Card; the Workbench keeps the card list, editable data, and live preview visible together

Authoring order

1. In List, choose the target card database, then create a card with + or duplicate a similar card with the copy button
2. In Inspector, complete Basic, Visual, and Behavior from top to bottom
3. In Preview, check Display, Render, and Behavior Summary against the result you want in game
4. Finish with Used By so you know which decks, upgrade links, or behavior graphs will be affected by later changes

List area

List

Choose a database first; + creates a blank card in that database, the copy button duplicates the selected card, and − deletes the selected card after confirmation; duplicating is the fastest starting point when the new card shares a frame, targeting mode, tags, or graph shape with an existing card

The search box matches card names; the filter rows narrow the list by Type, Rarity, Keywords, and Tags; the sort button cycles through the available list orders; drag a row to change its authoring order inside the database; this does not control battle draw order

Inspector area

Basic

Basic contains the card data that determines how the card is identified, presented, aimed, grouped, and upgraded

Field	What to configure
Name	The player-facing name; A non-empty value also renames the card sub-asset
Description	Rules text for your UI; keep it synchronized with the Behavior graph
Cost	Printed base energy cost; the editor clamps it to 0 or higher; runtime hooks and effects can change the amount actually paid
Type	A category used by display, filtering, and your own logic; choose a known value or type a new one
Rarity	Common, Rare, Epic, Legendary, or a custom project value
Target	How the player aims the card; choose the interaction that matches the Behavior's resolved range
Tags	Free-form project labels; they have no built-in rules until your graph or code reads them
Keywords	Fixed engine rules such as Exhaust, Ethereal, Retain, Innate, and Unplayable
Upgrade	The card this asset becomes when upgraded. None means there is no upgrade link

Target and graph agreement

The Target field controls the card-play interaction; the FlowGraph still decides which units receive each effect; these two choices must describe the same card

If Target says Single Enemy but the graph resolves All Enemies, the UI asks the player to choose one enemy and then ignores that choice. Target Selection is the authority for all four Target modes, UnitSource, connected Target ports, card sources, selectors, and empty results

Built-in keywords

Keyword	Runtime rule
Exhaust	Moves the card to the exhaust pile after it resolves
Ethereal	Exhausts the card if it remains in hand at turn end
Retain	Keeps the card in hand when the encounter discards the rest of the hand
Innate	Moves the card to the top of the initial draw pile; if Innate cards exceed opening-hand space, only a random subset fits
Unplayable	Prevents the card from being played while allowing it to occupy hand space

Visual

Assign Icon for list rows and UI presentation; assign Template to the prefab rendered as the full card face; A missing template falls back to a placeholder preview, so a readable Display card does not prove that Render is ready

Behavior

Click Edit FlowGraph to define what happens when the card resolves; A normal playable card begins at OnCardPlayed, then performs gameplay changes and presentation effects from left to right; the chips below the button summarize the entry points currently present in the graph

For example, a direct attack can connect OnCardPlayed to Deal Damage, then to a presentation group; A repeated attack can route through Loop and resolve a target for each iteration; the card's description should state the result the graph actually produces

Preview area

Display

Display is UI data, not the prefab render; it assembles the card's Icon, Name, Description, EnergyCost, Type, Rarity, and tags into a compact presentation so you can judge hierarchy and missing content at a glance

These are public fields on GameCard, so your own UI can read them directly from the card reference; for example, card.Name, card.Description, card.Icon, and card.EnergyCost can drive a hand view or reward screen without extracting data from the Workbench preview

Render

Render instantiates the assigned Template in an isolated preview and applies the card data to it; use it to check the finished card face, artwork crop, cost badge, name, and rules text; this is the closest Workbench check to what the player will see on the actual prefab

Behavior Summary

Behavior Summary condenses each entry path into a readable line; it is a quick structural check, not a substitute for opening the graph; if the summary is empty, the card has no executable entry path

Used By

Used By lists every known dependency on the selected card; deck entries show where the card is included; card links can show upgrade relationships; behavior references show graphs that point at the card; click a row to open the owning asset in its matching Workbench mode

Check Used By before changing a shared card or deleting an upgrade target; the listed owners show which authored content depends on it

Runtime access

During a battle, GCSApi.CurrentHand, GCSApi.Battle.DrawPile, GCSApi.Battle.DiscardPile, and GCSApi.Battle.ExhaustPile expose the live card references; read authoring data from each GameCard; use battle APIs and FlowGraph nodes for state changes instead of mutating deck piles directly

Validation and final check

Card validation reports an empty name as an error; empty type or description, a missing template, an empty behavior graph, and FlowGraph problems are warnings

Before moving on, confirm all of the following:

• The list row is recognizable without opening the card
• Basic data, target interaction, description, and graph describe the same result
• Display contains every value your UI needs
• Render shows the finished prefab without missing artwork or text
• Behavior Summary contains the intended entry path
• Used By contains only the dependencies you expect