Bedrock Wiki
新手入门指南
JSON UI
Meta
NBT
世界生成
动画控制器
命令
实体
战利品、配方与交易
文档
方块
服务器
概念
物品
视觉效果
粒子效果
脚本编写
虚拟现实

GameTest 问答集 2021/08/06

GameTest 问答集 2021/08/06

本次问答活动在 Bedrock Add-Ons Discord 举行。五位微软员工参与并解答了关于GameTest框架的问题，所有问题均来自社区征集。

注意： 并非所有对话记录都被完整保存，部分内容经过编辑。如需查看完整记录，请加入上述Discord服务器并获取"events archive"权限。

领域服务器(Realms) ​

  • 问：GameTest是否设计支持领域服务器？
  • 答：是的

QuickJS与V8引擎选择 ​

  • 问：选择QuickJS而非V8等其他JS引擎的原因是什么？QuickJS由于缺乏JIT编译导致速度较慢，这在某些社区被视为重大缺陷
  • 答：我们团队中有成员在过往项目中使用过QuickJS，其集成非常简便。虽然我们评估过V8（及其他引擎），未来可能会迁移。JIT编译确实很有吸引力，但并非所有平台都能轻松（或完全）支持该特性。

文件与网络访问 ​

  • 问：GameTest会提供文件或网络接口吗？
  • 答：我们倾向于保持脚本API的有限性，逐步扩展功能。文件与网络API需要权限管理及游戏所有者授权，因此可能不会作为基础API提供，但未来可能会为服务器所有者等特定场景添加这类功能
  • 问：这类接口是否仅会在部分平台实现？
  • 答：我们致力于在所有平台实现统一API。唯一例外可能是编辑器专属的桌面端API。

斜杠命令注册 ​

  • 问：何时能注册自定义斜杠命令？
  • 答：虽无具体时间表，但这在我们的开发优先级列表中名列前茅
  • 补充说明：当社区开始自制!commands时，我们就清楚认识到这个功能的重要性

原版内容测试 ​

  • 问：你们是否使用GameTest框架测试原版行为包？如何利用测试API验证自有内容？
  • 答：当然！目前已有大量针对原版内容的测试，并计划持续扩展。我们甚至在公开版本中发布了部分原版测试案例(vanilla_gametest)
  • 展望：理想情况下，社区也可以通过GameTest提交原版漏洞报告，我们将整合这些测试用例（修复问题后）以确保不再出现同类问题

开发路线图 ​

  • 问：能否分享API后续开发的时间规划？
  • 答：团队仍在确定新增事件的优先级，暂无具体时间表可分享。你们最希望看到哪些新增事件？
  • 补充意见：方块破坏/放置事件确实是高优先级需求

GameTest的成功之道 ​

  • 问：相比初代Scripting API，GameTest API在技术架构或组织决策上有何不同使其取得成功？如何定义"成功"标准以避免项目中止？社区如何助力？
  • 答：我们更聚焦于内容测试与验证这一具体场景——这不仅适用于核心游戏，也适用于自定义内容。目标是降低创建测试的门槛，该场景对平台覆盖率和性能要求相对宽松。GameTest的成功标准是让内容创作者能轻松测试他们的作品
  • 延伸说明：虽然我们看到其在游戏玩法等场景的潜力，但在验证性能表现、多平台支持及收集反馈前，我们不想过度承诺
  • 社区协作：持续与我们保持沟通就是最大的帮助！创作者社区是这一切的核心驱动力

主机平台支持 ​

  • 问：为何当前主机平台无法运行GameTest？未来会支持吗？
  • 答：我们计划支持全平台！某些平台原先缺少JS引擎必需的API（如aligned_alloc），目前正在积极解决这些问题

多语言支持 ​

  • 问：会支持其他编程语言吗？
  • 答：我们的绑定层设计足够通用，可适配多种语言。内部曾实验性集成Lua甚至Blockly等方案，但目前无法承诺官方支持其他语言
  • 追问：考虑过Kotlin吗？
  • 答：尚未深入研究（我们的Android平台仍使用Java），但听起来很有趣！会找时间调研

