今日速览

  • 导出（Export）不是「复制项目文件夹」，而是把项目资源打包成 data.pck，再配一个不含编辑器和调试器的精简二进制——体积更小、启动更快、玩家也看不到你的源码。
  • 导出前必须先装导出模板（Export Templates），否则导出菜单会直接报错、拒绝导出。
  • Windows 导出默认架构是 x86_64（覆盖绝大多数 PC），arm64 只给 Windows on ARM 用，x86_32 基本可以放弃。
  • 图标由项目设置里的 icon 自动转成 .ico；想让 exe 不被杀软/系统警告，需要代码签名（Code Signing）。
  • 上传 Steam 用的是 SteamPipe：steamcmd + app_build.vdf 脚本，把内容按 ~1MB 分块压缩加密传输，之后更新只传「变了的块」。

核心学习内容

1. 导出到底做了什么：pck + 精简二进制

官方文档说得很直白：PC 上最土的分发方式是「把 Godot 可执行文件丢进项目目录、压缩整个文件夹发出去」。能跑，但有三个问题：文件一堆、玩家能翻出你的工程、二进制里还带着编辑器和调试器。

导出系统解决的就是这三件事。对 Windows，导出器会：把所有项目文件收拢成一个 data.pck；再和一份专门优化过的引擎二进制打包在一起。玩家拿到的是一个（或一组）干净的成品。

理解这一点，后面所有选项就都顺了——pck 是「数据」，exe 是「引擎」，PCK 嵌入（PCK Embedding）就是把两者合成单文件（注意上限约 3.89 GB，实际 pck 别超 ~3.75 GB）。

2. 三步走：模板 → 预设 → 导出

第一步：装导出模板。 菜单 Editor > Manage Export Templates…，勾选 Windows 平台点 Install，或从官网下载 .tpz 文件导入。有个容易忽略的点：如果你的游戏要用中文/日文/韩文或 emoji，记得一并勾上 ICU Data，否则导出后这些字符会出问题——对我们做中文游戏的人来说这是必选项。

第二步：加导出预设。 点顶部 Export 按钮 → Add… → 选 Windows Desktop。默认选项通常够用，关键几项：

  • 架构：x86_64（默认，别动）；
  • 资源模式：五种之一，一般「导出项目全部资源」即可，做 DLC 时才会用「导出选中资源」；
  • 图标：自动从项目设置转换，想精细控制各分辨率外观就手动做 .ico；
  • PCK 嵌入：想要单文件就勾，否则 pck 与 exe 分开放。

第三步：导出。 底部三个按钮分工明确：Export All（所有预设）、Export Project（当前预设，产出可玩的 exe + 数据）、Export PCK/ZIP（只出数据，不出可执行文件——调试专用，别拿去发玩家）。

3. 让成品「像个正经游戏」：图标与代码签名

图标：Godot 会把项目设置里的 icon 自动转成 .ico。若想让任务栏/文件资源管理器在不同缩放下都清晰，就按官方「手动替换 Windows 应用图标」的步骤自制多尺寸 ICO。

代码签名：没签名的 exe 在 Windows 上会触发 SmartScreen「未知发布者」警告，玩家一看就慌、直接退款。Godot 支持导出时自动签名：在编辑器设置 Export > Windows 里指定签名工具（Windows 用 SignTool.exe，其他系统用 osslsigncode），再在 Windows 导出预设的 Code Signing 分类里填 Enabled = true、证书 Identity 等信息。上架前这一步值得花点小钱买张证书。

4. 交给 Steam：SteamPipe 上传与「增量更新」

导出得到成品后，最后一步是把它推上 Steam，靠的是 SteamPipe 内容系统。核心概念有两个：

  • Depot（仓库）：一个 depot 就是一组要下发给平台的文件集合；
  • Build（构建）：一次「把某组文件打包并分配到某分支」的动作，用 app_build.vdf 脚本描述（AppID、DepotID、本地内容路径、排除规则）。

上传流程是 steamcmd +run_app_build ... 跑脚本，Steam 后台会生成新 build，你可以在网页端先看更新体积，再决定是推到正式还是 beta 分支、或者一键回滚。

