GameTest 是 Minecraft 基巖版實(shí)驗(yàn)性功能中的一個(gè)致力于提高測試效率的模塊，允許玩家借助 JavaScript 腳本+ Minecraft 結(jié)構(gòu)、以更便捷的方式定義測試單元，驗(yàn)證自己創(chuàng)作內(nèi)容中的邏輯。

舉例來說，假設(shè)你想測試「生物 A 會主動(dòng)攻擊生物 B」，就可以建造一個(gè)封閉空間、導(dǎo)出為 Minecraft 結(jié)構(gòu)，然后用 JS 腳本使用這個(gè)結(jié)構(gòu)、在其中生成生物 A、生物 B，經(jīng)過一段時(shí)間后再檢測生物 B 是否死亡，得出測試結(jié)論。

為了方便創(chuàng)作者用 JS 腳本定義測試邏輯，官方提供了很多 API 接口、包括不少可監(jiān)聽的事件，這也使得 GameTest 具備了 Mod API 的潛力、備受社區(qū)關(guān)注。

為了更進(jìn)一步普及社區(qū)對 GameTest 的認(rèn)知，我在這篇文章中翻譯了官方此前的?Q&A，通過這一系列內(nèi)容，你將對 GameTest 的背景、后續(xù)發(fā)展有更具體的了解。

領(lǐng)域服

• 問：GameTest 能運(yùn)行到領(lǐng)域服上嗎？

• 答：可以

QuickJS vs V8

• 問：相比于其他 JS 的選擇比如 V8，為什么會選擇 QuickJS？QuickJS 比其他的速度慢很多（很有可能是因?yàn)樯倭?JIT），而且在一些社區(qū)中用它也被認(rèn)為是一個(gè)下策。

• 答：我們中有一些人在過去的項(xiàng)目中用過 QuickJS，它很易于集成。我們已經(jīng)了解過 V8（以及其他的），未來也可能會遷移過去。JIT 很有吸引力，但可惜的是并沒有全平臺的支持。

文件與網(wǎng)絡(luò)權(quán)限

• 問：GameTest 以后會有文件或網(wǎng)絡(luò)的接口嗎？

• 答：通常情況來說，我們希望對腳本 API 加以限制，隨著時(shí)間逐步增加功能。考慮到文件和網(wǎng)絡(luò) API 需要權(quán)限、以及游戲擁有者的許可，這類接口可能不會在默認(rèn)的接口中提供，但我們可能會在將來的某個(gè)時(shí)間加入這些功能（比如開放給服主）

• 問：所以說這類接口只會在部分平臺實(shí)現(xiàn)？

• 答：我們會努力讓 API 支持全平臺，除非我們引入了一些針對編輯器的 API，那類會限于 PC 端。

指令

• 問：我們什么時(shí)候可以注冊自定義的指令？

• 答：盡管我們還沒有確定具體的時(shí)間，但這在我們的待辦中是高優(yōu)先級的。

• 答：當(dāng)人們開始制作他們自己的指令時(shí)，很顯然我們是需要這方面支持的。

原版測試

• 問：你們現(xiàn)在是在用 GameTest 框架測試原版的行為包嗎？或者換個(gè)問題，你們在自己的內(nèi)容中是怎么用測試 API 的？

• 答：是的！我們現(xiàn)在有很多用于原版內(nèi)容的測試，也想持續(xù)拓展更多測試。實(shí)際上我們在公開版本中就已經(jīng)外放了一些我們所用的原版測試（vanilla_gametest）

時(shí)間線

• 問：能否透露 API 接下來有什么計(jì)劃中的事件嗎？

• 答：因?yàn)槲覀兊膱F(tuán)隊(duì)還在評估接下來要加入什么事件，所以目前還沒有可以分享的時(shí)間線，你們有什么想看到的新增事件嗎？

• 答：非常同意，破壞/放置方塊確實(shí)應(yīng)該優(yōu)先考慮。

