b站不滋瓷markdown真的好麻煩

前往我的博客獲得更好的markdown瀏覽體驗(yàn)以及更為長(zhǎng)期的更新支持：

https://fallenbreath.me/2019/12/08/deeply-dissecting-minecraft_1

修訂#1：2020-11-07

1 游戲流程

1.1 代碼層面上的 GameTime 內(nèi)游戲運(yùn)算順序

下圖這張樹(shù)狀剖析圖，代表了代碼層面上，Minecraft 每執(zhí)行一次?tick()?時(shí)的游戲執(zhí)行順序：

如讀者感興趣，這里（見(jiàn)原文）是1.15.2版本的流程分析圖

1.2 GameTick

GameTick（gt），也就是游戲刻，或者說(shuō)游戲里的時(shí)間量，是用來(lái)衡量電路延遲、生物生存周期等的重要指標(biāo)。要想明確 GameTick 是什么，就先得給出 GameTick 的定義

作為一個(gè)離散的時(shí)間量，在游戲的運(yùn)算過(guò)程中一定存在某個(gè)時(shí)刻，GameTick 這個(gè)時(shí)間量發(fā)生改變，這就是 GameTick 的分界線。在 1.1 節(jié)，我們從代碼執(zhí)行順序的角度列出了游戲的運(yùn)算順序。在這個(gè)長(zhǎng)達(dá) 24 條的列表里，我將 GameTick 的分界線的劃分在：GameTime 與 DayTime 加一，并給出GameTick的定義：

GameTick 為 x 的定義是：所有執(zhí)行?World.worldInfo.getGameTime()?得到的返回值為 x 的時(shí)刻的集合

于是，我們可以得到事件P發(fā)生于GameTick x的定義：

一個(gè)事件P發(fā)生于 GameTick x 的定義為：
發(fā)生事件P時(shí)若執(zhí)行World.worldInfo.getGameTime()，得到的返回值為 x

這樣做定義 GameTick 的好處有：

• 與 TileTick 元件的執(zhí)行時(shí)間相對(duì)應(yīng)。在 GameTick N 觸發(fā)的 x gt 延遲 TileTick 元件會(huì)在 GameTick N + x 執(zhí)行動(dòng)作

• 可以直觀地在代碼中調(diào)用?World.worldInfo.getGameTime()?來(lái)確定當(dāng)前的 GameTick

定義完 GameTick 并確定好分界線后，我們就可以重新排列 1.1 節(jié)的樹(shù)狀圖，并獲得一個(gè) GameTick 內(nèi)各階段發(fā)生的順序了：

對(duì)于與修改服務(wù)端世界相關(guān)的操作所在的階段，即樹(shù)狀圖中使用黃色標(biāo)出的階段，可歸納得到下常用階段順序表：

這個(gè)常用階段順序表是之后分析最為常用的列表，劃重點(diǎn)記筆記?。ㄆ鋵?shí)只要記住縮寫即可，因?yàn)橄挛臅?huì)大量使用縮寫）

對(duì)于之后對(duì)精確到一個(gè)游戲刻內(nèi)階段的分析，我稱之為：微觀時(shí)序分析

1.3 游戲事件執(zhí)行時(shí)刻

這一章節(jié)的目的是概述各大部分游戲事件運(yùn)作的時(shí)刻，其中性質(zhì)的詳細(xì)描述見(jiàn)后文

在1.2里，存在以下幾個(gè)游戲階段為抽象的階段，并未明確聲明在其中會(huì)發(fā)生什么事件。它們是：?

• 計(jì)劃刻 TT?

• 方塊事件 BE?

• 方塊實(shí)體 TE?

• 玩家操作 NU

下面列一下大部分與之相關(guān)的游戲事件

• 中繼器、比較器、紅石火把、偵測(cè)器的激活與熄滅：TT

• 按鈕、壓力板、紅石燈、絆線、絆線勾的激活：瞬時(shí)；熄滅：TT

• 拉桿、紅石線、鐵軌、各類活版柵欄木鐵門、漏斗、音符盒、投擲器發(fā)射器的激活與熄滅：瞬時(shí)

