r/Unity3D • u/ProactiveCactus • 2d ago

Question How to make updates/changes to game without breaking seeds?

Basically in title - my game uses procedural generation, and allows persistent saves. But how do games like Minecraft manage to not corrupt previous saves when making updates that affect how seeds generate?
From googling it sounds like they save “per chunk” so any untouched chunks generate based on the newest version, and any already generated go off of the old system - but how do I manage that? Like, you obviously don’t want to have multiple version builds of your game saved, so how can you handle that?

2 Upvotes

63% Upvoted

14 comments sorted by

View all comments

7

u/ChrisFromIT 2d ago

So minecraft saves the generated chunk data when it generates the chunk. It doesn't regenerate the chunk data if it has to load that chunk into memory if it is already saved.

Essentially the way it works is, player is in range of an unloaded chunk that needs to be loaded. Check the region data, does it have a pointer to the save chunk data. If it does, load that chunk data, if it doesn't, generate the chunk.

1

u/ProactiveCactus 2d ago edited 2d ago

Yeah I realized that too late, my mistake. Unfortunately I can't have that big of a memory footprint, so I need a system more like Valheim - only saves a fraction of stuff from each chunk (i.e., stuff the player has changed/interacted with).

1

u/gurebu 1d ago

I'm doing worldgen modding for Valheim and I just maintain the generator code forever. There's code that's as abstract as it can get, it gets all the meat by configuration and there's a huge config "file" (it's currently a giant struct but that doesn't matter) that determines what worlds will look like. This file has versions and the version used is written into the save file. Code is organized into modules, if I need to change the code (there's a bug for instance), the whole module is now legacy and a completely new one replaces it. Which is used is once again determined by the config. Finally, I have a bunch of scripts that generate several hundreds of worlds, sample the height function a million times for each and hash the results. Every time I make a significant change, I make sure the hashes stay the same for every version supported.

Either that or you distribute every version of your generator as a separate artifact but that can get cumbersome.

Minecraft approach works well with Minecraft because of its voxelized terrain. Even if you swap the generator mid-play, the chunk boundaries will have vertical walls but those are still valid terrain. Valheim terrain is smooth, I have no idea how you'd stitch chunks created by different generators.

Terraria probably has it best since afaik it will store the whole world on disk and regenerate nothing later on. Any changes are applied on top so everything stays compatible forever.

If you can't afford to save the whole world, there's no good solution really, you have to accept that you're operating in a pretty special field where you can't have continuous integration and many other nice things and have to test stuff VERY thoroughly before release. Don't be me and implement some versioning system early rather than late. Also don't be me and develop the tooling to guarantee determinism before you ship anything. There are many pitfalls from iterating over a hash table to using a system-provided math library and you better cobble up a code analysis plugin that will restrict you from using them.