In #232, cluster animations were added, but they weren't serialized as part of the cluster design, which meant that sharing them wouldn't copy over the animation. This fixes that.
This also removes "(experimental)" from the animation widget label.
Currently it's possible to generate random clusters (formerly known as creatures), but unlike mandalas, there's no way to _edit_ one if you decide that there's something about it that you'd like to change. This means, for instance, that if a randomly-generated cluster looks nice but needs a hat, or if it has arms you don't like, or if you find something cool in the gallery but want to remix it a bit, you will be able to make those changes.
It also isn't currently possible to randomly generate a cluster with lots of complexity; the data structure to represent a cluster is defined recursively, however, so this editing UI--however horrible this initial version is--allows for the construction of clusters of arbitrary complexity.
Note that the UX for this is currently terrible, but we can improve on it in future PRs.
This fixes#222. Note that it only renames it in the UI, not in the code or the TOML metadata, as that would require a ton of changes, and possibly break old links.
This adds a new `useRememberedState()` React hook that effectively allows us to have user interface elements that "remember" their most recent value, even if the UI itself was unmounted at some point. (It only works for the lifetime of the page, however, so it doesn't remember values across page reloads; this is intentional, as I didn't want to have to worry about serialization or schema migration.)
The hook is now used in the randomizer widget and for some of the creature page widgets, to ensure that their settings are preserved more often than not.
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