GMS 2 Generating multiple ds_grids and stringing them together visually

P

PepticPaladin

Guest
I'm trying to create an infinite world using chunks. Currently, I'm using a noise function to generate terrain on a ds_grid that is the same size as the room. It looks like this:

terrain.PNG

Now I'm trying to have the world generate in 16 by 16 chunks so I can make the game infinite. My plan was to create a new ds_grid for each chunk, string them together, and have them move across the screen, destroying the grid when it is off-screen.

The issue is, I don't even know if it's possible to string grids together, let alone make them move.

Is it possible to do something like this, am I missing something? Or should I be going about this in a different way?
 

NightFrost

Member
A ds list would be enough, as you only need to save how many tiles there are vertically at each step. Then you'd set up a variable to count terrain scrolling. Each time terrain moves N pixels to the left, you increase the variable by same amount. When it exceeds tile width, the leftmost column has moved out of screen. That's when you remove it from ds list, add a fresh generated value to the far end of the list, and subtract tile width from your counter variable. The counter variable also tells your draw routine the amount of pixels to offset to the left from zero x-position when drawing, to simulate terrain movement.

(I assume a perlin noise generator?)
 
P

PepticPaladin

Guest
Thanks for the reply.

I don't think using a ds list would work since I want to add caves eventually, and the terrain is destructible. Right now I'm using a grid and tilemap_set for visually displaying the terrain, and I use the grid for collisions. As far as I can tell, grids are always created in the top left of the room and expand down from there, and I can't move their origin around. I'd also like to avoid using one big grid so the memory usage isn't too bad once the player explores more. I could probably draw the terrain separate from the grid, to make scrolling terrain, but at that point I would still need access to the grid so I can check for collisions.

(The noise generator is a simplex noise algorithm I translated from java to gml. It's kind of slow, but it works)
 
T

Taddio

Guest
As far as I can tell, grids are always created in the top left of the room and expand down from there, and I can't move their origin around.
I don't know what you mean, ds_stuff don't have a position in the room, it's just data stored in memory. Sure, your grid will start at grid[0,0], but that's just the position WITHIN the grid, not an actual (x,y) position.
 
P

PepticPaladin

Guest
Yeah I get that they are just data stored in memory, I'm just struggling to figure out a way to use them in order to create infinite terrain without needing a really big grid or destroying information that I want to stay saved if it goes offscreen.
 

NightFrost

Member
Oh, ok, so you want the world to be persistent. The ideas of infinite and persistent don't go too well together, as all that data needs to be saved somewhere, and infinite expansion eventually means huge amounts of data. You'd need a system that offloads distant world chunks to disc and retrieves them when necessary. Now I also understand what you meant with stringing grids together. You need to manage a list of neighbours: each chunk needs to know what its eight neighbour chunks are, so when your view overlaps multiple chunks, the system is able to receive correct portion of each chunk to draw. Your world position data thus becomes: the x and y coordinate of the top left corner in the chunk, plus the identifier of the chunk. So when the corner has to move across a chunk borders, you retrieve the neighbouring chunk's identifier and move the coordinates there accordingly.
 
Top