卡组创作
用卡牌引用和份数组建初始卡组或奖励池，并确认这份卡组被哪些内容使用
完成卡牌创作后，即可把已经验证的 GameCard 加入 GameDeck，开始编辑前，先在当前场景的 GameCardManager 中启用至少一个 Deck Database，数据库配置决定 Game Card Editor 能够列出、创建和编辑哪些卡组
打开 Game Card Editor
Tools > TinyGiants > GCS > Game Card Editor
在窗口顶部选择 Deck，再从左侧定位要编辑的卡组
上图呈现了 Iron Resolve 从资产选择到构成与核对的完整创作视图，左侧 List 确定当前卡组，中间 Inspector 设置身份并组装卡牌，右侧 Preview 则会把这些条目即时换算为卡牌数量、类型、标签与费用结构，同一份 GameDeck 既可以被玩家引用为 Starting Deck，也可以被遭遇战引用为 Reward Deck，引用位置不同，份数的运行时含义也会随之改变
选择待编辑的卡组
列表操作
| 操作 | 使用方式与结果 |
|---|---|
| 选择数据库 | 在 Database 中选择目标 Deck Database，后续创建、粘贴和排序都作用于当前数据库 |
| 创建 | + 会创建以 NewDeck 为基名的子资产 |
| 复制 | 复制按钮会保留现有字段和卡牌构成并创建副本；副本暂时沿用原 Name，改成新的非空名称后会同步重命名子资产，列表显示名与搜索、排序使用的子资产名也会随之更新 |
| 删除 | − 会在确认后删除当前卡组 |
| 搜索与筛选 | 搜索框与名称排序读取卡组子资产名，Tags 筛选读取 GameDeck.Tags |
| 排序与拖动 | 排序按钮在数据库原顺序、名称升序与名称降序之间切换；拖动列表行只改变数据库中的创作顺序 |
| 批量操作 | 使用 Ctrl/Cmd 或 Shift 多选卡组，再从批处理栏执行 Duplicate、Tag +、Tag − 或 Delete |
| 跨数据库复制 | Ctrl/Cmd+C 复制当前选中的一份卡组，切换到另一个已启用的 Deck Database 后，使用 Ctrl/Cmd+V 把副本粘贴到该数据库 |
列表行会统计 Card 引用有效的 DeckEntry，并累加这些条目的 Copies，因此，你可以不用打开 Inspector 就能够比较不同卡组的条目数与总份数
当前 PresetDeckDatabase 包含 16 份随包卡组，选中的 Iron Resolve 由 7 种卡牌条目组成，共计 17 张卡牌，其他列表交互见 Game Card Editor，其余卡组及用途可在 Demo 内容索引中继续核对
配置卡组身份
Basic
Basic 保存卡组自身的名称、说明与项目分类，这些数据负责识别和查找卡组，不会替代卡牌条目，也不会直接改变抽牌行为
| 字段 | 配置内容 |
|---|---|
| Name | 编辑器列表与 Preview 使用的显示名称，非空修改会同步到子资产名，玩家卡组选择器读取同步后的子资产名，项目 UI 可以自行读取该字段 |
| Description | 说明卡组定位、预期打法或奖励用途的简短文本 |
| Tags | 供列表筛选和项目分类使用的卡组标签，GCS 不会自动为标签附加战斗规则 |
将 Name 设为 Iron Resolve，保留新兵初始套牌的说明，再添加 Warrior 与 Novice
Iron Resolve 的名称、说明和两枚标签已经与战士新兵套牌一致，接着用 Visual 绑定编辑器能够显示、项目 UI 可以读取的卡组图标
Visual
Icon 会直接出现在编辑器的卡组列表、Display 预览与 Player 模式 Deck 卡片中，项目 UI 可以读取这个字段自行显示，GCS 不会自动把它绘制到自定义界面
这个图标只负责卡组层面的呈现，不会替换卡背、卡牌 Template 或单张卡牌插画，当然，如果你的游戏中有卡组的UI展示，那你可以直接从资产中获取到它
为 Iron Resolve 选择 Deck_Warrior_Start
卡组身份与图标完成后，列表和 Preview 已经能够稳定显示 Iron Resolve，Cards 中的引用与份数则决定这份卡组包含哪些卡牌
设置卡牌与份数
点击 Cards 标题右侧的编辑图标会打开 Edit Deck 选择器，左键点击卡牌会增加一份，右键点击会减少一份，份数降到 0 时该条目会从卡组中移除，选择器支持名称搜索，并把当前已选卡牌排在各自数据库分组的前部，同时启用多个非空 Card Database 时，卡牌会按数据库分组，只有一个数据库时会展开成平铺列表，没有可用数据库时才会回退查找项目中的全部 GameCard
回到 Inspector 后，每个卡牌块都会显示图标、名称、Copies 与基础 EnergyCost，左键点击卡牌块可以直接切换到 Card 并继续编辑对应资产
Iron Resolve 使用 4 份 Strike、4 份 Defend、各 2 份 Insight、Bandage、Slash 与 Shield Bash，再加入 1 份 Channel，7 个条目合计 17 份，Cards 区没有卡牌重排控制，Entries 的保存顺序也不会决定抽牌顺序，战斗开始时抽牌堆会先洗牌，带有 Innate 的卡牌会在洗牌后获得起手优先级，起始手牌、抽牌方向与弃牌堆回洗规则见卡牌、手牌与牌堆
区分初始卡组与奖励卡池
卡牌引用与份数写入同一份 GameDeck，但引用这份资产的位置会决定 Copies 在运行时的含义
| 用途 | Copies 与运行结果 |
|---|---|
| Starting Deck | 持久 Master Deck 为空时，Copies 决定生成的战斗卡牌实例数，随后建立并洗牌初始抽牌堆 |
| Reward Deck | Copies 作为对应 DeckEntry 的抽取权重，候选按条目无放回抽取，选中的卡牌会向 Master Deck 增加 1 张 |
GamePlayerUnit.StartingDeck 保存角色的起始卡组引用，GameEncounter.RewardDeck 与 BattleRules.CardRewardCount 保存遭遇战的奖励卡组引用和候选请求数
BattleRules.CardRewardCount 默认请求 3 项，运行时最低按 1 计算，最终数量不会超过有效条目数
卡组引用缺失、卡组为空或没有有效卡牌时，奖励候选可以为 0 项
在任何一处引用这份卡组之前，Preview 都可以先检查它自身的静态构成是否符合预期，字段的完整配置分别见玩家创作和遭遇战创作
检查卡组预览
Preview 会在卡牌引用或份数变化后重新计算，它显示的是 GameDeck 当前保存的创作数据，不会模拟升级、费用修正、FlowGraph、Hook 或实际抽牌结果
显示信息
Display 把 Icon、Name 与 Description 组合成可见卡组卡片，并用 Cards 显示不同 GameCard 引用数量，用 Copies 显示所有有效条目的份数总和
Cards 7 与 Copies 17 和前面的构成一致，Edit Deck 选择器会把同一张卡牌的全部份数保存在一个条目中
如果外部序列化或旧资产留下重复引用，Preview 的 Cards 会按 GameCard 去重，List 行仍会统计每个 Card 引用有效的条目
身份与总数已经对齐后，Distribution 会说明这 17 份卡牌由哪些类型、稀有度与卡牌标签组成
卡牌分布
Distribution 按份数读取每张卡牌的 Type、Rarity 与 Tags，一张卡有 4 份，就会为对应分类贡献 4 次，它不读取卡组自己的 GameDeck.Tags，也不会统计卡牌 Keywords
Iron Resolve 包含 Basic 8、Skill 4 与 Support 5，17 份卡牌全部为 Common，标签则集中在 Attack 8、Armor 4、Card 2、HP 2 与 Energy 1
这些分类说明了卡组由什么组成，实际每回合能否使用这些卡牌还取决于基础费用在 17 份卡牌中的分布
费用曲线
Energy Bar 按每张卡牌创作时保存的基础 EnergyCost 与 Copies 统计：
0 至 4 费分别计入同名柱，5 费及以上都计入标记为 5 的最后一柱，下方再归纳为 Low（0-1）、Mid（2-3）与 High（4+）
这项统计不会计算升级形态、Master Deck 的 CostDelta、Hook 修改后的有效费用或遭遇战规则，费用曲线需要与玩家的每回合能量和实际战斗流程一起判断
当前卡组由 5 份 0 费牌和 12 份 1 费牌组成，17 份全部落在 Low，其中 1 费牌占比已经达到 Insights 的提示阈值
构成提示
Insights 使用固定阈值检查当前静态统计，它不会读取卡牌 Behavior，也不会判断项目中的真实连携逻辑
| 提示 | 触发条件 |
|---|---|
Cost N dominates | 任一费用桶占总份数的比例达到 50% |
No low-cost cards | 总份数至少为 6，并且没有 0-1 费卡牌 |
No high-cost cards | 总份数至少为 6，并且没有 4+ 费卡牌 |
Type-focused | 单一 Type 占总份数的比例达到 70% |
Tag only N cards | 任一卡牌标签出现 2-4 次，面板会以 5 次作为固定提示阈值 |
Curve looks balanced | 总份数至少为 6，并且没有命中其他提示 |
Cost 1 在 Iron Resolve 中占 71%，卡组又没有 4+ 费牌，这两项费用结果会产生前两条提示
Armor 4、Card 2 与 HP 2 都处于 2-4 次区间，因此又产生 3 条标签提示
面板合计显示 5 条启发式提示，用于复核设计取向，不属于结构校验错误，当总份数少于 6 且没有命中其他规则时，Insights 不会出现，Preview 核对完成后再处理 Validation 发现的数据结构问题
处理校验问题
Game Card Editor 的 Issue Badge 统计当前所选 Deck Database 中的全部卡组，不只统计当前正在查看的 Iron Resolve
| 级别 | 触发条件 |
|---|---|
| Error | Name 为空 |
| Warning | Description 为空 |
| Warning | Entries 为 null 或条目数量为 0 |
| Error | 任一非空 DeckEntry 的 Card 引用为空 |
| Error | 任一 DeckEntry.Copies 小于 1 |
上面这些问题不会阻止保存、删除或进入 Play Mode，Issue 条目只是用于定位到存在问题的卡组或字段使用，而想要校验未覆盖的内容，则需要按职责另行检查：
| 未检查范围 | 需要人工确认的内容 |
|---|---|
| 卡组呈现 | Icon 与卡组 Tags 是否符合项目约定 |
| 卡牌构成 | 是否存在重复条目，所引用卡牌自身是否完整 |
| 使用方式 | Starting Deck 与 Reward Deck 的分配是否符合预期 |
| 设计结果 | 费用曲线、实际抽牌与战斗结果是否符合设计预期 |
自动检查的边界与 Issue 跳转方式见 Game Card Editor
结构问题清除后，打开 Used By，确认这份 GameDeck 当前被引用为 Starting Deck 还是 Reward Deck
检查资产引用
Used By 会扫描当前场景 GameCardManager 已启用的 Player Unit Database 与 Encounter Database，玩家条目对应 StartingDeck，遭遇战条目对应 RewardDeck
这项检查不会覆盖未启用数据库、其他场景或 Prefab，不会扫描项目代码、私有字段、运行时查找与自定义间接引用，也不会在删除卡组时提供引用保护，替换或删除资产前仍要在这些范围内检查项目级引用
图中的 Squire 已经通过 StartingDeck 字段引用 Iron Resolve，这项引用决定战斗的初始卡牌来源，但运行时不会修改 GameDeck 资产本身
卡组进入战斗后的行为
GameDeck 是可复用的内容定义，玩家角色可以把它用作 Starting Deck，遭遇战也可以把它用作 Reward Deck，战斗开始后，GCS 会根据持久 Master Deck 或 Starting Deck 创建独立的卡牌实例，再把这些实例分配到抽牌堆、手牌、弃牌堆和消耗堆
编辑卡组时只需确认卡牌、份数和引用用途，跨战斗卡组如何初始化、战斗牌堆如何变化以及奖励如何加入持久卡组，统一见卡牌与牌堆生命周期；项目代码需要读取卡组或管理 Master Deck 时，再查阅 GCSApi 使用指南
从起始手牌到战后奖励的完整流程可以在第一场战斗中直接验证，继续创作时，在 Game Card Editor 顶部切换到 Player 并选择 Squire，保留已经绑定的 Iron Resolve，再按角色创作补全生命、能量、战斗预制体与遭遇战依赖，角色便可以带着当前卡组进入遭遇战