Roblox 如何评估游戏创作

Build 是我们全新推出的“移动优先”创作工具，它允许 Roblox 用户通过文本提示创建游戏，并将其发布给全球玩家。要生成一款完整的游戏，需要一个端到端的自主生成系统：该系统需将代码、视觉资源、游戏玩法系统、用户界面和控制机制协调整合为一个复合作品。该系统必须能够稳健地处理因玩家输入和多人互动而产生的各种场景。 自新西兰的 Alpha 版发布以来，已有超过 10 万名玩家使用 Build 尝试制作游戏，并发布了约 9,000 款 Build 游戏。^¹ 在数千名使用 Build 制作游戏的用户中，71% 此前从未使用过 Roblox Studio，^¹ 这表明他们正在通过 Build 尝试新事物。

但只有当这款新工具易于使用，且生成的游戏质量足够高、能够作为进一步开发的基础时，创作者才会愿意使用它。为了了解使用 Build 创建的游戏质量，我们对端到端的创作过程进行了评估，并结合这些评估结果以及创作者的反馈来改进产品。 我们的评估（eval）框架帮助我们确定了优先级，并提升了意图理解、3D可玩性和游戏打磨质量。自Build在新西兰进行Alpha测试以来，创作者满意度提高了10%，非预期输出从18%降至3%，约14%的提示会话和19%的试玩测试最终得以发布。^² 这些是进展的描述性指标，而非仅对评估影响的因果估计。

为何游戏创作的评估有所不同

游戏在评估方面面临着与生成复合成果的其他系统（如应用程序、视频和世界模型）相似的挑战。例如，质量取决于多个组件的协同工作，没有任何单一组件的评分能完全描述最终结果。 

游戏的独特之处在于，其成果是一个由玩家驱动的可执行、实时系统。响应性、自主性、进度感和游戏手感等特性是通过交互产生的，仅靠检查代码或资源无法全面评估。因此，游戏必须同时达到两个独特的高标准：低层级的正确性（无缺陷且可玩），以及高层级的玩家体验（感觉像是一款完成品，而非原型）。 

我们通过评估试图解答的问题，并非某个单独部分是否正确，而是整体作品是否符合创作者的意图，以及玩家能否完整体验整个游戏过程。要回答这个问题，仅靠一项指标是远远不够的。

四个信号，一个框架

我们的“Build”创作评估框架整合了四种信号。每种信号都回答一个不同的问题，捕捉不同类型的缺陷，并产生具体的量化评分：

1. 游戏规格书质量（0–100 分）：Build 作为端到端的创作代理，将创作者的提示语转换为规格书，并据此生成游戏。评估者将评估该规格书是否明确做出关键决策、是否保留了创作者的意图、是否考虑了 Roblox 运行时环境的可行性，以及是否避免了凭空捏造从未被表达过的需求。

2. 静态游戏质量（0–100 分）：静态评估器在 Roblox Studio 编辑模式下检查生成的游戏。这包括游戏结构、脚本、资源、属性、连接以及客户端/服务器边界。 在此阶段，我们旨在回答两个问题。首先是游戏是否构建正确：必备系统的实现、引擎 API 和网络方案的选择、预期控制方式和 UI 组件是否存在，以及游戏架构的健壮性和一致性。 

其次是游戏设计是否有趣：核心循环的深度、内容的多样性与递进性、进度系统、可重玩性，以及超越该游戏类型常规框架的创新性。一款游戏可能架构精良却缺乏内容深度，也可能创意丰富却实现不佳。 

将这两个视角区分开来，并参照最佳实践进行评估，能让我们更细致地了解游戏在哪些方面存在不足。

3. 试玩测试（0–100% 通过率）：试玩测试评估员运行游戏，并执行测试计划，使用类似真实玩家的输入操作（包括点击、点击、按键和导航），而非通过代码触发事件。 针对每个用例的测试计划会检查游戏能否启动、响应、推进流程、从故障中恢复，以及是否避免了运行时错误。每个项目均为二元通过/失败判定，报告时会以分级加权通过率的形式呈现，并附带“可玩”或“不可玩”的简单结论。我们会重复运行以衡量结果的一致性。

4. 视觉与体验质量（0–100 分）：游戏外观和体验中至关重要的某些方面无法从代码中读取，因此视觉评估员会单独根据在模拟不同设备的视口中捕获的游戏画面对呈现效果进行评分。该评分标准仅关注基于资源制作、UI 完成度、动态效果、光照和音频的游戏视觉与听觉表现。 核心问题是：这款游戏看起来像是一款可发布的成品，还是像一个原型？将视觉效果与机制分离，意味着“代码正常运行”和“游戏看起来已完成”不会被平均成一个具有误导性的分数。

