Marching cubes is an algorithm used to polygonise a scalar field, for example MRI scans. While it can be used in conjunction with noise to visualize procedural worlds, and i’ve actually done that, it’s not related to OPs map generator. Unless, of course, if OP wants to get away from the blocky look. Despite the name “marching cubes”, the algorithm does not result in cube-like shapes. Rather, the “cubes” part references to a visualization of the algorithm at work, where a “cube marches” through the data, deciding which polygonal shape to place at the given position, based on the scalar data in the 8 “vertices” of the cube.
Marching Cubes Visualization
There are some thing to keep in mind. You can adjust the scale. You can generate values for an offset. And you can mix different noise functions to get a more interresting result.
Adjusting the scale basically means you’ll just zoom in or out of the noise, so you could for example “zoom in” more in lower levels, to generate more land, and then zoom out for later levels to generate more water. Or the other way around.
Starting the generation at an offset, is what generally results in different terrain. When you generate a 10x10 map and start at 0, then the next time you generate this map size, the map will look the same. An offset is like a seed, determining where to start. So you should generate an offsetX and offsetY, and start at [offsetX, offsetY], with the end point being at [offsetX+10, offsetY+10].
Mixing different noise functions can result in interresting patterns, which is often used for 3D terrain generation, since a single noise function generally does not look very interresting for most applications. I dont think this makes a huge difference for now, but maybe have a look at other noise functions like Voronoi, Worley or Blue noise.
In a 3D world, different noise functions would be different “Biomes”, the offset for where you start the map would be your “Seed”, and the scale would increase or decrease the detail level of the terrain (even tho, depending on the sample resolution, obviously a lower level of detail is better, since otherwise all the detail would vanish into below-sample-sized spaces).
That said, there seems to be something wrong with the way you generate your maps, since it always results in this kind of hole to the right. If what you wrote is all you put into the noise function, then you are forgetting about the actual coordinates. The value for each cell can be described as follows (see it as pseudo code example):
Vector2 offset = new Vector2(Random, Random); // chose value from 0-10mil or something each. PER MAP! Not per cell!
float noiseScale = 0.03f; // our noise scale. See what works best. PER MAP! Possibly change between maps if wanted, not necessary tho
for each cell: // in your grid, so it's actually more like a nested-for loop over all x's and y's
Vector2 cellPosition = ... ; // whatever cell this is. From 0,0 to 0,1, .. to 10,10 for a 10x10 grid
Vector2 input = (cellPosition+offset) * noiseScale; // adding cell position to offset results in a unique value per map, based on the offset ("seed"). the scale is applies since even values always result in 0.5f, and also to regulate the "zoom"
float noiseVal = Mathf.PerlinNoise(input.x, input.y); // doing this for each cell would result in a image similar to the above greyscale image, if we were to visualize the output
And i’m sorry, since the comments got pretty long and this makes it hard to read…
which gives you bonus points.