事件系统整合 ​

  • 问：数据驱动中的事件系统与GameTest事件系统如何定位？未来会提供两者间的接口吗？
  • 答：我们希望两个系统能协同工作。熟悉数据驱动的开发者应该能自然地融入脚本逻辑，具体实现方式仍在探索中

功能禁区清单 ​

  • 问：能否分享你们明确"不会实现"的功能清单？包括不支持的设备或开发方向
  • 答：目前几乎没有"绝对不实现"的内容，但以下功能需要谨慎处理：
    • 网络访问
    • 文件访问
    • 平台专属API
  • 详细说明：
    • 网络访问可能通过严格管控的API实现
    • 文件系统会提供某种持久化存储方案，但非自由访问
    • 尽量避免平台专属API（编辑器功能除外）
    • 自定义着色器是个技术难点（如PlayStation要求着色器预编译），可能通过物理材质系统实现
  • 追问：持久化存储会支持跨实例的简单变量读写吗？
  • 答：计划添加键值对存储（可能是JSON格式），包括通过JS API访问标签和记分板。更进一步的通用存储方案仍需解决沙盒隔离等安全问题

自定义维度支持 ​

  • 问：有计划支持自定义维度的GameTest吗？
  • 答：API设计时已考虑自定义内容，例如Commands.run采用字符串参数而非硬编码维度变量，正是为未来整合预留空间

旧版Scripting API去向 ​

  • 问：旧版Scripting API会如何发展？是否保持可用但停止更新？
  • 答：旧版API会保留（如你所见近期已无更新）。当GameTest等系统逐步覆盖其功能后，我们将移除这个实验性API
  • 补充说明：
    • 旧版API不保证向后兼容
    • 不会扩展对移动设备的支持
    • 客户端体验与UI支持是我们关注的方向，但具体方案尚未确定

世界生成噪声 ​

  • 问：有计划暴露世界生成噪声给GameTest吗？现有JS噪声库无法匹配生物群系生成使用的噪声算法
  • 答：尚未深入研究脚本中的世界生成方案。区块生成运行在任务线程，当前架构暂不支持安全地迁移到其他线程。我们考虑过类似Web Worker的方案，但仅停留在讨论阶段

BDS服务器支持 ​

  • 问：GameTest能很快在BDS上稳定运行吗？
  • 答：我们已在CI流水线中使用BDS运行GameTest进行验证！
  • 现存问题：需要启用实验性选项的世界才能运行GameTest，目前最简便的方式是通过客户端创建世界后迁移至专用服务器

JavaScript学习资源 ​

BDS测试版发布 ​

  • 问：有计划发布BDS测试版帮助调试GameTest问题吗？
  • 答：感谢建议。我会与发布管理团队探讨可行性

NPM支持 ​

  • 问：支持NPM库吗？
  • 答：原生不支持，但通过WebPack打包已有成功案例
  • 好消息：官方TypeScript绑定即将发布！
  • 追问：会有类似npm的包管理器吗？
  • 答：考虑过但实现复杂。我们会观察社区使用模式后再决定发展方向

GameTest的终极目标 ​

  • 问：GameTest最终会保持为测试工具，还是扩展为内容创作系统？
  • 答：核心目标是简化内容测试流程，包括：
    • 丰富的模拟与断言API
    • 新增玩家模拟等测试方法
    • 降低JS测试创建门槛
  • 附加价值：同时也在探索通用服务端脚本API的可能性

实验性功能API ​

  • 问：实验性功能会获得API支持吗？会放在独立模块中吗？
  • 答：我们确实希望为实验性功能提供API，可能采用类似C++的"mojang-minecraft-experimental"命名空间方案

开发趣闻 ​

  • 问：开发过程中最有趣的部分是什么？
  • 答：个人最喜欢创建支持多语言的绑定层设计，让每个包能选择脚本运行时
  • 追问：未来可能支持Python吗？
  • 答：Game Jam中曾用Python 2.7实现过原型，但暂无产品化计划

API覆盖范围 ​

命令方块的未来 ​

  • 问：GameTest会取代命令方块吗？
  • 答：不会完全取代，但可能将复杂逻辑转移至脚本。理想情况是两者协作（例如脚本注册自定义命令供命令方块调用）

