Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[miauw62]

Yeah, it's always the simple things. I once had a while(true) {} for debugging at the end of my program and spent an hour trying to figure out why it didn't exit.

[Gatleos]

Spoiler (click to show/hide)

So as it turns out, axial hex to cartesian coordinate conversions aren't nearly as difficult as I thought. Add in a randomly-chosen region of simplex noise on a color-coded heightmap and I have some terrain. If I can use a second noise map to generate temperature or rainfall data then maybe I can make some more varied biomes. Random generation is a hard thing to manage, because you can't control occasionally getting dumb-looking geometric formations without crippling your generation algorithm.

I'm not sure if it would be a better idea to generate forests using noise data or a random-spread algorithm. It's easy enough to compute a hex's neighbors, so if I could find a good one that might work.

[HavingPhun]

So here is how my terrain generation is coming so far, turns out that implementing simplex noise wasn't too difficult.

Spoiler (click to show/hide)

What I did is set anything below a certain height to water. The image on the right is supposed to be a temperature gradient. Darker is supposed to be colder, and lighter is supposed to be warmer. That way, it can simulate poles, and the equator. Currently the temperature does nothing.

I'm not sure if it would be a better idea to generate forests using noise data or a random-spread algorithm. It's easy enough to compute a hex's neighbors, so if I could find a good one that might work.

What I am going to try and do is determine the biome based on the temperature and moisture level, and somewhat based on elevation. For my first attempt I am going to simulate the moisture coming off the water and going onto the land.

What I think i'll do is go through each water tile and draw a line east(for now). If it hits land, it will increase the moisture level of that tile, as it goes further inland, it will give less and less moisture. If it hits a mountain it will stop completely, and the other side will probably be a desert. To speed this up, before I draw the line from the water tile I will see if it is surround by water or if it has land that is adjacent, if it is surrounded by water I won't draw the line from it. That way it won't have to do this process for every water tile.

I feel like this may work. But, I am also feeling that it way end up with some odd looking results, that don't entirely make sense, like too many rainforests, or huge deserts on the eastern side of most mountains, if everything just goes the direction of the prevailing wind.

Spoiler (click to show/hide)

Random generation is a hard thing to manage, because you can't control occasionally getting dumb-looking geometric formations without crippling your generation algorithm.

I am also having some troubles with this. I am happy with the map above, but, I would rather create a map with less water sources, that are larger than the current ones. I might do something that Reelya mentioned above, and sort of grow the oceans, until there are enough of proper size. I might also flatten the small ones into normal land so there isn't so many random tiny ones sitting around.

[4maskwolf]

Yeah, it's always the simple things. I once had a while(true) {} for debugging at the end of my program and spent an hour trying to figure out why it didn't exit.

Hehehe oh man I should not find that so funny but I do.

[HavingPhun]

So, I implemented the moisture simulation that I was talking about, and it does not work as well as I would have hoped:

Spoiler (click to show/hide)

The lower left image is the moisture map, lighter is more moisture, darker is less. Black would most probably be a desert. The way it works is it loops through all the water tiles that are adjacent to land, and then 'walks' itself east, as it goes over more tiles it gives them less and less moisture. It also gives more or less moisture depending on the elevation of the tile. So if it hits a high elevation tile like a mountain, it will not put much if any moisture on the next. But this still leaves large tracts of land without moisture.

So, this simulation of moisture spread doesn't really work. Any ideas on how I could modify it to be more effective in spreading moisture around to more tiles? One solution I have seen used is to just determine the amount of moisture that a tile has by how far away it is from water. This could work, but I am not sure how I could effectively determine how far it is away from multiple water sources. Unless I create water separately from the rest of the terrain by 'growing' it from a node, then its location would be easier to determine.

[cerapa]

Hahaha. Wow, it's interesting to see people retrace the exact same steps I did. I did some tests with the eastward spread. Also with a hybrid, where I alternated eastward spread and regular spreading. If I remember correctly, it did what I wanted, but didn't actually look very good.

In the end I settled on spreading in every direction from water tiles. I also used a noisemap to set the humidity of water tiles to a random value, just to add a bit of variety. I feel that even with terrain affecting the spread, it still looks pretty obvious when humidity travels the exact same distance in every direction.

Spoiler (click to show/hide)

I'm quite proud of my handywork.


But anyway, some tips that may or may not be useful:
-It's generally easier (and actually faster, at least with my skills) to iterate through the entire map, instead of composing lists of coasts and such. The less exceptions you make, the easier it will be to understand what is happening.
-Don't be afraid to refactor your code once in a while to clean it up. Trust me, makes life so much easier after you do it.
-Try to divide the parts up in a logical manner as much as you can. It's very easy to add more stuff, but making sense of it and changing it afterwards is the hard part.
-Use colours. Using different colour channels, you could be looking at humidity, terrain height, and heat, or any other 3 values at the same time. It's easy to spot if things don't add up, and it usually looks really cool.

[HavingPhun]

Hahaha. Wow, it's interesting to see people retrace the exact same steps I did. I did some tests with the eastward spread. Also with a hybrid, where I alternated eastward spread and regular spreading. If I remember correctly, it did what I wanted, but didn't actually look very good.

