15 · 跨部门协作与文档体系
独立团队的协作本质是用最少的会议传递最多的设计意图。
原则:异步优先,可玩构建 > 文档 > 会议。
1. 文档层级(现代做法)
| 层 |
内容 |
载体 |
更新频率 |
| 宪法 |
支柱 + 反目标 + 常数表 |
1 页纸,置顶 |
仅方向变更时 |
| 活文档 |
系统细节、数值表 |
wiki / Notion |
随改随更 |
| 决策日志 ADR |
为什么这么定 |
追加式列表 |
每次重大决策 |
| 交接文档 |
TDD、美术 brief、音频清单 |
ticket / 规格单 |
按交付 |
三戒:
- 每页开头写清"读者是谁 + 他要做什么决定"
- 不写给"未来的自己"的文档
- GDD 只做索引,正文进 wiki(200 页 GDD 第二个月就没人打开)
2. 设计 ↔ 程序(7 条)
| # |
规范 |
| 1 |
每个系统一份 TDD:意图一句话 + 规则 + 边界条件 + 数据格式 + 失败模式 |
| 2 |
数值全部走外部参数表,设计可自调,改数值不编译 |
| 3 |
每个 feature 交付时带 debug 开关与可视化调试层 |
| 4 |
验收标准写进 ticket("什么算做完") |
| 5 |
每周一次"设计意图 vs 实现"走查,设计亲自玩构建 |
| 6 |
暴露可调参数清单,禁止硬编码手感数值 |
| 7 |
技术风险先 spike 后承诺 |
每份 TDD 必须有一句"反例":程序最容易做出"能跑但不对味"的东西。
写清楚"什么情况下这个实现是错的",比写规则更有效。
3. 设计 ↔ 美术(6 条)
| # |
规范 |
| 1 |
风格圣经 Style Bible:参考、色板、笔触、禁区 |
| 2 |
高概念情绪板:3 张图讲清调性 |
| 3 |
可读性优先级清单:玩家必须看清的三件事,永远高于好看 |
| 4 |
灰盒/白模先行,美术不为未验证玩法生产资产 |
| 5 |
资产规格表(尺寸/命名/枢轴/图集约定) |
| 6 |
镜头预算:定义 trailer 与截图会拍哪些画面,美术优先保这些 |
4. 设计 ↔ 音频(6 条)
| # |
规范 |
| 1 |
声音优先级矩阵:哪些时刻必须有反馈,哪些可静默 |
| 2 |
定义一个"音频钩子"—— trailer 的第一个声音 |
| 3 |
静音可玩性检查:反馈不能只靠声音 |
| 4 |
音频实现指南(中间件参数、分层/混音规则) |
| 5 |
临时音占位的最晚替换期限 |
| 6 |
音频参与垂直切片,不做后期贴片 |
5. 设计 ↔ 发行 / 市场(7 条)
| # |
规范 |
| 1 |
可发现性资产包:3 张 gif-able 截图 + 60–90 秒 trailer beats + 15 字钩子 |
| 2 |
wishlist 目标倒推里程碑(参考 ~0.15x 转化中位) |
| 3 |
Steam 标签策略:前 5 个标签画像、Top 20 排序、剔除误导标签 |
| 4 |
Next Fest demo 切片(独立可玩、10 分钟、有高潮) |
| 5 |
社区可玩梗点清单(主播能玩出什么) |
| 6 |
定价建议(体量 ↔ 价格带 ↔ 转化率) |
| 7 |
节展/IGF/IndieCade 提交时间表倒推可玩版本日期 |
6. 通用协作规范(5 条)
| # |
规范 |
| 1 |
单一真相源(wiki/Notion),禁止多份文档冲突 |
| 2 |
决策日志记录 ADR(5 行格式,见 principles/06) |
| 3 |
任何变更先过支柱检验(见 principles/06 §5) |
| 4 |
远程团队异步优先:用可玩构建 + 录屏替代长会 |
| 5 |
每页文档开头标注"读者是谁 + 他要做什么决定" |
7. 设计评审(Design Review)流程
频率:双周一次(与迭代同步)。
| 环节 |
时长 |
内容 |
| 1 演示可玩构建 |
10 min |
不看 PPT,看实际运行 |
| 2 对照支柱 |
10 min |
本次改动服务哪条支柱? |
| 3 对照常数表 |
5 min |
体验指标是否仍在目标内? |
| 4 六脉体检 |
10 min |
逐维打分,标出 ≤1 的维度 |
| 5 决策 |
5 min |
改 / 砍 / 再测;重大分歧用 48h 原型 |
禁止:评审变成"这个功能好不好看"的讨论。评审只问三件事:服务支柱吗?进入循环吗?玩家能感知吗?
8. 小团队(2–5 人)的协作简化
| 大团队做法 |
小团队简化 |
| 专职制作人排期 |
用看板 + 每周 30 分钟同步 |
| 完整 TDD |
TDD 精简为"意图一句话 + 边界条件 + 反例" |
| 正式评审会 |
一起玩构建,边玩边说 |
| 分层文档 |
宪法 1 页 + 其余在 issue 里 |
| 专门 UX 研究 |
每周 3–5 个外部玩家试玩 |
小团队铁律:减少文档,增加可玩构建。一个能跑的构建比十页文档更有效。
9. 反模式
| 症状 |
修法 |
| 200 页 GDD 无人打开 |
降为索引,正文进 wiki |
| 文档没写读者是谁 |
每页开头补一行 |
| 程序做出"能跑但不对味" |
TDD 加"反例" |
| 数值硬编码 |
参数外置 |
| 美术为未验证玩法生产资产 |
灰盒先行 |
| 音频后期贴片 |
参与垂直切片 |
| 发行前 4 周才想 trailer |
立项就写 5 个镜头 |
| 长会代替可玩构建 |
异步优先 |
| 评审变成审美讨论 |
只问三件事 |
| 创意分歧靠投票 |
支柱裁决 → 48h 原型 |
10. 参考
game-tech-art(美术/技术侧的接口细节)game-audio-design/.../audio-integration-spec.md(音频交接规格)- Steamworks 文档:标签与可见性
- IGF / IndieCade 提交规则(作为外部里程碑锚点)