教育版编程工具 ​

  • 问：会推出类似教育版Code Builder的易用工具吗？
  • 答：正在探索Blockly等可视化编程方案，暂无具体计划

最搞笑的Bug ​

  • 问：开发过程中遇到过什么有趣的Bug？
  • 答：测试驯服API时，曾尝试生成并驯服100多只狼...结果参见： https://imgur.com/a/NIF7D4x

市场影响 ​

  • 问：GameTest对市场内容会有多大影响？
  • 答：目前作为实验性功能无法用于市场内容，但非常适合用作发布前的验证工具

领域服务器前景 ​

  • 问：GameTest在领域服务器的未来如何？会像旧版Scripting API一样被移除吗？
  • 答：我们计划长期支持，不会轻易弃用

通用化发展 ​

  • 问：鉴于社区主要将GameTest用于最终产品（而非开发测试），会考虑扩展其通用性吗？
  • 答：当前仍聚焦测试场景。在扩展至通用玩法前，我们需要完善实验性验证和基础架构

Molang测试 ​

  • 问：能通过GameTest测试Molang吗？
  • 答：可通过多种方式测试实体行为（包含Molang的动画控制器和状态转换）。只需在运行测试时加载自定义实体的行为包即可

功能开发依据 ​

  • 问：新功能会基于Mojang需求还是社区反馈？这个策略会改变吗？
  • 答：两者兼顾！例如自定义命令API就是因社区需求而优先开发
  • 即将到来：模拟玩家API和VS Code脚本调试功能

平台效能 ​

  • 问：跨平台兼容性和效能如何？
  • 答：目标全平台支持。性能方面需兼顾JIT与非JIT平台
  • 追问："效能"指API的底层程度
  • 答：抽象层级与Bukkit类似（未来可能增加客户端功能）

命名由来 ​

  • 问：为何命名为GameTest？
  • 答：继承自Java版的测试框架名称
  • 追问：整个系统都会沿用这个名称吗？
  • 答：若扩展至非测试场景，可能调整命名体系

设计初衷 ​

  • 问：开发GameTest时的核心目标是什么？
  • 答：实现免编译测试！让社区成员在提交漏洞时能附带测试用例
  • 附加价值：也是脚本集成的重要试验场

功能限制 ​

  • 问：GameTest有哪些限制？
  • 答：目前主要限制：
    • 结构体尺寸限制64x64x64
    • 仅主世界维度可用（正在扩展）
    • 暂不支持玩家交互（开发中）
    • 仅剩Switch和PlayStation平台待支持
  • 追问：循环嵌套会导致崩溃吗？
  • 答：while(true)确实会挂起游戏。我们计划开发"看门狗"机制来监控脚本对象、内存和循环

热重载功能 ​

  • 问：会添加类似/reload命令的脚本热重载功能吗？
  • 答：作为经常编写GameTest脚本的开发者，这确实在我们的规划中

文档改进 ​

Hummingbird UI整合 ​

  • 问：GameTest会取代Scripting成为Hummingbird UI的引擎吗？
  • 答：Hummingbird（现称GameFace）是我们用于构建基岩版UI的技术。虽然计划让脚本操控UI，但具体实现方式仍在设计中，且与GameFace运行在不同的沙盒环境

外部脚本协作 ​

  • 问：支持跨目录的脚本协作吗？
  • 答：计划通过行为包依赖系统实现脚本复用，但不会支持任意路径加载（存在安全和跨平台问题）

市场内容支持 ​

  • 问：GameTest会向市场内容开放吗？预计时间？
  • 答：当前专注测试场景。在确保稳定性前，不想作出无法兑现的承诺

Discord集成 ​

  • 问：会支持Discord联动吗？
  • 答：初期版本大概率不支持

Java版一致性测试 ​

  • 问：许多标记为java_parity的测试被禁用，是否因为行为不一致？这些测试来自Java版吗？
  • 答：部分测试确实移植自Java版。即使存在版本差异，我们仍保留这些测试用于追踪问题
  • 社区协作：欢迎提交展示版本差异的测试用例： https://aka.ms/gametestsamples
  • 追问：能否贡献原版行为/资源包？
  • 答：正在讨论是否将内置测试移至开源仓库

贡献者

编辑 GameTest 问答集 2021/08/06