[Discussion] [Game Design] World Generator Same Seed, Different Size = completely different world

[Dan54]

Actual behavior

Using the same seed but a different size generates entirely different worlds.

50X50X5 with seed 20

51X51X5 with seed 20

Steps to reproduce the behavior

Generate two worlds with different sizes and the same seed

Alternative behavior

Using the same seed with a different size generates a similar world

[koosemose]

Is that expected behavior, I personally would expect different world parameters will in fact lead to a different world. And there're other things that need done that would further create a difference (Like not generating asteroids too close to the edge so they don't end up obviously cut off, and possibly adapting the size of asteroids more to the size of the play area, so a small play area will have smaller asteroids and larger ones will have larger.)

[BraedonWooding]

Maybe we could have 3 max sizes (and an infinite) and it would pick the most accurate one generate for that then crop down. I.e. 100x100, 1000x1000, 10,000x10,000; if you pick 50x60 it'll generate a 100x100 then crop downwards (or rather 'cut out' the 50x40 area). Now this however causes problems with asteroids being half cut out (and it's not like we can say just move them into the area). Now this is actual slightly problematic behaviour, UNLESS the size is part of the random generator, because if you have different sizes you'll have different asteroids but not different enemies (if random) or different x, y, and z so it'll be the same in all aspects except things like asteroids. So I think that maybe the crop system like I said could be done but the asteroids still a problem? Or simply we could just include the size for things like random ships and asteroids??

[koosemose]

With, of course, the standard disclaimer that someone else may be able to come up with a better way to do it than I can, but with seed based asteroid generation (in this sense I mean placing the origin point of the asteroid (the seed), and growing it), it is very difficult, without doing some kind of cropping as @BraedonWooding suggests, to have consistent generation.

To loosely explain why, to minimize asteroid overlaps I have to do some calculating trying to find points that are as far away from each other as possible (I am sure my algorithm is imperfect and could be improved, but it works reasonably well.). Additionally, to have any sort of meaningful way to express asteroid density I have to do some calculations approximating the number of tiles taken up by an average asteroid and figure out how many asteroids of that size could fit in the play area. Since world size figures into both of these heavily, that means changing the world size changes the parameters of generation.

There probably are ways to do this by generating the asteroids first on a sort of secondary map, and scaling it up or down as needed, but this then means that asteroid sizes are now relative to the world size (and a non square world will cause more oval shaped asteroids), which I personally would consider subpar.

This also means that, for the time being, events (and anything based off the random seed) will be different, since Random is potentially going to be called a different number of times. Though that can be fixed by using the master seed to seed other random generators, which is something that needs to be done eventually to allow seeds to affect multiple worlds in a consistent way (each world having its own generation seed that is generated at start.

I honestly think the question that needs to be decided is if it is really needed for a seed to be consistent between different world sizes. As I see it, the purpose of having a seed is so that other's can play in the same world as you (or at least with the same starting world)), and if you're changing parameters such as size, then even if the world generates approximately the same, it's not really the same world, just a rough approximation, and is counter to the point of a seed.

[abackwood]

I think the purpose of a seed is to make an otherwise random output deterministic given the same input. There is no semantic element to the seed, it's just a number. If you keep the same seed but change a parameter then the output could be anything.

[bjubes]

I don't see the seed being different on different sized maps as a problem, at least currently. I would imagine later we will standardize on a certain size map based on gameplay and whatnot. Players will be able to change it if they want, but if the default is chosen correctly then most will never change it and seeds will work for sharing and whatnot.

the options for keeping it consistent, either scaling or generating a larger map and choosing a chunk, would degrade gameplay and cause lots of load time respectivly. the first one just seems like an overall loss to quality of play. as for the other, low end machines might take almost a minute to generate a 10000x10000 grid for a 100x100 game, just so when someone else uses that seed its the same?? that seems ridiculous.

[crazyfox55]

There's no need to make ridiculously huge maps for similar game play on different size maps. You should take a look at adding layers of progress to the asteroid generation. This video explains the concept https://youtu.be/GJWuVwZO98s

Basic thing would be to grow asteroids just outside the bounds along with inside ones. Then only display the ones that lay inside the play area. The position of each asteroid would need to be picked in a deterministic order. Blue noise would be able to resolve this if chunks are chosen in a spiral sequence.

[koosemose]

It is technically (sort of) Blue noise now, and since the core is of course only pseudo random, it is technically deterministic. The biggest issue is the chunks, I'm not sure if the density of our asteroids (even on high density generators, but especially on low density) is enough to have the chunks of a useful size (I suspect they would be large enough that generating even one layer out would drastically increase generation time). Of course I could easily be wrong about the chunks, the video was a little too high level to get a clear idea of what is needed to define a useful chunk.

Another issue is that, at least based on the video, that leads to the noise being too far on the blue side, in my opinion we want the possibility for the asteroids to sometimes have clusters of several close together, areas that have almost no asteroids, and even for some to overlap (becoming a single oddly shaped asteroid)

The placement algorithm is essentially standard white noise (UnityEngine.Random) with a simplistic Farthest-First Traversal applied to get somewhat spread out points, but with limited input so it doesn't completely eliminate clustering (intentionally).

I wouldn't be opposed to someone attempting to implement such a feature, but at best it would be a "isn't that neat" sort of feature, rather than something required, as I see nothing wrong with generating differently with different parameters. So long as it could be implemented in such a way as to not eliminate potential of clustering and sparseness and without adding an unreasonable amount of time to world generation.

[crazyfox55]

How about a 2d perlin noise hight map where asteroid pieces are created where the height map is above a threshold? This would produce the same map even on bigger maps. In addition you could set the difficulty by changing the threshold.

[BraedonWooding]

Asteroids would still be cut off with that method?  Unless u scale the perlin map which in that case wouldn't give same result.  I do believe koose actually used a perlin map (tho I may be wrong)

[crazyfox55]

I believe the goal is to have identical asteroid generation with same seed no matter the play area. So scaling the perlin map would be incorrect. A perlin map doesn't have an edge they are infinite.

[BraedonWooding]

Yes but that'll still result in cut off asteroids?

[crazyfox55]

I was under the impression asteroids were still 2d. If they are 3d then maybe 3d perlin noise, I'm not sure.

[koosemose]

It was formerly a 2d perlin noise map, and that looked absolutely horribly, even more so when the map went to 3d, since there was minimal relation between layers. But regardless of that, perlin noise looks horrible for asteroids.