The creature state stored in #210, while quite compact, is also very fragile, because any minor change in our creature generation algorithm or even vocabulary will completely throw off existing serializations.
This attempts to serialize the actual _creature_ created by the generator rather than its random number seed, which will be a larger serialization but also one that is more resilient to future changes in the algorithm and/or vocabulary. It should also pave the way for tweaking generated creatures.
Note that the previous `v1` schema implemented in #210 is no longer supported--i.e., links that use it will now be broken. Hopefully this is OK because it hasn't been around for very long, but it was just way too much work to migrate that schema to the new `v2` format.
This is an attempt to help with #61 by storing the creature state in the querystring.
However, a crucial issue with this implementation as it stands is that it stores the random number seed used to generate the creature. This is great for representing the state in a compact form, but it's also likely to break easily as the vocabulary and randomization algorithm changes.
So, in the future, we might want to represent the creature state by enumerating the actual structure of the creature, which is likely to be a bit more future-proof. (It also makes it possible for us to add features in the future that allow users to tweak the randomly-generated creature.)
But for now at least, this will allow users to use the back and forward buttons in their browser to navigate between creatures, so that if they click randomize and skip past something that looked cool, it's easy to go back and visit it.
Atul Varma