这题当归属于编程大佬们

这个问题得怪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的世界高度必然是有限的。

推荐阅读：
相关文章