electronic storage is really optimized, from the hardware end, your phones capacity, to the software end, how the information is stored.

It is not downloaded. It is generated locally by your computer.

The worlds are generated in chuncks. And the chunks are based on a random seed. The same random seed will generate the same world every time.

A bunch of clever stuff goes into that! The entire world isn't really there at one time. Only the area you're in, and it will dynamically load the other areas when you get near. Reuse of assets and textures and stuff can make things way more efficient to store (e.g. storing one grass texture for every grass block in minecraft). Storage is just really optimized so you don't have to save a lot of data to represent the state of the world; just enough to rebuild world when you need it

Minecraft is procedurally generated. The world does not exist if it isn't loaded because you are in that section of it. Every time you load a section, the game uses the seed to rebuild that section based on a set of rules.

For example, the rules might say: start with bedrock here. If the seed value is X, put stone above it. If there are Y number of stone blocks within such and such distance, the next block should be magma. If there are such and such magma blocks, put diamond ore. If there are already diamond ore blocks within a distance, or Redstone instead. When it's at least so high up, put dirt.

Every chunk is built like this, based on the seed. Since the seed stays the same, the world can be rebuilt to be exactly identical every time you load in. When you make changes to the world, the seed is changed to make sure the change you made appears the next time.

It's like, instead of someone memorizing an entire story, you just give them a title and they invent the story as you go along based on that title. When you leave, the story is forgotten but you save the title. The next time you want that story, you give them the same title and they follow the same rules and end up creating that exact same story from scratch.

How do player-initiated changes to the world get persisted? Is it just as some kind of diff relative to the generated world?

[deleted]

That doesn’t sound right.

Finding the seed that yields a specific world plus a specific set of user changes would require a brute force search of all possible seeds, which is completely infeasible.

Even if you could do it, the encoding would be no more space-efficient than an optimally-compressed diff.

Yes that's how it is usually done. Either you simply store any chunk the player made changes to and just load that again, or you only store the changes and apply them after generating the untouched state of the world.

The "chunks" that have been modified in Minecraft get saved to the storage. So, the more you start changing things in a Minecraft world the bigger the save file gets.

If I got your analogy than that is not true, not every possible world has an associated seed, there are far more possible worlds than there are possible seeds.

[deleted]

To me your analogy sounds like changes to the world (=story) are saved by changing the seed (=title) to a seed which generates the changed world. But there is no seed that will generate a world with my oak plank house in it. Maybe I just got your analogy wrong, I believe we both mean a similar thing.

Ahh I think you misunderstood my original question. I wasn’t asking about how user-specified seeds are handled.

What I meant was, when I mine/build/craft, altering the state of the world, how is that new world state persisted (since the results of my actions would not be present in the procedurally generated chunk)?

No, as there are many world-states that don't correspond to any seeds because not all possible states can be baseline in a seed.

It's more like keeping the title of the story the same, but you also hand them a piece of paper with instructions for them to apply modifications to the story after they finish generating it. "Change John's name to Joe", or "Megan died of influenza instead of pneumonia", for example.

>When you make changes to the world, the seed is changed to make sure the change you made appears the next time.

Okay stop, this is complete ignorant nonsense. That's not how seeds work. You're proposing some sort of mechanism that could losslessly compress several hundred K of arbitrary data into a single number. Not only is that not how Minecraft works, it's literally impossible.

How Minecraft actually works is that a chunk is generated once when it's initially discovered, then written to disk. Any subsequent changes to that block are written to the save file.

Minecraft is honestly a pretty bad example - it's procedurally generated, so there's no "world" the game has stored beforehand, just the rules of how a world can look. Most games aren't like that though. Adventure games, shooters, RPGs, usually have hand-crafted worlds with very deliberately placed features.

And these are large. Many modern games are 10s or even >100GB in size, most of which are world files. But there are still clever tricks to keep the size smaller than it would be otherwise. Small patches of textures can be expanded to larger areas, terrain in the background can have lower resolution, and so on.

And finally, the storage density of modern electronics is just extremely high.

Minecraft specifically is procedurally generated. The game world basically consists of a bunch of mathematical algorithms for how to generate the world based on a random input, these are part of the game code and relatively small. That random input is distilled down to a single number called the seed, and using that seed you or any one else can recreate the environment assuming they have the same algorithms (ie. a compatible version of Minecraft). Individual changes the player makes to the world are then stored in the player's save file. But beyond that, the game world can extend almost an infinite amount using the same world generation algorithms (though you might get some oddities once you reach certain practical limits, hence Minecraft enforces an artificial boundary).

Most games do not use procedural generation, their worlds are hand-crafted or at least pre-determined. Even in this case it's not necessarily a problem to store a large world. The game's data might say, this map is 100x100 "virtual metres" and brown, and at coordinate 0,0 is a 2x2x2 metre red cube. It's just a few numbers, it doesn't take much space. Similar to procedural generation, all you're really storing is instructions for how to render the world (you're storing more numbers, but the algorithms for turning the numbers into 3D objects are far less complicated).

Now change the map to be 1000x1000 "metres", and the cube to be 4x4x4 metres. The map is an order of magnitude larger, but all you've really done is change some numbers; you're still using the same amount of data to describe a much bigger world. So the size of the virtual world doesn't really correlated with the amount of data needed to describe it.

What does increase the size of the game data though is complexity. Instead of a single cube, maybe it's thousands of triangles in the shape of a house. It's no longer a solid red colour, but it has detailed wood and brick textures. And the map isn't a 1000m^(2) flat plane any more, it's a realistic terrain with hills and valleys defined by a height map, littered with trees of varying heights at different x,y coordinates. Now your game world needs far more numbers, and other data like texture images, to be stored.

Portable devices today can easily store gigabytes of data and have relatively powerful processing capability; but even so, game developers need to ensure they balance graphical detail with the hardware resources they have available.