Skip to main content

PC 平台发行包上传流水线（Steam / WeGame / Epic）

June 26, 2024About 6 minTools打包发行

PC 平台发行包上传流水线（Steam / WeGame / Epic）

把一个 PC 游戏发到 Steam、WeGame、Epic 三个商店，流程骨架是一样的：组好分 SKU 的目录 → 清掉调试文件 → 用各家工具上传到一个测试 channel → 在后台把某个 build 设为 live。差异主要在工具和「设 live」的层级模型上。下面按这个骨架记录三家的做法，外加一份 Steam 上传踩坑合集——后者是这篇里最值钱的部分。

通用的目录与清理

上传前先把 build 按 SKU 拆成约定好的目录，典型布局：

  • 0.BaseData——各 SKU 共用的文件
  • 2.Global / 3.Japan / …——各区服 SKU 的差异文件

拆目录的好处是上传时各 depot/SKU 一一对应,后面做区服差异和增量也清晰。

清理调试文件这一步三家通用，发任何外发包之前都要做。需要删掉的典型内容：

  • 所有 *RtDbg* 调试版 exe、所有 *.pdb
  • LevelLauncherPresets、log、coredumps 等调试目录
  • Packed_DX12 里任何文件名带 debug 的文件
  • GFSDK_Aftermath_Lib.x64.dll(崩溃捕获库，根目录和 Tools\bin 下都要查)
  • BootLoader.exe、各种 *.bat 启动菜单脚本
  • OptickCore.dll(性能分析库)
  • 用不到的第三方 SDK dll:EOSSDK-Win64-Shipping.dll(Epic)、Galaxy64.dll(GOG)、steam_api64.dll(Steam) ——按目标商店保留对应那一个,删掉其余
  • steam_appid.txt(本地调试用,正式包不要带)

Steam:SteamPipeGUI

  1. 下载 Steamworks SDK,解压后到 sdk/tools/SteamPipeGUI/SteamPipeGUI.exe 运行。
  2. 按表填写:
    • App ID 与各 depot 的 Depot ID
    • Build Description(上传后还能在 Steamworks 后台改,且不对玩家展示,可随意填)
    • 每个 depot 对应的 build 路径(BaseData / Global / Japan …)
    • Steamworks SDK 的 ContentBuilder 路径
    • 用来上传的账号和密码
  3. 点 Generate VDFs 生成配置,再点 Upload 开始上传。

务必一次把所有 depot 一起上传。只传其中一两个,容易在后续的 alive build 里造成内容错配。

上传完到 https://partner.steamgames.com/apps/builds/<AppID> 找到刚传的 build,选目标分支 → Preview change → 确认,build 即对该分支玩家生效。

Default 分支直通玩家,对它做任何改动都要格外小心。日常验证用单独的 beta 分支。

WeGame:RailSetup

WeGame 的英文资料很少,这里把命令行流程记一下。

  1. 从 WeGame 开发者后台下载 RailSetup,运行 rail_setup.exe。

  2. 登录:login <账号> <密码>。

  3. 上传 build:

    upload_build game_id=<游戏ID> repository_id=<仓库ID> source_folder=<目录> build_name=<名称> no_prompt

    本体、DLC、完整版各有独立的 game_id/repository_id,分别上传。

  4. 设 live:登录开发者后台 → 进对应 app 的「版本管理」→ 在 Default Branch 上「新建发布 build」→ 选 build、填描述 → Next 发布。

DLC 和完整版的目录组合要注意:本体 = BaseData + Standard,完整版 = BaseData + Complete,完整版的主 exe 通常要从带后缀的名字重命名回正式名。

Epic:BuildPatchTool

Epic 的工具是 BuildPatchTool.exe,一般包一层 .bat 来调。每个 SKU 先单独组目录(BaseData + 对应区服)。

bat 里要改的几个变量:

  • BuildPatchToolPath——BuildPatchTool.exe 的路径
  • CloudDir——本地缓存目录(自己新建一个空目录即可)
  • BuildRoot——待上传 build 的路径
  • BuildVersion——build 描述。注意:这个字段会展示给玩家,别写内部代号或乱码