GameTest 政策

• 問：崛起的是 GameTest API 而不是原先的腳本 API，這背后有什么技術(shù)、結(jié)構(gòu)或政策上的原因嗎？能否說明下這次「你做了什么不一樣的」？另外，對于 GameTest 來說怎樣算是「成功」（而不至于被廢棄），有什么我們能做的嗎？

• 答：通常來說，我們會專注于我們的目標(biāo)場景，也就是從內(nèi)容的測試驗(yàn)證開始，既包括 Minecraft 原版的、也包括自定義內(nèi)容的測試。我們真心希望，能讓大家更便捷的為自己的內(nèi)容搭建測試。而這種場景下的需求也更有限（比如我們可以選擇更少的平臺、性能也不是什么大問題），因此，為了讓 GameTest 成功，我們希望看到內(nèi)容創(chuàng)作者們能更便捷的測試他們的內(nèi)容。

• 答：當(dāng)然，我們確實(shí)看到了 GameTest 在未來更多場景下的潛力，包括玩法。但我們不想拉高任何人的期待（或者讓人們在用腳本/gametest API 做玩法這件事上押注），我們還有很多要驗(yàn)證的，像是性能、多平臺支持，同樣也包括對你們反饋的回應(yīng)。

• 答：回復(fù)一下「有什么是你們能做的」，持續(xù)參與、幫助我們改善和添加新東西！創(chuàng)作者的社區(qū)就是這一切的驅(qū)動(dòng)力。

主機(jī)

• 問：為什么主機(jī)上無法運(yùn)行 gametest？主機(jī)平臺未來最終是否會支持 gametest API？

• 答：會的！我們計(jì)劃是支持全平臺，我們 JS 引擎所需的 API 在一些平臺上是缺失的，比如 `aligned_alloc`，我們正在積極推動(dòng)這些平臺上的支持。

更多編程語言

• 問：GameTest 以后會支持不同的語言嗎？

• 答：基本來說，我們已經(jīng)實(shí)現(xiàn)了適配其他編程/腳本語言所需的綁定層。我們也在內(nèi)部嘗試了一些有趣的事情，比如配合 Lua，甚至是像 Blockly 這樣的可視化編程語言，但我覺得在當(dāng)下，我們還不能承諾會為其他語言提供任何官方支持。

• 問：你們有考慮過 Kotlin 嗎？

• 答：我對 Kotlin 的了解還比較少（我們所有的安卓平臺仍然是用 Java 編寫的），但聽起來不錯(cuò)！我會去看看的。

事件系統(tǒng)

• 問：數(shù)據(jù)驅(qū)動(dòng)（data-driven）里面已經(jīng)有一套事件系統(tǒng)了，從你們的角度來看，GameTest 框架中的事件系統(tǒng)和數(shù)據(jù)驅(qū)動(dòng)中的，兩者之間是怎樣的關(guān)系？未來是否會提供一個(gè)連接兩者的接口？

• 答：我們希望這兩個(gè)系統(tǒng)能共處，如果你熟悉數(shù)據(jù)驅(qū)動(dòng)，我們希望你也能以一種有意義的方式步入腳本，這方面我們還在摸索。

哪些是不會做的？

• 問：你們是否方便分享「不做的清單」里有哪些東西？（已經(jīng)經(jīng)過你們討論，單方面決定不實(shí)現(xiàn)的）比如你們不會去支持的某些設(shè)備、或是 API 發(fā)展避開的方向，什么都可以

• 答：這個(gè)問題問得很好，在我們「絕對不做」的清單上幾乎沒有列多少東西

• 答：在我們「萬分小心」的清單上有這些：

• 網(wǎng)絡(luò)權(quán)限

• 文件權(quán)限

• 平臺限定的 API

• 答：就網(wǎng)絡(luò)權(quán)限來說，我們可能會允許通過非常結(jié)構(gòu)化的 API 訪問特定的目標(biāo)，文件也是：我們可能會有一些持續(xù)性儲存，但不是自由格式的文件。

