這題當歸屬於編程大佬們

這個問題得怪mc自己的一些機制上的問題。

首先，排除一些其他原因，比如早期（至少1.0時期）天空高度限制是128，後來改到256，但是這只是建築高度，玩家可以飛得更高（至於是TNT炸上去還是鞘翅飛上去還是一根2147483647級的激流直接上天就看個人意願了），至少表明y坐標限制並不是不能突破（區別於x/z=±30000000的世界界限，那真的是改坐標都出不去）。

那麼問題出在哪兒？

存檔機制本身是一個威脅。mc的存檔每個.mca記錄32x32共1024個chunk（ @海東喵 所以面積上好像真的是512*512？），分成1024個存儲對應區塊內全部信息的Chunk[x.z]文件，每一個里用Sections這個Tag_List記錄這個區塊內存檔的方塊信息，包含共計16個Tag_Compound，每一個複合標籤由一個「Y」值標記其存檔的信息的所屬位置（這個即所謂的subchunk的由來），Y:0表示y軸區間0~15，Y:1表示16~31……[1]。經驗表明，主世界通常平均會用到大約7個subchunk（實際上Oceans及變種最少，只用到4個，一般的平原森林在5個左右，帶hills能到6個左右，mountains、plateaus以及有大樹的那些比如giant_tree_taiga、jungle等一般在7~9個，特例是shattered_savanna及其plateaus變種，最平的時候5個，最高16個）。換句話說如果y軸高度提高的話，很可能需要同步提高一下各個生物群系的比例，這可能導致存檔變得非常大。但是，如果一個subchunk裡面沒有一個方塊（哪怕曾經）被填充為不是空氣的方塊的話，這個subchunk就根本不會計入存檔。此外，subchunk的Y並不一定非得連續。刪區塊存檔信息的經驗表明Y:6後面是真的可以直接Y:8的，這也就意味著只要生成世界的時候Depth Base Size（貌似叫基準深度大小？）[2]這東西不怎麼變的話，大量空閑空間其實根本不佔存檔；

區塊載入機制是另一個威脅。mc對區塊的載入是（除通過技術手段強制載入區域外）以每一個玩家為中心視距為半徑載入裡面所有區塊，但是每個區塊均是直接全部載入完，這就導致如果區塊的y軸能不斷建築上去的話，每個區塊的載入負擔就會越來越大，畢竟承載的光照計算和實體動作也越來越多（其實這也是曾經的farlands（邊境之地）特別卡的原因之一[3]，雖然不是主要原因）。順便一說，記憶中多年前貼吧就有討論過是否可能讓y軸變得跟xz一樣大範圍存在，或者直接把整個世界立過來。當時的結論是其實是也不是不行，只要y軸也跟xz軸一樣區域性載入就行了。

所以，最主要的問題可能還是出在Mojang上，畢竟是Mojang，不懂mc，懶得要死，負優化，還經常製造bug。如果mojang願意正優化下各種機制的話y軸再拉高一些也不是做不到。

參考

  1. ^https://minecraft.gamepedia.com/Chunk_format
  2. ^https://minecraft.gamepedia.com/Customized
  3. ^https://minecraft.gamepedia.com/Farlands

1.過高的高度會影響遊戲運行的性能，因為增加了需要處理和渲染的空間。

2.多出來的空間也會保存在地圖文件中從而增加儲存負擔。我至今玩過最大的存檔有1.4gb（不包含datapacks）

3.多出來的空間也沒有意義，除非是特殊的cb研究（寫bug）或是世紀偉大工程，用到的y軸空間很少超過200。

我們先來看直接原因：

原因一：地圖格式限制

MC的地圖是按照區塊（Chunk）劃分的，Chunk在地圖中只有x軸和z軸坐標，沒有y軸。

（y軸，對沒錯，大多數遊戲設計中y軸才是垂直方向）

因此地圖的垂直方向是不能重疊區塊的。

原因二：區塊格式限制

一個區塊是16x16x256個方塊大小，也就是說一個區塊內方塊的最大高度是255（256個方塊，即0-255）。

因此區塊內方塊的高度也被限制住了。

由於以上兩個原因，MC的地圖高度被限制在了255個單位。（當然，Mod可以改變這一切）

真正的問題來了，MC為什麼一開始要這麼設計？俺尋思題主其實是想問這個。

更深層次的...：

