I find myself a bit stuck with getting myself a level or environment to render using libGDX. I have sprites that can move around in various different ways (mouse/keyboard), but it's a bit boring on a plain old black screen or a level created in Tiled.

I have worked out how to render a map using TiledMap and the program called Tiled and I understand the process, but I would prefer to work on doing some procedural map generation and I'm pretty well baffled as to where to start. I've looked for hours and hours online, just purely looking for resources, but not doing any work what so ever, and it's all narrowing down to 1D or 2D Simplex or Perlin noise generation techniques for top down 2D game with several layers of height. I understand the concepts, but as far as the implementation goes, I can't help but feel like a bit of a dumbo, I see posts on forums talking about it all, and it feels like those talking are already way ahead of where I am at in regards to procedural generation of terrain.

I want to get the ball rolling and start seeing some kind of progression, because right now, it's very disheartening that I just don't seem to be getting anywhere. I'm not as smart as most people on these forums (or at least not feeling very smart right now), and I am nearly always tired and burnt out from my day job and gym, so perhaps that's why I'm finding it difficult to wrap my head around things, I dunno, but I feel as though I need to ask for some help and guidance here.

So before I go to bed, I just wanted to ask where should I get started with 2D procedural terrain generation using libGDX?

At this stage, I would be happy to be able to generate just land and sea, or even just grass and sand or just 2 of something. (Just want to figure out the base level of terrain generation and expand from there, just like learning the base level of programming in general, then expanding from there). I just have to keep plugging away at it like I've always done and be confident that I will eventually progress, even if right now it feels like I am not getting anywhere.

I have a day off tomorrow, so should be able to focus more on getting this done and working

Using the diamond square algorithm, I have got myself some lovely randomized terrain.While it's nothing too spectacular to look at (since you've all seen it before many times!), I feel it is a milestone

Next up, I just need to do some frustrum culling, putting textures into an atlas, map controls, and perhaps even a map generation ui, before I move on to other things such as generating transitional tiles (auto-tiling?), randomized objects based on terrain type, and other cool stuff

Yeah, looks really good, though its not done yet, I see small dark pieces random in the water and its a bit angular/rugged. However, we see a pretty nice 'world' instead of one big grassfield!

Yeah, that is partly due to my threshold values on where terrain should be. Since they are float values and 0.001 of a difference can determine if a tile is grass, or sand, it means every now and then there will be odd tiles. I plan on doing some research on how to refine the terrain even more without losing it's larger details. The code has smoothness control, but smoothing will smooth the ENTIRE terrain out, rather than averaging out smaller details.

Could you post your code for the terrain generation? I've been struggling with noise generation and am interested to see how you managed to implement it in one day!

Well, I wouldn't say one day, perhaps 1 day of coding, a week of pulling hairs out of my head trying to find something appropriate to learn from.

It's difficult to just post a whole bunch of code, as most of the code I have is horribly unoptimized and messy

I will say that I came across various articles on simplex noise, perlin noise and mid-point displacement/diamond square algorithm, and all of it, I found myself dumbfounded.

Diamond square was the easier for me to understand but. It really just seems like it is subdividing a square, over and over, refining the details, but also adding it's own random variations on sub-division.When I fully understand how it works, or find a simple explanation given, I will be happy to share it! This article is what seemed to explain it quite well, and what every other person points out as being the best resource to learn it (still not easy to read when you're super tired and frustrated but)http://www.gameprogrammer.com/fractal.html

