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.
What I’m asking here is for Roblox to not restrict creativity so much. These limitations (not just data caps) force certain types of games, rather than the kind that people want to make. If it only harms less than 1% of games, like my above example, then there’s no reason for such a cap to exist in the first place.
Local storage could also solve this as well. I would expect local storage to act as a permission request and it would ask to allocate a certain amount of storage space. Said space would also have to be expandable by the game (with another request). But it would also have to be possible for the user to erase the data on their end as well.
These needed improvements to terrain would also help with other optimizations considerably.