审核不是把按钮点掉
Steam 上架需要商店页和构建通过审核。很多个人开发者会把审核理解成“后台检查完就提交”,然后等待结果。如果被退回,再临时修。这个流程能走,但效率低。因为退回意见往往会牵连多个地方:页面描述、截图、构建内容、语言栏、价格、平台支持、敏感内容说明。没有准备材料时,返工会变得混乱。
审核证据包的目的不是给 Valve 额外提交一堆文件,而是给自己和团队使用。它帮助你在提交前确认:页面说的内容,构建里真的有;截图展示的功能,玩家真的能玩到;语言栏勾选的语言,游戏内真的支持;测试路径清楚,审核者能顺利进入主要内容。
个人开发者越小,越需要证据包。因为没有专门发行经理帮你记这些对应关系。
证据包应该包含什么
一份轻量证据包可以放在内部文档里:
| 模块 | 内容 |
|---|---|
| 版本信息 | App ID、构建号、提交日期、分支 |
| 页面承诺 | 短描述、核心功能、语言、平台 |
| 截图来源 | 每张截图对应的游戏场景 |
| 视频来源 | Trailer 是否为当前版本 |
| 测试路径 | 从启动到核心玩法的步骤 |
| 已知问题 | 不影响审核但可能被注意的问题 |
| 敏感内容 | 暴力、成人、赌博等说明 |
| 联系人 | 审核反馈由谁处理 |
这份文档不用漂亮,但要准确。提交审核前全员按它检查一次。
页面承诺逐条对照构建
把商店页长描述中的关键承诺列出来,对照构建。
| 页面承诺 | 构建证据 | 状态 |
|---|---|---|
| 包含 6 个章节 | 主菜单可进入 6 章 | 通过 |
| 支持手柄 | Xbox 手柄完成前 20 分钟 | 通过 |
| 支持简中和英语 | 两种语言菜单和教程可用 | 待复测 |
| 有每日挑战 | 当前构建未开放 | 删除页面承诺 |
这一步能抓出很多问题。开发者很容易在文案里写未来计划,却忘记当前构建还没有。审核和玩家都看的是当前可交付内容,不是开发愿景。
截图和视频要标注版本
截图和 Trailer 是审核和玩家理解的重要依据。不要使用已经过时的素材。证据包里给每张关键素材标注来源版本。
| 素材 | 来源版本 | 是否仍然准确 | 备注 |
|---|---|---|---|
| screenshot_01 | 0.9.1 | 是 | 首关核心玩法 |
| screenshot_04 | 0.8.7 | 否 | UI 已改,需要重拍 |
| trailer_main | 0.9.0 | 部分准确 | 第 12 秒旧技能已删除 |
如果素材里有已删除功能,必须替换。玩家和审核者会依据素材判断游戏,旧素材会制造误解。
测试路径要让陌生人能走通
审核者不是你的内部测试员。构建提交前,要确保从启动到核心玩法的路径清楚。尤其是需要账号、服务器、特殊输入、测试密码或教程较长的游戏,更要准备说明。
测试路径写法:
- 启动游戏;
- 选择简体中文或英语;
- 点击新游戏;
- 完成 3 分钟教程;
- 进入第一关;
- 在第一个终端选择“潜行路线”;
- 5 分钟内可看到核心声音机制;
- 如果需要测试第二章,可使用菜单中的章节选择。
如果游戏需要联网,写清测试服务器状态和账号方式。如果有内容锁定,确保审核路径能进入代表性内容。不要让审核者卡在账号注册或漫长开场里。
语言和地区信息要复查
语言支持是审核和玩家预期的重要部分。证据包中应列出每种语言的支持范围。
| 语言 | 商店页 | 游戏内菜单 | 字幕/正文 | QA 状态 |
|---|---|---|---|---|
| 简体中文 | 是 | 是 | 是 | 通过 |
| 英语 | 是 | 是 | 是 | 待校对 |
| 日语 | 页面未勾选 | 部分测试 | 否 | 不公开 |
如果只有商店页翻译,游戏内没有,不要作为游戏语言支持展示。如果某语言仍在测试,也不要提前勾选。
已知问题要分级
审核前不可能零问题。关键是分清哪些问题必须修,哪些可以说明。
| 等级 | 示例 | 处理 |
|---|---|---|
| 阻塞 | 启动崩溃、主线无法继续 | 提交前必须修 |
| 高 | 语言缺字、手柄无法操作菜单 | 优先修 |
| 中 | 某些 UI 文本溢出 | 视影响修 |
| 低 | 个别错别字、轻微穿模 | 可记录 |
不要把阻塞问题提交给审核。审核通过也不代表玩家会接受。证据包不是为了蒙混过关,而是为了判断当前版本是否够公开。
敏感内容说明要和页面一致
如果游戏有暴力、成人、赌博、药物、恐怖、裸露或其他敏感元素,要确保内容问卷、商店页和游戏实际一致。不要因为担心影响曝光而淡化。错误披露可能带来审核和玩家信任问题。
检查:
- 内容问卷是否如实;
- 截图和视频是否展示敏感内容时符合页面说明;
- 年龄提示是否一致;
- Demo 是否包含敏感内容;
- 不同地区是否有额外注意事项。
个人开发者不需要写法律论文,但要诚实、具体。
提交前 24 小时流程
提交审核前一天:
- 锁定构建;
- 更新证据包版本号;
- 从 Steam 客户端安装;
- 跑测试路径;
- 对照页面承诺;
- 检查素材版本;
- 检查语言栏;
- 检查敏感内容说明;
- 记录已知问题;
- 再提交。
如果这期间改了构建或页面,证据包也要更新。不要让文档和实际状态脱节。
证据包也能帮助团队沟通取舍
证据包不仅用于审核前自查,也能帮助团队决定哪些内容暂时不公开。比如你发现页面写了“支持手柄”,但证据包里手柄测试只跑了主菜单,没有跑战斗;页面写了“多结局”,但当前构建只有一个结局完成;截图展示了某个 Boss,但审核构建里它还会卡死。这些都是取舍信号。
处理方式可以有三种:
| 情况 | 动作 |
|---|---|
| 功能已完成但未充分测试 | 延后提交,补测试 |
| 功能未完成但页面已写 | 删除页面承诺 |
| 功能重要但风险高 | 保留内部,不作为首发卖点 |
个人开发者最容易把“快做好了”写成“已经有了”。证据包会迫使你只公开可验证内容。
审核通过后也要保留证据包
审核通过不代表证据包可以丢掉。它会成为发售候选版本的历史记录。发售后如果玩家反馈“页面说有某功能但我找不到”,你可以回看当时页面和构建对应关系;如果后续做折扣或大更新,也能知道哪些素材来自旧版本。
建议每次重大提交都保存一份副本:review-pack-2022-08-rc1、review-pack-2022-08-final。不要只保留最新文档。发行历史越清楚,后续维护越轻松。
审核证据包也要覆盖商店外素材
很多玩家第一次认识游戏并不是通过商店页,而是通过你发给媒体的截图包、社交视频、官网介绍或社区公告。如果这些素材和审核构建不一致,也会造成预期问题。证据包可以增加“外部素材”页,列出哪些素材会在发售前后公开使用。
| 素材 | 使用位置 | 是否与当前版本一致 |
|---|---|---|
| press_screenshot_01 | 媒体包 | 是 |
| old_trailer_cut | B站预告 | 否,需下架或备注 |
| demo_gif_03 | 社交平台 | 是 |
| feature_chart | 官网 | 部分功能未首发,需修改 |
这样做能避免商店页已经修正,外部宣传仍在传播旧信息。个人开发者经常复用早期素材,越接近发售越要清理。
被退回后如何处理
如果审核被退回,不要马上到处改。先把反馈拆成问题项:
| 反馈 | 属于页面还是构建 | 负责人 | 修复证据 |
|---|---|---|---|
| 截图含旧 UI | 页面素材 | 美术/发行 | 新截图 |
| 构建无法进入第二关 | 构建 | 程序 | 测试记录 |
| 语言支持不一致 | 页面+构建 | 翻译/发行 | 语言表 |
修完后更新证据包,再重新提交。这样不会修 A 漏 B。
证据包让发行更稳
Steam 审核本身有流程,但个人开发者能控制的是提交质量。证据包把页面、构建、素材、语言和测试路径放到同一张桌子上,让你提前发现不一致。它不复杂,却能减少被退回后的焦虑。
第一次上架时,很多问题不是不会做,而是没对齐。页面写了未来功能,截图来自旧版本,构建路径不清楚,语言栏勾错。证据包就是对齐工具。提交审核前多花半天整理,通常比被退回后混乱返工更省时间。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。