infinite procedural world

Started by
14 comments, last by sliders_alpha 11 years, 11 months ago
Hi, I want to make a minecraft clone but I don't know if I'm going in the right way or not.
having never took any game programming courses I might be re-invented the wheel^^

first thing first, my world is stored in a 2D sectors array.
I give the illusion of movement by drawing the world backward when the player wants to go forward.

post-197666-0-64050400-1335789331_thumb.png

and here is my Idea for infinite world generation.

post-197666-0-64208800-1335789443_thumb.png
(in reality I have a bigger array called cache which contains the world sectors and the sourrounding ones, this cache object is managing hard disk access on it's own to always give to the world quick access to new sectors)

what do you think?

thanks
Advertisement
So basically you have a square grid which holds the visible chunks of the world, where it moves them around trying to keep the player in the center cell? k.

You could make it not-square but something similiar to a circle (leave some corner cells not pointing anywhere) as theyre not really useful in the corners as you cant see that far in all of the directions...

o3o

yeah but I'm using java, Since i'm declaring an array of chunk.
I think that even If I put nothing inside a cell the memory for it is still allocated.

I just thought about something, it's all ok if the player start a 0,0.

but how to move it back to where he was last time?
my current thought is to store the chunk name and the coordinate on the chunk.
But if theyre kind of references the memory usage will be a lot lower without those extra chunks as youre just storing something that can point to chunks, not the chunks themselves.

o3o

I see no problem in line of theory. Keep in mind however that wrapping the world to reset it around the origin might be more problematic than expected. I can tell for sure Bullet (a physics API I'm using) wouldn't allow you to do so. If you're going to write your own physics, keep in mind the periodic "re-centering" operation will likely have to be supported somehow.

It is possible to do something like what you have drawn in the first two images, let the camera move forward for a few chunks (say 1024*16 units) and keep streaming (letting the model "grow", without changing camera position). Then, wrap to the origin only when a certain rationale is met, such as distance from the origin > 1024*16. This is fairly easy: just subtract a constant such as 1024*16 along a certain axis.

How to move back where it was last time? It's not like we are talking about something we don't know. We know exactly how big a chunk is. Think at it. As long as FP precision allows, the operation will be perfect.

What's the deal with chunk names and coordinates? It appears to me this information is not required.


But if theyre kind of references the memory usage will be a lot lower without those extra chunks as youre just storing something that can point to chunks, not the chunks themselves.
I don't completely agree for two reasons.

  1. Nobody says chunks will be reused. In the case of minecraft, they are mostly unique - this means the difference will be close to zero but anyway..
  2. Java does not really create a array of objects. It creates arrays of references to objects. Java does not really deal with the objects themselves like C/C++ does, it deals with the references only.
  3. I hardly believe the chunk structure itself will take much space. It's data will.

Previously "Krohm"

you were both right, making an array of reference to chunk does not allocate anything it just creates reference.
then I have to instanciate a class and link it to this reference.


[background=rgb(250, 251, 252)]I see no problem in line of theory. Keep in mind however that wrapping the world to reset it around the origin might be more problematic than expected. I can tell for sure Bullet (a physics API I'm using) wouldn't allow you to do so. If you're going to write your own physics, keep in mind the periodic "re-centering" operation will likely have to be supported somehow.[/background]



[/quote]

well I'm planning on coding everything, i'm doing this for fun^^
what kind of other type of infinite world algorythm is there out there? I searched the first 10 pages of google and each camera implementation is the same.

the camera never moves, the world does.
therefore I don't see any other way to do it.


[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]It is possible to do something like what you have drawn in the first two images, let the camera move forward for a few chunks (say 1024*16 units) and keep streaming (letting the model "grow", without changing camera position). Then, wrap to the origin only when a certain rationale is met, such as distance from the origin > 1024*16. This is fairly easy: just subtract a constant such as 1024*16 along a certain axis.[/background][/font]


[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)][/quote][/background][/font]



[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]why? basically you are asking me to do exactly the same thing but to increase the "reset" distance from 1 chunk to 1024 chunk.[/background][/font]


[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]what will it changes?[/background][/font]

That's more or less sound, what you're doing is generally called "streaming" -- However, you probably don't want to decide which "chunks" of the world to cache based on direction the player is facing, since the player can turn quite rapidly. I would cache chunks based on distance to the player, and perhaps use direction of travel as a secondary influence -- so basically, cache concentric rings around the player from the inside out, and on those rings start with the chunks directly in front of the player, going around the ring in either direction until they meet behind the player.

Within that set you might use a heat-map to identify commonly-traveled areas, so that you know to get updates for those more-frequently, if it matters for your game. For example, most of the time when I play Minecraft I'm at my home, or in a nearby area where I hunt mobs.

throw table_exception("(? ???)? ? ???");

well I'm not choosing wich chunk to cache, I'm caching EVERY chunk around the player.

post-197666-0-96149300-1335814160_thumb.png

for now I'm only working with 49 Chunk but storing 600-900 chunk on RAM is more than acceptable.
it would take around 400Mb and today's computer have at least 4GB of ram, why shouldn't I use it?
I would do it like this:

Assuming the visibility range is 10 units.
- Load all chunks within 12 units range. Do not use any separate threading, just load chunks one by one without hurry, you are loading these before these are needed (since you have 2 chunks buffer).
- Unload all chunks that are farther than 30 units range (much bigger than visibility range and the load range). Players frequently go back and forth so unloading prematurely is a big waste.

Do not forget the bottleneck is CPU, not memory nowadays. You should waste some memory to in order to give CPU some break.

Stellar Monarch (4X, turn based, released): GDN forum topic - Twitter - Facebook - YouTube

It's true that by expanding the cache size from radius+1 to radius*radius would allow me to load chunks in a unique thread.

however are you sure that it changes anything for when a player is going back and forth?
look at this, if the player is going back and forth, the red lines keeps getting loaded/unloaded.

but not having to be in a hurry to load chunk is quite nice^^

This topic is closed to new replies.

Advertisement