除了计入评分的信号外，每次运行还会捕获仅供参考的指标，例如令牌使用量、工具调用次数、触发的技能以及延迟。这些指标不会影响评估分数，但它们可以解释结果的产生过程，并发现评分标准可能忽略的退化问题，例如同一款游戏的构建成本突然翻倍。

这些信号与它们所捕获的故障对应如下：

体验一个带提示的3D障碍赛关卡

在真实的提示中，这些信号最容易识别。例如：“一款真正的3D障碍跑游戏，包含起跑平台、移动障碍物、检查点和终点线。”障碍跑是Roblox上一种流行的平台游戏类型。即使提示并未规定每个实现细节，创作者的意图也很明确。开发者需要基于合理的假设来填补细节。

规划与规范

开发团队为一款名为《Skyforge Ascent》的新游戏编写了一份规格说明书，详细描述了一条包含检查点和三种危险类型的五段式赛道。该文档定义了核心循环、难度曲线、美术方向、界面、叠加层以及操控方式。规格评估得分为91/100，在完整性、及时性、可行性和内部一致性方面均获得满分。扣分主要源于两个具体维度：实现细节和验收标准覆盖率。 

该规格说明书从未明确规定数值常量（如旋转速度、滑行距离、格子计时、平台尺寸或重置平面高度），因此工程师仍需自行设定这些参数。 此外，部分验收标准（如“约 24 个平台”或“天界熔炉配色方案”）在严格意义上无法被证伪。高规格评分仅证明该文档已具备开发基础。这些承诺能否经受住实际游戏开发的考验，正是接下来三个阶段要衡量的重点。

静态检查：代码质量与内容质量

虚拟评委在未实际游玩的情况下检查了《Skyforge Ascent》的场景文件，而两种评估视角得出了不同的结论。

工程评估视角在读取同一场景文件时，给出了98/100的评分。它发现这是一个堪称典范的构建，包含五个区域和三个移动障碍物，通过采用服务器权威的顺序检查点、坠落重置系统以及基于StyleSheet框架构建的用户界面，完全满足了创作者的意图。规格说明中概述的一切均已实现。唯一的问题是存在两个未使用的辅助函数导出。

设计视角则给出了31/100的评分。虽然所有功能都能正常运行，但在进度推进、可重玩性、玩家自主权和原创吸引力方面均得分为零。核心循环简单且线性——到达每个检查点，穿越终点——不同通关过程几乎毫无变化，也没有让玩家再次尝试的理由。这只是障碍跑（obby）这一游戏类型的常规套路，而非一款拥有独特吸引力的游戏。

这一差距正是本次评估的发现。代码质量与内容质量是根本不同的维度，一个版本可能在其中一个方面近乎完美，却在另一个方面表现欠佳。如果采用单一的综合质量评分，这些差异会被平均化，最终得出毫无意义的结果。

游戏测试

测试代理以真实玩家般的操作方式进行了通关测试，并通过了测试计划中的全部九项内容：在起始平台生成角色、穿越3D几何障碍物、承受危险冲击、触发检查点和自动坠落恢复、完成通关以及重新开始，且全程未出现任何运行时错误。在此特定测试中，《Skyforge Ascent》获得了100/100的测试评分。

完美的测试分数仅仅证明了游戏机制正常运作，且从头到尾在技术上可玩。这并不能说明游戏是否真正引人入胜或有趣——正是这种区别，才导致设计维度仅给出了31分。

视觉质量

最后，评估系统针对手机尺寸视口下的视觉呈现对录制的游戏片段进行了评分。《Skyforge Ascent》获得86/100分：画面干净、风格统一，与典型障碍跑酷游戏的视觉风格相契合；平台几何结构清晰可辨；危险元素标识明确；HUD设计现代且不显眼。虽然存在些许视觉上的局限，使其未能达到完美，但没有任何画面故障，也没有任何会让玩家停止滑动的元素。

运行指标

同一轮运行还记录了过程指标。游戏构建耗时约八分钟，未出现任何工具错误，且构建过程调用了 3D、UI、脚本编辑、资源插入和游戏音频技能。这些指标虽不会直接影响评估分数，但能反映游戏的制作过程，并能预警未来构建过程中若出现无实际收益却导致速度变慢或成本增加的情况。

在五个评估阶段中，《Skyforge Ascent》在游戏规格、代码质量、内容质量、试玩体验和视觉质量方面的得分各不相同。其中四个维度表明，“Build”能够将一个单一提示转化为完整、正确、可玩且可展示的Roblox体验；而另一个维度则表明，这并非一款玩家会选择重复游玩的游戏。衡量这一差距——而非通过取平均值将其抹平——正是“Build”评估的全部意义所在。

早期评估如何改善了 Build 