• 投擲器發(fā)射器的工作：TT

• 命令方塊的運(yùn)作：TT

• 樹(shù)葉、流體、腳手架的更新：TT

• 重力方塊判定并創(chuàng)建重力方塊實(shí)體：TT

• 活塞推拉的開(kāi)始：BE

• 移動(dòng)中方塊的運(yùn)算：TE

• 移動(dòng)中方塊的到位：BE（粘性活塞受短脈沖）；TE（粘性活塞受長(zhǎng)信號(hào)）

• 玩家移動(dòng)、放置破壞方塊、與方塊交互：NU

注：瞬時(shí)指的是可屬于任意階段，觸發(fā)即運(yùn)算，且觸發(fā)與運(yùn)算之間無(wú)法插入其他操作

實(shí)例 自加載型區(qū)塊加載器偽和平

對(duì)于基于在卸載后能加載回自身的區(qū)塊加載器的偽和平，在重加載時(shí)是否存在 1gt 的刷怪空檔期是至關(guān)重要的，因?yàn)檫@直接與偽和平是否可用 100% 阻止生物刷新相關(guān)。完美的偽和平裝置是不存在可刷怪空檔期的

讓我們分析一下基于活塞區(qū)塊加載器的偽和平：

活塞區(qū)塊加載器，利用了方塊事件可以加載區(qū)塊的原理，通過(guò)在每個(gè)gt利用活塞計(jì)劃方塊事件來(lái)確保自動(dòng)保存后能加載回自身區(qū)塊。

備注：此活塞加載器并非完美設(shè)計(jì)，但足以應(yīng)用于本實(shí)例分析

這個(gè)方案是可以 100% 阻止生物刷新的，也就是不存在 1gt 的刷怪間隔。微觀時(shí)序分析很簡(jiǎn)單。先列一下相關(guān)的階段：

可看到，在自動(dòng)保存等引發(fā)的區(qū)塊卸載之后，下一次進(jìn)行刷怪前，游戲執(zhí)行了方塊事件相關(guān)的運(yùn)算，并在此處加載回了存怪的區(qū)塊，讓怪物容量超過(guò)上限，阻止下一次進(jìn)行刷怪時(shí)的生物刷新。因此，這是一個(gè)完美的偽和平

如果出于某些原因，活塞區(qū)塊加載器與存怪裝置不在同一個(gè)區(qū)塊，需要使用漏斗加載存怪區(qū)塊，如下圖所示。這樣的話這種偽和平裝置是否還是完美的？

相關(guān)的階段：

讓我們看一下這個(gè)設(shè)計(jì)的區(qū)塊被卸載時(shí)的微觀時(shí)序

因此，這個(gè)偽和平設(shè)計(jì)也能保證 100% 時(shí)刻不刷怪，是個(gè)完美的偽和平

假如有個(gè)小天才嫌一個(gè)漏斗太少，非得多串幾個(gè)漏斗才接到存怪裝置區(qū)塊，那會(huì)怎么樣？

區(qū)塊卸載在 GameTick N，活塞加載器自加載在 GameTick N+1 的 BE，三個(gè)漏斗依次加載區(qū)塊使存怪區(qū)域在 GameTick N+1 的 TE 被加載？并不是這樣的

TE 階段有個(gè)性質(zhì)：在 TE 階段內(nèi)新增的 TE 實(shí)體，并不會(huì)立即參與運(yùn)算，而是會(huì)先加入一個(gè)臨時(shí)的列表?addedTileEntityList，等到該 TE 階段運(yùn)算結(jié)束后再統(tǒng)一添加新 TE 實(shí)體至參與運(yùn)算的 TE 列表?loadedTileEntityList?中，也就是說(shuō)在 GameTick N 新增的 TE 實(shí)體要等到 GameTick N+1 的 TE 階段才能進(jìn)行運(yùn)算

因此，這個(gè)小天才活塞區(qū)塊加載器偽和平的微觀時(shí)序是這樣的：

因此這個(gè)偽和平方案在每次被卸載時(shí)，足足有 2gt 的刷怪空檔期，不是一個(gè)完美的偽和平方案