Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

了解更多

Minecraft Wiki
Advertisement

幾乎所有的遊戲(包括 Minecraft)都是由一個大的程式循環驅動的。正如時鐘中的每個齒輪都與鐘擺同步一樣,驅動遊戲仿真所涉及的每個任務都與遊戲循環相同步。相稱地,遊戲循環的一個週期被稱之為一「刻(tick)」

遊戲刻

遊戲的一刻是指 Minecraft 的遊戲循環執行一次所佔用的時間。正常情況下,遊戲固定以每秒鐘20刻的速率執行,因此一刻的時間為0.05秒(50毫秒,或一秒鐘的五百分之一),使得遊戲內的一天剛好持續24000刻,也就是20分鐘。然而,如果計算機無法跟上這個速度,那麼每秒刻數(ticks per second, TPS)會減少。由於絕大多數操作都是基於刻數而非現實中的時間來計時,許多操作在速度較慢的計算機上需要更長的時間。

有一個與每秒刻數(TPS)相關的統計量,稱作每刻毫秒數(milliseconds per tick, MSPT),即伺服器實際用於完成一刻內計算的耗時。只有當MSPT不高於50時,TPS才能維持在20。通常情況下,以下因素是伺服器端卡頓的主要誘因:

  • 漏斗頻繁嘗試檢查其上方是否有物品。用任一含有物品欄的容器方塊或堆肥桶即可停止對物品的檢查。也可以利用更快地運輸散裝物品。
  • 紅石機構。紅石元件,尤其是紅石粉會導致大量的方塊更新和卡頓。停用一些暫不使用的紅石裝置和時鐘有助於緩解卡頓情況。
  • 生物 AI。可以使用照明控制怪物的產生,並使用更高效的技術養殖家畜

在在Java版中,中,MSPT 值在 F3 除錯熒幕中顯示為 「ms ticks」。打開幀生成時間圖表(Alt + F3)時可查看 TPS 值。這兩種顯示都只能在多人遊戲的主機或單人遊戲上可見,因為數據來自 Minecraft 遊戲裏的集成伺服器

遊戲流程

Java版中,遊戲循環的每個週期中。以下行為會依次處理:

  • 執行帶有 tickload 標籤的函數
  • 主世界地獄終界的順序依次對每個維度進行以下流程:
    • 發送時間至用戶端
    • 更新世界邊界
    • 天氣邏輯
    • 玩家睡眠邏輯
    • 若維度為主世界:
      • 增加遊戲內時間和天數
      • 執行計劃內函數
    • 對每個已載入區塊:
      • 發送區塊資訊至用戶端
      • 區塊刻邏輯
    • 嘗試生成夜魅窳民喪屍圍城
    • 發送實體變更至用戶端
    • 嘗試卸載區塊
    • 處理計劃刻
      • 方塊的計劃刻
      • 液體的計劃刻
    • 襲擊邏輯
    • 嘗試生成流浪商人
    • 處理方塊事件
    • 處理實體
  • 處理玩家實體
  • 如果已過去6000刻,嘗試自動儲存
  • 處理來自用戶端的數據包

區塊刻

RandomTickRange

隨機刻的範圍,以草在泥土上的生長傳播所示。注意,草是服從區塊邊界分佈的。中間的紅色和藍色箭頭分別標記 +X 和 +Z 方向。玩家位於區塊的 (7, 7) 位置,略微面朝區塊的西北角,這意味着 -X 和 -Z 方向邊緣上兩個區塊的中心納入了128方塊的半徑內,從而得到區塊刻處理。正北方和正西方邊緣的兩個一區塊面積的草突出證實了這一點。(以上為北)

作為遊戲刻的一部分,每個遊戲刻都會對特定的區塊處理區塊刻。

