GameTest 是 Minecraft 基岩版实验性功能中的一个致力于提高测试效率的模块，允许玩家借助 JavaScript 脚本+ Minecraft 结构、以更便捷的方式定义测试单元，验证自己创作内容中的逻辑。

举例来说，假设你想测试「生物 A 会主动攻击生物 B」，就可以建造一个封闭空间、导出为 Minecraft 结构，然后用 JS 脚本使用这个结构、在其中生成生物 A、生物 B，经过一段时间后再检测生物 B 是否死亡，得出测试结论。

为了方便创作者用 JS 脚本定义测试逻辑，官方提供了很多 API 接口、包括不少可监听的事件，这也使得 GameTest 具备了 Mod API 的潜力、备受社区关注。

为了更进一步普及社区对 GameTest 的认知，我在这篇文章中翻译了官方此前的 Q&A，通过这一系列内容，你将对 GameTest 的背景、后续发展有更具体的了解。

领域服

• 问：GameTest 能运行到领域服上吗？

• 答：可以

QuickJS vs V8

• 问：相比于其他 JS 的选择比如 V8，为什么会选择 QuickJS？QuickJS 比其他的速度慢很多（很有可能是因为少了 JIT），而且在一些社区中用它也被认为是一个下策。

• 答：我们中有一些人在过去的项目中用过 QuickJS，它很易于集成。我们已经了解过 V8（以及其他的），未来也可能会迁移过去。JIT 很有吸引力，但可惜的是并没有全平台的支持。

文件与网络权限

• 问：GameTest 以后会有文件或网络的接口吗？

• 答：通常情况来说，我们希望对脚本 API 加以限制，随着时间逐步增加功能。考虑到文件和网络 API 需要权限、以及游戏拥有者的许可，这类接口可能不会在默认的接口中提供，但我们可能会在将来的某个时间加入这些功能（比如开放给服主）

• 问：所以说这类接口只会在部分平台实现？

• 答：我们会努力让 API 支持全平台，除非我们引入了一些针对编辑器的 API，那类会限于 PC 端。

指令

• 问：我们什么时候可以注册自定义的指令？

• 答：尽管我们还没有确定具体的时间，但这在我们的待办中是高优先级的。

• 答：当人们开始制作他们自己的指令时，很显然我们是需要这方面支持的。

原版测试

• 问：你们现在是在用 GameTest 框架测试原版的行为包吗？或者换个问题，你们在自己的内容中是怎么用测试 API 的？

• 答：是的！我们现在有很多用于原版内容的测试，也想持续拓展更多测试。实际上我们在公开版本中就已经外放了一些我们所用的原版测试（vanilla_gametest）

时间线

• 问：能否透露 API 接下来有什么计划中的事件吗？

• 答：因为我们的团队还在评估接下来要加入什么事件，所以目前还没有可以分享的时间线，你们有什么想看到的新增事件吗？

• 答：非常同意，破坏/放置方块确实应该优先考虑。

GameTest 政策

• 问：崛起的是 GameTest API 而不是原先的脚本 API，这背后有什么技术、结构或政策上的原因吗？能否说明下这次「你做了什么不一样的」？另外，对于 GameTest 来说怎样算是「成功」（而不至于被废弃），有什么我们能做的吗？

• 答：通常来说，我们会专注于我们的目标场景，也就是从内容的测试验证开始，既包括 Minecraft 原版的、也包括自定义内容的测试。我们真心希望，能让大家更便捷的为自己的内容搭建测试。而这种场景下的需求也更有限（比如我们可以选择更少的平台、性能也不是什么大问题），因此，为了让 GameTest 成功，我们希望看到内容创作者们能更便捷的测试他们的内容。

• 答：当然，我们确实看到了 GameTest 在未来更多场景下的潜力，包括玩法。但我们不想拉高任何人的期待（或者让人们在用脚本/gametest API 做玩法这件事上押注），我们还有很多要验证的，像是性能、多平台支持，同样也包括对你们反馈的回应。

• 答：回复一下「有什么是你们能做的」，持续参与、帮助我们改善和添加新东西！创作者的社区就是这一切的驱动力。

主机

• 问：为什么主机上无法运行 gametest？主机平台未来最终是否会支持 gametest API？

• 答：会的！我们计划是支持全平台，我们 JS 引擎所需的 API 在一些平台上是缺失的，比如 `aligned_alloc`，我们正在积极推动这些平台上的支持。