In the end I settled on spreading in every direction from water tiles. I also used a noisemap to set the humidity of water tiles to a random value, just to add a bit of variety. I feel that even with terrain affecting the spread, it still looks pretty obvious when humidity travels the exact same distance in every direction.

Spoiler (click to show/hide)

I'm quite proud of my handywork.


But anyway, some tips that may or may not be useful:
-It's generally easier (and actually faster, at least with my skills) to iterate through the entire map, instead of composing lists of coasts and such. The less exceptions you make, the easier it will be to understand what is happening.
-Don't be afraid to refactor your code once in a while to clean it up. Trust me, makes life so much easier after you do it.
-Try to divide the parts up in a logical manner as much as you can. It's very easy to add more stuff, but making sense of it and changing it afterwards is the hard part.
-Use colours. Using different colour channels, you could be looking at humidity, terrain height, and heat, or any other 3 values at the same time. It's easy to spot if things don't add up, and it usually looks really cool.

That is a great solution, it's what I will likely implement. If I decide that I am up to it, I way play around with something similar to what is on this page: http://jessekaukonen.blogspot.com/2014/02/generation-of-procedural-worlds-using.html. It's listed about half way down. Though I probably will not do that, at least for now, since it is somewhat complicated.

Also, about the coastlines. I just created a function that checks to see if all of the adjacent tiles are water, or if there is any land adjacent, to determine if it is a coastline. Thank you for the other tips, they are useful, especially the idea of giving different maps different color scales.

[miauw62]

Wouldn't you theoretically be able to just loop through every water tile, so larger bodies of water provide more moisture?

[HavingPhun]

Wouldn't you theoretically be able to just loop through every water tile, so larger bodies of water provide more moisture?

Hmm, I guess so. The way I was looking at it is that it wasn't necessary to go through every water tile for speed purposes, but that would create more varied results.

Edit: As it turns out, it is faster to run it on all of the water tiles. Running it on all tiles took 1.0345 seconds. Running on just coastal tiles took 1.1432 seconds. So either works I guess. I'll just run it on all of the water tiles since it may create more varied maps.

[cerapa]

Told ya.

When calculating fuckhuge datamaps, making exceptions actually slows the processing down.

[HavingPhun]

Told ya.

When calculating fuckhuge datamaps, making exceptions actually slows the processing down.

Yeah, hehe, you were right. Something strange happened. I have set up the moisture calculation to go east, west, north, and south, and will add northeast, northwest, and the others after I do some more testing. The strange thing is that beforehand it was taking ~70 seconds to do the moisture calculations on a 512x512 map. Now it takes half a second.

All I did was change a variable that chose the seed generator for the map generation. Then after being disatisfied with the different seed generator I switched it back to what I had beforehand. That shouldn't effect the speed of the moisture calculations but somehow it did. No clue why.

[Gatleos]

It's a lot harder to get good-looking results when you're working with a relatively small chunky hex map instead of a huge grid like in those images.

On the other hand, it should be much easier to use that moisture propagation. Did you just flood fill from every contiguous water source, reducing the moisture based on terrain type as you went?

[HavingPhun]

It's a lot harder to get good-looking results when you're working with a relatively small chunky hex map instead of a huge grid like in those images.

On the other hand, it should be much easier to use that moisture propagation. Did you just flood fill from every contiguous water source, reducing the moisture based on terrain type as you went?

I can only imagine, I purposely upped my map size since it can sometimes be easier to work with, or at least can look somewhat better at a larger scale. So a smaller hex map must be very difficult.

Though right now, it is crashing because I did something wrong. What I did is loop through every water tile, and draw a line, in every direction(the picture above just draws a line east), and like you said, the moisture decreases based on the elevation. The pseudo code is something like this:

Code: [Select]

Loop Through every Tile
{
   float BaseMoisture = 255.0; //Starting moisture level, amount of moisture the water has.
   float MoistureDivisor; //Used to control how far I want the moisture to be able to spread
   //lower numbers allow less moisture spread, higher levels allow more.
   if(CurrentTile == Water)
   Loop
   {
      CurrentTileElevation = BaseMoisture;
      MoistureChange = CurrentTileElevation / MoistureDivisor;
      BaseMoisture -= MoistureChange;
      Xposition++;
   }
}

The real thing has many more checks to make sure I don't run out of map bounds, but you get the idea. Once I can get it to stop crashing, i'll try assigning the biomes based on a combination of the tiles elevations, temperatures, and moisture levels. I got it to not crash on some smaller maps, and the overall result looked good.

[Gatleos]

Spoiler (click to show/hide)

It looks nice, but the diamond-square algorithm doesn't seem to produce good mountain ranges. It tends to create swells at the center of continents, but doesn't produce a thin mountain range.

[i2amroy]

Told ya.

When calculating fuckhuge datamaps, making exceptions actually slows the processing down.

That said if you were processing a lot of things that used the coastline in addition to moisture (like if you used it for shipping routes, different plant locations, etc), you might be able to get some pretty nice speedup by caching a single copy of all the coast tiles at the beginning and then just using that for your iterations later.