• 答：平臺限定的 API 也是我們想避免出現(xiàn)的，但我們可以想象為編輯器類場景實(shí)現(xiàn) PC 端限定的 API，不過我們會在玩法和 GameTest 的場景中避免這種事。

• 答：我想說的還有一件事，自定義著色器真的很難。PlayStation 要求在提交時(shí)內(nèi)置著色器，因此我們不得不提供一套基于物理的材質(zhì)系統(tǒng)，將非常靈活的著色器硬編碼。

• 問：剛剛提到了「持續(xù)性儲存」，意思是我們以后會有辦法通過單獨(dú)實(shí)例的方法、讀寫簡單的整型變量嗎？或者說還是在實(shí)例中、運(yùn)行結(jié)束時(shí)被刪除？

• 答：是的，我們有計(jì)劃加入像 Json 這類的鍵值對存儲。屆時(shí)就可以通過 JavaScript API 訪問標(biāo)簽、記分板，更進(jìn)一步可以允許常規(guī)的讀寫儲存（但還不是直接的文件系統(tǒng)訪問權(quán)限）。我們需要解決一些安全問題，確保每個(gè)包的存儲都是沙箱。

自定義維度

• 問：如果有自定義維度的話，GameTest 是否計(jì)劃支持？

• 答：設(shè)計(jì) GameTest API 的過程中，我們一直有在考慮自定義內(nèi)容。這也是為什么 Commands.run 所需的維度是字符串、而不是硬編碼的維度變量這樣的信息。毋庸置疑，我們對 GameTest 與自定義維度集成的可能性保持開放，對其他自定義內(nèi)容也是一樣。

舊的腳本 API

• 問：舊的腳本 API 會怎么辦？仍然可用但不會再更新了嗎？（一直支持下去）

• 答：原先的腳本 API 還會保持可用（并且你也已經(jīng)注意到了，它最近幾乎沒有更新了），考慮到隨著 GameTest API 和其他玩法邏輯系統(tǒng)的發(fā)展，它們有可能會覆蓋腳本 V1 的功能范疇，我們之后也會移除腳本 V1 的功能。

• 答：舊的腳本 API 是實(shí)驗(yàn)性的，因此幾乎沒有向后兼容的保證。另外，舊的腳本 API 沒法用在移動(dòng)設(shè)備上，在這個(gè)時(shí)間點(diǎn)上，我們也不會拓展它的平臺支持。

• 答：我們確實(shí)想支持像 UI 這樣的客戶端體驗(yàn)，我們已經(jīng)有了一些實(shí)現(xiàn)的想法，但還沒有確定的計(jì)劃。

世界生成

• 問：有沒有計(jì)劃在 GameTest 中放出世界噪波（world noise）？JS 有噪波的庫，但需要的是能用在群系生成、MoLang 查詢。

• 答：我們還沒想好要怎么將世界生成放入腳本，區(qū)塊生成是在任務(wù)線程上運(yùn)行的，現(xiàn)在我們的 GameTest 實(shí)現(xiàn)也不支持安全的遷移到其他線程。我們有想過創(chuàng)建類似 web worker 東西，但僅限于此。

GameTest BDS

• 問：GameTest 以后能在 BDS 上流暢運(yùn)行嗎？

• 答：我們目前就在我們的 CI 管線中使用了 BDS 運(yùn)行 GameTest、驗(yàn)證結(jié)果！

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

• 答：如果 GameTest 不生效，有一個(gè)可能的原因就是世界沒有開啟實(shí)驗(yàn)性功能，而這在專用服務(wù)器上是有難度的。目前最簡單的方法是先用一個(gè) Minecraft 客戶端，在開啟 GameTest 實(shí)驗(yàn)性功能的情況下生成世界，然后再將這個(gè)世界轉(zhuǎn)到專用服務(wù)器上。

學(xué)習(xí) JS