更多编程语言

• 问：GameTest 以后会支持不同的语言吗？

• 答：基本来说，我们已经实现了适配其他编程/脚本语言所需的绑定层。我们也在内部尝试了一些有趣的事情，比如配合 Lua，甚至是像 Blockly 这样的可视化编程语言，但我觉得在当下，我们还不能承诺会为其他语言提供任何官方支持。

• 问：你们有考虑过 Kotlin 吗？

• 答：我对 Kotlin 的了解还比较少（我们所有的安卓平台仍然是用 Java 编写的），但听起来不错！我会去看看的。

事件系统

• 问：数据驱动（data-driven）里面已经有一套事件系统了，从你们的角度来看，GameTest 框架中的事件系统和数据驱动中的，两者之间是怎样的关系？未来是否会提供一个连接两者的接口？

• 答：我们希望这两个系统能共处，如果你熟悉数据驱动，我们希望你也能以一种有意义的方式步入脚本，这方面我们还在摸索。

哪些是不会做的？

• 问：你们是否方便分享「不做的清单」里有哪些东西？（已经经过你们讨论，单方面决定不实现的）比如你们不会去支持的某些设备、或是 API 发展避开的方向，什么都可以

• 答：这个问题问得很好，在我们「绝对不做」的清单上几乎没有列多少东西

• 答：在我们「万分小心」的清单上有这些：

• 网络权限

• 文件权限

• 平台限定的 API

• 答：就网络权限来说，我们可能会允许通过非常结构化的 API 访问特定的目标，文件也是：我们可能会有一些持续性储存，但不是自由格式的文件。

• 答：平台限定的 API 也是我们想避免出现的，但我们可以想象为编辑器类场景实现 PC 端限定的 API，不过我们会在玩法和 GameTest 的场景中避免这种事。

• 答：我想说的还有一件事，自定义着色器真的很难。PlayStation 要求在提交时内置着色器，因此我们不得不提供一套基于物理的材质系统，将非常灵活的着色器硬编码。

• 问：刚刚提到了「持续性储存」，意思是我们以后会有办法通过单独实例的方法、读写简单的整型变量吗？或者说还是在实例中、运行结束时被删除？

• 答：是的，我们有计划加入像 Json 这类的键值对存储。届时就可以通过 JavaScript API 访问标签、记分板，更进一步可以允许常规的读写储存（但还不是直接的文件系统访问权限）。我们需要解决一些安全问题，确保每个包的存储都是沙箱。

自定义维度

• 问：如果有自定义维度的话，GameTest 是否计划支持？

• 答：设计 GameTest API 的过程中，我们一直有在考虑自定义内容。这也是为什么 Commands.run 所需的维度是字符串、而不是硬编码的维度变量这样的信息。毋庸置疑，我们对 GameTest 与自定义维度集成的可能性保持开放，对其他自定义内容也是一样。

旧的脚本 API

• 问：旧的脚本 API 会怎么办？仍然可用但不会再更新了吗？（一直支持下去）

• 答：原先的脚本 API 还会保持可用（并且你也已经注意到了，它最近几乎没有更新了），考虑到随着 GameTest API 和其他玩法逻辑系统的发展，它们有可能会覆盖脚本 V1 的功能范畴，我们之后也会移除脚本 V1 的功能。

• 答：旧的脚本 API 是实验性的，因此几乎没有向后兼容的保证。另外，旧的脚本 API 没法用在移动设备上，在这个时间点上，我们也不会拓展它的平台支持。

• 答：我们确实想支持像 UI 这样的客户端体验，我们已经有了一些实现的想法，但还没有确定的计划。

世界生成

• 问：有没有计划在 GameTest 中放出世界噪波（world noise）？JS 有噪波的库，但需要的是能用在群系生成、MoLang 查询。

• 答：我们还没想好要怎么将世界生成放入脚本，区块生成是在任务线程上运行的，现在我们的 GameTest 实现也不支持安全的迁移到其他线程。我们有想过创建类似 web worker 东西，但仅限于此。

GameTest BDS

• 问：GameTest 以后能在 BDS 上流畅运行吗？

• 答：我们目前就在我们的 CI 管线中使用了 BDS 运行 GameTest、验证结果！

• 问：有没有一些地方是 BDS 和 GameTest 配合不太好的？

