个人游戏技术选型案例：发布流程为什么从手动打包改成半自动管线

写在前面：发布失败常常不是游戏代码失败

个人游戏开发到后期，很多风险不再来自玩法系统。

而是来自发布流程：

• 打错版本包
• 忘记更新版本号
• 上传了 Debug 构建
• macOS 包缺权限
• Windows 包少了依赖文件
• Steam 分支传错
• 补丁说明和实际内容不一致
• 本地测试通过，玩家机器启动失败

这些错误看起来低级，但非常真实。

贾南做过一款短篇战术潜入游戏。
玩家控制三名快递员，在夜间城市里避开无人机，把包裹送进不同安全屋。

游戏本身不大，目标平台只有 Windows、macOS 和 Steam Deck。
但第一次公开 Demo 前，他手动打包出了事故：上传到测试分支的包缺少一组字体文件，导致英文系统上部分 UI 显示为空。

这件事让他意识到，发布流程不能完全靠记忆。

他最终没有上复杂 CI/CD，而是做了一套半自动构建发布管线。

一、手动打包的问题

早期流程是这样的：

打开引擎。
切换目标平台。
点 Export。
复制到发布目录。
手动改文件名。
压缩。
上传 Steam。
写公告。

这个流程看似简单，但每一步都可能出错。

尤其是个人开发者在发售前状态很差：

• 熬夜修 bug
• 同时回邮件
• 同时写商店公告
• 同时看测试反馈
• 同时打多个平台包

这时再要求自己每一步都记得，风险很高。

技术管线的价值，不是炫技。
而是在疲劳状态下减少人为错误。

二、为什么没有直接做完整 CI/CD

贾南考虑过 GitHub Actions 自动构建。

每次打 tag 自动生成 Windows、macOS、Linux 包，再上传到 Steam。
听起来很漂亮。

但他最后没有第一时间做。

原因有几个：

• 引擎导出在 CI 环境配置麻烦
• macOS 签名和 notarization 需要额外处理
• 项目资源较大，CI 缓存和时间成本不低
• 他对 Steam 上传自动化不熟
• 当前只有一个开发者，不需要多人协作触发构建

完整 CI/CD 不是不好。
只是对这个项目的第一版来说，成本超过收益。

他选择本地脚本化构建，把最容易错的步骤固化下来。

三、半自动管线包含什么

贾南写了一个 release 脚本。

它做几件事：

• 检查 Git 工作区是否干净
• 读取版本号
• 更新游戏内版本显示
• 清理旧构建目录
• 调用引擎命令行导出
• 复制必要资源
• 生成校验文件
• 打包成平台目录
• 输出发布清单

脚本不自动发布到正式分支。

它只生成“可以被人工检查的候选包”。

这符合他的需求：
让机器处理重复步骤，让人保留最后确认。

四、版本号要有一个来源

以前版本号分散在几个地方：

• 游戏主菜单
• 配置文件
• Steam build 描述
• 补丁公告
• 压缩包文件名

很容易不一致。

贾南把版本号收敛到一个 version.txt。

构建脚本读取它，并生成：

• 游戏内版本字符串
• 构建目录名
• 发布清单
• Steam 上传备注模板

这样不会出现“游戏内显示 0.8.3，但上传包叫 0.8.4”的情况。

个人项目也应该有单一版本来源。
这不是大团队才需要的规范。

五、发布清单比自动化更重要

贾南做了一份发布清单。

每次构建后必须检查：

• 游戏能否启动
• 新存档能否创建
• 旧存档能否读取
• 主菜单版本号是否正确
• 语言切换是否正常
• 手柄是否能操作菜单
• 分辨率设置是否保存
• Windows 包是否包含字体和音频
• macOS 包是否能在另一台机器打开
• Steam Deck 控制器布局是否可用
• 崩溃日志路径是否正确

清单很长，但每项都来自真实事故或潜在事故。

自动化能减少重复劳动。
清单能减少判断遗漏。

个人开发者不一定能做到大型 QA，但至少要把每次发布都必须看的东西写下来。

六、Steam 上传仍然保留人工门槛

贾南没有让脚本直接上传正式分支。

他使用 SteamCMD 上传到内部测试分支，然后手动检查，再推广到公开分支。

流程是：

• 本地脚本生成构建
• SteamCMD 上传到 candidate
• 自己下载 candidate 分支测试
• 通过后再切到 default 或 Demo 分支
• 发布公告

这比直接上传正式分支安全很多。

尤其是发售后补丁。
一个错误补丁可能让所有玩家同时下载坏版本。

保留候选分支，是个人开发者最划算的风险控制之一。

七、构建日志要保存

脚本每次构建都会生成一个目录：

• 版本号
• Git commit hash
• 构建时间
• 平台
• 文件校验
• 引擎版本
• 构建日志

这在排查问题时很有用。

如果玩家反馈“0.9.2 打不开”，开发者能知道这个包来自哪个 commit，用的哪个引擎版本，构建时有没有 warning。

没有构建记录时，很多问题只能靠回忆。

而发售期最不可靠的就是回忆。

八、未来如何升级

贾南给管线留了升级空间。

如果后续项目变大，他会考虑：

• CI 自动跑测试
• CI 自动生成候选包
• 自动上传测试分支
• macOS 自动签名
• 崩溃符号文件归档
• 多平台构建矩阵

但第一版不强求。

他的原则是：
先脚本化最容易出错的手动步骤，再根据真实痛点升级。

技术管线也要渐进。

结语：发布流程也是游戏质量的一部分

贾南的半自动管线不复杂。

它没有全自动部署，没有漂亮仪表盘，也没有完整 DevOps 系统。
但它解决了个人开发者最常见的发布错误。

对个人游戏来说，玩家不会关心你的构建脚本。
但玩家会关心他下载的版本能不能启动，补丁有没有修对，存档会不会坏。

发布流程越稳定，开发者越能把精力放回游戏本身。

技术选型不只发生在玩法代码里。
从导出到上传，从版本号到清单，这些看似枯燥的流程，同样决定项目能不能体面上线。