教學/基岩版開發指南

可列印版不再被支援且可能有渲染錯誤。請更新您的瀏覽器書籤並改用瀏覽器預設的列印功能。

此特性為基岩版獨有。

此處提供的指南是為了使創作者得到為Minecraft創作內容時的較好體驗的一種最佳操作。它將有助於確保作品可以工作，並且在應對遊戲中的變化時具有高效性和彈性。

總指南

從世界和包的目錄中移除所有與內容無關的檔案。
- 不要在包中存放包，或存放Windows或Photoshop檔案。它們中的任意一種都會在讀取、匯入或載入內容時導致出錯。
- 在發佈之前從內容中移除任何未使用的資源。
- 這能夠保證在將內容縮減到最小的同時減少內容驗證失敗的可能性。
此外，如果原版檔案被修改，這樣做對你的內容來説不會造成意外的變更。
不同的平台有不同的路徑長度限制。算上包或世界的路徑，平台會計算匯入到Minecraft裡的目錄長度。如果長度超出限制，包會匯入失敗並且會變成無效狀態。正因如此，我們建議：
- 保持路徑長度為70字元或更少，即從包或世界模板的根目錄到一個檔案的最長路徑長度應該只能有70字元長。
- 路徑中的每一部分（目錄或檔案名）必須小於60字元。否則，一些平台將無法識別這一部分。
- 資源包或行為包的目錄名應該小於10字元長。這樣可以使創作者可以寫更長的檔案或子目錄名。例如， bp_mw 有如下目錄：
  - MyWorld/behavior_packs/bp_mw

定義檔案

例如blocks.json、mobs.json、sound_definitions.json以及其他位置的定義檔案包含了原版中所有元素的定義。請確保你的包只包含那些需要變更的元素和字段。這意味着：不要直接複製/粘貼所有原來的定義，然後只變更需要變更的那一段，而是僅需要保留檔案中需要變更的那一段。遊戲會自動將這些變更與原版的檔案合併。
- 如果需要變更的之外的某些部分也被留在了檔案中，而原版的方塊或生物在遊戲版本更新時發生了變更，那麼那一段就會造成內容裡不必要的變更。

以下檔案不應該改寫，除非你有意變更此內容。它們還沒有獲得官方的支援，但是如果你的修改可行，也可以在至少同版本正常執行。因此無法保證所做的變更會正常工作或在未來依舊能工作。

credits/end.txt
font/emoticons.json
texts/language_names.json
items_client.json
items_offsets_client.json
shaders目錄裡的任何檔案

注:shaders資料夾內檔案為HLSL或GLSL語言編寫

函數

使用子目錄來建立命名空間，以避免多個行為包的函數檔案之間的衝突。如果一個函數的路徑（以/functions/subdirectory開頭）與另一個包一個函數的路徑完全吻合，那麼在包棧中靠近頂部的包會覆蓋其他的包。
為了減少你的函數在特定平台上無法工作的概率，請用使用小寫字母且不留空格的方式來命名你的目錄和函數檔案，例如/functions/awesome_pack/level1_function.mcfuntion。
請謹慎地使用遞歸。儘管遞歸是支援的，當遞歸很深的時候它依舊會導致一些效能問題。
在你行為包清單檔案的「min_engine_version」之後輸入你目前開發所處的遊戲版本，例如"min_engine_version" : [1,8,0] 。
- 這樣你就可以控制使用哪個版本的命令來保證向後相容性。
如果你的命令方塊只執行函數，那麼修改他們就會變得簡單很多。更重要的是，如果你發佈了一個包含函數檔案的新的行為包，那麼使用那個行為包的世界也會在新包應用時立馬得到更新。
最後一個關鍵點是説明性的：目前的基岩版尚未支援條件分支（例如execute (if unless)），但是它可能會在未來加入到遊戲中。

命令

請避免每刻都執行命令。尤其重要的是不要每刻都執行大量的命令。
- 儘量不要在每刻執行超過30條命令。
- 如果需要頻繁執行命令，可以考慮把它們放到一個時鐘循環裡，這樣它們可以每5+刻執行一次。
- 如上面所説，如果你設定了偏置時鐘使得命令在不同的刻上執行，那麼就可以平衡你的工作並獲得更佳的效能。
- 獲知你內容的效能是否是由於命令過多而表現不佳的一個簡單方法就是使用commandblocksenabled遊戲規則來關閉所有命令方塊的執行。
請儘可能地不要使用長時命令（例如覆蓋區域很大的/clone或/fill）。如果可以的話，請把它分開並在不同的刻執行。
不要在目標選擇器中使用物品的本地化名字，例如/testfor @e[name=beacon]。
- 如果玩家來自不同語言區，那麼物品的名字可能會改變而後命令將無法工作。

模型

具有許多微小部件的模型在低端裝置和某些GPU上效能可能會很差。請在細節與效能之間推敲出適當的平衡。

聲音

