Extended Services Update

MightyDantheman · November 14, 2025, 8:14pm

This DataStore cap is still rather upsetting. It has been stated before that less than 1% of experiences would be affected by this. By that logic, there would then be no need to introduce a cap.

This data cap essentially kills any large-scale UGC world, such as voxel survival games similar to that of Minecraft. I’ve explained many times how awful this is:

Terrain General Overhauling/Additions

Regarding DataStore Caps:

As I’ve said in other related posts, the new data cap won’t harm 99% of games. This, however, will directly harm any form of large scale UCG-type game, such as Minecraft. I’ve done the math and have already considered all of the optimizations that I can, and the data limits then become awful.

Let’s go with Minecraft’s old chunk size of 16x256x16. That’s 65,536 blocks per chunk. I had come to the conclusion that a basic block would be about 5 bytes, so that makes a single chunk a total of 327,680 bytes. This isn’t even including things like mobs, inventories, or other special types of blocks, items, or containers. With the new system, each player will add an increase of 1 MB to the total cap, which essentially means that each player only gets 1 MB (obviously not every player will actually use all of their data, but this is not the kind of game that you want to take those risks in). So that’s about 3 full chunks that a player can save. I should also mention that this isn’t including other data, such as chunk versions, chunk timestamps, which chunks have been loaded but haven’t been modified, etc.

Obviously, there are some things you can do to improve this, such as reducing the chunk height, but now that’s nerfing what was previously capable. Another thing is that players will almost never modify every single block in a given chunk anyway, and, because the world loads from a seed, you don’t need to save anything other than changes. However, that creates a different issue. Do you allow players to claim whole chunks at once, or do you only save blocks they change in random chunks? If doing the latter, the player will eventually run out of data randomly and the only thing they can do about it is undo any of their modifications to the world, which they’d be lucky to find, just think about all of the random mining or explosions that could’ve happened over time. Yes, there’s also greedy meshing (and whatever the data compression version of that would be called), but that also has its limits.

The only way this can be expanded on is with what’s basically a subscription that’s also only in USD, as far as I’m aware. I’ve considered other hacky solutions, like allowing players to donate chunks to other players, but this borders on exploiting the system, as this would indirectly encourage players to create alts to donate chunks to their main account. There’s also plenty of ways that I can nerf the game, such as making chunks far smaller, undoing block changes under certain conditions (perhaps by time, under a certain Y level for things like mining, in other dimensions, etc), and so on. But worsening the quality of the gameplay experience should not be what I have to do to make it work on Roblox.

The only path I see, for a minimally compromised project, is to allow players to pay for subscriptions themselves, which would cover the cost of their world (of a limited size) and support multiplayer better. I’d likely have a system where they can control where they want their money to go with said subscription, such as increasing/decreasing world size, which would control how much they’d have to pay each month. But subscriptions suck and they can’t even play singleplayer without either having a very limited experience or paying for a subscription.

It also hasn’t been addressed that the data cap increases by 1 MB per new player, when a DataStore is 4 MB max. Why is it not 4 MB per player? Not that this would solve my issue.

My project that I’ve worked on, off and on, for years, is now essentially dead in the water, unless I severally reduce the scope of the project and/or sell a subscription to users just to play the game as I had intended it. It might be okay if it were a one-time payment for an increase in storage, but a subscription to play a game is not a good model.

Is this the only solution that we have come to?

I understand that this is technically an ongoing cost for Roblox, but don’t forget that Roblox still takes about an 80% cut.

This is the cost:

$0.12 / GB per Month

https://create.roblox.com/docs/en-us/cloud-services/extended-services#service-pricing

Let’s say that we are to go through with this and I offload the cost to my players. I’d have to create a system to automatically handle data deletion if they don’t keep up with their subscription. If I don’t want to take any cost onto myself, I wouldn’t even be able to offer a forgiveness period. There currently doesn’t seem to be a way to automate this process. I can’t set the exact amount that they’d need to pay with a subscription. I can’t have the subscription they pay go directly to that, I’d still have to pay it directly, after I get paid. A Robux solution complicates things, but still has the same problems anyway, it’s just easier to get closer to the price. Why is there not a Robux payment solution for extended services? This is a whole mess just to make my game playable without severally harming the intended gameplay. Why do I have to qualify for extended services? Why is it USD only? So many things just don’t seem to add up. I don’t want to have to be an indefinite accountant for as long as the game is alive.

As a separate solution, I’d also be open for local data storage. I believe I briefly touched upon that in the quoted summary. I am aware of the risk of user-stored and controlled data, and its limitations are clear, but this would almost perfectly solve the issue at hand. Prompt the player for local storage space while showing the amount desired to be reserved. Further prompts could be given if needed. The player could also remove the data themselves, if they so choose, as could the server.