# How would you do this?

26 posts

 I am trying to figure out how to make a generate chunks essentially. When the player moves around a new chunk (lets say 800×600 movieclip) is created adjacent to (800×600 movieclip) the on the player is currently on top of. This would simulate a infinite world. I am wondering how you would go about calculating where the new chunk goes. I tried making this and realized a made a big mistake. The link to what I made can be found here: http://www.fastswf.com/AaBT6UA (move with arrow keys). The first surrounding tiles work fine but what I essentially did is only make new tiles be created in 8 directions (which works fine for the first tile) but the 8 directions are based off the first tiles location so when you get farther out there are gaps. I think it makes a lot more sense if you move around in the swf and you’ll eventually see the problem as you progress in any one direction. This might be in a completely wrong direction, but perhaps some sort of quad tree? Or sparse grid implementation? Someone has solved this issue before, so I’d suggest some hardcore googling, perhaps with the terms “infinite terrain generation” or “infinite terrain storage” or “infinite terrain data structures”. I’d simply keep a pool of trees contained in a constant rectangle. If a tree gets outside of the rect, I’d just move it to the other side of the rectangle. ie: In the Tree class `if(x<-WIDTH)x+=RECT_WIDTH;` Same for all directions. This avoids the unnecessary creation and destruction of new areas and trees. But I need the creation of the new tiles and they never get destroyed. I am not looking for endless scrolling I am making endless generation. Then build it as any tile-based map. A tile goes at `X*TILE_WIDTH,Y*TILE_HEIGHT`. But the x and y has to appear based on what tile the player is exploring past how do you find out what tiles need to be generated and on what side. You’d have to keep track of the current limits of the map. Then if `player.position+player.speed` exceeds a limit, you’d generate a new tile in the appropiate place (you already know the current tile, so that should be a problem). I’m about to go to bed, but if you don’t understand it, I can post some code later if I find some free time. But you need to know what tiles are around the tile the player is in. For instance if you go the the left and you are on the 1/4 top of your current tile then you need to create a tile to the right and a tile above that tile to the right (aka a tile to the east and NE) I would like to see what you come up with if you find the time. Edit: Fine, then. Don’t mind me. As good of read as that was Ace_Blue… It has nothing to do with the question at all. What were talking about is generating the tiles. The trees are just there so that you can actually notice you are moving in the example. What I am trying to do is figure out how to generate a new 800×600 tile and where to place it when the sprite that holds all the tiles gets to a point where no tile is on the screen. For instance starting out we just have the player in the center of a 800×600 tile. Now the stage is 800×600 big so if the player presses the up key it will generate a new tile above the current tile the player is in. As the player continues up it will keep generating tiles when the player gets to a point where a new tile is needed. If the player presses the left key it will generate a new tile because if it didn’t then the player would see a empty background. However you also have to keep in mind that if the screen has already been moved a little ways up and you then move to the left then two more tiles need to be generated. One to the left and one above that tile to fill in the space to the top left diagonal. This may be a silly question, but why are you wanting your tiles the size of the screen? That means if I move one pixel to the right, and then just move up, you have to generate a whole other screen that I’m never even going to see for each screen I traverse in this manner… Anyway, if I understand your question correctly (which I’m not sure I do), you’ll be disposing of “tiles” once they get far enough away? If so, I’d do something like this (assuming your screen-sized tiles): Have a double-array (for simplicity’s sake) with 9 elements. Element `[1][1]` represents the tile that the player is in. When player moves across a tile boundary, change the array’s contents so that the player’s new current tile is still in element `[1][1]`. So if I moved left enough to enter the next tile: ``` var ri:int; for (ri = bgTileArray.length – 1; ri >=0; ri—) { bgTileArray[ri].shift(new bgTile()); bgTileArray[ri].pop(); } ``` Moving right into a new tile: ``` for (ri = bgTileArray.length – 1; ri >=0; ri—) { bgTileArray[ri].push(new bgTile()); bgTileArray[ri].unshift(); } ``` Moving up: ``` var ci:int; for (ci = bgTileArray[ 0 ].length – 1; ci >=0; ci—) { bgTileArray[ 0 ][ci] = new bgTile(); } for (ci = bgTileArray[ 2 ].length – 1; ci >=0; ci—) { bgTileArray[ 2 ][ci] = new bgTile(); } ``` …and you should be able to figure out down from that. Not optimized, but then, if you’re using screen-sized tiles, I don’t think you can be very concerned with optimization… Yes a whole new tile the size of the screen will be created. However it will be seen and used as the player moves into that tile. I don’t understand why you think the player wouldn’t see/transverse it. Also once the tile is created it is not deleted. It stays there forever. I think I can make this easier by setting something like this up for an example. O = starting location 1 = a tile that was just created 2 = tiles that were already created Game loaded. O Move Up. (any number of pixels) 1 O Move Up. (enough to generate a new screen) 1 2 O Move Right. (enough to generate a new tile and being exactly in the center of the previous last created tile. 21 2 O Move Down. (enough to generate a new tile) 22 21 O Move To an area around the Center of the current tile and the last created tiles. Then Moving to the right (Has to generate 2 tiles because you are not in the exact middle of the last created tile.) 221 221 O Move diagonally down and to the right (creates 3 tiles for the right, diag down and to the right, and straight down.) 222 2221 O 11 Its just creating new tiles when the sprite that is holding all the tiles goes to far in any direction so that the player never sees empty space. If you have ever played minecraft pretend that the tiles are chunks. When the player moves new chunks (tiles) have to be created so that there is something there for the player to see. Originally posted by evan999333:I don’t understand why you think the player wouldn’t see/transverse it. Because your explanation of the problem was very bad. Its a very hard problem to explain apparently and I am doing my best… I really don’t know how else to explain what I am trying to do. Well yes, tiles have to be created for players to see, but why screen-sized tiles? It seems a bit wasteful. If free movement is allowed, I can move 1 pixel to the right (assuming that is the smallest step size). If I move one pixel to the right, you have to place another screen-sized tile to the right, yes? Then let’s say I hold the up button for an hour. I will never see any of the screens to the right that you have to place (apart from a 1 pixel-wide line). Example: [ O ] Move right one pixel: [ O ] [ 1 ] Move up any amount: [ 1 ] [ 1 ] [ O ] [ 2 ] Move up enough to generate new screen: [ 1 ] [ 1 ] [ 2 ] [ 2 ] [ O ] [ 2 ] After an hour: [ 1 ] [ 1 ] [ 2 ] [ 2 ] (long, long list of [ 2 ] [ 2 ]) [ O ] [ 2 ] Note that apart from the 1-pixel wide line, I’m not going to see any of the screens created on the right side of the list. Sure, at some point I might move that direction. I might not. Yes that’s correct that would happen and it could be a problem. But its not the problem that I am really asking about. What I am trying to figure out is how to make the tiles appear no matter what direction you go in and make a endless generation. Anyway, as to how to deal with how to add them on, maybe you could have four pointers; one for each direction (or eight, if you want the diagonals — though I’d think that be more complicated than helpful). ``` || == [ O ] == || ``` move up: ``` || == [ 1 ] == || == [ O ] == || ``` move up enough to get new screen and right a bit: ``` || || == [ 1 ] == [ 1 ] == || || == [ 2 ] == [ 1 ] == || == [ O ] == || ``` etc… I don’t really understand how the pointer idea would work at all… How would you find the x and y to attach the new tile onto? Oh, that’s what you wanted to know? Well, presumably your currently-occupied tile has coordinates to place it on the screen appropriately, and you obviously know the screen/tile dimensions, so I must be misunderstanding this problem — it seems a bit obvious: if node A is the current tile and we move up to generate node B: ``` || == [ B ] == || == [ A ] == || ``` nodeB.x = nodeA.x nodeB.y = nodeA.y – tileHeight + 1 Is that what you mean? The point that you seem to be not grasping is that (however you actually generate the tiles and whatever size they are) you need to use the location of the player within your virtual world to determine what tile you’re on. I’m not sure what’s hard about this. If the tile size is 400 and the player is currently at [3700, -2100], he is in tile [9, -5] (assuming the first tile is centred on [0,0]). Screen-sized tiles wouldn’t be my choice. You still need to load 9 tiles at a time in that case, so you might as well go down to tiles 2/3 the size of the screen (where you still have to load 9), or scale up to tiles 3/2 the size of the screen when you can get away with loading 4. Originally posted by dragon_of_celts:Oh, that’s what you wanted to know? Well, presumably your currently-occupied tile has coordinates to place it on the screen appropriately, and you obviously know the screen/tile dimensions, so I must be misunderstanding this problem — it seems a bit obvious: if node A is the current tile and we move up to genereate node B: ``` || == [ B ] == || == [ A ] == || ``` nodeB.x = nodeA.x nodeB.y = nodeA.y – tileHeight + 1 Is that what you mean? No that’s just what I wanted to know about what you posted. What I want to know is how you actually go about coding this type of generation. Even psudo code might help but no one is really talking about how you can make it so that when a sprite that is holding the movieclips moves to a point where nothing would appear on the screen – it generates a new movieclip so that the player sees new tiles inside the sprite instead of nothing. Also keep in mind the player is always at 400x 300y and never moves. It is the sprite that moves around the player. Once someone figures out how to actually generate the tiles then talking about tile size, or optimization might be relevant but we haven’t really done anything to solve the original problem. You mean like `new bgMovieClip(nodeA.x, nodeA.y - tileHeight + 1)` (where the constructor for bgMovieClip would set the x/y of the newly instantiated MovieClip to the passed-in values)? The player is always at 400x 300y in physical coordinates (i.e., screen coordinates). However, you should have virtual coordinates that tells where the player is within the virtual world (unbounded by the screen). This whole thread is rather silly. It’s pretty irresponsible to try and generate an infinitely growing world in an unbounded way that doesn’t trash tiles at some point without spending most of your time thinking of optimization, especially in flash. Plus I was under the impression that you had the ‘generation’ of tiles part working fine, and you only wanted to ask how to go about knowing if you needed to put a tile somewhere in cases where there would be gaps. That question has already been answered but you don’t seem satisfied, or particularly grateful for the help. I am trying to figure out a way of making the tiles so that the player never sees empty space. I haven’t really seen a way to solve my problem in the thread yet. I am grateful for peoples comments but also a little frustrated that I am unable to explain what I want to do adequately enough for people to be able to help me. I don’t really know how you got the idea that I am ungrateful but I do not mean to come off as that. I figure’d I’d take a shot at it, here is what I made (starts off with a black screen) move with WASD. http://www.fastswf.com/eg4vgeY It creates tiles of random color after the first 9 and stores them in a dictionary. And here is the code: http://pastebin.com/SzwHwC1W E: I should also probably mention that some of the code is rather lazily written, such as render not checking if a tile is close enough to be seen and instead just rendering anyways.