How can I create a DataStore system for large maps, similar to Obby Creator?

Help and Feedback Scripting Support
1

Hello,

I am currently developing a game where players can create and save their own custom maps. I would like to implement a DataStore system that allows players to save very large builds, similar in scale to what is possible in games like Obby Creator.

Given the known limitations of Roblox’s DataStoreService (such as the 4 MB size cap per key and the API request budgets), I am wondering:

  • How could I structure a saving system that allows maps of large or very large size to be reliably saved and loaded?
  • How can I handle maps that exceed the DataStore size limit, ensuring that no data loss occurs?
  • How should I approach saving and loading to maintain performance, especially when dealing with thousands of parts or complex player creations?

I am aiming to create a system that is scalable, reliable, and can handle maps with hundreds or even thousands of parts, while respecting Roblox’s DataStore restrictions.

If anyone has experience designing systems for saving large amounts of user-generated content, or any insight into techniques that would be applicable in this situation, I would greatly appreciate your advice.

Thank you for your time.

1 Like
2

Well I believe that saving large maps like in Obby Creator, you should serialise the map data very efficiently by only saving essential part properties (like position, size, colour, material) and using mainly compact arrays with rounded numbers to reduce size

When the data grows too large for one key (over the 4MB) it split it into multiple chunks, saving each chunk under a different key (e.g., “Map_Player123_Chunk1”, “Chunk2”, etc.) and then you can simply just reassemble the chunks back into the full map, this method should keep you within Roblox’s DataStore limits while allowing players to save very large data

3

That’s an incredibly hard task. No matter how you look at it, the task is daunting. Let me write out my thought process for you. I’m planning out something on a much simpler scale for my game so this’ll be a good thought exercise for me too.

First things first, we need to determine what they have the freedom to do. Is it place individual bricks, piece by piece? Grid locked models with 4 rotation options?

What I would do is create a list of prebuilt models for the system and give each of them a code. Then, I would give them the labels A, B, C, and D for each rotation.

001, 002, 003, 004, 005…
001A, 001B, 001C, 001D, etc

Then, with the grid in mind, I would determine what X and Z axis these are going to be on. For this experiment, let’s say purely positive numbers with no negative. If the player has a 200x2000 space for their obby, we can say that the point 0x0 is 000x0000. Have it so that that the rotation and placement start at the same place every time (let’s say towards 0,0). If they place the long, 10 by 100 brick at 25,25 set to the A rotation, I would store it in the system as 001Aat025x0025

Roblox limits the length of DataStore keys to 50 characters. That means, with this method, we can store three-part locations on a 1 stud grid by separating the parts with a comma. That should easily support 100 parts reliably without being a hassle storage wise.
Example Key: 001Aat025x0025,002Cat030x0030,001Aat025x0125

You can shrink part size down substantially by replacing 001 with a variable key to fit even more options. Another option could be replacing “XXXxZZZZ” with location spots, like in a game of battleship (Think “Do you have any ships at E4?”).

While a challenge, it’s definitely doable. You can codify the parts in really interesting ways and I’m sure you’ll find a solution that you like. Let me know if you need clarification

4

You can use multiple datastores for 1 map. Which makes the limit infinite if i know correctly.

5

No, roblox just announced datastore limits by 2026.

6

Wont this option flood the database or will this not be a problem because not that many people build large maps?

7

Where did you learn that? If its real is it 2026 by the player or the server? Also even 4mb is hard to get full i think you are exaggerating the obbys data potential.

8

https://devforum.roblox.com/t/datastores-access-and-storage-updates

It has been announced in this post

9

I mean it generally should not be a problem at all because only a small percentage of players will actually create huge maps that need multiple chunks most players either don’t build that much or just save small/medium creations I believe… Roblox’s DataStore limits (like request quotas) are built to handle typical game loads and unless your game has thousands of simultaneous players all saving giant maps at once splitting large saves into chunks it won’t literally “flood” the database

10

Ive actually been creating a system for taking full advantage of every single character that datastores allow you to use, basically allowing to read and write in full binary, though you 100% don’t need full binary for this, but I’m sure the extra characters could help:

Datastores can store like 4,194,304 characters, and there are 128 supported characters you can use. Instead of creating a key for each character (like half of which are invisible anyway), you can use string.char(any number between 0-127) to make a character, and string.byte(character) to read that character back into a number. Both of those are a bit more complicated, but here’s the documentation for them both: string | Documentation - Roblox Creator Hub
If you are clever with this, you can make your own binary system so you can store everything in however many bits you want. I’m not really the most experienced, but this is just something I’ve been working with recently, so sorry if my explanation kinda sucks.

Anywho, that allows for you to use the full potential of datastores, but you can always use multiple datastores per player, just as long as the average player who plays your game only uses 1MB of data, you will be safe from the future limits.

1 Like