Infinite world size

[Tedypig]

Don't you want to say 'the maps in Minetest are bigger than in Minecraft'?.

No, I don't care if I can say that! This is not Minecraft, so I'm not going to compare the two. This is Minetest. I love the game how it is (well, WAS before 0.4.9). If you don't, go play (and PAY FOR) Minecraft... Have fun, I won't stop you. Hell, you can even go the way of Freeminer, Mosstest, WorldCraft, and the like 50 more out there and make your own clone. Just don't expect Minetest to turn into Minecraft (or the others, for that matter), Some people came here to get away from Minecraft. Some people don't want to play Minecraft. Some people want to play and enjoy Minetest, the way it is. If you don't, the exit is just an X click away in your top left corner. Have fun.

[rubenwardy]

Err, what? I am saying that it would become another way in which this game is better than Minecraft. I don't want to buy it, and I don't want Minetest to turn into it. I want Minetest to be better than it.

[Kilarin]

I've got a question.
I wonder what is the largest area explored on any minetest map? I would assume it would probably be on a multiplayer map. Would some of the admins of the multiplayer servers be willing to post what percentage of their current maps are actually explored?

It seems to me that this information would go a long way towards answering the question about whether we really need bigger worlds in minetest. Are there ANY maps out there that are anywhere near to exploring all of the area, of even just the surface? I'll be surprised if we have any maps that have gotten even to 50% of the surface explored. Very surprised.

[rubenwardy]

Redcrab's server is over 6gb in size.

[Calinou]

I presume we could gain about 6 % in all directions by increasing map generation limit. This way, we'd have worlds of up to about 32768 blocks in all directions.

Not that much, but it's worth trying.

[emugod]

I presume we could gain about 6 % in all directions by increasing map generation limit. This way, we'd have worlds of up to about 32768 blocks in all directions.

Not that much, but it's worth trying.

the current code has an arbitrary limit of 31000 (defined in constants.h, very easy to change), as a lazy workaround to the proper/true limit of 32768 minus rendering view distance, which would be kind of an annoying thing to implement due to variable view distnaces, or even undesirable for that same reason (having player graphical choices affect server logic). I don't know if there is somewhere else a hard rendering view distance limit of 1768 to complement this (I doubt it)? perhaps something like that could be implemented, with a far smaller number, probably (some hundreds of blocks?) and gain a thousand and change blocks back that way.

I still feel that larger/'infinite' world size is a worthy goal to be pursued. Using the 'slicing' Kilarin talked about on page 3 would let us make much better use of the 64k limit, and definitely push away any practical concerns (at present, at least), but we should always be looking ahead.

I'll be surprised if we have any maps that have gotten even to 50% of the surface explored. Very surprised.

This might be correct, at present, but its really a sad commentary on mintests lack of players. I don't think I've ever seen more than 100-200 or so active players, from the public server list, and all spread over many servers. A single server with that many regular active players would get most of the surface exposed in relatively short order, I imagine.

