Steam 个人游戏开发环境实战：2021 年 3 月从工程目录到版本控制的落地流程

为什么先整理开发环境

很多个人开发者第一次准备上 Steam 时，会把注意力放在商店页、愿望单和宣传图上，工程本身却还停留在“能在自己电脑上跑”的状态。这个状态在原型阶段没有问题，但一旦进入 Steam 构建、审核、Demo、正式版和补丁并行的阶段，就会暴露出几个麻烦：本地资源和构建资源不一致，测试分支不知道对应哪个版本，Steamworks SDK 被随手塞进工程，上传脚本只能在一台电脑上运行，临时修复打完之后没人知道改了什么。

个人游戏不需要一开始就搭建复杂的流水线，但必须让工程能够被自己在一周后、一个月后重新理解。2021 年 3 月我整理一个小体量解谜游戏时，最有用的不是某个工具，而是一套可复现的目录和记录方式：源码、原始资源、导入资源、构建输出、Steam 配置、发行文档各自有位置；每次提交都能解释意图；每个上传到 Steam 的包都能追溯到提交号、构建号和测试结论。

推荐的工程目录

目录结构不要追求花哨，关键是让“会变化的源文件”和“可以重新生成的输出”分开。下面是一种适合 Unity、Godot 或自研小引擎项目的通用布局：

这里最容易出错的是资源目录。个人开发常常把原始资源和导出资源混在一起，导致构建机或另一台电脑打开项目时缺素材。比较稳妥的方式是：引擎工程只引用 art_export/ 里的文件，art_source/ 只用于编辑；如果原始文件太大，可以用网盘或 Git LFS，但要在 docs/assets.md 写清楚来源、导出尺寸、命名规则和字体授权。

Git 不只是备份

Git 对个人项目的价值不只是防丢文件。它能回答三个开发后期经常出现的问题：某个 bug 是什么时候引入的，某个 Steam 构建对应哪次提交，某个修复是否已经进入 Demo 或正式分支。

一个小团队甚至一个人，也建议至少保留三类分支：

如果项目还早，分支可以少一点，但不要让 Demo 和正式版共享一个不断乱动的分支。Steam 上 Demo、Playtest、正式版、测试分支经常会同时存在，工程里如果没有明确边界，最后会出现“玩家下载到的 Demo 包含未公开内容”或“审核包缺少正式版修复”的问题。

提交信息也要具体。fix bug 这种提交在发布前没有帮助。更适合的写法是：

fix: prevent save slot overwrite when returning to chapter select
content: add tutorial prompt for first conveyor puzzle
steam: update depot build script for demo branch
qa: add controller smoke checklist for launch candidate

这些信息以后会直接服务补丁说明、测试回归和审核记录。

Steamworks SDK 的放置方式

Steamworks SDK 不建议随手复制到引擎工程根目录。SDK 版本会变，平台库文件会变，某些文件不能公开提交。建议在 steam/sdk/README.md 里记录当前使用的 SDK 版本、下载时间、放置位置和哪些二进制文件被复制到游戏工程。

例如可以这样分：

在 Windows 上开发时，很多人会只验证 steam_api64.dll 是否存在，却忘了 macOS 或 Linux 的库文件。即便首发只支持 Windows，也建议目录里提前保留平台差异说明。等后面加 Steam Deck 或 Linux 支持时，最怕的是没人知道当前包到底依赖了哪些 Steam 动态库。

构建输出必须可追溯

每个上传到 Steam 的构建都应该有一条记录。记录不需要复杂，放在 docs/build-log.md 就够：

这个表后面会救很多时间。审核被退回时，你能知道被退回的是哪个包；玩家反馈一个问题时，你能判断它是否已经在后续构建修过；准备发补丁时，你能确认测试包和正式包是不是同一条提交线。

忽略文件要认真写

个人项目经常把引擎缓存、构建输出、临时截图、系统文件一起提交上去，仓库很快变得难以维护。.gitignore 要按照引擎和平台整理，不要复制一份网上模板就结束。检查重点包括：

• 引擎生成缓存是否被忽略。
• 本地用户配置是否被忽略。
• 构建输出目录是否被忽略。
• Steam 登录、上传凭据、临时 VDF 是否被忽略。
• 崩溃日志和测试录像是否按需要另存，而不是混进工程。

这里有一个细节：不要把所有 .vdf 文件都无脑忽略。Steam 上传脚本可能需要提交模板 VDF，但模板里不能包含账号密码。可以把 steam/scripts/app_build_template.vdf 提交，把本地生成的 app_build_local.vdf 忽略。

资源命名和版本命名

Steam 开发后期的很多返工，其实来自资源命名混乱。截图素材、胶囊图、宣传视频、商店页 GIF、游戏内字体、音效最终版，如果都叫 final、new、fix2，上架前一定会出错。

建议资源命名包含用途、尺寸、语言和日期。例如：

capsule_main_616x353_zh_20210302.png
screenshot_puzzle_room_01_1920x1080_en_20210302.png
trailer_store_cut_30s_no_logo_20210302.mp4
ui_font_noto_sans_sc_subset_20210302.ttf

游戏版本也要有统一规则。商店上看到的版本号、构建日志里的版本号、游戏主菜单的版本号、崩溃日志的版本号，应该能互相对应。个人项目可以用 0.8.0-demo、0.9.0-rc1、1.0.0 这种简单规则，不要每次临时手写。

本地开发与 Steam 客户端测试分开

开发阶段直接运行编辑器很方便，但 Steam 相关功能必须在 Steam 客户端环境里测。成就、云存档、覆盖层、手柄配置、语言选择、DLC、启动参数，都可能在编辑器里表现正常，在 Steam 启动后才暴露问题。

我的做法是保留三种运行方式：

尤其是云存档和成就，不要只在编辑器里模拟。Steam 客户端启动时的用户目录、权限、语言环境和覆盖层状态才接近真实玩家。

每周环境审计

开发环境不是搭好一次就结束。进入上架前两三个月后，建议每周做一次轻量审计，内容包括：新资源是否按目录放置，构建日志是否补齐，Steam SDK 版本是否变更，分支是否有未合并修复，忽略文件是否漏掉大文件，测试清单是否跟版本一致。

这个审计不需要仪式感，一张表就够：

一个真实的整理节奏

如果你的项目已经比较乱，不要试图一天内重构所有目录。更实际的顺序是：第一天先加 .gitignore 和构建日志；第二天整理 Steam SDK 和上传脚本；第三天把资源命名中最危险的商店素材、截图、构建输出改清楚；第四天建立 Demo 分支；第五天用另一台电脑或新目录克隆项目，验证是否能打开、构建、运行。

这一步看似慢，却能减少后面大量不可见成本。Steam 上架不是把一个可执行文件传上去，而是把一个能持续维护、能解释版本、能对玩家负责的项目交出去。个人开发者时间少，更要让工程自己说得清楚。