Steam Demo 截取范围怎么定：2021 年 1 月个人游戏试玩版上架流程

先决定 Demo 要回答什么问题

个人开发者做 Steam Demo 时，很容易从“截哪一段内容”开始想。更好的起点是：这个 Demo 要回答什么问题。不同项目的问题不同。有人需要验证核心玩法是否吸引人，有人需要测试低配机器能否运行，有人需要让主播有可播内容，有人需要把愿望单玩家重新唤醒。如果问题没写清，Demo 会变成一个既想展示所有内容、又怕剧透、还想引导购买的混合体。

2021 年 1 月准备 Demo，建议先写一份目标说明：

一个 Demo 可以有多个目标，但只能有一个优先目标。比如你最担心玩家看不懂玩法，就不要把前 15 分钟都用来讲世界观；如果你最担心性能，就要让 Demo 包含真实压力场景，而不是只放轻量教程。

Demo 不一定等于正式版开头

把正式版开头直接切出来最省事，但不一定有效。正式版开头通常需要慢慢铺垫，而 Demo 需要在有限时间内证明游戏值得继续关注。尤其是策略、经营、解谜和叙事游戏，前期教学可能还没出现核心乐趣。

可以考虑三种 Demo 结构：

个人开发者通常适合“开头式加轻度改造”或“精选式”。比如正式版第一章需要 40 分钟才出现核心系统，Demo 可以把关键资源、敌人或选择提前，让玩家在 10 分钟内经历一次完整循环。不要害怕为 Demo 调整节奏，只要不虚构正式版没有的内容即可。

结束点比开始点更重要

很多 Demo 开始不错，结束很糟：玩家突然走到空气墙，或者弹出一句“内容到此结束”，然后回到主菜单。这会打断情绪，也浪费愿望单引导。Demo 的结束点应该像一个小章节收束：玩家完成了一个目标，看到了更大的问题，并知道正式版会继续展开。

好的结束点包含三层：

1. 当前目标完成，例如修好第一座电站、击败第一个 Boss、解开核心谜题。
2. 展示后续期待，例如新区域、新系统、新敌人或未解开的剧情。
3. 给出行动入口，例如加入愿望单、填写反馈、查看正式版内容说明。

结束文案可以很简洁：

Demo 到这里结束。正式版将包含更多区域、完整结局、进阶模块和挑战模式。
如果你想在发售时收到提醒，可以回到 Steam 页面加入愿望单。

不要只喊“请愿望单”。先说明正式版为什么值得关注，再给行动。

存档和正式版要提前规划

Demo 最容易埋雷的是存档。很多个人项目直接复用正式版存档路径，发售后导致旧 Demo 数据污染正式版。更稳的做法是默认隔离：

Studio/GameDemo/
Studio/GameFull/

如果你想让 Demo 存档继承到正式版，要非常谨慎。继承意味着你要处理版本迁移、任务状态、物品 ID、数值平衡、成就触发和坏档修复。个人开发者如果没有成熟存档迁移工具，最好只继承低风险数据，例如设置、语言、音量、键位，主线进度不继承。

存档测试清单：

这些测试比多加一个 Demo 关卡更重要。玩家第一次试玩就遇到坏档，很难再相信正式版。

反馈入口要在游戏内外都存在

Demo 发出去后，如果没有反馈入口，你只会得到零散评论。游戏内可以放一个“反馈”按钮，指向邮件、表单或社区；商店页公告也可以说明反馈格式。不要让玩家写长篇问卷，先收集最关键的信息。

反馈模板：

你玩到 Demo 的哪个位置？
最困惑或最卡住的地方是什么？
有没有遇到崩溃、黑屏、坏档或严重掉帧？
你是否愿意把正式版加入愿望单？原因是什么？
你的系统配置和输入设备是什么？

这个模板能同时收集体验、转化和技术问题。个人开发者不需要复杂数据平台，也能通过这些问题判断 Demo 是否达到目标。

Demo 页面也要和主页面联动

Steam Demo 不是孤立存在的。主游戏页面、Demo 页面、公告、社媒、主播邮件要说同一件事。玩家从 Demo 进入正式页时，应该看到一致的游戏名、截图风格、标签和内容说明。

联动检查：

不要让 Demo 宣传一个玩法，主页面又强调另一个玩法。玩家会困惑，也会降低愿望单转化。

试玩时长要可控

Demo 不是越长越好。太短无法证明价值，太长会让玩家满足离开，或者暴露大量未完成内容。个人项目常见时长可以控制在 20 到 45 分钟，具体取决于类型。短局 Roguelite 可以给一局完整流程，解谜游戏可以给一组规则递进，经营游戏可以给 3 到 5 个游戏日，叙事游戏可以给一个完整小章节。

时长设计还要考虑主播。一个可播 Demo 最好在 30 到 60 分钟内形成明显节目效果：有开场、有理解、有挫折、有收束。如果 Demo 需要两个小时才能看出亮点，小主播很难安排。

Demo 更新要控制频率

Demo 公开后，不要每收到一条反馈就更新。启动崩溃、坏档、卡死这类问题要快速修；教程文字、难度数值和按钮提示可以合并成小版本；新增内容、结构调整和存档变化则要谨慎。频繁大改会让主播录制素材过期，也会让玩家讨论不同版本时互相混淆。

可以把更新分成三类：hotfix 只修阻塞；polish 修体验和文案；content 才增加内容。每次更新都写清版本号和变化，尤其是影响存档或通关路线的内容。Demo 的目的不是展示开发者每天都在改，而是给玩家一个稳定、可信、能代表正式版方向的试玩入口。

Demo 数据要回到正式版决策

Demo 结束后要统计几个简单问题：多少玩家玩到结束，多少玩家反馈教程卡点，多少玩家愿意愿望单，哪些配置出现技术问题。如果大部分玩家没有玩到结束，先别急着上正式版宣传，应该检查开头节奏和目标引导。如果玩完的人愿望单意愿很高，说明 Demo 作为转化入口有效，可以把它放进发售前公告和主播邮件。

也要看玩家离开的具体位置。退出发生在首次战斗前，问题多半是引导；退出发生在第一轮失败后，可能是失败反馈；退出发生在 Demo 结束前，可能是节奏或奖励不足。位置比总下载量更能指导修改。

发布前的 Demo 检查表

Demo 做得好，不只是让玩家提前试玩。它会帮你验证页面定位、收集真实问题、给主播内容、提高愿望单质量。个人开发者最需要的不是一个内容很多的 Demo，而是一个目标清楚、结束得体、技术稳定、能推动玩家下一步行动的 Demo。