While he/she uses Artemis or some entity system (and I didn't), I couldn't really follow along with his tutorial, but the principles still applied, I read through his code, tried to understand it, and how I could apply it to my already existing code, and then pretty much did a copy/paste (typed out what he had really, as copy/paste doesn't really help you learn I find...) for the sake of prototyping.

He does the mid-point displacement differently to normal due to limitations (as he explains), and it works well.The same sort of class could be made for Simplex and Perlin noise, as there seems to be a few people out there who have done a code dump of the actual noise generation code. You just need to store the information in an array using a series of numbers, by setting threshold values to determine what int value goes where on the array(depending on how many textures you have I guess).

Essentially what the code is doing is filling the float[][] map with float values using a modified diamond square algorithm, then it averages the values out so that they are in a range of 0 - 1f (I believe that's what it is trying to do), before iterating through the values and using the set threshold values to determine what int values go into the int[][] returnMap.The threshold being this code here:

which determine the int values down here: (This snippet basically iterates through the float array, asks what the value is at that iteration of the array, and then checks to see if it is below one of the threshold values to determine what int number we assign to returnMap).

He also creates a getter class used to get the mid point displacement map.

I will show you the not so messy part of my code which determines what texture goes where

Bare in mind, w and h determine the location of tiles on the screen, and they have (float) (x * .5); assigned to them as I have scaled the textures down using a scalex and scaley, which are float values of 0.5f.What you see in the video shows the scale of the textures are 1f scale, therefore that w = (float) (x * .5) business is normally something like w = x * 32 / 32 or something like that.It's just because of the way i'm doing things is not very optimized or object orientated just yet, that my code is a nightmare to look at since it is just a direct approach to prototyping everything.

If you wish to view my entire messy code for my "WorldRenderer" class, just because I know the more code, the better when studying something, here it is (I hold no responsibility for brain aneurysms as a result of crappy code ):

I still haven't gotten frustrum culling in yet, mainly because I have been busy all day and tired when I sat down to do some programming, but I did pop my textures into a textureAtlas with immediately improved framerate.

Wow thank you!! I'm still a little confused as to how the algorithm works exactly but I'll take a look at all the resources you linked and hopefully I'll be able to implement it in my game too! Also, why do you think your game is so slow? Just because you don't use frustum culling? I'm a little confused. Don't you use frustum culling for 3D? Since you only have one plane to worry about can't you just check to see if the tile is within the limits of the screen?

Yeah, the algorithm is still a little confusing, but less confusing than Perlin and Simplex (although simplex is supposed to be easy to understand). I didn't bother to try and understand those algorithms. But I will

And it's running slow simply because it's running every single tile on the entire map, on every single frame, at the moment, it's trying to render over 50,000 tiles each frame (depending on the size of the map), if I cull out what is not on the camera, then i'll probably only be rendering maybe 5000 tiles or less (depending on zoom level, the zoom level I want for my vehicles i'll probably only be rendering around 2000 tiles + whatever objects I need to render with it.The video also runs horrible because every tile texture was a seperate texture object, so draw calls were quite high. I popped the tiles into a texture atlas using the texture packer that libgdx comes with, and the frame rate doubled just from cleaning up my code a bit and packing my tiles into a textureAtlas

Frustum culling is still used in 2D space too I believe. So that is the next step.

Without really looking up any techniques, I was thinking of maybe creating a bounding box for the camera, and setting bounding boxes on every tile, or perhaps bounding boxes on chunks of tiles, and if those bounding boxes overlap, then I should render what is inside of them, otherwise don't render.I will see if I can try this tonight, but I think right now, I seriously need to clean up my code, make it more object orientated, as currently it's a bit of a mixture from several tutorials (which don't use very good object orientated programming techniques )

There is probably a better way to do rendering, but I guess half the fun is trying different techniques out. I'm also looking into how to store map tiles so that they can render as chunks, like how minecraft and other procedural games load in their terrain.

I would recommend using a quadtree to speed up the rendering checks. I would then only check chunks on the outside of a tree node to see if it needs to be rendered or not. I'll have to look into 2D frustum culling I guess I never thought about that! Can't you just check if the tile's position is greater than the screen and maybe factor in the offset of the tile somewhere in there? I guess that is frustum culling... Hmm can't believe I never thought of that!

Ah ok, thankyou for correcting me, I honestly didn't know :OI just kept seeing the term oct-trees being used a lot when people were talking about rendering chunks of a map.Thinking about that now, all of the references were made in relation to games like minecraft, not a top down 2d game -_- (massive durp!).

So quad-trees makes more sense, I shall read up about them, thanks for correcting me

I was reading before about using a chunk of tiles to create one texture as you just described I was thinking about getting to work on that tonight, but so far, all i've done today, other than a few little optimizations and uploading a youtube video showing results, is reading, reading, reading

As for what I am going to do with the terrain, I won't say just yet, it is a mystery for the time being. But my intentions are obvious to make something awesome and fresh to the gaming scene (no surprise there!).

Clearly though, it involves sea-faring, and procedurally generated terrain. As I develop this more into a game, more will be revealed, but until I have something that resembles an actual game, I won't be saying exactly what it is, as much as I would like to

After some (light) reading, I am not sure if I should use quad-trees or something else just to render the map itself.Quad-trees seem to be more so really for any entities on the map such as tree's, plants, players, moving sprites etc, am I correct?

Currently, if I up the n value of the terrain generation class, it slows things down a hell of a lot, even changing from 7 to 9 slows my fps down dramatically, despite still only rendering tiles within the view port. I do wish to do massive sized game worlds that take a very long time for the player to traverse, and I think the only way i'm going to be able to do that is rendering in chunks. I just have to work out what the best way of doing this is. Is quad-trees sufficient for this? Or should I use some other method?

I understand the concept of quad-trees, it's pretty straight forward, but once again, it's the implementation that has me scratching my head (although, I haven't really TRIED to implement it how I think I would yet).

Currently, this is my code to render tiles within the viewport for those interested:

Basically the code is saying that upon that iteration through the world map, if the tile location is within the constraints of the viewport (x0, y0, x1, y1), then draw the tiles to the screen, nothing too fancy going on here.

I've noticed that you aren't disposing of your tile textures, causing memory leaks. Also, you should just load a big spritesheet with all of the tiles on it, then get texture regions for the tiles. Other than that, looking very good.

I was considering using switch statements, but wasn't too sure if they would be as efficient with this sort of things. I actually really like switch statements, having used them in a procedural story generator I created, I just wasn't sure if people really used them for map rendering.

As for iterating only what is inside of the viewport, I don't know why I couldn't quite figure out what to do, but then before bed last night, after a few american honey bourbons and coke, it occured to me that I was checking through every single tile on the map to determine what I should and shouldn't render, so therefore the larger the map, the slower the performance, so proceeded to do exactly what you have here (literally the same), and it works a treat.Seeing your post this morning with the added suggestion of using Switch statements helps clean up my code and hopefully run better too.

Since last night, I am able to render massive worlds (which is obviously a longer load time) with the same realtime rendering performance as a smaller world as i'm only checking tiles within the viewport.For those who like numbers, previously, it struggled to render after generating 6,296,577 tiles, now it is able to render after generating 235,960,321 tiles, and probably more if the terrain generator wouldn't run out of heap space.It spits out the message:

I will still look into quad-trees some more, as I know I will want to use those for entities etc

The wiki seems to be a great resource for this so far, there are a few other websites out there talking about quad-trees, and videos of people showing them off helped me understand in about 10 seconds how they work, where as reading about the quad-trees initially had me scratching my head

The wiki does show the pseudo-code for implementation however, so I will create a class and toy around until I get something working some time.

Also, Hugo Elias's "Perlin noise" is not Perlin noise. Read Ken Perlin's presentation if you care what Perlin noise actually is. Simplex noise was also made by Perlin. Different types of gradient noise are often interchangeable and the concept behind the algorithms are simple, yet it is not necessary to know it. It is absolutely important to know what "Perlin noise" is NOT, so you can wrap your mind around the various totally different concepts people describe which people think are related to Perlin noise. Then you can look at the algorithms as something totally unrelated and just disregard the Perlin part, docking points based on how absurdly they get the terminology wrong.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org