在流上只播放長時聲音，例如背景音樂。
- 可以獲得遊戲內更佳的效能。
- 一些平台在同一時間只能打開一定數目的檔案，在流上播放所有的聲音可能會因內容過多而導致遊戲崩潰。
短時聲音（例如音效）在記憶體上載入會有最佳效能。
使用一些小技巧來縮小你的檔案，例如從開頭和結尾移出所有的靜音部分
有一個標識load_on_low_memory可以用於聲音的定義裡。這個標識預設設為false，這意味着如果此時計算機記憶體較低，它就不會再載入任何聲音。如果對於某個特定的聲音來説，它必須得到載入，那麼就把這個標識設為true。請權衡利用這一特性。
基岩版音效檔案為FSB格式，如果條件有限，可以轉碼成OGG格式後直接重新命名成FSB檔案。

UI

所有UI的修改都是有風險的。如果原版的界面以某種形式被修改，那麼使用這個界面的內容就有可能崩潰。UI系統是以一種有助於我們能靈活地透過JSON檔案修改界面的方式設計的。任何對UI的JSON檔案的變更（在一個自訂的資源包裡）都會和原版的檔案合併。如果合併過程不正確則遊戲可能會進入一種不佳狀態。
重新繪製UI貼圖，即修改他們所使用的紋理，這樣風險就會小很多，並且能做出一些更漂亮的元素。
重新編輯元素的尺寸以及移動它們風險更大，但是在大多數情況下還是可行的。
改變一個界面中的元素本身具有破壞性的高度風險。

修改UI示例

下面是一些示例，它們介紹了如何在不完全複製整個界面的前提下修改一個UI定義檔案。下面以附魔台界面檔案（enchanting_screen_pocket.json）的一部分為例。

示例1: 減少變數

不要包含那些無需變更的變數。例如，如果"color"和"shadow"是要變更的，那麼就不要把其他的變數複製/粘貼到這裏。只需要聲明那些需要替換的變數就可以完成簡單的所需要的變更。

不佳的複製/粘貼法：

   "generic_label": {
       "type": "label",
       "color": "$pocket_title_text_color",
       "anchor_from": "center",
       "anchor_to": "center",
       "shadow": false
   },

更好的例子：

   "generic_label": {
       "color": "$pocket_title_text_color",
       "shadow": false
   },

示例2: 繼承

無需重新聲明正在修改的控件所繼承自的控件。僅聲明正在修改的控件名即可。在下面的代碼中，"common.button"就可以跳過不寫：

不佳的例子：

   "enchanting_confirm_button@common.button": {

較好的例子：

   "enchanting_confirm_button": {

示例3: 修改子控件

以同一個按鈕為例，如果只需要修改該控件的子控件中的一些特定的變數，例如，default控件。僅修改一個控件的子控件請使用control_name/child_name語法。所以與之這樣寫：

   "enchanting_confirm_button@common.button": {
       "controls": [
         { 
           "default@enchanting_pocket.confirm_default_control": {
             "type": "image",
             "texture": "textures/ui/button_borderless_light" //Added fancy button texture to default control
           }
         }
       ]
   },

不如這樣寫：

   "enchanting_confirm_button/default": {
       "texture": "textures/ui/button_borderless_light" //Added fancy button texture to default control     
   },

示例4: 修改陣列

這個示例將展示如何修改一個控件中的陣列。例如：加入一個新的控件作為子控件或從一個控件的綁定中移除一個綁定。就該例來説，有一個叫"modifications"特殊的變數。對modifications陣列裡的每一條記錄，可以指定一個特定的陣列去修改、操作並輸出結果。

以"enchanting_book_panel"為例，如果需要在"controls"陣列裡加入一個控件，就可以加入一個modifications陣列，陣列中指定了"array_name": "controls"、"operation": "insert_front"和"value"，其中最後一個中可以填入新的控件，新控件就會如同被放到了controls 陣列裡一樣。下面的例子展示了上面所説的內容以及偏移量的變更。

   "enchanting_book_panel": {
       "offset": [ -4, 1],
       "modifications": [
       {
           "array_name": "controls",
           "operation": "insert_front",
           "value": [
           "panel_outline@beacon_pocket.panel_outline": { "layer": 0 }
           ]
       }
       ]
   }

要從"player_level_label"子控件中移除"#player_level_color"綁定，可以進行如下操作：

   "enchanting_book_panel/player_level_label": {
       "offset": [ 0, 10 ],
       "layer": 3,
       "color": "$experience_text_color"
       "modifications": [
       {
           "array_name": "bindings",
           "operation": "remove",
           "where": {
           "binding_name": "#player_level_color"
           }
       }
       ]
   }

世界

生物

不要一次生成過多的實體。根據裝置的不同，如果在同一時間有過多的實體更新，效能可能會很差。

紅石

只要有可能，就一定不要讓紅石元件在區塊邊界處互動。

遊戲是有能力處理大部分這種情況的，然而，的確有些例子表明當區塊的載入和紅石元件更新發生矛盾時，的確會引起一些元件失去它們狀態並破壞電路直到它們被重新放置。
紅石元件包括所有可以產生、傳遞或消耗紅石訊號的方塊，例如：
- 按鈕
- 命令方塊
- 比較器
- 發射器
- 漏斗
- 拉桿
- 偵測器
- 活塞
- 路軌：啟動型、探測型和充能型
- 紅石線
- 中繼器
- 以及其他

常載入區域

不要過度使用常載入區域。
- 這對低記憶體裝置尤其重要。
如果可以，在不使用常載入區域時請卸載它們。
- 這可以使得裝置回收一些記憶體，也可以為所需要的新的常載入區域騰出空間。

參見

語言

English

Minecraft Wiki