我們知道遊戲內所有的數據都是二進位儲存的（這不廢話么），而且得按照程序語言標準的各種數據類型來，那麼首先我們來康康Java有哪些基本數據類型：

  • byte：8位整型
  • short：16位整型
  • int：32位整型
  • long：64位整型
  • float：32位浮點數
  • double：64位浮點數
  • boolean：表示true或者false的布爾代數

如果把一個區塊設計成16x16x256個方塊大小，即2^4 x 2^4 X 2^8，這麼劃分剛好是2^16，在代碼中一個方塊的位置就可以用一個16位整型表示，多麼合適（255個單位高度也夠用了，至少一開始Notch是這麼想的，大概）！如果讓區塊再大點，方塊就得用超出16位整型範圍的數據類型去存儲，空間占的多了，不太划算。

而為什麼區塊在地圖中的坐標只有x和z兩個方向上的，原因其實也很簡單，如果地圖內區塊只需要在水平面上分布就好了，就不需要考慮第三個維度，世界生成時的生態系統分布等，以及後面地圖的讀寫等等和地圖相關的操作都會簡單不少。

這麼一來，地圖內方塊的高度就被限制在255以內了。

MC的代碼其實水平8行，裡面有很多早期時順手一寫留下來的坑（無數Mod作者吐槽不能），有興趣可以自行去看相關的問題。

Notch製作這個遊戲本來是帶有自嗨性質的（有一說一，那些好玩的獨立遊戲從來都是首先用來滿足作者的創作欲的），僅僅用了一年就製作出了遊戲原型，最初的版本也僅僅是可以在草地里搭建些泥土塊、石頭之類的幾個方塊，遊戲在後面才逐步完善，也添加了越來越多的新花樣。而後面遊戲火遍全世界，乃至於微軟收購，則是Notch一開始不曾設想到的。Notch之後也退出了Mojang，他覺得Minecraft已經偏離了他希望的方向，不再是他最開始希望表達自己的那個遊戲了。當然，那就是另一個故事了。

參考來源：

Minecraft Wiki-區塊格式

一些知識：

  • MC一個地圖文件為：1024 × 1024 × 256
  • 即 2^10 × 2^10 × 2^8
  • MC一個區塊為：16 × 16 × 256
  • 即 2^4 × 2^4 ×2^8
  • 地圖的高度為：255 （0 到 255 一共256個數）
  • 即 0 到 2^8 - 1

地圖的高度限制在 255 是因為 「優化」

  • MC的機制就是玩家所在的區域會載入玩家附近的區塊，也就是只載入附近 16×16×256 的數據
  • 如果上調了高度限制，那麼要載入的數據也就越多
  • 如果是伺服器，那麼會更加傳輸數據，佔用帶寬，例如一個原來能同時8人玩的伺服器，這麼一搞只能4人玩了
  • 會影響處理性能，例如命令中有判斷實體坐標之類的，會導致檢索效率下降

同時也是因為 2^8 這個值比較 「合理」

  • 在編程中，存儲數據的容量大小一般是 2^n
  • 想想看如果高度值不是 2^8，而是 2^7 或者 2^9
  • 2^7：高度為127，按MC的天地分法，128/4＝ 32，32為地，96為天，想想看礦物的分布就不合理了，很容易就挖到底，要是55分，64天地，建築黨可能要不高興了，高樓大廈蓋一半就不給蓋了
  • 2^9：高度為511，總有很大的天地，地底128的深度，384的高空，那麼問題就來了，礦物的分布會變得稀疏，多半進地里都在冒險，而且進一次地底需要帶足充足的食物，不然很難再回地面，剩下參考先前所說的 「優化」

假如Bugjang突然突發奇想，不限制高度了。

我進入遊戲，飛到了(0,一千萬,0)，然後在這裡以此為中心搭建了一個32*32的大平台。

我回到了地面上(0,64,0)，關閉了遊戲。

第二天，我進入遊戲。MC時間是大白天。

問題：我所站的位置的亮度是0還是15？

按理說是0。但是，假如MC要想知道我站在陰影中，就必須讀取從這裡向上一千萬格，找到那個平台，然後才能正確地計算出這裡的光照。

很顯然我的電腦不想讓MC這麼干。

注意：光照這一點很嚴重。有些人可能想，把y軸也做成像x和z軸一樣的分段讀取就好了。但是，光照的計算需要這一點向上一直到世界頂端的數據。基於這一點，MC的世界高度必然是有限的。

推薦閱讀：
相关文章