I have a chunk generation system using roblox terrain (32x256x32 chunk size in studs) and Im wondering how I should save those chunks for when the player plays on that world again. I know the roblox datastore limit for a key is 4MB which is pretty large for text, but the terrain has text for the position and material for every single cell (stud).
The question is, will I be fine with just saving all the chunks using a single key? Or should I group the chunks into sections and save each section with a unique key? (key example: 0x0, 0x1, 1x0, 1x1, 1x2, and so on for the position of the chunk). I assume this would be better, but I would like confirmation on if I should do this or not, because I don’t want to go through all the effort of writing this key system if it’s not going to work.
If you know the answer, please tell me! Thanks for reading.
Short:
Use as low keys as possible due to other limits, like usage of Asyncs
Long:
If you can save everything in 1 key, save with only 1 key and not split in multiple keys, because there’s also other limits like SetAsync limit, GetAsync limit and such. Assuming that you will need to make other saving mechanics too, you need to use as less datastore keys as possible.
If you want world to be very large, you indeed need chunk system and save using diffirent datastore keys. But, with that, you will need to make system which will load terrain chunk-by-chunk when player is near it and unload when player go further away.
This way, you shouldn’t overflow any limits of Roblox DataStores.
Yes, I actually already have this chunk render distance system in place. I do have an idea though, if the player has not been within render distance of a chunk in a very long time (lets say, after 25-50 hours of playtime) I can simply reset the chunk and unload it from the server. This way, any chunks that the player will likely never go to ever again will not be saved, but all the chunks that are frequently visited will.
This also works because it will ONLY reset player made changes, as the terrain generation will always generate the same basic terrain at that spot. This makes the chunk look completely normal compared with adjacent chunks, I might have to warn the player about this though, as that could completely reset bases they might have left something important at but forgot about.
(this would be very easy to do, because i can just check if the LoadChunkOnClient function has been run on that chunk within the last however many hours)