Did I? Their method was vague and I’m not sure where I defended it. Sorry for the confusion
3 choices.
1, You can drop them all at once as square blocks that aren’t visible. Then as someone gets close, it just makes it visible and changes it’s mesh to look complex. Like how buildings in Open world games are just blocks until you get closer.
2, But to me, I think you would be best off just rolling if it’s a Bronze or not. If not, roll if it’s a Copper or not. If not, roll if it’s a Silver or not. If not, roll if it’s a Gold or not.
3, Either that or have 5000+ entries in an array, and get a random value between 1 and array length.
Just test all 3 and see which one you like best. Make a test map. Run each choice and look at your performance and see which is running most efficient.
You just have that for each layer you are on. If surface then. You can just have it as a function. You can even have it as a separate script that’s just required. It just needs to output 1 value. Bronze. Gold. Whatever.
Just test all 3 and see which one you like best. Make a test map. Run each choice and look at your performance and see which is running most efficient.
It’s impossible to see which one is running most efficient in this scenario. You have to calculate the Big O notation here. Rolling a virtual dice for every single possibility for every single generated block is horribly inefficient.
1, You can drop them all at once as square blocks that aren’t visible. Then as someone gets close, it just makes it visible and changes it’s mesh to look complex. Like how buildings in Open world games are just blocks until you get closer.
Also very inefficient. There’s several issues here.
- You must keep track of the magnitude between the player and each block
- A new block type is picked every time a player get’s near posing the issue of replication to other players i done on client, or if done on server, terrible drops to performance.
3, Either that or have 5000+ entries in an array, and get a random value between 1 and array length.
Large data entries can be found in almost every game. Metadata has to be stored somewhere. Either in a script or in the form of physical values (NumberValue, StringValue etc). I highly doubt you will have 5000+ entries to a table. Just simply split the metadata into module scripts for different areas? I.e a module script dedicated to the “Winter Biome” and have a small table of say 20 entries inside. This would make compartmentalizing your data extremely easy.
Another comment is that having many values in a script can’t be judged on efficiency as they’re simply static values stored in a static table. Efficiency comes into play when you write the algorithm to pick a random block.
I’m only giving constructive criticism in such detail because I’ve run into the same questions and had to tackle the same issues. Don’t take it the wrong way 
1 Like
Yeah I’d go for the array idea. Seems the simplest to me. I don’t know how I would do the check for where is spawns though.
From my understanding, in games like MineCraft, the blocks are an array and it creates the blocks based on how far they are away. Mine Simulator seems the same since you can dig into someone else’s area. Maybe it’s an empty array where the blocks aren’t established until someone digs a block out.
But if it’s like a cave and ore is spread out on the ground, like in Subnautica, then that would be more about the spot being in range of the player. And in that case, it’s spawning at the edge of vision at a random offset to one side.
That’s the bit I would have trouble working out.
Minecraft’s block creation doesn’t have anything to do with the distance from the player. The map is shown to the player depending on the players RenderDistance. That’s why you see chunks loading and unloading. That’s in place to simply mitigate the lag of the game. The same goes for generating terrain in Roblox. A simple math.noise equation can be used to create a very simple random map. You can simply iterate through every instance of a block and then use the algorithm to determine what block to place.
Yeah it all depends on what sort of map it is.
I usually achieve this by defining an abundance function for each ore type, that returns a number representing its relative abundance at a specific point in space (or in your case, the depth). This gives you a lot of flexibility when it comes to the specific way that each ore occurs. If you want “veins” or “clumps” of coal, you can use math.noise to determine the abundance of coal. If you want chalk to occur in thin “layers”, you can again use math.noise but ignore the x and z coordinates. If you always want diamonds to be near coal, you can use the abundance of coal at any point to determine the abundance of diamonds at that point. If you want dirt to be replaced by stone at a specific depth, you can return a weight of 0 for stone above that depth, and a weight of 0 for dirt below that point. The sky’s the limit!
Once you have defined all your abundance functions (e.g. abundanceCoal(x, y, z), abundanceDirt(x, y, z), abundanceDiamond(x, y, z), you can pick the ore type at a given coordinate by putting all the material weights/ abundance function outputs into a table, and choosing the ore type from it in exactly the same way as other people have suggested.
This way of doing it can also be deterministic, meaning you can generate the same map every time based on a seed, if you want to.