Steam游戏开发每日学习 · 第 69 天（第二篇）：Steam Playtest 与 Demo——不发 key 也能拉人试玩，把 bug 和手感问题在发售前榨出来

今日速览

• Steam Playtest 是一个独立的「子 appID」，挂在你主游戏下面：免费、技术能力（成就、云存档、Steam Input）和主游戏一样，但商店与社区配置被大幅简化——它没有自己的商店页，报名入口直接长在主游戏页面上。
• 对玩家来说好处很直接：报名即玩，不用拿 key；对你来说更直接：不会产生评测、不会占愿望单转化，测砸了也不留痕。
• 报名默认是 limited signup（限额报名）：玩家点「请求访问」，你在后台按批放人；人多了可以切 Open signup，之后新报名的人自动进。
• 关测试不是删东西，把 Playtest 状态设成 Not Playable 即可；想重开就设回 Visible，老玩家不用重新报名。但注意：已经发出去的 key 不会被收回。
• Playtest key 能申请到很大数量（官方提到可达 5 万），而未公布游戏的「保密测试」只能用主游戏的 Release State Override key（上限 2500），且泄露风险高——官方建议先公布游戏再对外测。

核心学习内容

一、先把三件容易混的事分清楚

形态	面向谁	目的	关键特征
Playtest（子 appID）	一小批报名玩家	早期拿数据、修 bug	免费、可开关、无独立商店页、无评测
Demo（独立 appID）	所有路过的人	转化愿望单、进新品节	有独立 release checklist，可建独立商店页
Beta 分支	已拥有游戏的玩家	灰度更新	走主游戏库，天然有「已购买」门槛

一句话判断：还在改核心玩法 → Playtest；玩法已经稳了、要拉愿望单 → Demo。 两者不冲突，很多团队是先 Playtest 三个月，再拿调好的版本做 Demo 冲新品节。

二、Playtest 的开通流程（官方 6 步）

1. 在游戏的 Associated Packages & DLC 页面新建一个 Playtest app。
2. 配置 app：至少要给库封面资产（Library capsule）和社区资产，否则发布流程走不下去。
3. 走 Playtest 的发布流程：审核清单很轻，只查 capsule 图和图标，不查整页文案。
4. 回到主游戏的商店页后台 → Special Settings 勾选开启 Playtest 报名，发布后玩家就能在商店页看到报名按钮。随时可以隐藏。
5. 像普通游戏一样上传 depot 和 build（用 Godot 导出的 Windows 包即可），顺便把 Steam Input 模板、云存档配好。
6. 在 Playtest 设置里 Manage Your Playtest 按批放人（可按国家限制，避免服务器延迟干扰测试结论）。

两个「不可逆」的细节：Playtest 的对外名称发布后不能改（所以别再叫「Test Build 3」）；切到 Not Playable 之前一定要先发公告，官方明确提醒这会挫伤社区。

三、Playtest 构建里必须塞进去的 5 样东西（Godot 落地）

Playtest 的价值全在「拿到可行动的反馈」，而不仅仅是「让人玩到」。构建里建议硬编码这几件：

1. 版本号 + 构建时间常驻标题页右下角（ProjectSettings.get_setting("application/config/version")），否则玩家报 bug 你都不知道是哪个包。
2. 一键反馈按钮：抓 OS.get_name()、显卡、语言、当前场景、最近 200 行日志，打包成 zip 丢进 user://feedback/。
3. 一个「打开日志文件夹」按钮：OS.shell_open(ProjectSettings.globalize_path("user://"))，让小白玩家也能把文件发给你。
4. 轻量遥测 CSV：关卡开始/结束、死亡坐标、退出方式，各写一行。别上重型方案，几十个测试者用 CSV 足够做热区图。
5. 成就/统计要降级处理：Playtest 用的是另一个 appID，主游戏的成就 ID 在这里可能对不上——用 Engine.has_singleton("Steam") + 一个 IS_PLAYTEST 开关把它们包起来，别让测试包因为成就初始化失败直接崩。

还有个常被忽略的点：别在测试包里做「难度讨好」。测试者帮你找的是问题，不是帮你刷好评数据。

四、问对问题，才拿得到有用的反馈

「你觉得好玩吗」几乎零信息量。有效的问题都指向行为：

• 你第一次死在哪？当时你以为该怎么做？
• 有没有哪个瞬间不知道下一步该干嘛？大概在第几分钟？
• 哪个操作你觉得「不听话」？（跳跃、攻击、交互）
• 如果现在要你花 30 块买它，你最犹豫的是什么？

前三个问题回答「设计有没有教对人」，最后一个回答「商店页和定价有没有说服力」。

🎯 DeepSeek 提示词

提示词 1：Playtest 测试计划生成器

适用场景：第一次开 Playtest，不知道该测几轮、每轮测什么、看哪些指标。

