返工要先分类,不要马上乱改
Steam 构建审核或内部发布演练发现问题后,个人开发者常见反应是立刻打开工程修。这个反应很自然,但风险也很高。发售前的问题不只影响代码,还影响分支、包、页面、公告、客服模板和测试记录。你修了一个启动问题,可能改动运行库;改了存档路径,可能影响 Demo;换了截图里的功能,可能要改商店页承诺。
所以构建返工第一步不是修,而是分类:
| 类型 | 示例 | 处理方式 |
|---|---|---|
| 阻塞问题 | 无法启动、主流程卡死、坏档 | 立即修并完整回归 |
| 配置问题 | 启动项错、运行库缺失、Depot 映射错 | 修改后台和客户端验证 |
| 页面不一致 | 商店说有某功能,构建没有 | 改页面或补构建,优先收敛承诺 |
| 体验问题 | 教程不清、难度尖刺 | 判断是否影响首发 |
| 普通瑕疵 | 错字、边缘 UI | 能修则修,风险高就延后 |
分类能避免把所有问题都当成同等紧急。个人开发者时间有限,发售前必须优先保护玩家能买、能下、能启动、能保存、能理解第一段流程。
返工记录要包含构建关系
每次返工都要写清从哪个版本改到哪个版本。不要只在聊天记录里写“修好了”。建议记录:
问题编号:BR-20210212-01
发现来源:Steam 客户端普通账号测试
影响版本:0.9.0 review
问题描述:首次启动黑屏,日志显示缺少运行库
处理动作:补充运行库配置,重新上传 0.9.1
验证方式:两台无开发环境机器安装启动
页面影响:无
是否需要公告:否,未公开
这个记录看起来细,但首发后非常有用。玩家反馈“还是黑屏”时,你能知道是否和审核时的问题同源;如果要回滚,也能知道哪个版本可用。
启动项问题要在 Steam 客户端验证
本地双击 exe 能跑,不代表 Steam 启动项正确。构建审核返工里,启动项错误很常见:工作目录不对、启动 exe 指错、平台架构不匹配、运行库缺失、启动参数只在开发机有效。修完后一定要通过 Steam 客户端验证,而不是只在本地目录双击。
启动验证清单:
- 普通账号安装。
- Steam 客户端点击开始游戏。
- 桌面快捷方式启动。
- 离线模式启动。
- 卸载重装后启动。
- 没装开发环境的机器启动。
如果只在开发机验证,很容易漏掉运行库和路径问题。2 月如果假期临近,更要提前完成这些测试,避免上线后无法快速借到测试机器。
存档返工要谨慎
发售前最危险的返工之一是存档。存档路径、字段、版本迁移、云存档、Demo 存档继承都会影响玩家数据。如果审核或测试发现存档问题,不要只修当前案例,要考虑旧存档和新存档。
存档修复检查:
| 场景 | 需要验证 |
|---|---|
| 新玩家首次创建存档 | 能保存和读取 |
| 旧版本升级 | 旧存档能迁移或有清楚提示 |
| 异常退出 | 不生成损坏存档 |
| Demo 与正式版 | 不互相污染 |
| 多语言切换 | 任务和文本状态正常 |
| 卸载重装 | 本地和云存档行为符合预期 |
如果没有把握兼容旧存档,发售前宁可重置测试存档,也不要让正式玩家承担迁移风险。公开后再改存档成本会高很多。
分支不要在返工中混乱
返工时最容易把分支弄乱。建议保持:
| 分支 | 用途 |
|---|---|
review | 当前提交审核的候选构建 |
beta | 返工验证版本 |
default | 准备公开或已公开版本 |
archive-x | 可回退版本 |
返工版本先放 beta 验证,再更新 review。不要直接把未验证构建推到 default。如果已经公开发售,热修复也要先走最小验证,不要让所有玩家成为测试者。
页面承诺也要跟着返工
有些返工不是修代码,而是修承诺。比如某个功能不稳定,发售前决定移除;某种语言没来得及校对;控制器支持达不到页面承诺。此时不要硬补代码,更稳的做法可能是修改页面,收敛承诺。
页面返工表:
| 问题 | 页面动作 |
|---|---|
| 控制器只部分可用 | 修改控制器说明和 FAQ |
| 英文剧情未校对 | 不勾完整语言支持,公告说明状态 |
| 关卡数量减少 | 长描述改成首发实际内容 |
| Demo 存档不继承 | Demo 结束页和 FAQ 写清 |
发售前承认限制,比发售后让玩家发现落差更稳。
返工后重新打包素材
构建返工有时会改变素材。比如 UI 文案变了,截图就要重截;启动流程改了,预告片里的开场菜单可能过时;语言状态调整了,截图语言要同步。不要只关注二进制构建。Steam 审核和玩家购买看到的是完整页面。
返工后检查:
| 改动 | 需要同步 |
|---|---|
| 删除功能 | 长描述、截图、FAQ |
| 修改 UI | 商店截图、预告片片段 |
| 改语言支持 | 语言列表、截图、公告 |
| 改控制器 | 商店字段、客服模板 |
| 改存档 | Demo 说明、FAQ |
这一步能避免“构建修好了,页面还错着”的情况。
审核返工的沟通节奏
如果返工影响发售日期,要尽早更新内部和外部沟通。内部沟通包括测试者、外包、主播、媒体;外部沟通包括 Steam 公告、社媒、Demo 页面和愿望单提醒。不要只在后台重新提交构建,却忘了已经发出去的日期。
沟通模板可以很直接:
我们在最终构建检查中发现存档迁移问题,决定把发售从 2 月 19 日调整到 2 月 26 日。接下来会验证旧存档升级、Demo 存档隔离和低配机器启动。Steam 页面会同步更新日期。
这种说明比含糊说“为了优化体验”更可信。玩家能接受具体问题,也更容易相信延期是必要的。
回归测试要围绕修改点
返工后不要只测“问题是否消失”,还要测“有没有破坏相关流程”。修启动项,要测安装、运行库、快捷方式;修存档,要测新旧存档和异常退出;修 UI 语言,要测截图和教程;改 Depot,要测下载内容是否完整。
回归表:
| 修改点 | 必测范围 |
|---|---|
| 启动项 | 客户端启动、快捷方式、离线模式 |
| 存档 | 新建、读取、升级、异常退出 |
| 运行库 | 干净机器、低配机器 |
| 分支 | beta、review、default 指向 |
| 页面承诺 | 截图、长描述、FAQ |
个人开发者不需要大型 QA,但需要最小回归表。
返工看板模板
可以用一个很小的看板管理返工,不需要复杂工具:
| 状态 | 放什么 |
|---|---|
| 待确认 | 审核反馈、测试反馈、玩家复现不完整的问题 |
| 修复中 | 已确认原因,正在改的 P0/P1 |
| 待验证 | 已上传 beta,需要普通账号测试 |
| 待同步 | 需要改页面、公告、截图或 FAQ |
| 已关闭 | 构建和页面都验证通过 |
关键是不要让问题只停留在“修好了”。只有经过验证、页面同步、记录归档,才算关闭。个人开发者一人多职,更需要这种简单状态栏提醒自己不要漏环节。看板里还应该保留“延后处理”状态。有些问题风险很低但修改成本高,可能更适合写进已知问题或后续版本。
最终清单
| 检查项 | 标准 |
|---|---|
| 问题已分类 | P0/P1 优先处理 |
| 返工记录完整 | 版本、来源、处理、验证清楚 |
| Steam 客户端验证 | 不只本地双击 |
| 存档风险评估 | Demo、旧版、新版不冲突 |
| 分支清楚 | beta 验证,review 提审,default 谨慎 |
| 页面同步 | 构建变化影响承诺时及时改 |
| 回归测试完成 | 修改点相关流程都测过 |
构建审核返工的本质是重新建立可信发布状态。修 Bug 只是其中一步,真正重要的是确保玩家最终下载到的版本、页面看到的承诺、公告里的说明和开发者手里的记录都指向同一个事实。
最后再做一次“下载即真实”的检查:把自己当成首日玩家,只通过 Steam 客户端下载,不使用本地工程文件。如果这个路径能完成安装、启动、游玩、保存和退出,返工才真正结束。
这一步要截图归档,方便发售后排查。
不要只靠记忆确认。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。