• 答：如果 GameTest 不生效，有一个可能的原因就是世界没有开启实验性功能，而这在专用服务器上是有难度的。目前最简单的方法是先用一个 Minecraft 客户端，在开启 GameTest 实验性功能的情况下生成世界，然后再将这个世界转到专用服务器上。

学习 JS

• 问：我刚开始学 JavaScript，有什么推荐编程新手学习 GameTest 的参考资料吗？就学习 GameTest 来说，不是通用的 JS。

• 答：酷！JavaScript 很适合入门编程。

• 答：我们有一篇很简短的文章，讲了如何搭建你的第一个 GameTest：https://docs.microsoft.com/en-us/minecraft/creator/documents/gametestbuildyourfirstgametest

• 答：未来还会有更多这方面的内容！

• 答：注意：如果你想参与贡献这些指南，我们也会很乐意的。

beta BDS

• 问：有没有计划公开发布 BDS 的 beta 版？这样有助于我们更好的调试、诊断 GameTest 中的问题。

• 答：感谢建议，我很乐意那么做，我会跟进我们的发布管理团队、评估这方面的可行性。

NPM

• 问：GameTest 能支持 npm 库吗？

• 答：原生来说，我们是不支持 NPM 库的，但我们在用 WebPack 「烘焙」包体时也取得了一些有限的成功。

• 答：另外！我们的官方 TypeScript 绑定快发布了，我们已经在此分享过了一些早期的版本，但我们离发布也已经很近了。

• 问：GameTest 以后会有像 npm 这样的包管理器吗？

• 答：我们考虑过这方面，但这确实是不小的工作量。我们会持续考虑的，随着越来越多人开始用起脚本，我们也将看到一些自然的开发模式出现，我们也会朝着那些模式倾斜。

GameTest 的终极目标

• 问：GameTest 的终极目标到底是什么？它会一直作为一个测试工具，还是会进一步拓展，比如能添加全新的内容？

• 答：就 GameTest 来说，我们致力于简化内容的测试和验证，我们希望大家能更便捷的为自己的内容、装置、脚本搭建测试。为了做到这些，我们所做的其中一部分就是通过 GameTest 模块提供丰富的脚本 API，方便用于模拟和测试断言。我们会持续添加一些新的 API，也会在 GameTest 中加入一些能在环境中模拟玩家的酷炫方法。此外，我们也在想方设法简化创建这些 JavaScript 测试的工作。

• 答：当然，这个过程中 GameTest 也带来了让人高兴的副产物，那就是我们有机会构建更多通用的、基于服务端的脚本 API，这也有助于我们在未来的场景中探索它的应用潜力。

实验性模块

• 问：你们在过去曾经表示过所有指令都有望成为 API，如果现在有一个实验性特性，它是否会有 API 支持？如果有的话，是会放在一个实验性模块里？

• 答：我们当然希望能有针对实验性特性的 API，但我们还没有决定好具体要怎么做。可能是一个单独的模块，类似 mojang-minecraft-experimental 这样的？就像 C++ 在实验性命名空间中处理未标准化类型的做法。

开发 GameTest API 的工作

• 问：开发 GameTest API 的工作中最酷的是什么？有没有什么实现起来特别有满足感/有趣的设计决策，或是技术要素？

• 答：个人而言，就是为了引入多脚本语言支持，创建了一个绑定层+消费者

• 答：设想是每个包都可以选择要用什么脚本运行时（script runtime）

• 问：赞！未来我们可能支持 Python 吗？

• 答：在一次 Game Jam 中，我确实用某种黑科技让 Python 2.7 跑起来了，但我们目前还没有这方面的产品计划。

API 覆盖面

• 问：现有的一些方法（method）会增加对玩家的支持吗？比如 item stack

• 答：你可以在这里看到最新的 API 清单：https://docs.microsoft.com/en-us/minecraft/creator/scriptapi/mojang-minecraft/player

• 答：注意：现有的 API 还只是一小部分，我们会逐步添加更多的。

GameTest 替代命令方块

• 问：GameTest 会替代命令方块吗？

• 答：我不太能理解为何它会替代命令方块，但我能理解的是，GameTest 将很多「繁重的逻辑」迁移到了脚本，理论上它们两者会紧密合作（不妨试想一下，你在脚本里注册了一个自定义指令，然后用一个命令方块执行它）。

教育版 Code Builder

• 问：有没有计划让 GameTest API 更好上手一些，比如像教育版的 code builder 那样？

