Steam 构建与 Depot 上传基础流程：个人游戏 2020 年发售前技术清单

为什么要尽早上传第一个构建

个人开发者很容易把 Steam 构建上传放到最后，因为本地能运行、压缩包能发给朋友、看起来没有必要提前折腾后台。但 Steam 的构建系统不只是文件托管，它还关系到 Depot 配置、运行库、启动项、分支、包、测试权限和最终发布审核。越晚接入，越容易在发售前一周发现“游戏在本地能跑，在 Steam 客户端里跑不了”。

2020 年很多个人项目的开发环境变得更分散：有人在家用 Windows 主机打包，有人用云盘发测试包，有人让朋友远程试玩。这个阶段如果没有固定的构建上传流程，版本会很快失控。测试人员说的 Bug 可能来自三天前的压缩包，美术看到的截图可能来自开发分支，Steam 审核拿到的构建又是另一个版本。

尽早上传第一个构建的目的不是让它通过发布审核，而是验证整条链路：本地打包、SteamPipe 上传、Depot 映射、启动项、测试分支、下载安装到另一台机器、记录版本号。链路打通后，每次更新只是重复流程；链路没打通，发布前每个环节都可能变成未知数。

先理解 App、Depot、Package、Branch

Steamworks 后台里的几个概念如果一开始没分清，后面会很容易误操作。

一个 Windows 单平台个人游戏，最简单可以只有一个 App、一个 Windows Depot、一个默认包和一个测试分支。但“简单”不等于随意。即使只有一个 Depot，也要记录它包含哪些文件、哪些文件不该上传、启动 exe 是哪个、运行库怎么处理。

如果计划未来做 Demo，建议从一开始就把 Demo 当成单独应用或至少单独流程看待。不要把主游戏删内容后临时打成 Demo，因为这样很容易把正式存档、未公开关卡、调试菜单或付费内容带进去。

建立本地构建目录规则

SteamPipe 上传前，先规范本地输出目录。很多个人开发者的构建目录叫 Build、Final、Final2、SteamFinal，几周后自己也分不清。建议使用包含平台、版本、日期的目录名：

builds/
  windows/
    2020-09-04_v0.3.0_steam-review/
    2020-09-12_v0.3.1_beta/
  tools/
    steam_upload/

每个构建目录里放一份 build-note.txt 或 release-note.md，记录：

版本号：0.3.0
Git 提交：如果项目有版本管理则填写
构建时间：2020-09-04 09:30
目标分支：steam-review
主要变更：完成第一章流程，加入设置菜单
已知问题：窗口模式切换后需重启，手柄图标仍为占位
测试重点：首次安装、存档创建、退出重进

即使你没有使用 Git，也要写版本号和构建时间。Steam 后台的构建编号是平台记录，不等于你的项目版本。客服、测试和公告沟通时，玩家更容易理解 0.3.1 这种版本。

上传前先清理不该进包的文件

独立游戏构建里常见的脏文件包括调试日志、编辑器缓存、未压缩源素材、PSD、临时配置、崩溃 dump、测试存档、外包交付文件、内部说明文档。它们不一定会让审核失败，但会增加包体、暴露未公开内容，甚至带来版权和隐私风险。

可以建立一份“上传前排除清单”：

上传脚本最好只指向干净输出目录，而不是整个工程目录。不要用“反正玩家看不到”安慰自己。Steam 客户端会下载你上传的内容，包里有什么就是交付给玩家什么。

启动项要在真实客户端测试

本地双击 exe 能运行，不代表 Steam 启动项配置正确。Steam 启动会涉及工作目录、启动参数、运行库、覆盖层、控制器输入和云存档等环境差异。个人开发者至少要在一台非开发机上通过 Steam 客户端安装并启动测试。

测试启动项时要覆盖这些场景：

1. 从 Steam 客户端点击开始游戏。
2. 从桌面快捷方式启动。
3. 离线模式启动。
4. 首次安装后启动。
5. 更新后启动。
6. 没有开发环境和编辑器的普通机器启动。

如果游戏依赖 Visual C++ 运行库、DirectX、.NET 或其他组件，要确认 Steamworks 后台的运行库配置是否覆盖。不要假设玩家机器和开发机一样。很多“玩家打不开游戏”的问题，其实不是游戏逻辑崩了，而是缺少运行库或启动目录配置错误。

分支命名要能看出用途

Steam 分支是个人项目非常实用的功能，但命名混乱会制造新问题。建议使用少量稳定分支：

不要把每天开发用的临时版本都推到 Steam 分支。Steam 分支应该代表“可以被别人安装测试”的版本，而不是开发机上的中间状态。上传后要写清构建备注，例如 0.4.2 beta - fixed save migration crash，这样几周后回看仍然知道它解决了什么。

测试包和权限要单独检查

构建上传成功后，还要确认测试人员能不能拿到。Steam 的访问通常通过包、Key 或权限控制。个人开发者容易出现一种情况：自己在后台能启动，朋友却看不到游戏；或者朋友拿到的是旧分支；或者测试 Key 发出去后没人记录。

建议把测试流程写成固定步骤：

1. 上传构建到 beta 或 review 分支。
2. 设置测试包包含正确 App 和 Depot。
3. 给测试人员发访问方式和分支密码。
4. 要求测试人员截图 Steam 客户端里的版本或分支。
5. 记录每个测试人员的系统配置和测试日期。
6. 测试结束后回收不需要的权限。

不要只问“能玩吗”。要问“你从哪里安装、装的是哪个分支、首次启动有没有报错、退出后存档是否保留、是否出现杀毒软件提示”。这些问题比笼统反馈更有价值。

构建审核前的证据包

提交正式发布审核时，最好准备一个证据包，里面包括：构建版本号、上传时间、分支名、测试通过清单、已知问题说明、系统需求测试记录、主要流程截图、崩溃日志处理方式。如果审核或发售前出现问题，你可以快速判断是配置问题、构建问题还是页面信息问题。

证据包不需要提交给玩家，但对自己非常重要。个人开发者在临近发售时同时处理 Bug、社媒、Key、折扣、公告和客服，如果没有证据包，很容易凭记忆做决定。

一份可执行的上传检查表

这张表每次上传都可以复用。第一次填会慢，第三次以后会明显降低出错率。

不要把上传流程交给临时记忆

个人游戏发行不是只靠灵感和冲刺。Steam 构建上传是一个工程化流程：文件从哪里来、怎么排除、上传到哪个 Depot、放到哪个分支、谁能安装、怎么验证、怎么回滚，都应该有记录。

如果你在 2020 年准备发布个人游戏，建议在商店页公开后不久就完成第一次 Steam 客户端安装测试。即使游戏还很粗糙，只要主循环能跑，就值得上传一次。越早发现平台接入问题，越不会在发布前把时间浪费在本可以提前解决的配置细节上。