评估结果不仅能生成分数，还能为产品改进提供可操作的指导方向。通过将单个组件的调试与整体系统级测试相结合，针对标准化提示集进行的离线批量评估直接推动了 Build 的开发进程。 

1. 快速解决 Alpha 版创作者的痛点：在新西兰的 Alpha 版发布中，用户反馈称 Build 有时会生成 2D 游戏，而他们想要的是 3D 游戏。评估框架帮助我们的团队迅速提升了 Build 的 3D 能力。在两周内，我们改进了 Build 理解用户创建 3D 游戏意图的能力——即使用户并未明确表达这一意图。 我们还通过修复物体定位、光照等方面的常见问题，优化了3D游戏的可玩性和完成度。自此，在所有投诉中，“这不是我想要的”类投诉从18%降至3%；游戏测试后的总体不满率下降了10个百分点。在迭代框架本身的过程中，我们也积累了宝贵的经验。 
2. 跨模型和架构的对比基准测试：我们利用评估框架，针对标准化的提示词集对构建系统配置进行严格的基准测试。在将更改部署到生产环境之前，离线 A/B 评估报告会从以下四个维度将候选版本与我们的生产基准进行对比： 

例如，这些离线差异分析使我们能够孤立分析各种模型升级和代理路由决策如何影响各个质量指标：

• 基础模型性能：升级基础模型在所有指标上均实现了稳定的提升——这使得首次构建失败的情况减少，视觉效果更臻完善，游戏内容也更加丰富。
• 智能体路由架构：相反，在双智能体架构中将特定子任务委托给轻量级模型，虽然保留了内容的深度和多样性，却导致可玩性和视觉完成度出现明显退化。

1. 跨创作范式追踪质量基准：我们还利用该框架，结合最相关的评估数据集，来了解不同时间点构建成果的当前质量。这些数据集呈现了范围日益广泛、复杂程度不断提升的创作任务的快照。
   最早的数据集完全由机制相对简单的2D游戏组成。由于游戏逻辑易于构建，因此游玩测试评分往往较高；另一方面，正因如此，内容评分却一直较低。
   随着我们把重点转向3D游戏，评分分布自然发生变化：实现无bug的游戏体验变得更加困难，导致游戏测试评分下降。由于资源打磨不足，视觉评分保持平稳，使游戏带有原型般的质感。内容评分则更高，因为3D游戏具有更深层次的潜力——但总体评分往往仍较低，因为单回合提示为内容扩展提供的空间有限。

1. 发现特定游戏类型的瓶颈：评估数据还突显了不同游戏类型之间存在的显著性能差异。注重玩法机制的游戏类型（例如角色扮演游戏、射击游戏、赛车游戏）往往会遇到更多可玩性问题。 逻辑相对简单的游戏类型（例如生存类和经营类游戏）在试玩测试中往往表现更佳，这使得视觉打磨和界面设计成为接下来需要解决的关键问题。了解不同游戏类型的差异，促使我们扩大评估集，在Build平台上的游戏中进行更均衡的采样。
2. 评估框架设计中的经验教训：对框架本身的迭代让我们学到了关于框架可靠性的关键经验：

• 系统指标与组件指标：干净的代码结构或 API 使用并不能保证游戏的可玩性。我们将正确性、设计和呈现区分开来，以避免掩盖可修复的 bug。
• 测试框架的弱点与人工校准：静态检查可能遗漏导致游戏崩溃的运行时阻塞问题，而自动化试玩测试则难以应对复杂的物理系统。虚拟评判系统会持续参照专业游戏开发者和经验丰富的社区评审员进行校准。
• 扩展至多轮迭代与真实流量：由于真实的创作者会持续迭代（添加系统、调整难度、修复 bug），我们正在扩展评估框架，以评估多轮编辑和真实世界的提示词分布。

下一步计划

我们目前正致力于从五个方向扩展“Build”创作评估系统：

1. 覆盖更广泛的游戏类型、2D/2.5D/3D体验、多人游戏场景及复杂度层级
2. 对多轮编辑提供更强支持
3. 更可靠的试玩测试、截图、视频和音频证据
4. 基于大规模人类评分及创作者主导的基准案例进行校准
5. 更好地整合离线评估、在线产品信号和回归测试

我们的长期目标是建立一个透明且持续改进的评估系统，该系统能够从创作者最关心的层面衡量 Build 的表现：即他们能够制作、测试、分享并持续开发的游戏体验质量。目前，这些指标被用于评估 Build 生成的游戏。随着时间的推移，当我们进一步优化这些指标并根据人类判断进行校准后，它们可能会推广到其他创作工作流中，并帮助在更广泛的 Roblox 生态系统中建立一种理解游戏质量的共同语言。

关于 Roblox Assistant 代理系统评估的相关内容，请参阅《使用 OpenGameEval 对 Roblox Studio 的代理式 AI 助手进行基准测试》。