• 問：我剛開始學(xué) JavaScript，有什么推薦編程新手學(xué)習(xí) GameTest 的參考資料嗎？就學(xué)習(xí) GameTest 來說，不是通用的 JS。

• 答：酷！JavaScript 很適合入門編程。

• 答：我們有一篇很簡短的文章，講了如何搭建你的第一個(gè) GameTest：https://docs.microsoft.com/en-us/minecraft/creator/documents/gametestbuildyourfirstgametest

• 答：未來還會有更多這方面的內(nèi)容！

• 答：注意：如果你想?yún)⑴c貢獻(xiàn)這些指南，我們也會很樂意的。

beta BDS

• 問：有沒有計(jì)劃公開發(fā)布 BDS 的 beta 版？這樣有助于我們更好的調(diào)試、診斷 GameTest 中的問題。

• 答：感謝建議，我很樂意那么做，我會跟進(jìn)我們的發(fā)布管理團(tuán)隊(duì)、評估這方面的可行性。

NPM

• 問：GameTest 能支持 npm 庫嗎？

• 答：原生來說，我們是不支持 NPM 庫的，但我們在用 WebPack 「烘焙」包體時(shí)也取得了一些有限的成功。

• 答：另外！我們的官方 TypeScript 綁定快發(fā)布了，我們已經(jīng)在此分享過了一些早期的版本，但我們離發(fā)布也已經(jīng)很近了。

• 問：GameTest 以后會有像 npm 這樣的包管理器嗎？

• 答：我們考慮過這方面，但這確實(shí)是不小的工作量。我們會持續(xù)考慮的，隨著越來越多人開始用起腳本，我們也將看到一些自然的開發(fā)模式出現(xiàn)，我們也會朝著那些模式傾斜。

GameTest 的終極目標(biāo)

• 問：GameTest 的終極目標(biāo)到底是什么？它會一直作為一個(gè)測試工具，還是會進(jìn)一步拓展，比如能添加全新的內(nèi)容？

• 答：就 GameTest 來說，我們致力于簡化內(nèi)容的測試和驗(yàn)證，我們希望大家能更便捷的為自己的內(nèi)容、裝置、腳本搭建測試。為了做到這些，我們所做的其中一部分就是通過 GameTest 模塊提供豐富的腳本 API，方便用于模擬和測試斷言。我們會持續(xù)添加一些新的 API，也會在 GameTest 中加入一些能在環(huán)境中模擬玩家的酷炫方法。此外，我們也在想方設(shè)法簡化創(chuàng)建這些 JavaScript 測試的工作。

• 答：當(dāng)然，這個(gè)過程中 GameTest 也帶來了讓人高興的副產(chǎn)物，那就是我們有機(jī)會構(gòu)建更多通用的、基于服務(wù)端的腳本 API，這也有助于我們在未來的場景中探索它的應(yīng)用潛力。

實(shí)驗(yàn)性模塊

• 問：你們在過去曾經(jīng)表示過所有指令都有望成為 API，如果現(xiàn)在有一個(gè)實(shí)驗(yàn)性特性，它是否會有 API 支持？如果有的話，是會放在一個(gè)實(shí)驗(yàn)性模塊里？

• 答：我們當(dāng)然希望能有針對實(shí)驗(yàn)性特性的 API，但我們還沒有決定好具體要怎么做?？赡苁且粋€(gè)單獨(dú)的模塊，類似 mojang-minecraft-experimental 這樣的？就像 C++ 在實(shí)驗(yàn)性命名空間中處理未標(biāo)準(zhǔn)化類型的做法。

開發(fā) GameTest API 的工作

• 問：開發(fā) GameTest API 的工作中最酷的是什么？有沒有什么實(shí)現(xiàn)起來特別有滿足感/有趣的設(shè)計(jì)決策，或是技術(shù)要素？

• 答：個(gè)人而言，就是為了引入多腳本語言支持，創(chuàng)建了一個(gè)綁定層+消費(fèi)者