你是一位做过多次 Steam 封闭测试的独立游戏制作人。我的项目信息：
- 类型：【2D 横版动作 / 像素风】
- 当前完成度：【核心循环可玩，有 3 关，无音效】
- 团队规模：【1 人】，每周能投入测试相关时间约 6 小时
- 目标：在 3 个月内为新品节的 Demo 版本做好准备

请输出一份 Playtest 计划，严格按以下结构：
1. 分 3 轮测试，每轮写清：测试目标（一句话）、邀请人数、测试时长、需要玩家完成的 5 个具体任务、本轮不做的事
2. 每轮对应的 5 个核心观察指标（要能在游戏内埋点或用 CSV 记录，不要「留存率」这类需要大样本的指标）
3. 每轮结束后 48 小时内的处理流程（收集 → 归类 → 优先级 → 修复）
4. 常见风险：哪些问题会在第 1 轮被玩家大量报告但其实该忽略（附带判断依据）

约束：
- 单人开发，流程必须能在 6 小时内跑完一轮
- 不要建议使用第三方分析平台，只用游戏内 CSV + 玩家手填问卷
- 用中文，条目化输出，不要客套话

提示词 2：设计「问行为不问评价」的测试反馈问卷

适用场景：你需要一份玩家能 5 分钟填完、但你真能据此改设计的问卷。

你是一位玩家研究方法顾问，熟悉游戏可用性测试。请为下面这款游戏设计一份 Playtest 反馈问卷。

游戏：【一句话描述：像素风横版动作，玩家用一把可回收的飞刀战斗】
测试版本时长：约 25 分钟（3 关 + 1 个 Boss）
填写者：通过 Steam Playtest 报名进入的普通玩家，非硬核玩家

要求：
1. 问卷分 4 段：开场体验 / 核心操作 / 关卡引导 / 购买意愿，总题量 12 题以内
2. 至少 8 题必须是「行为回忆型」问题（例：你第一次死亡时在做什么？），而不是「你觉得 X 好不好」的打分题
3. 最多 2 题使用 1-5 分打分，并说明这两个分数你打算怎么用
4. 给出每题的分析口径：如果多数人这样回答，说明什么设计问题、下一步改什么
5. 最后附一段给玩家的说明文字（100 字内，说明反馈会怎么被使用，让玩家愿意认真填）

输出格式：编号列表 + 每题下方的「分析口径」小字，中文。

提示词 3：把一堆零散反馈归因成修复清单

适用场景：收了 20 份问卷和一堆聊天记录，脑子一团乱，不知道先改哪个。

你是一位资深游戏 QA 与设计负责人。下面是我从 Steam Playtest 收到的原始反馈（问卷文本、聊天记录、Discord 留言混在一起）。

原始反馈：
"""
【把 10-30 条反馈原文粘在这里，一条一行，保留玩家原话和错别字】
"""

请完成以下分析，用表格输出：
1. 归因分类：把每条反馈归到「真 bug / 引导缺失 / 手感数值 / 内容不足 / 玩家口味不符」五类之一
2. 频次统计：合并同类问题，按「影响人数 × 阻断程度」排序，给出 Top 5
3. 对 Top 5 各给一条修复方案：写清改什么参数或哪个场景、预期效果、验证方法（怎么确认改好了）
4. 标出哪些反馈应当「明确不改」，并给出一句能回复玩家的解释
5. 最后给出本轮 Playtest 的一句话结论：现在最该做的是修 bug、补引导，还是加内容？

约束：不要臆造玩家没说过的问题；信息不足的条目单独列在「需追问」区，并附上要追问玩家的原话。

学习心得

今天最大的收获是「测试的分层」：Playtest 不是 Demo 的早期版本，而是另一条工具链。它最妙的地方在于把「让人玩到」和「让人买」彻底解耦——你不用背评测压力，不用手发 key，报名口就长在自己商店页上，玩家顺手点一下就成了测试者，同时还 Follow 了你的游戏。

对「用 DeepSeek 做一款 Steam 游戏」这个目标来说，这一步的意义比技术实现更大：一个人做游戏，最贵的不是写代码，而是判断自己写的东西到底对不对。DeepSeek 能帮你写脚本、能帮你审代码，但它没法替你坐在玩家背后看他们卡在哪。Playtest 就是那个「把玩家请进来」的通道，而上面那三条提示词负责把混乱的反馈变成一张可执行的清单。

顺带记一笔成本账：Playtest 免费，子 appID 不用额外付 100 美元；真正花掉的是你的时间和一小批玩家的耐心——所以每一轮都要有明确的问题，别为了「感觉在做测试」而开测试。

明日关注

• 在 Steamworks 后台确认自己游戏的 Playtest app 是否已创建，把库封面资产规格（Library capsule）过一遍。
• 在 Godot 里加一个 debug_overlay.tscn：显示版本号、FPS、当前场景、内存，并做一个「导出反馈 zip」按钮。
• 写一版 12 题以内的反馈问卷初稿（可以直接拿提示词 2 生成再改），找 2 个朋友试填，看有没有歧义题。

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