最该记住的是它的「块」机制：SteamPipe 把每个文件切成约 1MB 的块，压缩加密后上传；更新时只在旧 build 里找相同块，只传不一样的部分。所以想让更新包小，就要让改动「局部化」——这也是官方建议「按关卡/功能拆成多个 pack 文件、别打乱资源顺序、别把时间戳写进资源」的原因。Godot 的 data.pck 整体重打包时，若资源顺序稳定，增量更新通常会小很多。

🎯 DeepSeek 提示词

① 让 DeepSeek 生成一份「导出 + 上传 Steam」的检查清单（适合：准备首次打包上架）

你是一名有 Steam 上架经验的独立游戏发行顾问。
背景：我用 Godot 4.x 开发了一款 2D 游戏，准备导出 Windows 版并上传 Steam。
任务：给我一份从「导出」到「上传」的完整检查清单，分四个阶段：
1) 导出前准备（导出模板/ICU Data/项目 icon/版本号）
2) 导出设置（架构选择、资源模式、PCK 是否嵌入、代码签名）
3) 打包自测（在干净的 Windows 机器上验证：能启动、能存档、分辨率、中文显示）
4) SteamPipe 上传（depot 划分、app_build.vdf 关键字段、分支策略、回滚）
输出格式：按阶段分组的 checkbox 清单，每项一句话说明「为什么」。
约束：只讲 Godot + Steam 官方支持的做法，不要臆造不存在的菜单或命令。

② 让 DeepSeek 写一个可复用的导出脚本（适合：要反复出包）

你是一名 Godot 4.x 自动化工程师。
任务：帮我写一个打包脚本，把 Godot 项目导出为 Windows x86_64 版本，产出到一个 releases/ 目录。
要求：
- 优先给出可直接运行的命令行方案：`godot --headless --export-release "Windows Desktop" <输出路径.exe>`，
  并说明必须先安装导出模板、预设名字要与编辑器里一致。
- 若更适合用编辑器操作，则改为分步操作清单。
- 输出后自动把 exe 与 data.pck（或单文件）放进以版本号命名的子目录，如 releases/v0.1.0/。
- 附一个「核对表」：如何确认导出成功（文件大小合理、能双击运行、标题栏/图标正确）。
输出：脚本 / 命令 + 注释，以及 3 条常见导出失败原因及排查方法。

③ 让 DeepSeek 生成 SteamPipe 的 app_build.vdf 模板（适合：首次配置上传）

你是一名 Steamworks 发行工程师。
任务：为我的 Godot 游戏生成一份 app_build.vdf（SteamPipe 构建脚本）模板。
已知信息：AppID = <填你的AppID>，主 depot 内容目录 = ./build/windows，
要上传到分支 default，版本描述用命令行传入。
要求：
- 使用官方 AppBuild 脚本结构：AppID / Desc / BuildOutput / SetLive / ContentRoot / Depot 块。
- Depot 块里用 FileMapping 指定 LocalPath 与 DepotPath，并给出 Exclusion 排除 *.pdb、*.log 的示例。
- 每行用一句中文注释解释作用。
- 文末附上运行命令示例：steamcmd +login <账号> +run_app_build <绝对路径>/app_build.vdf +quit
约束：字段名必须与 Steamworks 官方文档一致，不确定的字段标注「请对照官方文档确认」。

学习心得

导出与上传，看似是「最后一步的杂活」，其实是把前面 29 天所有积累变成「玩家真能下载到的东西」的临门一脚。今天最大的收获是心智模型：pck 是数据、exe 是引擎，SteamPipe 是「按块比较、只传差异」。想通了这两点，PCK 嵌入、增量更新、为什么别乱动资源顺序，全部串成了一条线。

对我们「用 DeepSeek 做一款 Steam 游戏」的目标来说，今天这套特别适合交给 AI：导出选项、vdf 脚本、自测清单都是有标准答案的模板型知识，让 DeepSeek 生成初稿、自己照着官方文档核对字段，能省掉大量翻文档的时间。而真正需要人判断的，是「单文件还是分离」「depot 怎么划分」这些跟发行策略相关的决策——AI 给选项，我们拍板。

明日关注

  • 实际跑一次 godot --headless --export-release，确认导出模板已装、预设名一致，产出一个能跑的 exe。
  • 对照 Steamworks 文档核对 app_build.vdf 的字段拼写，先传到 private beta 分支练手。
  • 用 DeepSeek 生成一份「干净 Windows 机器自测清单」，重点覆盖中文显示、存档读写、不同分辨率。

本文由自动化学习流水线每日生成，坚持即学即记。