• 答：設(shè)想是每個(gè)包都可以選擇要用什么腳本運(yùn)行時(shí)（script runtime）

• 問：贊！未來我們可能支持 Python 嗎？

• 答：在一次 Game Jam 中，我確實(shí)用某種黑科技讓 Python 2.7 跑起來了，但我們目前還沒有這方面的產(chǎn)品計(jì)劃。

API 覆蓋面

• 問：現(xiàn)有的一些方法（method）會增加對玩家的支持嗎？比如 item stack

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

• 答：注意：現(xiàn)有的 API 還只是一小部分，我們會逐步添加更多的。

GameTest 替代命令方塊

• 問：GameTest 會替代命令方塊嗎？

• 答：我不太能理解為何它會替代命令方塊，但我能理解的是，GameTest 將很多「繁重的邏輯」遷移到了腳本，理論上它們兩者會緊密合作（不妨試想一下，你在腳本里注冊了一個(gè)自定義指令，然后用一個(gè)命令方塊執(zhí)行它）。

教育版 Code Builder

• 問：有沒有計(jì)劃讓 GameTest API 更好上手一些，比如像教育版的 code builder 那樣？

• 答：我們已經(jīng)在嘗試讓 GameTest 支持像 Blockly（可視化編程）這樣的東西，雖然目前還沒有什么可以透露的，但我覺得還是很酷的！

最有趣的 Bug

• 問：用 GameTest 時(shí)遇到的最有趣的 bug 是什么？

• 答：有一個(gè)不久前發(fā)生的，當(dāng)時(shí)我在測試馴服的 API，我想看看如果我刷出 100 頭狼再馴服會怎么樣……h(huán)ttps://imgur.com/a/NIF7D4x

市場

• 問：GameTest 會對市場產(chǎn)生多大的沖擊？

• 答：就目前來說，GameTest 還屬于實(shí)驗(yàn)性功能，因此沒法包含在市場的內(nèi)容中。我們認(rèn)為在「上架前幫助驗(yàn)證內(nèi)容」的這一側(cè)來說，GameTest 還是很有用的。

領(lǐng)域服

• 問：GameTest 未來在領(lǐng)域服上會如何發(fā)展？它會保留在領(lǐng)域服，還是像舊的腳本 API 那樣被移除？

• 答：我們的打算就是將 GameTest（以及后續(xù)的玩法腳本）帶入領(lǐng)域，因此我們不會想之后再棄用它。

GameTest 的用途是多樣的嗎？

• 問：從社區(qū)的用法來看，大多數(shù)是將 GameTest 作為最終成品的一部分（就像腳本引擎的使用場景），而不是僅僅用于開發(fā)過程中捕捉 bug，你們是否有看到 GameTest 正拓展到更普遍的應(yīng)用，并且逐步成長、被看作是一項(xiàng) addon 所支持的特性？

• 答：目前來說，我們對 GameTest 還是專注于內(nèi)容測試，而不是為了通用的玩法去支持腳本 API。為了能確定腳本 API 應(yīng)該在何時(shí)、以怎樣的方式脫離實(shí)驗(yàn)性功能，承載這些角色，我們需要確保我們在幕后做了足夠多的測試和基礎(chǔ)設(shè)施的準(zhǔn)備。

Molang

• 問：能通過 GameTest API 測試 MoLang 嗎？

• 答：你可以用各種方法測試實(shí)體行為，當(dāng)然實(shí)體也可以在動(dòng)畫控制器和狀態(tài)遷移條件中包含 Molang。

• 問：你有沒有什么想特別說的？

• 答：我應(yīng)該提到過，要想在自定義實(shí)體上使用 GameTest，可以在運(yùn)行 GameTest 時(shí)加載自定義實(shí)體的行為包。

社區(qū)反饋

• 問：添加新的 GameTest 特性時(shí)，是基于 Mojang 的測試需求，還是基于社區(qū)的反饋或需求？這會有所改變嗎？