And actually I have a somewhat question, if anyone might know the answer to it (otherwise I'll repost it later somewhere more likely); I've seen reference to servers using mods to limit world size even further, to keep the wolrd filesize down. How is this done? A custom LUA mapgen, that turns everything to air past the desired limit (in which case afaik blocks could/would still be generated and take up some space, if significantly less)? Or is there some way for this to be set to override the constants.h value (I didn't see any apparent such mechanism, in my glances at the code).

[Calinou]

This might be correct, at present, but its really a sad commentary on mintests lack of players. I don't think I've ever seen more than 100-200 or so active players, from the public server list, and all spread over many servers. A single server with that many regular active players would get most of the surface exposed in relatively short order, I imagine.

What we need is quality players, not kids using illegal mobile clients (oh, connect to the “just test” server to see how it is). In this case, we'll never ever reach 40 on a single server.

[drkwv]

Do someone tried to implement gravity approach already? I doubt if I have enough skills and time to create such mod.

[paramat]

Multi direction gravity would be a major engine rewrite, so that's probably not going to happen.

[rubenwardy]

From what I understand of the code, it would mostly be client side. The server would need to send gravity spots and do player rotation differently. It wouldn't be a rewrite of the engine, just a rewrite of several classes. I talked about this with pa about a year ago.

[thetoon]

From what I understand of the code, it would mostly be client side. The server would need to send gravity spots and do player rotation differently. It wouldn't be a rewrite of the engine, just a rewrite of several classes. I talked about this with pa about a year ago.

I guess we would need better entities management (esp. when it comes to rotation) before, wouldn't we?

[rubenwardy]

Better entity rotation is a requisite of better player rotation, as players are just special entities.

[digitalmouse]

not sure if "infinite world size" is a necessary solution, as the current map size (64 square kilometers, if I understand correctly?) is often under-utilized - in all directions. as alluded to by other members in this post, I think it comes down to getting good quality, creative, players, as opposed to spawn-point camping lazy buggers who whine if the have to walk/fly a few kilometers in world to get somewhere to build. on my little Pi server I've already had a request for a monorail/train system so that one guy can get to the edge of the world quickly...as if teleport was too hard to type. :P

what about... connecting worlds directly together? as you reach the edge of one map, you enter through a connecting 'portal' or 'border control point' that warps/teleports/passes you through to a map on that border? could have a series of these spread along a border, in co-operation with another person's server. might even be able to give the illusion of a continuous world by providing just enough data to 'see' across the border - maybe up to whatever the standard fog-of-war distance is, but no farther. player has to cross the border at the control-point/checkpoint/portal to keep going.

neat additional trick would be to get players inventory to be carried along with them (although I can see that getting abused or creating other headaches).

[RHR]

(64 km)² is NOT 64 km²
=> 64² km² = 4096 km² !!!
Compared with countries:
64 km² ~ Size of San Marino
4096 km² ~ Size of Cape Verde
4096 km² are 4.096x10^9 m² = same amount of blocks in one ! layer.
If you are placing one block per second you would need ~ 130 years to fill this one layer with pixel art if you are very fast without any beak :D

A solution of overcrowded spawn points could be alternating static spawn points. Always a few thousand blocks away form original spawn. Eyery server owner can already do that.

Connecting worlds together does not make much sence, because every server uses different mods and evan if possible, players would immediately abuse that system if they could keep their inventory on different servers.
IMO is the idea of stacked worlds in one world better (a stacked world of 2000 blocks should be more than deep enough to mine)

Compared with MC in Minetest player aren't forced to walk far away from spawn because every serious server has a protection mod and locked chests.

Of course if one day a Minetest server really hits it's limits we could try to find a solution for huger maps, but right now nobody has to rack one's brain about stuff that isn't a problem yet or in near future.

[drkwv]

4096km² is a square with 4'096'000m sides. Minetest square has 64'000m sides, so it's 64km², not 4096. Considering each block is 1 meter (as for me, visually it's 0,5m-0,6m so it's not 64km² but something around 32km²).

[rubenwardy]

Wow.

Area = Width * Height.
Area = 64km * 64km
Area = 4096km²

Don't confuse it with square kilometres (which is what the above post is doing), which is the side of a square with the same area. It is not an area, and has a unit of km not km².

[drkwv]

True. I was wrong about km². But anyway it goes out of considering that block is an equivalent of 1m which is not correct. Because if you'll take a measuring tape, slide it to 1m and put on the floor it would give you an image and feelings different from the same as if you look on the floor block side in game. I wonder if 195cm tall guys wouldn't feel the difference though (I'm 180). It would be weird if additional 15cm will make everything look so smaller.

[Sokomine]

But anyway it goes out of considering that block is an equivalent of 1m which is not correct. Because if you'll take a measuring tape, slide it to 1m and put on the floor it would give you an image and feelings different from the same as if you look on the floor block side in game. I wonder if 195cm tall guys wouldn't feel the difference though (I'm 180). It would be weird if additional 15cm will make everything look so smaller.

A block feels less than 1 m to me as well. I wonder why that is so. Viewing angel? Eye height? Could be that the player's eyes are more like 1.5 m above ground. Another misleading factor is that horizontal surfaces as found on blocks we use for tables, kitchens and the like are in reality more like ~70 cm in height. Also "walking" on stairs where each step is half a meter in height wouldn't be much fun.

[Krock]

@Sokomine, drkwv:
I changed the fov (field of view) to ~90, now it looks fine for me.
The stairs are not optimal and should be changed somewhen.

[drkwv]

Well, I changed fov to 90 but hasn't seen big difference. Stairs are ok. And even sizes ok too. No need for realism. It's just thoughts about sizes.

[GauVeldt]

I thought the issue with the map size was due to the endcoding used to decorate the 3D chunk address primary key in the sqlite database.

Couldn't the code be modified to use multiple primary keys and the limitation could be lifted since the decoration algorithm would no longer be required and a separate (signed) int32 would exist for each axis, being good for 2 billion or so blocks in any direction?

To sound like a certain 1984 software entrepreneur dare I say, "2 million km should be enough for anyone"

[GauVeldt]

I presume we could gain about 6 % in all directions by increasing map generation limit. This way, we'd have worlds of up to about 32768 blocks in all directions.

Not that much, but it's worth trying.

32768 blocks (32.7) km is not much of an improvement over the current limitations. Best to use int32's, exchange the single-primary-key-with-decorator for a triple (int32,int32,int32) primary key then be done with limitations as it would then be around about [-2 billion,+2 billion] on any axis. That's 2 million km in any direction from [0,0,0].

[twoelk]

would a database holding an "infinite" map really be manageable?

[GauVeldt]

would a database holding an "infinite" map really be manageable?

Well nothing in computers is actually infinite. However choices could be made for the map axes storage units that have large enough values, int32 or double perhaps, (say around +- 2 billion blocks per axis) that the limitation would not likely occur in practice (if more than +- 2 million km in all directions is needed a different engine choice may be in order such as a sparse 3D outer space/galactic engine :P)

Server communication could be adjusted if need be to output the position as a coupled integer block position, plus fractional block position if the float will not store a high enough value.

[Krock]

Generally, 3 bits for the coordinates X and Z would be loong enough. (16'777'216 meter)
I don't see any big use in 2 billion meter on each direction because not even 1% of the total space will be used.
First, we need a check to not save every generated mapblock. (To prevent a data floodbecause of explorers)

I like the idea of having huge maps but if someone asks for your coordinates.. ehm. Okay.