Hello! This project was originally made 2 years ago, but over the past couple days I have optimized and polished a lot. On mid graphics quality it uses around 20% while moving, and around 12% standing still however I’m working to optimize it even more.
Included below are some pictures and videos of it, as well as the link to the game.
https://gyazo.com/7a1377d4f725ed963c3f8a1ce01454a
Biomes (TESTING)
Linked here is a better explanation of the math behind this
Feel free to leave feedback and questions below (maybe a like too), i’d love the hear it. Oh and by the way! If you do play the game make sure to keep your eye out for the rare structures! You’ll receive a badge if you find them.
Also, a special thank you to Grersh, Synthlax, and ChallengeDev for helping play test
6 Likes
Big fan of the tweens for the terrain that’s spawning in. This is super cool.
You should try creating biomes with different colors of grass just for a problem to solve.
2 Likes
Awesome stuff, criminally underrated. Mind sharing how you did this and the math behind it?
1 Like
Thank you! To optimize it I lerped it in a loop, for the objects in a set of 8 and a the land in a set of 30.
Also, I was thinking about biomes, it may be hard but i’ll do my best and reply to you again if I add them.
Hi, for now i’ll just go over the simple math, the triangle stuff is very complicated and even I don’t completely understand it.
-
This part basically just works like a cubical terrain generation. Every half a second or so, the render script snaps the position of the HumanoidRootPart to the chunk grid and sends this point as the origin to the “Render” function. This function generates new chunks within the render distance around the given “Origin”.
-
So basically, every 4 triangles you see in that square type pattern is a chunk, split into 5 parts. I use perlin noise to calculate the position of the 4 corners of the chunk, and the center is just the average position of all of them.
-
After this, I use a bunch of complicated math to connect all these points using wedge parts. (Btw these wedge parts are averaged with the other colors around them and then randomized a bit).
-
Another thread checks for chunks outside of the render distance and deletes them when they get out of range (Settings their parent to nil or replicated storage causes more lag and also keeps the part in memory, which can cause a lot of problems in an infinite world).
I also would like to mention something I discovered that many games have to deal with. This has to do with the fact that the farther you get away from [0,0,0] (aka the world origin), the harder math becomes. This is because the farther you get from world origin, the larger the numbers you have to deal with become. Now me, (being the smartest man in the world of course), just said “Well why can’t I just do the calculations at world origin, and then reposition the chunk later?”. And this ended up working brilliantly.
Now a fellah named Valurim said something interesting, while this works in my game, in a lot of space games such as Kerbal Space Program, they move objects around the player. This stops floating point errors as well as the issue described above.
Now, if you have any more questions or thoughts don’t be afraid to ask.
Hey, I tried this out with biome blending and it looks great! I may implement it after playing around a bit more.
Wow, that looks really neat. I love the smooth gradient as opposed to a hard transition.
1 Like
I was playing it then all of a sudden there was a red flash and the music became distorted, was this intentional?
1 Like
Because I used perlin noise to generate biomes, I was able to tell which biome was adjacent to it using “biome_strength”.
The only concern I have with this is that it isnt very random and some biomes show up more than others.
*If anybody has any better ways to do this I would love to hear them, as I don’t think my method is the best