• 答：當(dāng)然是兩者都有！為了測試一些原版的邏輯，我們一直在添加新的 GameTest API，但我們也想知道你們對什么 API 感興趣。

• 答：自定義指令的 API 就是個(gè)很好的例子，因?yàn)樯鐓^(qū)一直在詢問，這個(gè) API 在我們的待辦中也是高優(yōu)先級的。

• 答：還有一些即將到來的特性，可以讓 GameTest 更強(qiáng)大、更易于創(chuàng)建，比如模擬玩家 API、Visual Studio Code 中的腳本調(diào)試。

各平臺的效率

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

• 答：我們希望能支持全平臺，關(guān)于性能，我們不得不在支持即時(shí)編譯的與不支持的平臺間輾轉(zhuǎn)，因此這也是一個(gè)已知且很大的分析和性能調(diào)優(yōu)領(lǐng)域。

• 問：我所說的「通用效率」指的是這套 API 有多接近內(nèi)核（close to the metal）

• 答：感謝你的澄清，我們的 API 首先會嘗試與數(shù)據(jù)驅(qū)動(dòng)系統(tǒng)相配合，因此它會運(yùn)行在 Minecraft 實(shí)體、物品、方塊、區(qū)塊等抽象級別上。如果你熟悉 Bukkit，我們試著做到的正是類似的抽象級別（再加上一些我們想實(shí)現(xiàn)的客戶端內(nèi)容）

GameTest 這個(gè)名字的由來？

• 問：起 GameTest 這個(gè)名字的原因是什么？

• 答：我們是在 Java 版做過的基礎(chǔ)上做了一些工作，他們搭建了一個(gè)用于測試流程的初版 GameTest 框架。

• 問：接著這個(gè)問題，計(jì)劃中是將整個(gè)系統(tǒng)稱作 GameTest，還是別的什么？

• 答：我認(rèn)為如果我們會拓展到測試場景之外，將整個(gè) JS API 集合稱作 GameTest 是無意義的，你可以在整個(gè) API 的命名中看出這種思想的表達(dá)。

為什么要用 GameTest？

• 問：你們推出 GameTest 的目的是什么？或者說，你們對 GameTest 的用途有沒有什么想法？

• 答：基本來說就是，做游戲測試！允許在游戲中添加測試而不用重新編譯的好工具，有了它我們就可以更快的做測試，社區(qū)的成員們也能在反饋 bug 時(shí)編寫測試了。

• 答：從「讓腳本在 Minecraft 里運(yùn)行」這件事來說，GameTest 也是一個(gè)很好的「試驗(yàn)場」。

GameTest 有什么限制？

• 問：GameTest 有什么限制？

• 答：只有你想不到的！

• 答：好吧，正經(jīng)點(diǎn)說，我們是有一些限制的：結(jié)構(gòu)最大可以是 64x64x64，目前也只能在主世界維度運(yùn)行，但我們想進(jìn)一步拓展。

• 答：我們現(xiàn)在還不支持和玩家的互動(dòng)，但那也在后續(xù)的工作中。

• 答：GameTest 可以用在移動(dòng)端，我們現(xiàn)在也在推進(jìn)唯二的兩個(gè)不支持的平臺：Switch 和 PlayStation。

• 問：在游戲崩潰之前，最多可以嵌套多少層 for 循環(huán)？

• 答：事實(shí)上，這個(gè)問題問得很好，目前來說，如果你用 while(true) 會把游戲停住，但我們通過制作原型、計(jì)劃搭建一個(gè)「看門狗」來檢測并阻止這類情況。

• 答：我們的看門狗原型能做的也不止這些，除了循環(huán)周期以外，它也能監(jiān)控腳本對象的數(shù)量和內(nèi)存。（它也是跨語言運(yùn)行時(shí)工作的，所以很酷）

熱重載

