Steam 构建审核返工流程:2021 年 2 月个人游戏如何处理发布前问题

面向个人游戏的 Steam 构建审核返工流程,覆盖候选版本、启动项、运行库、存档、分支、回归测试、审核记录和发售前冻结。

返工要先分类,不要马上乱改

Steam 构建审核或内部发布演练发现问题后,个人开发者常见反应是立刻打开工程修。这个反应很自然,但风险也很高。发售前的问题不只影响代码,还影响分支、包、页面、公告、客服模板和测试记录。你修了一个启动问题,可能改动运行库;改了存档路径,可能影响 Demo;换了截图里的功能,可能要改商店页承诺。

所以构建返工第一步不是修,而是分类:

类型示例处理方式
阻塞问题无法启动、主流程卡死、坏档立即修并完整回归
配置问题启动项错、运行库缺失、Depot 映射错修改后台和客户端验证
页面不一致商店说有某功能,构建没有改页面或补构建,优先收敛承诺
体验问题教程不清、难度尖刺判断是否影响首发
普通瑕疵错字、边缘 UI能修则修,风险高就延后

分类能避免把所有问题都当成同等紧急。个人开发者时间有限,发售前必须优先保护玩家能买、能下、能启动、能保存、能理解第一段流程。

返工记录要包含构建关系

每次返工都要写清从哪个版本改到哪个版本。不要只在聊天记录里写“修好了”。建议记录:

问题编号:BR-20210212-01
发现来源:Steam 客户端普通账号测试
影响版本:0.9.0 review
问题描述:首次启动黑屏,日志显示缺少运行库
处理动作:补充运行库配置,重新上传 0.9.1
验证方式:两台无开发环境机器安装启动
页面影响:无
是否需要公告:否,未公开

这个记录看起来细,但首发后非常有用。玩家反馈“还是黑屏”时,你能知道是否和审核时的问题同源;如果要回滚,也能知道哪个版本可用。

启动项问题要在 Steam 客户端验证

本地双击 exe 能跑,不代表 Steam 启动项正确。构建审核返工里,启动项错误很常见:工作目录不对、启动 exe 指错、平台架构不匹配、运行库缺失、启动参数只在开发机有效。修完后一定要通过 Steam 客户端验证,而不是只在本地目录双击。

启动验证清单:

  1. 普通账号安装。
  2. Steam 客户端点击开始游戏。
  3. 桌面快捷方式启动。
  4. 离线模式启动。
  5. 卸载重装后启动。
  6. 没装开发环境的机器启动。

如果只在开发机验证,很容易漏掉运行库和路径问题。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 客户端下载,不使用本地工程文件。如果这个路径能完成安装、启动、游玩、保存和退出,返工才真正结束。

这一步要截图归档,方便发售后排查。

不要只靠记忆确认。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页