World size considerations in voxel based game
Author
I have been working on a voxel game for the last couple months. Progress is going very well on my map generator, but there is there is something that I believe may be in issue. First off, my game works very differently than other voxel games (such as minecraft). The world is finite, because there are certain structures that must exist in every world. My problem is the size of the world data. Currently, a medium sized world contains 1440*1440 chunks, which are 16*16*128 blocks. Each block basically consists of a block id of the short data type. If my calculations are correct, that would mean that an entire explored world would be over 63 GB. That is WAY too big. A large part of my game is exploration of the world, so this will not work. Is there any way to save the data in a smaller format, or some more efficient way to store it? I have not found anything.
I'm not a voxel expert, but I believe that voxels are often stored compressed. The trick is that the compression scheme must allow for easy modification and fast spatial access. I gather RLE is often used, based upon a tiled region, a heightmap, or a sparse voxel octree. I believe people often store the average or median value for the cells inside an octree node against that node, and differences against the subnodes. The diffed data often compresses well.
For discussion on these topics, check out:
http://gamedev.stackexchange.com/questions/17050/which-data-structure-should-be-used-to-represent-voxel-terrain
http://hbfs.wordpress.com/2011/03/22/compressing-voxel-worlds/
For discussion on these topics, check out:
http://gamedev.stackexchange.com/questions/17050/which-data-structure-should-be-used-to-represent-voxel-terrain
http://hbfs.wordpress.com/2011/03/22/compressing-voxel-worlds/
Author
That gives me something to start with. Something that that I thought of is adding the type of each block in a chunk together, then generating a key based on the values added. That way the only values that would have to be stored would be the total value and the key. When retrieving the chunk, the total value could be parsed into a complete chunk by using the key to get each block value. So far I have not been able to figure out how to make this work.
I agree with making them finite. Honestly players do not really need to travel past 10k blocks out. I run a very popular server in minecraft that has 3 nations and over 200+ regular players. They have not even TOUCHED half of the things that are in the 10k x 10k world.... so honestly a finite world is the best option for performance as well as control. I know in my own voxel game we are going to let the server owner decide the size but it will not be infinite based. ( a mod could come out that allows for it occur... but the game would run like shit on a 20gb map file.... really it would. )
I say stick with your plan and find a way to optimize these things. We have done this in our own project and can load a 32x32x255 chunk in less than 6ms. With more optimization possible in the later parts of our development. If those topics dont help let me know and I will have my coders see if they cant guide you in the right direction.
I say stick with your plan and find a way to optimize these things. We have done this in our own project and can load a 32x32x255 chunk in less than 6ms. With more optimization possible in the later parts of our development. If those topics dont help let me know and I will have my coders see if they cant guide you in the right direction.
A large part of my game is exploration of the world, so this will not work. Is there any way to save the data in a smaller format, or some more efficient way to store it? I have not found anything.Consider saving the seed instead and generating them on the fly. Then just save what was changed by the player.
I agree with making them finite. Honestly players do not really need to travel past 10k blocks out.
I couldn't agree more.
I've played Minecraft for a long time and I've never bothered to explore too far (in spite the fact that I'm an explorer-type player), mainly because there's (1) absolutely no reason to and (2) if you go too far then there's the journey back home to consider
. Most of the interesting stuff happening in Minecraft is interconnected at short distances, the Nether and the End are accessed through portal systems and the best ore types are found down below through digging. This is a reason for the game's success IMO, not the world size. The game could've easily been 10 times smaller and still it wouldn't matter for 99% of the playerbase. So instead of reaching the edge of the map in about 800 hours of non-stop walking, it'd take "only" 80 hours.I think game worlds should only ever be as big as to prevent player congestion and similar. The should be a specific purpose behind the world size. Too many games (although Minecraft isn't one of them) overestimates the value of random, procedural generation. This is a big mistake IMO.
Minecraft has the problem that the world feels unique for a really small area, theres too many forever repating boring small hills and cave everywhere. It would be great if there was a 1000 meter high mountain and the next one would require hours of walking... Or a big ocean/desert practically impossible to get over by walking.
Author
The game could've easily been 10 times smaller and still it wouldn't matter for 99% of the playerbase. So instead of reaching the edge of the map in about 800 hours of non-stop walking, it'd take "only" 80 hours.[/quote]
This is true. Most players ultimately settle in one area in these sorts of game. In my game, I want players to have the option to keep exploring, even if most probably will not. There will always be those who complain that the world is too limited or too small.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