• 答：我们已经在尝试让 GameTest 支持像 Blockly（可视化编程）这样的东西，虽然目前还没有什么可以透露的，但我觉得还是很酷的！

最有趣的 Bug

• 问：用 GameTest 时遇到的最有趣的 bug 是什么？

• 答：有一个不久前发生的，当时我在测试驯服的 API，我想看看如果我刷出 100 头狼再驯服会怎么样……https://imgur.com/a/NIF7D4x

市场

• 问：GameTest 会对市场产生多大的冲击？

• 答：就目前来说，GameTest 还属于实验性功能，因此没法包含在市场的内容中。我们认为在「上架前帮助验证内容」的这一侧来说，GameTest 还是很有用的。

领域服

• 问：GameTest 未来在领域服上会如何发展？它会保留在领域服，还是像旧的脚本 API 那样被移除？

• 答：我们的打算就是将 GameTest（以及后续的玩法脚本）带入领域，因此我们不会想之后再弃用它。

GameTest 的用途是多样的吗？

• 问：从社区的用法来看，大多数是将 GameTest 作为最终成品的一部分（就像脚本引擎的使用场景），而不是仅仅用于开发过程中捕捉 bug，你们是否有看到 GameTest 正拓展到更普遍的应用，并且逐步成长、被看作是一项 addon 所支持的特性？

• 答：目前来说，我们对 GameTest 还是专注于内容测试，而不是为了通用的玩法去支持脚本 API。为了能确定脚本 API 应该在何时、以怎样的方式脱离实验性功能，承载这些角色，我们需要确保我们在幕后做了足够多的测试和基础设施的准备。

Molang

• 问：能通过 GameTest API 测试 MoLang 吗？

• 答：你可以用各种方法测试实体行为，当然实体也可以在动画控制器和状态迁移条件中包含 Molang。

• 问：你有没有什么想特别说的？

• 答：我应该提到过，要想在自定义实体上使用 GameTest，可以在运行 GameTest 时加载自定义实体的行为包。

社区反馈

• 问：添加新的 GameTest 特性时，是基于 Mojang 的测试需求，还是基于社区的反馈或需求？这会有所改变吗？

• 答：当然是两者都有！为了测试一些原版的逻辑，我们一直在添加新的 GameTest API，但我们也想知道你们对什么 API 感兴趣。

• 答：自定义指令的 API 就是个很好的例子，因为社区一直在询问，这个 API 在我们的待办中也是高优先级的。

• 答：还有一些即将到来的特性，可以让 GameTest 更强大、更易于创建，比如模拟玩家 API、Visual Studio Code 中的脚本调试。

各平台的效率

• 问：GameTest 和其他平台的兼容性/通用效率如何？

• 答：我们希望能支持全平台，关于性能，我们不得不在支持即时编译的与不支持的平台间辗转，因此这也是一个已知且很大的分析和性能调优领域。

• 问：我所说的「通用效率」指的是这套 API 有多接近内核（close to the metal）

• 答：感谢你的澄清，我们的 API 首先会尝试与数据驱动系统相配合，因此它会运行在 Minecraft 实体、物品、方块、区块等抽象级别上。如果你熟悉 Bukkit，我们试着做到的正是类似的抽象级别（再加上一些我们想实现的客户端内容）

GameTest 这个名字的由来？

• 问：起 GameTest 这个名字的原因是什么？

• 答：我们是在 Java 版做过的基础上做了一些工作，他们搭建了一个用于测试流程的初版 GameTest 框架。

• 问：接着这个问题，计划中是将整个系统称作 GameTest，还是别的什么？

• 答：我认为如果我们会拓展到测试场景之外，将整个 JS API 集合称作 GameTest 是无意义的，你可以在整个 API 的命名中看出这种思想的表达。

为什么要用 GameTest？

• 问：你们推出 GameTest 的目的是什么？或者说，你们对 GameTest 的用途有没有什么想法？

• 答：基本来说就是，做游戏测试！允许在游戏中添加测试而不用重新编译的好工具，有了它我们就可以更快的做测试，社区的成员们也能在反馈 bug 时编写测试了。

• 答：从「让脚本在 Minecraft 里运行」这件事来说，GameTest 也是一个很好的「试验场」。

GameTest 有什么限制？

• 问：GameTest 有什么限制？

• 答：只有你想不到的！

• 答：好吧，正经点说，我们是有一些限制的：结构最大可以是 64x64x64，目前也只能在主世界维度运行，但我们想进一步拓展。