Epic 的「设 live」是多级 sandbox 提升模型:

  1. 先上传到 staging sandbox(各区服分别一个 staging)。
  2. 在 staging 把目标 build 的 Label 设为 Live,给 QA 验。
  3. 验过之后,把 staging 的 live build 克隆到生产 sandbox。
  4. 在生产 sandbox 上再把对应 SKU 的 build 设 Label="Live"(区服可用不同 label,如 Live-Japan),正式对玩家生效。

也可以在 Epic 开发者后台网页里选 staging sandbox → Windows → 直接挑一个新二进制设 live,作为命令行之外的备选。

Steam 上传踩坑合集

下面这些是真在 build machine 上反复踩到的问题,大多和 Steam DRM、增量上传机制有关,换项目一样会遇到。

DRM 包不上 / 包了下不下来

exe 大于 64MB 时,drm_wrap 命令直接报错。 这时改用 Steam DRM Wrapper 的 GUI 手动包。GUI 里虽然也提示命令出错,DRM 其实已经上传成功,但它不会把包好 DRM 的 exe 回写到本地——所以本地 exe 还是没 DRM 的版本,你得手动下载替换,再重新上传整个包。

另一个绕法:命令参数里把 drmtoolp 0 改成 drmtoolp 6。

报 Couldn't read file ...exe、手动上传也失败时,把进程切到兼容模式(Compatibility Mode) 再上传 DRM,Steam 验证通过后游戏就能正常打开。

drmtoolp 的模式和 build 配置、引擎版本有耦合,实测过的现象:

  • 引擎 4.27:development 模式用 drmtoolp 6 仍下不下来,但 Test 版用 drmtoolp 6 能下。
  • 引擎 4.17:development 下四种模式(含网上建议的兼容模式、引擎升级)都下不下来,但 Shipping 版用 drmtoolp 6 能下。

经验法则:正式外发的 Shipping/Test 包配 drmtoolp 6 最稳,development 包别指望 DRM 能正常走下载链路。

哪些 exe 不该包 DRM

用 .NET 框架的 exe 不要包 DRM。 除 launcher 外给其它 exe 包 DRM,会导致游戏在 PC 上起不来(在 Steam Deck 上反而能开)。原因 Steamworks 文档里写了——和 SteamAPI_RestartAppIfNecessary 的重启机制有关。只给 launcher exe 包 DRM 就够了。

DRM 会抹掉数字签名

所有 exe 都要数字签名,但包完 DRM 签名会消失。正确顺序是:先包 DRM,再把 exe 交给发行方签名,反过来签名会被 DRM 覆盖掉。

下载校验失败:App state 0x402 / 0x602

用 steamcmd +app_update <AppID> -beta <分支> -betapassword <密码> 拉版本时,报:

Error! App '<AppID>' state is 0x402 after update job.

在 app_update 后面加 validate,并允许命令多跑几次断点续传,直到下载成功:

steamcmd ... +app_update <AppID> -beta <分支> -betapassword <密码> validate +quit

下载到 100% 后报错也没关系,再跑一遍命令,它会做一次校验然后成功。

上传相关

  • Failed to commit build ... : Failure:多半是 setlive 参数里的分支名写错了。这只会让 setlive 失败,build 本身已经传上 Steam、可以用,后台手动 setlive 即可。
  • OUT OF MEMORY! attempted allocation size: ...:上传超大增量时内存扛不住,多跑几次上传命令就行——比如 30GB 的差分文件可能要跑三次才传完。
  • Steam 上传是增量的:它拿当前要传的版本和同一 depot 上一个 live 分支的内容做对比,只传差异。所以维持 live 分支的连续性能显著减小上传量。

多机并发登录

在多台 build machine 上同时跑 Steam 上传/下载脚本时,登录阶段会有账号并发上限——同时登录的机器太多会卡在登录或直接失败。实测:

  • 同时 6 台机器登录没问题。
  • 一台机器同时登两个账号也没问题。
  • 首次登录过验证码后,后续一段时间不需要反复验证。

并发报错时,降低同时登录 Steam 的机器数量即可。