Java版中,載入類型為強載入(請參見區塊#載入等級其中心與玩家(非觀眾模式)之間的水平距離小於128個方塊的區塊在每次遊戲刻內得到處理。這裏應該注意以下幾點:首先,區塊應當載入成處理實體的區塊。其次,如果區塊接收到區塊刻,即使區塊中的某些方塊超出128個方塊半徑,它們也可以像正常情況一樣接收隨機刻。最後,因為128方塊是水平距離,所以玩家沿 Y 軸的位置無關緊要。

基岩版中,每個遊戲刻內,所有載入的區塊都得到區塊刻處理。以下行為在某個區塊得到區塊刻處理時會發生:

  • 生物自然生成
  • 暴風雨天氣下,閃電可能在區塊內某處生成(1100000的概率)。
  • 每一縱向上的最頂端方塊有 116 的概率檢查天氣更新:
  • 區塊內一定數量的方塊受到隨機刻處理,如下所述。

隨機刻

區塊中每16方塊高度為一節子區塊,也就是説子區塊是一個 16×16×16=4096 方塊大小的一節長方體。各節子區塊從最低的 Y 水平面開始垂直分佈。每個區塊刻隨機抽選區塊內每一節子區塊的一些方塊。被選中的這些方塊會被給予一個「隨機刻」。

Java版中,每一節被抽選的方塊個數可由 /gamerule randomTickSpeed 指定(預設為 3),而且一個區塊刻內可以選中同一個方塊多次。在基岩版中,同樣可由 randomTickSpeed 指定(預設為 1),但是該選項只會確定一個相對的速度,並非實際的數值。

大部分方塊不會受到隨機刻影響,但是以下方塊會利用它做一些事:

因為隨機刻是被隨機賦予的,無法預測某個方塊何時會接收到隨機刻。

Java版中,因為隨機刻是隨機產生的,所以沒有辦法預測一個方塊下一次得到隨機刻的時機。兩次隨機刻時間間隔的中位數47.30 秒 (946.03 遊戲刻)。也就是説時間間隔有 50% 的機率等於或短於 47.30 秒,有 50% 的機率等於或長於 47.30 秒。不過,有時候這個時間間隔會長得多或短得多:比如,時間間隔有 1.38% 的機率會比一秒還短,且有 1.23% 的機率比五分鐘還長。方塊每次更新時間的平均數68.27 秒(1365.33 遊戲刻)。若要了解這些數字背後的數學原理,請查看百科幾何分佈條目。

計劃刻

一些方塊可能會請求在將來的某一個遊戲刻更新方塊,這種更新方塊的方式被稱為計劃刻。在一段時間後必定發生並且行為可以預測的變化,往往使用這種「計劃刻」——比如,紅石中繼器會在Java版中,計劃一刻之後改變其狀態,在需要流動時會計劃一刻。

作為遊戲刻的一部分,已經請求計劃刻的方塊所在之處會得到給定量的刻。

Java版中,計劃刻有兩種:方塊計劃刻和液體計劃刻。方塊計劃刻的處理順序首先取決於優先級,其次取決於計劃順序。優先級越小。執行時間越早。若紅石中繼器指向紅石二極管的背面或側面,則該中繼器將有 -3 的優先級。若中繼器準備熄滅,則優先級為 -2。否則中繼器將有 -1 的優先級。若紅石比較器指向紅石二極管的背面或側面,比較器將有-1的優先級。其他所有方塊的優先級都為 0。方塊計劃刻執行完後,將處理液體計劃刻。液體計劃刻沒有優先級,僅根據計劃順序依次執行。

Java版中,每個遊戲刻內所能處理的最大計劃刻數是65536。在基岩版中,每個遊戲刻內,一個區塊所能處理的最大計劃刻數為100。

紅石刻

一個紅石刻代表了兩個遊戲刻。紅石刻在一個紅石電路訊號中產生 110 秒的延遲;也就是説,從地點 A 到地點 B 的訊號傳輸耗時要增加 0.1 秒。刻只會引起訊號時間的增加,因此一個訊號的傳輸時間永遠不會因為刻而減少。紅石中繼器會帶來 1-4 個紅石刻的延遲。預設的延遲時間為 1 紅石刻,且可以透過在紅石中繼器上的使用物品操作來增加,可由方塊上的滑桿下移看見。

Java版中,紅石刻不是「真實」存在的事物,但是這個由社群創造的術語使得紅石工作更加簡單,因為絕大部分紅石元件都有 2 倍遊戲刻的倍數的延遲。

活塞刻

Information icon
此特性為Java版獨有。

即時更新理論認為活塞啟動的延時為0,實體階段至方塊事件階段屬於一遊戲刻,即以方塊事件階段的結束劃分遊戲刻,這種遊戲刻稱為活塞刻。音符盒發聲的啟動延遲和活塞相同,也是0活塞刻。計劃刻元件按活塞刻計的延時則不固定。

參見

參考

Advertisement