There's actually a lot of well founded desire and technical need for a world of size about 1M blocks in the horizontal dimensions at least. And for stuff like creating 1:1 replica worlds either of IRL or of fiction, which is something we have seen in, for example, official community servers based on IRL locations, the extra space is invaluable.

But this issue has thorns. One, the minimum viable size increase that would still be fast for machines to operate with is much more than needed and quite difficult to justify, and also changes the backend a good lot. Two, the full "cube" of materials is currently not used nor useable because – and this is going to be a key point later – Luanti mapgen is intended for human consumption, and thus for generating worlds that are, at large, interesting only horizontally.

I could go on an essay about both the mental and the mechanical issue with world size, but in the interest of time I'll make a short demonstration of the foundational problem.

The current Luanti world size is 64k blocks on each three dimensions. Sure that "sounds" like a big cube with lots of room to fill, but for practical purposes, you are not filling a 64k cube, you are filling a 64k surface. No mapgen available generates mountains or seas that high, and bedrock that deep would be a PITA to work against to make room.

So, what I "have" to work with is a square 64k blocks length. For comparison, that length is not enough for me to model a trip from my country's capital of Santiago, Chile, ya know, one of the memetically narrowest countries in the world, to the nearby towns of the Pacific coast. It's just ~6k blocks short. And that's just half the country wide. So any sort of reasonable "IRL simulation" is shot off the 1x1 luanti:glasspane.

Without delving deep into the code of Luanti, I have to guess that the reason to use coordinates that are 16 bits wide (2p16 = 64k) is so that a "point" (a coordinate tuple) fits into a 64-bit variable, the widest, portablest, arithmetically capable numeric size that computers are widely capable of. 1 point is made of 3 such coordinates, using 48 of those 64 bits. Measures of 16, 32 or 64 bits are also "aligned" in hardware to how the machine operates on those numbers.

Increasing the world size means increasing the coordinate size. Up from 16 bits, the next aligned size is either 24 bits or 32 bits depending on how much do you want to struggle against the hardware (the common Windows desktop will love 32 and loathe 24, for example); but either way, packing 3 of those coordinates together means you get a "point size" of either 72 or 96 bits - far more than the 64 we are locked upto. Right off the bat, that means a coordinate point can no longer be copied or operated in directly into the CPU and its 64-bit wide pipelines. Extra processing, extra size, extra work, extra slowness, will be made patent and necessary.

Still, this increase if done would get us to worlds that would at minimum be about 16M blocks side length – 16000k blocks, a vast improvement over 64k blocks to the point you can model whole countries into such a world cube, as well as practical fictional deep space structures and even fantasy-like "realms".

Is there a middle point?

Well, if we didn't have to worry about machines demanding the bits they byte to be "aligned", we could simply give each dimension a mere 4 more bits from 16, for a total of 20+20+20, still leaving 4 bits freely available, and that still would allow Luanti to model worlds 1M blocks in length (2p20 = 1048576). Still a vast improvement over 64k, but the code that has to handle the coordinates will have to be willing to "fight the computer" to achieve that because the bits where each coordinate begins will no longer be at the nice and comfortable markers of 16 or 32 bits that the computer wants.

Respectably better solutions are available, however, if the Luanti devs are willing to accept a human component, a simple reality that I've seen often disregarded on tickets raised about the issue of world size.

The devs aim to treat the three dimensions equally. They want the game to model working in truly three dimensions. Which is understandable, because Luanti is not intended to merely be a Minecraft clone – it's intended to be a sort of "engine engine".

But when it comes to the games that people will and do actually play on Luanti, they deal with generated IRL-like worlds, and with our mental perception of them. The construction of structures, or even the natural landscapes, that make much of the "Mine..." part of Minetest Luanti, the truth of the matter is those human experiences are a largely two-dimensional paradigm. When we observe worlds with rivers that go from mountains to seas, and when we use those worlds to erect awesome fortresses, our mental model of such a world is that it is ten or so kilometers "thick" (tall) and "richly large" in ground surface (side length). The Witcher, Breath of the Wild, Red Dead Redemption, any kind of such constructed world, let alone our IRL one, is for purposes of our mental modelling of what to do with them almost two-dimensional, even when factoring IRL Spherical Earth in.

So, if we ditch the idea of treating all three dimensions equally, and since it's not possible to split 16 available bits between 3 dimensions equally anyway, various possible solutions (around 12, last time I did the math) emerge of which I will select a random example. We could split the 16 bits as 4 for vertical and 6+6 for horizontal. So our coordinates are 22, 22, 20 bits size. Such a combo allows for worlds that are 4M blocks side length and 1M blocks tall, and points still fit inside that desirable 64-bit barrier that makes the CPU happy. But it means the world, of which neither we nor the mapgen make "cubic" use anyway, will no longer be a cube. It will be more "horizontal", as the gods we created intended.

Thank you for coming to my TED Talk.