• 問：有沒有什么簡單的方法可以在游戲內(nèi)重載 GameTest API 文件？就像 function 里面的 /reload 指令那樣。支持快速重載的話，真的可以讓調(diào)試和處理事情變得輕松愉快。

• 答：作為一個(gè)寫過一堆 GameTest JS 的人來說，我們的想法和路線圖中絕對會考慮提供一個(gè)更輕松重載 JS 的方法。

文檔

• 問：讓我覺得 GameTest 難上手的原因之一，就是它的文檔難啃。有沒有計(jì)劃讓文檔更通俗易懂一些？這樣大家就能更輕松、由淺入深的理解如何使用這個(gè)框架了。

• 答：我們最近發(fā)布了一個(gè)新的創(chuàng)作者入口，里面就有如何入門 GameTest 的文章。https://docs.microsoft.com/en-us/minecraft/creator/documents/gametestgettingstarted

• 答：因?yàn)?API 的文檔還很新，我們在提供細(xì)致文檔和示例上還有很長的路要走，這些文檔托管在 Github 上，因此如果社區(qū)里有人想貢獻(xiàn)，我們也歡迎發(fā)起 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/]）之前用的名字，是一個(gè)我們正在研究的用于搭建新的基巖版 UI 的 技術(shù)。

• 答：我們當(dāng)然有計(jì)劃讓腳本支持創(chuàng)建或修改 UI，但我們想讓它能和內(nèi)置的 UI 更自然的配合，我們也還在研究具體的做法。

• 答：我們不想在 GameFace JS 那樣的沙箱中運(yùn)行，另外，我們現(xiàn)在主要關(guān)注的是服務(wù)端，而 GameFace 只運(yùn)行在客戶端。

外部腳本

• 問：GameTest 以后能和外部的腳本互動(dòng)嗎？這樣的話就能和其他目錄的腳本通訊了。

• 答：我們確實(shí)想讓腳本能將其他腳本作為依賴項(xiàng)，比如依賴一個(gè)好的測試腳本、或是生成地形的腳本，但那很有可能要借助行為包的依賴系統(tǒng)，我覺得我們目前還沒有辦法從任意位置加載 JS。

• 答：是的，讓外部腳本能跨越全平臺并非易事，安全方面也有潛在的挑戰(zhàn)。

市場

• 問：GameTest 能用在基巖版市場的內(nèi)容嗎？如果能的話，有沒有大概的時(shí)間？

• 答：目前來說，我們還是會專注于測試的場景，盡管我們有很多未來的想法和計(jì)劃，但我們不想讓大家基于我們還沒有承諾的東西做計(jì)劃、或是指望太多。

Discord

• 問：GameTest 以后能將 Discord 連接到 MC 嗎？

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

Java 版限定特性

• 問：我看到有很多原版標(biāo)有 suite:java_parity 的 GameTest 都被禁用了，大概是因?yàn)檫壿嫴簧?，這些測試是否來自 Java 的測試套件？它們的目的是什么？

• 答：我們過去在 Java 中搭建過一些 GameTest 的測試，其中的一些也被遷移過來了。即便 Java 和基巖版存在不共通的特性，我們也想追蹤一部分用于 Java 版的測試。

• 問：如果禁用的這些測試能作為遷移更多 Java 版邏輯的待辦會很棒，我們也能提供更多，哈哈

• 答：如果你編寫了一個(gè)演示 Java 版限定問題的 GameTest，歡迎發(fā)給我們：? https://aka.ms/gametestsamples

• 答：是的，我們在追蹤那些通過 GameTest 發(fā)現(xiàn)有 bug 的版本限定問題。

• 問：如果 GameTest 能以這種方式開放接受貢獻(xiàn)，有沒有什么方式能讓我們貢獻(xiàn)原版行為包/資源包的？

• 答：我們正在討論是否應(yīng)該將「內(nèi)置」的 GameTest 移動(dòng)到同一個(gè)倉庫，以便更輕松的獲取開源的行為包。

參考來源

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