你打的那隻史萊姆，程式碼裡有名字
這些名字通常不會出現在遊戲畫面上，除非你開啟除錯模式、看日誌、或者拆檔案。但正是這些名字，決定了牠會不會在夜晚生成、會不會被岩漿燒死、死掉會不會分裂、掉落的東西是哪一張表。換句話說，你看到的行為，是這些名字在背後投票的結果。
為什麼開發者非要給每隻怪取名字？
答案很樸素：因為程式需要「指向」。存檔要記住這隻史萊姆是什麼、網路要同步這隻史萊姆是什麼、任務系統要知道「打死三隻史萊姆」中的史萊姆是哪一種、掉落表要知道「史萊姆該掉什麼」、成就系統要知道「你殺過幾隻史萊姆」。這些全部都需要一個穩定的識別符。
如果你只用顯示名稱，那遊戲一旦改成英文版，存檔就會壞掉；如果你只用數字，那模組作者就無法擴充。所以成熟的遊戲通常會同時保留好幾層命名：顯示名稱給玩家、內部代號給引擎、數值 ID 給舊系統、標籤給群體判斷。這四層不一定一致，而不一致的地方，就是攻略最容易出錯的地方。
二、拆解一隻史萊姆：從生成到死亡的五個身分
我們把一隻史萊姆從「被生成」到「被殺死」的過程攤開來看，會發現牠同時擁有五種不同的名字。理解這五種名字的分工，你就能看懂大部分的遊戲資料庫。
身分一：實體實例（Entity Instance）
當史萊姆真的出現在你的地圖上時，引擎會給牠一組實例 ID。這組 ID 通常是流水號或 UUID，代表「這一隻」而不是「這一種」。例如你眼前這隻史萊姆的實例 ID 可能是 4582，下一隻可能是 4583。
這個 ID 對玩家的意義在於：它是網路同步與指令操作的對象。當你在遊戲裡用 /tp、/kill、/data 這類指令指定某隻怪物時，你其實是在指定它的實例 ID。很多玩家會困惑「為什麼我打指令殺不到那隻史萊姆」，原因往往是選錯目標選擇器，指到了別的實例。
對攻略作者的意義則是：實例 ID 不能拿來查資料。你在 Wiki 上永遠查不到 4582 這隻史萊姆，因為它是即時產生的。要查資料，你查的是「種類」。
身分二：實體類型（Entity Type）
這才是我們一般說的「史萊姆」在引擎裡的名字，例如 minecraft:slime。它是一個類型層級的識別符，代表「所有史萊姆都共用這個代號」。你打死一隻，統計數字加一；你召喚一隻，引擎就照這個類型去初始化。掉落表、生成規則、音效、材質，全部掛在這個類型底下。
對玩家來說，實體類型是最實用的一層。因為它通常是跨版本穩定的：遊戲改版會改材質、改數值、改掉落，但很少會把 minecraft:slime 改名成 minecraft:goo，因為那會讓所有存檔與模組一起炸掉。所以當你要查資料、寫指令、找模組設定，認的就是這一層。
身分三：程式類別（Class）
再往下一層，是程式碼裡的類別。例如某些遊戲的原始碼中會有一個 SlimeEntity 類別、一個 SlimeRenderer 渲染類別、一個 SlimeModel 模型類別。這些名字不會出現在遊戲資料裡，但會出現在模組文件、開發教學、以及當你反編譯遊戲時看到的程式碼中。
為什麼要知道這一層？因為很多行為是由類別決定的，而不是由資料決定的。例如「史萊姆會不會分裂」這件事，在某些遊戲裡是寫死在類別裡的邏輯，你改設定檔也改不掉；而「史萊姆分裂成幾隻」則可能是資料驅動的，可以改。分清楚哪個是哪個，才不會白花時間改一個根本不讀設定檔的參數。
身分四：資料標籤（Tag）
標籤是一組群體名稱，用來回答「這隻怪算不算某類東西」。例如 #minecraft:slimes 可能包含了所有史萊姆變種，#minecraft:bosses 包含所有 Boss。標籤的用途非常廣：藥水效果、傷害加成、任務條件、成就判定，都常常用標籤而不是用單一 ID。
對玩家的實際影響是這樣的：你以為「打史萊姆有加成」的附魔，其實判斷的是「目標是否帶有 slime 標籤」。如果某隻變種史萊姆忘了被加進標籤，那你的附魔對牠就完全沒用。這類「明明看起來是史萊姆，卻不吃史萊姆加成」的現象，在遊戲社群裡經常被誤傳成 Bug，實際上只是標籤沒補。
身分五：顯示名稱與譯名
最後才是我們看到的名字。這一層最不穩定、最容易被改、也最容易被玩家當成唯一真相。但它在遊戲邏輯裡的地位其實最低——它只是「給人看的那一層皮」。
理解這五層的差別之後，你就會知道：攻略應該以「實體類型」為主軸，以「顯示名稱」為入口，以「實例 ID」為操作對象。這三者的分工清楚了，查資料的效率會直接翻倍。
三、牠是怎麼被生成的？生成規則裡的隱形名字
史萊姆不會無緣無故出現。每一個生成事件背後，都有一組規則在決定「什麼東西、在哪裡、什麼時候、生幾隻」。而這些規則本身的命名，往往比怪物本身更有攻略價值。
生成表（Spawn Table）與權重
多數遊戲會用一張「生成表」來決定某個區域會出現哪些怪物。表裡每一列大概是這樣的結構：怪物 ID、權重、最小數量、最大數量、生成條件。權重越高，越容易被抽到；條件則是「這個怪物能不能被考慮」的門檻。
這裡的重點是：生成表用的名字是實體類型，不是顯示名稱。所以當你想查「為什麼這附近的史萊姆特別多」，你要查的是那張表裡 minecraft:slime 的權重，而不是在討論區問「史萊姆是不是變多了」。前者有數字，後者只有感覺。
另外，很多遊戲會區分「地表生成」「洞穴生成」「特殊生成」好幾張表。同一隻史萊姆可能在這三張表裡都有，但權重不同。只看一張表就下結論，很容易得到錯誤的攻略結論。
生成上限與 mob cap
「為什麼我蓋了生怪塔，史萊姆卻不來？」這題的答案幾乎永遠是生成上限（mob cap）。引擎會計算目前區域內已經有多少怪物，超過上限就不再生成新的。而計算的時候，認的同樣是類型 ID。
這帶出一個很實用的攻略觀念：如果你的目標是特定怪物，你要做的不是「增加生成機率」，而是「減少其他怪物佔用名額」。例如把附近照亮、封住洞穴、清掉其他怪，讓上限名額留給史萊姆。這也是為什麼高效率的刷怪場設計，幾乎都在處理「排除」而不是「吸引」。
生成條件：亮度、高度、方塊、生態域
史萊姆的生成條件在不同遊戲裡差異很大，但通常會牽涉到幾個變數：光照等級、Y 軸高度、腳下方塊、所在生態域、難度設定、以及是否是「史萊姆區塊」。這些條件在程式裡都是有名字的參數，例如 minY、maxY、lightLevel、biomeTag。
攻略實作上，最有效的做法是先把條件列成一張檢查表，然後一項一項排除。因為生成失敗通常不是「全部條件都不對」，而是「某一個條件剛好差一點」——例如亮度多了一格、高度多了一層、生態域差了一個區塊。這些細節在顯示名稱層面完全看不出來，但在參數層面一目了然。
生成後的初始化：Size 與變體
史萊姆生成時通常會附帶一些「個體參數」，例如體型（Size）、顏色、變體編號。這些參數會存在實體的資料標籤裡，而不是存在類型定義裡。也就是說，同一種史萊姆可以有不同體型，而體型會直接影響血量、傷害、掉落與經驗。
這一點對攻略非常重要。很多玩家會說「史萊姆掉黏液球」，但更精確的說法是「只有某個體型以下的史萊姆才會掉黏液球，大型史萊姆打死會分裂成中型，中型再分裂成小型，小型才掉東西」。這中間的差異，全都寫在參數與分裂邏輯裡，而不是寫在「史萊姆」這三個字裡。
四、資料探勘入門：玩家怎麼看到這些名字
接下來是最實作的部分。你可能會想：「我又不是工程師，怎麼可能看到程式碼裡的名字？」其實比想像中簡單，而且大部分方法都不需要寫程式。
方法一：遊戲內建除錯資訊
許多遊戲都有隱藏的除錯介面。例如開啟除錯畫面後，你可以看到目前準心對準的實體類型、實例 ID、座標、資料標籤。這是最快的入門方式，因為你不需要離開遊戲，就能把「眼前這隻怪」對應到「它的內部名字」。
使用時建議搭配截圖紀錄。當你發現某個行為異常——例如某隻史萊姆不會分裂、某隻怪打不死、某個掉落沒出現——先把除錯資訊拍下來，那個類型 ID 就是你後續查資料與回報問題的關鍵字。
方法二：遊戲日誌（Log）
遊戲執行時通常會寫日誌檔，內容包含載入的資源、錯誤訊息、以及有時會記錄的實體事件。日誌裡出現的名字，幾乎都是內部名稱，而不是顯示名稱。這也是為什麼回報 Bug 時，附上日誌片段比附上截圖更有用——因為日誌裡有名字，截圖裡只有「史萊姆」。
看日誌的技巧是：先搜尋你懷疑的關鍵字（例如 slime），再看錯誤訊息的上下文。很多「遊戲崩潰」的真正原因，其實是某個資源檔引用了不存在的名字，例如 entity.mymod.slime_king 找不到對應的語言鍵。
方法三：拆資源包與資料包
現代遊戲大量使用外部資料檔（JSON、XML、CSV）。這些檔案裡通常會有完整的怪物定義、掉落表、生成表。把它們解壓縮、用文字編輯器打開，你就能看到所有內部名稱。這是最完整的資料來源，因為它就是遊戲實際讀取的內容。
拆檔案時要注意兩件事：第一，不要直接改動原始檔案，複製一份出來研究；第二，注意版本，因為不同版本的資料結構可能完全不同，網路上的舊教學常常不適用。建議把拆出來的檔案連同版本號一起備份，方便日後對照。
方法四：社群 Wiki 與資料庫
如果你不想自己拆，最快的路是查社群整理好的資料庫。這些網站通常會把「顯示名稱」與「內部 ID」並列，還會附上掉落表、生成條件、歷史改動。對於攻略用途來說，這已經綽綽有餘。
使用這類資料庫時，請養成一個習慣：看 ID 欄位，不要只看標題。因為標題是翻譯的，ID 才是準的。如果你要寫指令、改設定、查模組，永遠複製 ID 欄位。
方法五：反編譯與原始碼閱讀（進階）
如果你真的想看到「類別名稱」與「邏輯實作」，那就需要反編譯。這一步技術門檻較高，也涉及遊戲的使用條款，建議只在單機、個人研究、以及官方允許的範圍內進行。多數遊戲的模組開發者都會提供對應的開發文件，直接讀文件通常比反編譯更有效率也更安全。
即使不反編譯，你也可以從官方釋出的模組 API 文件、開發者部落格、以及版本更新說明中，看到大量的內部名稱。這些都是合法且穩定的資訊來源。
五、知道名字之後，攻略能多做什麼？
講了這麼多技術細節，回到玩家最關心的問題：知道這些名字，到底能幹嘛？答案比你想的多，而且幾乎每一項都能直接變成攻略內容。
精準查找：從「感覺」升級成「數據」
當你知道某隻史萊姆的內部 ID，你就能查到它的完整數值：血量、傷害、移動速度、偵測範圍、掉落表的每一列、經驗值、以及所有生成條件。這比在論壇問「史萊姆很強嗎」精確太多了。
更進一步，你可以用這些數據反推策略。例如：如果某隻變體史萊姆的偵測範圍特別大，那「繞後偷襲」就沒用，應該改用遠程或地形阻隔；如果牠的掉落表有兩個獨立的抽取池，那你就要分別計算期望值，而不是把掉落物加起來除以二。
指令與召喚：把測試變成可控實驗
知道內部名稱的最直接好處，就是可以用指令精準召喚。你可以指定類型、體型、數量、甚至裝備與效果，然後在一個封閉環境裡測試。這種「可控實驗」是攻略作者最強的工具，因為它能把「我記得好像會這樣」變成「我測了二十次，結果是這樣」。
做實驗時建議固定三個變數：體型、難度、場地。每次只改一個，記錄結果。累積十幾次之後，你就會得到一張比 Wiki 更貼近當前版本的數據表。
模組與設定檔：改得動的地方在哪裡
如果你玩的是可模組化的遊戲，內部名稱就是設定檔的鑰匙。多數模組的設定檔會用內部 ID 當鍵，例如「某個 ID 的怪物生成權重」「某個 ID 的掉落倍率」。知道名字，你才知道要改哪一行。
反過來說，如果你不知道名字，就會出現「我把設定檔裡所有 slime 相關的選項都改了，但沒效果」的情況——因為你改的是顯示名稱的欄位，而程式讀的是另一個。這類錯誤在模組社群非常常見，解決方法永遠是：打開日誌，確認程式實際讀到哪個名字。
Bug 回報：讓開發者一看就懂
「史萊姆有時候不會分裂」這句話，開發者很難處理，因為他不知道是哪一隻、在哪裡、什麼版本、什麼體型。但如果你寫「minecraft:slime 在 Size=2 時，於特定條件下死亡後未觸發分裂，附上日誌與座標」，處理速度會快很多。
這就是內部名稱的隱形價值：它是玩家與開發者之間的共同語言。玩家用這個語言描述問題，開發者用這個語言定位問題，中間不需要翻譯，也不會因為譯名不同而雞同鴨講。
速通與農場：理解演算法，才能壓縮時間
對於喜歡效率的玩家，內部名稱是理解演算法的起點。當你知道生成表怎麼抽、上限怎麼算、分裂邏輯怎麼跑，你就能設計出更有效率的農場，或是更快的路線。
例如：如果分裂是「死亡時立刻生成兩隻小一號的」，那你的輸出水準就要調整成「能一擊打死大型、但不浪費過多資源」，因為分裂會延長戰鬥時間。如果掉落是「只有最小體型才掉」，那你的農場設計就要確保最後一定回到最小體型，而不是在中途就把怪清光。
命名陷阱：三個容易踩的坑
最後提醒三個常見陷阱。第一，同名不同物：不同遊戲都有「史萊姆」，但內部 ID 完全不同，攻略不能互相套用。第二，同物不同名：同一個怪物在不同版本可能改了內部代號，舊教學會失效。第三，譯名落差：中文譯名可能是「黏液怪」「史萊姆」「軟泥怪」，但內部 ID 只有一個，查資料時要用 ID 而不是譯名。
避開這三個坑的方法很簡單：建立自己的對照表。左欄寫顯示名稱，右欄寫內部 ID，中間註明版本與來源。這張表會隨著你玩的遊戲越來越多而越來越有價值，因為它是你自己驗證過的，不是網路上抄來的。
六、給想更進一步的人：命名規範與研究習慣
如果你已經開始拆檔案、寫模組、或者整理攻略，下面這些習慣會讓你少走很多冤枉路。
命名空間的意義：不要搶別人的名字
命名空間（namespace）是內部名稱的前綴，用來區分「誰定義了這個東西」。原版遊戲用一個命名空間，每個模組用自己的命名空間。這個設計的目的是避免衝突：即使兩個模組都做了「史萊姆王」，只要命名空間不同，就能並存。
對玩家的啟示是：看到命名空間，就知道這個東西是誰加的。如果某個 ID 的前綴不是官方命名空間，那它就是模組內容，出了問題要找模組作者，而不是找官方。這一點在排查衝突時特別有用。
穩定 ID 與可讀名稱：兩個都要，但不能混用
好的命名慣例是：內部 ID 保持穩定、簡短、全小寫、用底線分隔；顯示名稱則可以自由翻譯、自由改寫。兩者之間的對應關係，透過語言檔或資料表建立，而不是寫死在程式裡。
這個慣例對攻略作者的意義是：你的文章標題可以用顯示名稱吸引讀者，但內文的表格與指令一定要用內部 ID。這樣文章才會被搜尋到，又不會因為改版而整篇失效。
版本標註：沒有版本號的攻略，等於沒有攻略
遊戲資料會變。今天正確的掉落表，下個版本可能被調整。所以任何一篇有價值的攻略，都應該標註「適用版本」與「資料來源」。如果你是自己測的，寫上測試日期與測試方法；如果你是查資料庫的，寫上資料庫名稱與查詢時間。
這不是形式主義，而是讓後人能判斷「這篇文章還能不能用」。很多老攻略之所以變成陷阱，不是因為作者寫錯，而是因為沒有標版本，讀者以為它還有效。
結語：那隻史萊姆，比你想的更有身分
下次你在草原上遇見一隻史萊姆，不妨多想一秒。牠不只是一團會跳的果凍，牠是一個有命名空間、有類型 ID、有實例編號、有標籤分類、有生成條件、有掉落表、有分裂邏輯的完整物件。牠在程式碼裡的名字，決定了牠會不會出現在這裡、會不會掉東西、會不會分裂、會不會被你的附魔加成。
而當你開始用這些名字去查資料、做實驗、寫攻略，你會發現一件有趣的事：遊戲世界從來沒有「只是雜魚」這種東西，只有「還沒被理解的系統」。史萊姆之所以看起來簡單，是因為你只看到了最表層的顯示名稱。往下一層，牠其實是一整套規則的縮影。
所以，去打那隻史萊姆吧。但打完之後，記得去看看牠叫什麼名字。那個名字，才是牠真正的樣子。
```