Saving the seed

Will Wright (by way of Fraxas) got me thinking about a neat technique I learned a while back for saving simulation runs, or certain other forms of data. The basic idea is to save the seed of your random number generator before you do anything. In some cases, like simulations where there is no user input except for a few initial parameters, you can exactly reproduce a particular simulation run just by setting your random number generator correctly and running the program again.

This is particularly useful for computationally inexpensive simulations. I once wrote a fairly complex simulation whose save files were a mere 24 bytes. The output was much much bigger of course, but it only took a second or so to calculate it all from the seed (4 bytes) and 5 initial parameters.

Game developers have also on occasion used this technique to save the static portions of a randomly generated game world. Sometimes the generated universe becomes so compelling that exploring it becomes the main focus, as in Noctis.

By static portions, I mean the bits whose state were completely determined by the program. For example, you could generate the terrain using a random seed and some parameters, but if the terrain is deformable, then you have to keep track of all the changes the user made. In some cases this is worth doing, but if the user makes enough changes then it eventually becomes more efficient just to store the final state.

Using this technique also requires that you have efficient algorithms for generating things. Using Will Wright's Spore as an example, if the algorithms used to figure out how your creature walks take too long to reach a stable final state, then users are going to be annoyed when their creatures have to spend 10 minutes learning to walk again every time the game is loaded. In this case, figuring out an efficient way to store or compute the walking behaviour is necessary. <rant>Efficiency is still important!<\rant>