简介这份《游戏项目管理》PDF文档面向游戏研发团队管理者、项目经理及有志于进入游戏行业的从业者梳理项目管理在游戏开发场景中的落地框架。内容从项目管理的基本定义切入系统讲解规划、组织、人事、领导与控制五大过程并延伸到项目经理的职责定位、组织架构应以结果为导向的设计原则以及项目经理与制作人在权责划分上的差异。文档还附有实用的检讨清单逐项辨析制作人、执行制作人、监制、企划、游戏设计师、编剧、角色设计师、2D/3D插画师等岗位的职务分工并涉及甘特图、进度表等常用工具与项目评价标准。资源为单个PDF文件压缩包约20KB轻量易读适合作为团队内部分工梳理与流程规范建设的参考。目前已有388人学习下载。1. 别急着排甘特图《游戏项目管理.pdf》里最扎眼的是组织架构检讨项目做到第八个月例会上一句这个改动谁签字把所有人问住了——制作人认为自己管方向项目经理认为自己管流程监制认为自己只管这周的活结果三份周报对应三套进度。这份《游戏项目管理.pdf》开头那段项目管理检讨几乎就是这场景的病历公司与项目应有不同架构却混着用、各部经理与总监的职务定位含混、项目经理与制作人的权责没划开甚至连项目算不算已经成立都没有界定标准。它真正值钱的地方不在附录里那串规划、组织、人事、领导、控制的定义而在于把游戏行业特有的头衔——制作人、执行制作人、监制、企划、游戏设计师、编剧、角色设计师——和草案、仕样书、α版、β版、Master 这套收敛流程摊在同一份文档里。适合带着五到二十人团队、正准备从作坊切到流水线的人读如果你同时被外包与发行方两头追进度表这份文档能把你缺的那几块补上。2. 权责错位怎么修用 RACI 把项目经理、制作人与监制的边界写死头衔不清不是命名问题是决策问题。同一件事有两个人都觉得我能拍板最后的结果通常是谁都不拍工期在等签字的过程中一点点漏掉。先把每个头衔的实际职责摆平再用一张矩阵把签字权固定下来最后才是照着结果去搭组织。2.1 五个头衔到底各管什么中文游戏圈常把这几个叫法混用尤其是制作人和项目经理很多团队干脆一个人兼。混用本身不是错错在兼了之后没人说得清哪些决定必须由谁做。下面这张表按文档里的职责描述整理重点看关键决策权一列。头衔对什么负责关键决策权最常见的误用产品经理 Product Manager产品从调研、制造到销售的整个过程产品变成普通产线一部分后仍负责维持与成长产品定位与后续延续性被当成需求收集员只有整理权没有取舍权制作人 Producer游戏从制作到贩卖的全流程掌控发展方向、进度与预算重要事项决定、范围与预算取舍只对上层汇报长期脱离执行现场执行制作人 Executive Producer执行面开发工作分配、执行检查、跨组协调执行节奏与任务分配与制作人职责重叠形成双头指挥监制 Director发包、工作分配、制作流程与行程管理实际制作现场负责人现场排程与外包发包被当成行政打杂排程权被架空项目经理 PM指派并领导工作人员推进项目对项目成败负责解决项目内各项问题流程、资源与风险处理只有会议纪要权没有冲突裁决权分界线可以粗暴记成三句话制作人回答做什么、值不值得做项目经理回答怎么按时做出来、现在卡在哪监制回答这周谁做哪件活。文档里那句游戏制作人并不能随时与游戏研发在一起所以执行面由执行制作人来负责就是这个意思——制作人要面对公司与外部执行面必须有人常驻现场。2.2 一张 RACI 矩阵把签字权落定RACI 的四个字母分别对应执行R、最终负责A、被咨询C、被告知I。规则只有一条要紧每一行交付物必须有且仅有一个 A。有两个 A 等于没有 A一个 A 都没有则意味着这事没人对结果负责。下面是按游戏项目常见节点填的示例。交付物 / 决策制作人项目经理监制主程企划草案评审通过ACIIR仕样书冻结ARCCR里程碑验收ARCCI内存超预算裁剪ACRRC外包美术发包ACRIIMaster 版本放行ARCCI小团队常见做法是制作人兼 A、项目经理兼 R这没问题但名字要写死在同一格里不能写看情况由谁定。矩阵本身是文档改起来容易所以最好让机器帮你守规则。2.3 以结果为导向搭架构而不是按人头搭文档里有一段讲得很直白许多公司把组织营建在员工身上而不是先决定要达成的结果再找合适的人占住那些位置。小公司没有真正的组织架构先把现有人员分配去做所有工作不用多久又招一批人来分摊架构始终是补出来的。可执行的做法分四步先列出这一阶段必须交付的结果给每个结果指定唯一负责人按结果把岗位画出来最后才往岗位里填人。落到工具上把矩阵存成 CSV 并用脚本校验比每次开会确认要省事得多。# raci_check.py # 校验 RACI 矩阵每个交付物必须有且仅有一个 A且至少一个 R # 输入 CSV 第一列为交付物其余列为角色格值为 R/A/C/I 或留空 import csv import sys LIMIT {A: 1} # A 只能出现一次 AT_LEAST {R: 1} # 至少要有一个执行人 def check(path): problems [] with open(path, newline, encodingutf-8) as f: rows [r for r in csv.reader(f) if any(c.strip() for c in r)] for row in rows[1:]: deliverable, marks row[0], [m.strip().upper() for m in row[1:]] counts {k: marks.count(k) for k in ARCI} for k, limit in LIMIT.items(): if counts[k] ! limit: problems.append(f{deliverable}: {k} 数量为 {counts[k]}应为 {limit}) for k, least in AT_LEAST.items(): if counts[k] least: problems.append(f{deliverable}: 缺少 {k}) for p in problems: print([FAIL], p) print(矩阵校验通过 if not problems else f共 {len(problems)} 处问题) return 1 if problems else 0 if __name__ __main__: sys.exit(check(sys.argv[1] if len(sys.argv) 1 else raci.csv))脚本读的是格值而不是角色名所以换了角色列也不用改代码。LIMIT和AT_LEAST两个字典是唯一需要动的地方比如某个交付物确实要两个 A把 limit 改成 2 就行改完再跑一遍。退出码为 1 表示矩阵不合格可以直接挂进 CI 或 git pre-commit 钩子矩阵被改坏的时候构建会红比等人发现要快。调用方式很简单python raci_check.py raci.csv提示同一个人兼任多个角色时仍然要把名字写进对应单元格不要用看情况糊过去否则这张矩阵对现场没有任何约束力。3. 草案与仕样书把「好玩在哪」和「怎么实现」拆成两份文档文档里有个容易被忽略的对照日文语境中的企划书约等于我们说的草案仕样书才是我们说的企划书或规格书。两份东西的读者、粒度、变更成本完全不同混成一份后期的返工量会非常可观。3.1 草案的使命只是传达意念草案没有固定格式少的时候两三页 A4多的时候连参考资料五十几页不同公司、不同企划、不同项目都能不一样。它只回答两个问题这是个什么样的游戏什么好玩、哪里好玩。除了核心玩法草案还要带上对应平台、预定发行时间、适合的年龄层、主要画面草图Rough Continuity必要时附参考资料写到这个程度就可以拿去评审了。常见误用是把冗长的故事剧本和详细角色设定塞进草案。这些内容属于仕样书提前写会拖慢筛选节奏还会让评审者抓不到重点。稍具规模的制作公司随时压着一百份以上未商品化的草案来源包括内部企划和外部募集——草案是筛选单元不是开工文件只有通过层层筛选才进入仕样书阶段。3.2 仕样书要写到可执行粒度仕样书是让企划把想法传达给程序、图形、音乐等制作成员的文件不能只写知道游戏的概略。从开始画面到结束画面、画面中任何角落的表现设定、分数计算方式、角色的动作都要具体写清楚。RPG 这类剧情分支庞大的项目页数用几公分厚几个纸箱来计量反而更贴切。维度草案仕样书核心问题这是个什么游戏、哪里好玩每个画面、每条数值规则怎么实现主要读者经营者、业务、其他企划程序、图形、音乐等制作成员篇幅量级2 至 3 页到 50 余页以厚度计可达多个纸箱表述方式文字为主少量草图文字、图解、计算公式、图表并用变更成本低高改一处要评估牵连范围写法本身很自由按画面单位写或按登场角色写都行唯一标准是制作成员看完知道自己要做什么。下面的骨架是我一般会用的最小结构重点是修订记录放在最前面。# 仕样书 SPC-014 关卡战斗系统 ## 0. 修订记录 | 版本 | 日期 | 修改人 | 变更点 | 影响范围 | ## 1. 系统目标一句话说清这个系统解决什么 ## 2. 输入与输出 - 输入玩家操作、当前关卡配置 ID - 输出结算结果、分数、掉落表 ## 3. 数值规则 - 伤害 攻击力 * 系数 - 防御力系数表见附录 A ## 4. 画面与表现 - 命中特效第 0 帧起播持续 12 帧取消条件为玩家受击 ## 5. 验收用例 - 用例 ID / 前置条件 / 操作步骤 / 预期结果 / 负责人员修订记录里的影响范围一栏是关键它决定要不要重排工期验收用例一栏是给 QA 和主程看的没有用例的条目不允许冻结。这两栏空着的仕样书后期一定会变成口头需求。3.3 用 PROTOTYPE 证伪「好不好玩」程序前期不铺细节只搭系统骨干主角动作、画面显示系统。用绘画打比方就是先准备纸、画具和颜料把轮廓勾出来。必要时先做工具和编辑器地图编辑器、动作编辑器先做好后期编辑动作和地图的效率差别会非常明显像盖房子之前先把锯子做好。这一步的目的是回答两个问题企划脑子里的东西真能实现吗真会好玩吗。原型有结论之后才决定是否朝完整版推进砍掉某个核心循环也通常发生在这一步。验证项判定方式通过线记录人核心操作手感5 人以上试玩打分平均不低于 3.5 分主程核心循环意愿连续试玩 15 分钟后是否愿意再来一局5 人中至少 4 人愿意企划目标平台性能在目标机型上跑原型帧率不低于目标值的 80%主程工具链可用美术独立用编辑器产出资源1 天产出 1 个可玩关卡片段监制原型代码通常复用率不高所以我一般单独开分支不往正式线上合# 原型独立分支避免探索期的临时逻辑污染主线 git checkout -b proto/battle-core-0712 main git push -u origin proto/battle-core-0712原型通过后由主程挑必要模块重写进正式分支而不是直接 merge。原型结论必须回写到草案或仕样书里否则半年后没人记得当初为什么砍掉某个系统。4. 内存预算、α/β/Master把收敛变成可检查的数字项目做到中期麻烦会变得具体内存不够、创意被判定不可能、抽象需求在团队间来回传递。这几类问题的共同点是——不解决也能往前推但每推一天后期代价都在涨。把它们变成数字和门槛才有讨论空间。4.1 开工前先分内存超了要有仲裁路径文档里描述得很典型计划一开始就分配好图形多少兆、主程序多少兆、音乐多少兆随着制作推进总有人超。原因可能是企划阶段估算错误、开发能力不足也可能是某个组确实需要更大容量来表现效果。这时候制作人或监制必须明确判断还有没有余量可以分配削减哪个部分是否变更规格模块预算(MB)当前占用(MB)差值责任人状态图形-角色420455-35美术组长超标图形-场景60054060美术组长正常主程序300312-12主程超标音频1809684音频正常这张表手工维护很容易看漏用脚本每周跑一次更稳# budget_check.py # 读取内存预算 CSV输出超标模块与需要仲裁的条目 # CSV 列module,budget_mb,used_mb,owner import csv, sys TOLERANCE 0.05 # 允许超出 5%超过即进入仲裁流程 def check(path): rows [] with open(path, newline, encodingutf-8) as f: for r in csv.DictReader(f): budget, used float(r[budget_mb]), float(r[used_mb]) rows.append((r[module], budget, used, used - budget, (used - budget) / budget, r[owner])) rows.sort(keylambda x: -x[4]) total_budget sum(r[1] for r in rows) total_used sum(r[2] for r in rows) print(f总量{total_used:.0f}MB / {total_budget:.0f}MB) for name, b, u, over, ratio, owner in rows: if ratio TOLERANCE: print(f[仲裁] {name}: 预算 {b:.0f} 实际 {u:.0f} 超出 {over:.0f}MB f({ratio*100:.1f}%) 责任人 {owner}) return 0 if __name__ __main__: sys.exit(check(sys.argv[1] if len(sys.argv) 1 else budget.csv))TOLERANCE是容忍度而不是硬上限5% 意味着小幅波动不进会超过就必须有人做取舍。总额那一行是给制作人看的第一眼数据总量有余量仲裁就是内部调配总量都满了就只能改规格。4.2 α、β、Master 的准入标准三个阶段的门槛必须提前说清临到发布才定标准一定会吵。阶段内容完整度允许缺陷放行角色典型动作α 版图形、音乐、剧本、程序资料全部整合允许明显错误与不合理表现制作人简单试玩、修明显错误、调整难度β 版内容与市售版基本一致允许存在 BUG但不得有阻塞级制作人 主程全员 Debug覆盖文案错字到当机Master无已知阻塞级缺陷阻塞级为 0其余有明确结论制作人交付压片量产α 阶段最容易踩的坑是看得到树却看不到森林各部门分工做出来的东西单看没问题拼起来不像一个游戏α 的工作就是把一棵棵树修成一片森林。另一个坑是 α 之后还在加功能——内容没在 α 之前全部进来β 阶段就会变成边加功能边 Debug回归测试永远追不上新增。4.3 用 SQL 盯 Debug 收敛曲线Debug 是最后也是最大的一项工程覆盖范围从游戏讯息里一个文字错误到会导致当机的重大问题。判断能不能按计划进 Master看的是净增而非总量。-- 按周统计缺陷新增、关闭与净增判断能否按期进入 Master SELECT date_trunc(week, created_at) AS week, COUNT(*) FILTER (WHERE created_at date_trunc(week, created_at)) AS opened, COUNT(*) FILTER (WHERE closed_at IS NOT NULL) AS closed, COUNT(*) FILTER (WHERE closed_at IS NULL AND severity blocker) AS open_blocker, COUNT(*) FILTER (WHERE closed_at IS NULL AND severity IN (major,minor)) AS open_normal FROM issues WHERE build_stage IN (alpha,beta) -- 只统计 α 之后的缺陷 AND created_at DATE 2024-01-01 GROUP BY 1 ORDER BY 1;opened与closed的差就是净增。判读规则很直接连续两周净增为正、且open_blocker没有下降趋势当前排期就不可能进 Master制作人要在范围、时间、人力里砍掉一项。build_stage这个字段是关键它把 α 之前的技术债和 α 之后的收敛缺陷分开统计否则早期的历史遗留会把曲线彻底污染看着吓人却没有参考价值。5. 把「不可能」变成可排期项冲突升级与版本冻结的检查脚本制作现场反复出现的两句台词是这是可以办到的吧和不可能我做不出来。争论靠嗓门没有产出靠流程才有。做法是把争议降级成一条时间盒验证任务限时两天产只出两个结论——可行或不可行附带实测数据比如帧率、内存占用、预估工期。结论回写仕样书并走变更单变更单里必须写影响范围否则工期重排没有依据。抽象需求也是同一类问题。再可爱一点我要一种无形的感觉反应要有速度感这类说法发言者的想法和听者的理解天然存在偏差。落地时把它们翻译成可验收描述原始说法可验收写法验收人再可爱一点参考图 3 张头身比头部占比不低于 1/3美术组长无形的感觉对照特效片段纯透明过渡不少于 8 帧主美要有速度感从静止加速到最高速不超过 0.4 秒主程到了版本冻结这一步检查项应该固定下来并自动化而不是每次靠人回忆遗漏了什么。时点检查项放行条件T-72h变更单状态不存在 accepted 状态且未评审的变更单T-24h阻塞级缺陷open_blocker 为 0T-2h构建与资源版本freeze_check.sh 全部通过#!/usr/bin/env bash # freeze_check.sh 版本冻结前检查任一失败即不冻结 set -euo pipefail echo 1. 构建可重复性 git diff --quiet || { echo 工作区存在未提交改动; exit 1; } echo 2. 阻塞级缺陷清零 blocker$(grep -c ,blocker,open, issues.csv || true) [ $blocker -eq 0 ] || { echo 仍有 $blocker 个阻塞级缺陷; exit 1; } echo 3. 资源包版本与构建配置一致 grep -q ^assets_ver$(cat ASSETS_VERSION) build/config.ini \ || { echo 资源包版本与构建配置不一致; exit 1; } echo 4. 范围冻结 grep -q stateaccepted changes.csv { echo 存在未评审的变更单; exit 1; } echo 冻结检查通过set -euo pipefail保证中间任一步失败立即中断不会出现检查到一半还打印通过的假象。四项检查分别对应可复现构建、缺陷门槛、资源版本和范围冻结退出码非 0 时直接拒绝合并到 release 分支——冻结就从一句口头承诺变成了一条会失败的构建。本文还有配套的精品资源点击获取 游戏项目管理：RACI权责划分与α/β/Master版本收敛
简介这份《游戏项目管理》PDF文档面向游戏研发团队管理者、项目经理及有志于进入游戏行业的从业者梳理项目管理在游戏开发场景中的落地框架。内容从项目管理的基本定义切入系统讲解规划、组织、人事、领导与控制五大过程并延伸到项目经理的职责定位、组织架构应以结果为导向的设计原则以及项目经理与制作人在权责划分上的差异。文档还附有实用的检讨清单逐项辨析制作人、执行制作人、监制、企划、游戏设计师、编剧、角色设计师、2D/3D插画师等岗位的职务分工并涉及甘特图、进度表等常用工具与项目评价标准。资源为单个PDF文件压缩包约20KB轻量易读适合作为团队内部分工梳理与流程规范建设的参考。目前已有388人学习下载。1. 别急着排甘特图《游戏项目管理.pdf》里最扎眼的是组织架构检讨项目做到第八个月例会上一句这个改动谁签字把所有人问住了——制作人认为自己管方向项目经理认为自己管流程监制认为自己只管这周的活结果三份周报对应三套进度。这份《游戏项目管理.pdf》开头那段项目管理检讨几乎就是这场景的病历公司与项目应有不同架构却混着用、各部经理与总监的职务定位含混、项目经理与制作人的权责没划开甚至连项目算不算已经成立都没有界定标准。它真正值钱的地方不在附录里那串规划、组织、人事、领导、控制的定义而在于把游戏行业特有的头衔——制作人、执行制作人、监制、企划、游戏设计师、编剧、角色设计师——和草案、仕样书、α版、β版、Master 这套收敛流程摊在同一份文档里。适合带着五到二十人团队、正准备从作坊切到流水线的人读如果你同时被外包与发行方两头追进度表这份文档能把你缺的那几块补上。2. 权责错位怎么修用 RACI 把项目经理、制作人与监制的边界写死头衔不清不是命名问题是决策问题。同一件事有两个人都觉得我能拍板最后的结果通常是谁都不拍工期在等签字的过程中一点点漏掉。先把每个头衔的实际职责摆平再用一张矩阵把签字权固定下来最后才是照着结果去搭组织。2.1 五个头衔到底各管什么中文游戏圈常把这几个叫法混用尤其是制作人和项目经理很多团队干脆一个人兼。混用本身不是错错在兼了之后没人说得清哪些决定必须由谁做。下面这张表按文档里的职责描述整理重点看关键决策权一列。头衔对什么负责关键决策权最常见的误用产品经理 Product Manager产品从调研、制造到销售的整个过程产品变成普通产线一部分后仍负责维持与成长产品定位与后续延续性被当成需求收集员只有整理权没有取舍权制作人 Producer游戏从制作到贩卖的全流程掌控发展方向、进度与预算重要事项决定、范围与预算取舍只对上层汇报长期脱离执行现场执行制作人 Executive Producer执行面开发工作分配、执行检查、跨组协调执行节奏与任务分配与制作人职责重叠形成双头指挥监制 Director发包、工作分配、制作流程与行程管理实际制作现场负责人现场排程与外包发包被当成行政打杂排程权被架空项目经理 PM指派并领导工作人员推进项目对项目成败负责解决项目内各项问题流程、资源与风险处理只有会议纪要权没有冲突裁决权分界线可以粗暴记成三句话制作人回答做什么、值不值得做项目经理回答怎么按时做出来、现在卡在哪监制回答这周谁做哪件活。文档里那句游戏制作人并不能随时与游戏研发在一起所以执行面由执行制作人来负责就是这个意思——制作人要面对公司与外部执行面必须有人常驻现场。2.2 一张 RACI 矩阵把签字权落定RACI 的四个字母分别对应执行R、最终负责A、被咨询C、被告知I。规则只有一条要紧每一行交付物必须有且仅有一个 A。有两个 A 等于没有 A一个 A 都没有则意味着这事没人对结果负责。下面是按游戏项目常见节点填的示例。交付物 / 决策制作人项目经理监制主程企划草案评审通过ACIIR仕样书冻结ARCCR里程碑验收ARCCI内存超预算裁剪ACRRC外包美术发包ACRIIMaster 版本放行ARCCI小团队常见做法是制作人兼 A、项目经理兼 R这没问题但名字要写死在同一格里不能写看情况由谁定。矩阵本身是文档改起来容易所以最好让机器帮你守规则。2.3 以结果为导向搭架构而不是按人头搭文档里有一段讲得很直白许多公司把组织营建在员工身上而不是先决定要达成的结果再找合适的人占住那些位置。小公司没有真正的组织架构先把现有人员分配去做所有工作不用多久又招一批人来分摊架构始终是补出来的。可执行的做法分四步先列出这一阶段必须交付的结果给每个结果指定唯一负责人按结果把岗位画出来最后才往岗位里填人。落到工具上把矩阵存成 CSV 并用脚本校验比每次开会确认要省事得多。# raci_check.py # 校验 RACI 矩阵每个交付物必须有且仅有一个 A且至少一个 R # 输入 CSV 第一列为交付物其余列为角色格值为 R/A/C/I 或留空 import csv import sys LIMIT {A: 1} # A 只能出现一次 AT_LEAST {R: 1} # 至少要有一个执行人 def check(path): problems [] with open(path, newline, encodingutf-8) as f: rows [r for r in csv.reader(f) if any(c.strip() for c in r)] for row in rows[1:]: deliverable, marks row[0], [m.strip().upper() for m in row[1:]] counts {k: marks.count(k) for k in ARCI} for k, limit in LIMIT.items(): if counts[k] ! limit: problems.append(f{deliverable}: {k} 数量为 {counts[k]}应为 {limit}) for k, least in AT_LEAST.items(): if counts[k] least: problems.append(f{deliverable}: 缺少 {k}) for p in problems: print([FAIL], p) print(矩阵校验通过 if not problems else f共 {len(problems)} 处问题) return 1 if problems else 0 if __name__ __main__: sys.exit(check(sys.argv[1] if len(sys.argv) 1 else raci.csv))脚本读的是格值而不是角色名所以换了角色列也不用改代码。LIMIT和AT_LEAST两个字典是唯一需要动的地方比如某个交付物确实要两个 A把 limit 改成 2 就行改完再跑一遍。退出码为 1 表示矩阵不合格可以直接挂进 CI 或 git pre-commit 钩子矩阵被改坏的时候构建会红比等人发现要快。调用方式很简单python raci_check.py raci.csv提示同一个人兼任多个角色时仍然要把名字写进对应单元格不要用看情况糊过去否则这张矩阵对现场没有任何约束力。3. 草案与仕样书把「好玩在哪」和「怎么实现」拆成两份文档文档里有个容易被忽略的对照日文语境中的企划书约等于我们说的草案仕样书才是我们说的企划书或规格书。两份东西的读者、粒度、变更成本完全不同混成一份后期的返工量会非常可观。3.1 草案的使命只是传达意念草案没有固定格式少的时候两三页 A4多的时候连参考资料五十几页不同公司、不同企划、不同项目都能不一样。它只回答两个问题这是个什么样的游戏什么好玩、哪里好玩。除了核心玩法草案还要带上对应平台、预定发行时间、适合的年龄层、主要画面草图Rough Continuity必要时附参考资料写到这个程度就可以拿去评审了。常见误用是把冗长的故事剧本和详细角色设定塞进草案。这些内容属于仕样书提前写会拖慢筛选节奏还会让评审者抓不到重点。稍具规模的制作公司随时压着一百份以上未商品化的草案来源包括内部企划和外部募集——草案是筛选单元不是开工文件只有通过层层筛选才进入仕样书阶段。3.2 仕样书要写到可执行粒度仕样书是让企划把想法传达给程序、图形、音乐等制作成员的文件不能只写知道游戏的概略。从开始画面到结束画面、画面中任何角落的表现设定、分数计算方式、角色的动作都要具体写清楚。RPG 这类剧情分支庞大的项目页数用几公分厚几个纸箱来计量反而更贴切。维度草案仕样书核心问题这是个什么游戏、哪里好玩每个画面、每条数值规则怎么实现主要读者经营者、业务、其他企划程序、图形、音乐等制作成员篇幅量级2 至 3 页到 50 余页以厚度计可达多个纸箱表述方式文字为主少量草图文字、图解、计算公式、图表并用变更成本低高改一处要评估牵连范围写法本身很自由按画面单位写或按登场角色写都行唯一标准是制作成员看完知道自己要做什么。下面的骨架是我一般会用的最小结构重点是修订记录放在最前面。# 仕样书 SPC-014 关卡战斗系统 ## 0. 修订记录 | 版本 | 日期 | 修改人 | 变更点 | 影响范围 | ## 1. 系统目标一句话说清这个系统解决什么 ## 2. 输入与输出 - 输入玩家操作、当前关卡配置 ID - 输出结算结果、分数、掉落表 ## 3. 数值规则 - 伤害 攻击力 * 系数 - 防御力系数表见附录 A ## 4. 画面与表现 - 命中特效第 0 帧起播持续 12 帧取消条件为玩家受击 ## 5. 验收用例 - 用例 ID / 前置条件 / 操作步骤 / 预期结果 / 负责人员修订记录里的影响范围一栏是关键它决定要不要重排工期验收用例一栏是给 QA 和主程看的没有用例的条目不允许冻结。这两栏空着的仕样书后期一定会变成口头需求。3.3 用 PROTOTYPE 证伪「好不好玩」程序前期不铺细节只搭系统骨干主角动作、画面显示系统。用绘画打比方就是先准备纸、画具和颜料把轮廓勾出来。必要时先做工具和编辑器地图编辑器、动作编辑器先做好后期编辑动作和地图的效率差别会非常明显像盖房子之前先把锯子做好。这一步的目的是回答两个问题企划脑子里的东西真能实现吗真会好玩吗。原型有结论之后才决定是否朝完整版推进砍掉某个核心循环也通常发生在这一步。验证项判定方式通过线记录人核心操作手感5 人以上试玩打分平均不低于 3.5 分主程核心循环意愿连续试玩 15 分钟后是否愿意再来一局5 人中至少 4 人愿意企划目标平台性能在目标机型上跑原型帧率不低于目标值的 80%主程工具链可用美术独立用编辑器产出资源1 天产出 1 个可玩关卡片段监制原型代码通常复用率不高所以我一般单独开分支不往正式线上合# 原型独立分支避免探索期的临时逻辑污染主线 git checkout -b proto/battle-core-0712 main git push -u origin proto/battle-core-0712原型通过后由主程挑必要模块重写进正式分支而不是直接 merge。原型结论必须回写到草案或仕样书里否则半年后没人记得当初为什么砍掉某个系统。4. 内存预算、α/β/Master把收敛变成可检查的数字项目做到中期麻烦会变得具体内存不够、创意被判定不可能、抽象需求在团队间来回传递。这几类问题的共同点是——不解决也能往前推但每推一天后期代价都在涨。把它们变成数字和门槛才有讨论空间。4.1 开工前先分内存超了要有仲裁路径文档里描述得很典型计划一开始就分配好图形多少兆、主程序多少兆、音乐多少兆随着制作推进总有人超。原因可能是企划阶段估算错误、开发能力不足也可能是某个组确实需要更大容量来表现效果。这时候制作人或监制必须明确判断还有没有余量可以分配削减哪个部分是否变更规格模块预算(MB)当前占用(MB)差值责任人状态图形-角色420455-35美术组长超标图形-场景60054060美术组长正常主程序300312-12主程超标音频1809684音频正常这张表手工维护很容易看漏用脚本每周跑一次更稳# budget_check.py # 读取内存预算 CSV输出超标模块与需要仲裁的条目 # CSV 列module,budget_mb,used_mb,owner import csv, sys TOLERANCE 0.05 # 允许超出 5%超过即进入仲裁流程 def check(path): rows [] with open(path, newline, encodingutf-8) as f: for r in csv.DictReader(f): budget, used float(r[budget_mb]), float(r[used_mb]) rows.append((r[module], budget, used, used - budget, (used - budget) / budget, r[owner])) rows.sort(keylambda x: -x[4]) total_budget sum(r[1] for r in rows) total_used sum(r[2] for r in rows) print(f总量{total_used:.0f}MB / {total_budget:.0f}MB) for name, b, u, over, ratio, owner in rows: if ratio TOLERANCE: print(f[仲裁] {name}: 预算 {b:.0f} 实际 {u:.0f} 超出 {over:.0f}MB f({ratio*100:.1f}%) 责任人 {owner}) return 0 if __name__ __main__: sys.exit(check(sys.argv[1] if len(sys.argv) 1 else budget.csv))TOLERANCE是容忍度而不是硬上限5% 意味着小幅波动不进会超过就必须有人做取舍。总额那一行是给制作人看的第一眼数据总量有余量仲裁就是内部调配总量都满了就只能改规格。4.2 α、β、Master 的准入标准三个阶段的门槛必须提前说清临到发布才定标准一定会吵。阶段内容完整度允许缺陷放行角色典型动作α 版图形、音乐、剧本、程序资料全部整合允许明显错误与不合理表现制作人简单试玩、修明显错误、调整难度β 版内容与市售版基本一致允许存在 BUG但不得有阻塞级制作人 主程全员 Debug覆盖文案错字到当机Master无已知阻塞级缺陷阻塞级为 0其余有明确结论制作人交付压片量产α 阶段最容易踩的坑是看得到树却看不到森林各部门分工做出来的东西单看没问题拼起来不像一个游戏α 的工作就是把一棵棵树修成一片森林。另一个坑是 α 之后还在加功能——内容没在 α 之前全部进来β 阶段就会变成边加功能边 Debug回归测试永远追不上新增。4.3 用 SQL 盯 Debug 收敛曲线Debug 是最后也是最大的一项工程覆盖范围从游戏讯息里一个文字错误到会导致当机的重大问题。判断能不能按计划进 Master看的是净增而非总量。-- 按周统计缺陷新增、关闭与净增判断能否按期进入 Master SELECT date_trunc(week, created_at) AS week, COUNT(*) FILTER (WHERE created_at date_trunc(week, created_at)) AS opened, COUNT(*) FILTER (WHERE closed_at IS NOT NULL) AS closed, COUNT(*) FILTER (WHERE closed_at IS NULL AND severity blocker) AS open_blocker, COUNT(*) FILTER (WHERE closed_at IS NULL AND severity IN (major,minor)) AS open_normal FROM issues WHERE build_stage IN (alpha,beta) -- 只统计 α 之后的缺陷 AND created_at DATE 2024-01-01 GROUP BY 1 ORDER BY 1;opened与closed的差就是净增。判读规则很直接连续两周净增为正、且open_blocker没有下降趋势当前排期就不可能进 Master制作人要在范围、时间、人力里砍掉一项。build_stage这个字段是关键它把 α 之前的技术债和 α 之后的收敛缺陷分开统计否则早期的历史遗留会把曲线彻底污染看着吓人却没有参考价值。5. 把「不可能」变成可排期项冲突升级与版本冻结的检查脚本制作现场反复出现的两句台词是这是可以办到的吧和不可能我做不出来。争论靠嗓门没有产出靠流程才有。做法是把争议降级成一条时间盒验证任务限时两天产只出两个结论——可行或不可行附带实测数据比如帧率、内存占用、预估工期。结论回写仕样书并走变更单变更单里必须写影响范围否则工期重排没有依据。抽象需求也是同一类问题。再可爱一点我要一种无形的感觉反应要有速度感这类说法发言者的想法和听者的理解天然存在偏差。落地时把它们翻译成可验收描述原始说法可验收写法验收人再可爱一点参考图 3 张头身比头部占比不低于 1/3美术组长无形的感觉对照特效片段纯透明过渡不少于 8 帧主美要有速度感从静止加速到最高速不超过 0.4 秒主程到了版本冻结这一步检查项应该固定下来并自动化而不是每次靠人回忆遗漏了什么。时点检查项放行条件T-72h变更单状态不存在 accepted 状态且未评审的变更单T-24h阻塞级缺陷open_blocker 为 0T-2h构建与资源版本freeze_check.sh 全部通过#!/usr/bin/env bash # freeze_check.sh 版本冻结前检查任一失败即不冻结 set -euo pipefail echo 1. 构建可重复性 git diff --quiet || { echo 工作区存在未提交改动; exit 1; } echo 2. 阻塞级缺陷清零 blocker$(grep -c ,blocker,open, issues.csv || true) [ $blocker -eq 0 ] || { echo 仍有 $blocker 个阻塞级缺陷; exit 1; } echo 3. 资源包版本与构建配置一致 grep -q ^assets_ver$(cat ASSETS_VERSION) build/config.ini \ || { echo 资源包版本与构建配置不一致; exit 1; } echo 4. 范围冻结 grep -q stateaccepted changes.csv { echo 存在未评审的变更单; exit 1; } echo 冻结检查通过set -euo pipefail保证中间任一步失败立即中断不会出现检查到一半还打印通过的假象。四项检查分别对应可复现构建、缺陷门槛、资源版本和范围冻结退出码非 0 时直接拒绝合并到 release 分支——冻结就从一句口头承诺变成了一条会失败的构建。本文还有配套的精品资源点击获取