本站文本內容除另有聲明外,均在知識共享 署名-非商業性使用-相同方式共享 3.0 協議下提供。(詳情…本站文本內容除另有聲明外,均在知識共享 署名-非商業性使用-相同方式共享 3.0 協議下提供。(詳情…中文Minecraft Wiki是完全公開的。請勇於擴充與修正內容!中文Minecraft Wiki是完全公開的。請勇於擴充與修正內容!Minecraft中文Wiki微博正在更新!或許有興趣去看看Minecraft中文Wiki微博正在更新!或許有興趣去看看想與其他用戶進行編輯上的溝通?社區專頁正是為此創建的。想與其他用戶進行編輯上的溝通?社區專頁正是為此創建的。翻譯或創建頁面之前,不妨看看譯名標準化Wiki條例頁面。翻譯或創建頁面之前,不妨看看譯名標準化Wiki條例頁面。需要管理員的協助?在管理員告示板留言也許可以幫到您。需要管理員的協助?在管理員告示板留言也許可以幫到您。

教程/基岩版開發指南

出自 Minecraft Wiki
前往: 導覽搜尋
Information icon.svg
此特性為基岩版獨有。

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

總指南[編輯 | 編輯原始碼]

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

定義文件[編輯 | 編輯原始碼]

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

以下文件不應該改寫。它們還沒有獲得官方的支持,因此無法保證所做的更改會正常工作或在未來依舊能工作。

  • credits/end.txt
  • font/emoticons.json
  • texts/language_names.json
  • items_client.json
  • items_offsets_client.json
  • shaders目錄里的任何文件

函數[編輯 | 編輯原始碼]

  • 使用子目錄來創建命名空間,以避免多個行為包的函數文件之間的衝突。如果一個函數的路徑(以/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。請權衡利用這一特性。

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"
           }
       }
       ]
   }

世界[編輯 | 編輯原始碼]

生物[編輯 | 編輯原始碼]

  • 不要一次生成過多的實體。根據設備的不同,如果在同一時間有過多的實體更新,性能可能會很差。

紅石[編輯 | 編輯原始碼]

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

  • 遊戲是有能力處理大部分這種情況的,然而,的確有些例子表明當區塊的加載和紅石元件更新發生矛盾時,的確會引起一些元件失去它們狀態並破壞電路直到它們本重新放置。
  • 紅石元件包括所有可以產生、傳遞或消耗紅石信號的方塊,例如:
    • 按鈕
    • 指令方塊
    • 比較器
    • 發射器
    • 漏斗
    • 控制桿
    • 觀察者
    • 活塞
    • 鐵軌:激活型、探測型和充能型
    • 紅石線
    • 中繼器
    • 以及其他

常加載區域[編輯 | 編輯原始碼]

  • 不要過度使用常加載區域。
    • 這對低內存設備尤其重要。
  • 如果可以,在不使用常加載區域時請卸載它們。
    • 這可以使得設備回收一些內存,也可以為所需要的新的常加載區域騰出空間。

另見[編輯 | 編輯原始碼]