1. 文档目标与范围
本文档用于定义 Card-en-Ciel 的完整玩法设计方案，面向以下角色：
- 系统策划：用于拆分规则与参数实现。
- 关卡策划：用于构建关卡、事件、敌人组与节奏。
- 数值策划：用于平衡卡牌、敌人与经济系统。
- 程序与TA：用于确认状态机、流程图、数据结构。
- QA：用于构建玩法测试矩阵与回归项。
本文覆盖：
- 核心玩法循环（局外元进程 + 局内战斗）
- 回合制卡牌战斗规则
- 卡组构筑与成长路径
- 关卡与事件设计
- 难度与平衡理论
- 可观测指标（Telemetry）
- 内容生产规范
一场战斗打到后半段，帧时间从 22 ms 涨到 44 ms，帧率对半砍。抓 trace 之后发现罪魁是玩家的闪避拖尾特效——它在场景里稳态堆了 702 个存活实例，而玩家每秒最多闪避一两次。
根因在 Ribbon 发射器的 Particle State 模块：三个「让粒子死掉」的开关全是关的，于是组件永远不回池，每闪避一次净增 6 个，攒到 117 次就是 702。
这篇记录整个链条：怎么从 trace 定位到资产、为什么静态审计工具查不出来、运行时怎么在十分钟内实锤根因，以及归因过程中我自己踩的两个坑。数据来自一个 UE 5.x ARPG 项目的 Win64 Development 构建实机 trace。
上一篇按屏幕占比裁剪局部光动态阴影记的是同一个密集城市街道场景里,针对光的那一刀。这篇记另一条杠杆:那个场景里 30,518 个独立 StaticMeshComponent 直接推高的 draw-call 体量。我写了个编辑器工具把同 mesh 的散摆静物折成 HISM,全图跑通一次把 21,483 个 SMC 合进了 494 个 HISM。这篇讲为什么要合、怎么用、以及一路上崩过的几次和绕不开的坑。
做存档调试时经常要改档：改角色数值、改背包物品、换装备武器。但 .sav 是不透明的二进制，没法直接看、直接改。这篇记录一个把 .sav 导出成可读 JSON、手工编辑后再导回 .sav 的工具，以及做无损往返时踩到的几个坑——它们都和 UE 的 SaveGame 序列化机制细节相关。
整体只有两条控制台命令，在编辑器或 PIE 里输入：
SaveSystem.ExportSlotToJson <完整.sav路径>
SaveSystem.ImportJsonToSlot <完整.json路径>
玩家砍断僵尸肢体时，断口处那块"断骨"伤口网格会被拉扯成一根又细又长的尖刺，从蜷缩的躯干里穿出来，伴着被拉长的红色血肉，严重穿模。
这块伤口网格挂在一个 UPoseableMeshComponent 上，和宿主僵尸共用同一套骨架，骨骼名一一对应。问题就出在"共用骨架但只摆正了一根骨头"。
先说清楚：蒙皮和骨骼的关系
要看懂这个 bug，得先分清骨骼和网格这两件事。
骨骼（Skeleton / Bone） 是一套层级化的坐标系——父子变换树。骨头本身不可见，只是空间中的一组变换（位置、旋转、缩放）。动画每帧改变这些骨头的变换。
一个密集城市街道场景抓的 trace 里,我碰到一个不太常见的瓶颈形态:GameThread / RenderThread / RHIThread 三条线并列卡住,各约 88 ms,彼此在 ±9 ms 内;GPU 只忙 53 ms,有约 36 ms 余量。这篇记一下我针对其中一条杠杆——局部光动态阴影——做的运行时裁剪,包括为什么这么做、实现上几个绕不开的点,以及关掉/打开 CVar 的 A/B 数据。
同一个 trace 里针对另一条杠杆(30k 散摆静物的 draw-call)的处理,见把近场散摆静物合成 HISM 削 draw-call。两条线一起压,帧时才真正掉得下来。
GOAP（Goal-Oriented Action Planning，目标导向行为规划）是一种让 NPC 自己「想办法」达成目标的决策技术。行为树把决策路径提前写死，GOAP 反过来：你只描述角色想要什么（Goal）和能做什么（Action），至于先做哪一步、再做哪一步，交给规划器（Planner）在运行时算出来。
这套思路并不新，源头是 1970 年代的自动规划（STRIPS）。真正让它在游戏圈出名的是 2005 年的《极度恐慌》（F.E.A.R.）——敌兵会绕后、找掩体、喊队友合围，很大程度上就是 GOAP 规划出来的。更早在 2003 年的《杀出重围：隐形战争》里就试过一次，但那一代的 AI 因为行为不一致、战术偏简单、算力吃紧挨了不少批评。这段历史其实提前把 GOAP 的代价摆到了台面上：规划是要花 CPU 的，用之前得想清楚值不值。
在 VS 里装个 P4 插件,写代码时直接 checkout/revert 比来回切 P4V 顺手很多。Perforce 官方的 P4VS 插件用起来容易让 VS 卡顿甚至崩溃,不推荐。这里用的是第三方的 P4EditVS——轻量、不挂 VS。
装好后:
- VS 的选项(Options)里会多出 P4EditVS 页,每个配置项都带详细说明。
Extensions菜单下的 P4EditVS 子菜单,可以对当前编辑的文件执行 P4 操作。- 报错时去 VS 的 Output 窗口看 P4EditVS 的日志,排查用。
适用引擎:UE 5.4。平台以 Windows（dev/editor）为主,主机同理。
这是一份通用操作方法论,不针对某一次具体分析。单次分析的原始数据建议另存成一份带日期的记录,别和方法论混在一起。文中路径/类名均已脱敏,技术细节原样保留。
内存排查有两套互补工具,各有强项。我的经验是两套一起用、相互印证——单看任何一套都容易把「换血」误判成「泄漏」。
| 工具 | 强项 | 弱项 |
|---|---|---|
| memreport | 快、离线可读、给出各类对象/贴图/RT 的绝对占用,能判断「池子总量是否封顶」 | 只是快照,看不到分配来源/调用栈 |
| Unreal Insights 内存 trace | 逐条分配、时间轴、按 A/B/C 时间点筛「存活增长」、可到调用栈 | 文件巨大;调用栈需额外开启 + 配符号;区分不了「池内换血」和「真泄漏」 |