• 答：我们现在还不支持和玩家的互动，但那也在后续的工作中。

• 答：GameTest 可以用在移动端，我们现在也在推进唯二的两个不支持的平台：Switch 和 PlayStation。

• 问：在游戏崩溃之前，最多可以嵌套多少层 for 循环？

• 答：事实上，这个问题问得很好，目前来说，如果你用 while(true) 会把游戏停住，但我们通过制作原型、计划搭建一个「看门狗」来检测并阻止这类情况。

• 答：我们的看门狗原型能做的也不止这些，除了循环周期以外，它也能监控脚本对象的数量和内存。（它也是跨语言运行时工作的，所以很酷）

热重载

• 问：有没有什么简单的方法可以在游戏内重载 GameTest API 文件？就像 function 里面的 /reload 指令那样。支持快速重载的话，真的可以让调试和处理事情变得轻松愉快。

• 答：作为一个写过一堆 GameTest JS 的人来说，我们的想法和路线图中绝对会考虑提供一个更轻松重载 JS 的方法。

文档

• 问：让我觉得 GameTest 难上手的原因之一，就是它的文档难啃。有没有计划让文档更通俗易懂一些？这样大家就能更轻松、由浅入深的理解如何使用这个框架了。

• 答：我们最近发布了一个新的创作者入口，里面就有如何入门 GameTest 的文章。https://docs.microsoft.com/en-us/minecraft/creator/documents/gametestgettingstarted

• 答：因为 API 的文档还很新，我们在提供细致文档和示例上还有很长的路要走，这些文档托管在 Github 上，因此如果社区里有人想贡献，我们也欢迎发起 PR。https://github.com/MicrosoftDocs/minecraft-creator/tree/main/creator/ScriptAPI

Hummingbird UI

• 问： GameTest 是否会继承脚本 API 的角色，作为 Hummingbird UI 的引擎？

• 答：Hummingbird 是 GameFace（https://coherent-labs.com/products/coherent-gameface/]）之前用的名字，是一个我们正在研究的用于搭建新的基岩版 UI 的 技术。

• 答：我们当然有计划让脚本支持创建或修改 UI，但我们想让它能和内置的 UI 更自然的配合，我们也还在研究具体的做法。

• 答：我们不想在 GameFace JS 那样的沙箱中运行，另外，我们现在主要关注的是服务端，而 GameFace 只运行在客户端。

外部脚本

• 问：GameTest 以后能和外部的脚本互动吗？这样的话就能和其他目录的脚本通讯了。

• 答：我们确实想让脚本能将其他脚本作为依赖项，比如依赖一个好的测试脚本、或是生成地形的脚本，但那很有可能要借助行为包的依赖系统，我觉得我们目前还没有办法从任意位置加载 JS。

• 答：是的，让外部脚本能跨越全平台并非易事，安全方面也有潜在的挑战。

市场

• 问：GameTest 能用在基岩版市场的内容吗？如果能的话，有没有大概的时间？

• 答：目前来说，我们还是会专注于测试的场景，尽管我们有很多未来的想法和计划，但我们不想让大家基于我们还没有承诺的东西做计划、或是指望太多。

Discord

• 问：GameTest 以后能将 Discord 连接到 MC 吗？

• 答：最初的版本不会，大概率不会。

Java 版限定特性

• 问：我看到有很多原版标有 suite:java_parity 的 GameTest 都被禁用了，大概是因为逻辑不生效，这些测试是否来自 Java 的测试套件？它们的目的是什么？

• 答：我们过去在 Java 中搭建过一些 GameTest 的测试，其中的一些也被迁移过来了。即便 Java 和基岩版存在不共通的特性，我们也想追踪一部分用于 Java 版的测试。

• 问：如果禁用的这些测试能作为迁移更多 Java 版逻辑的待办会很棒，我们也能提供更多，哈哈

• 答：如果你编写了一个演示 Java 版限定问题的 GameTest，欢迎发给我们：  https://aka.ms/gametestsamples

• 答：是的，我们在追踪那些通过 GameTest 发现有 bug 的版本限定问题。

• 问：如果 GameTest 能以这种方式开放接受贡献，有没有什么方式能让我们贡献原版行为包/资源包的？

• 答：我们正在讨论是否应该将「内置」的 GameTest 移动到同一个仓库，以便更轻松的获取开源的行为包。

参考来源

https://wiki.bedrock.dev/scripting/gametest-qna.html#top