Solamander NFT generator
The Solamander NFT generator is a completely custom work born out of the need for a configurable and tunable NFT attribute generator. It is complete with built-in analytics for rapid prototyping.
But before the generator, there needed to be a system for obtaining the basis score for attribute ranking. How did our team come up with the order of “rareness’ and determine the relative scarcity of available attributes?
Just running a vote to choose which attributes were rarer than others was not quite good enough, because this would only provide an order of ranking without a rarity curve. Instead we chose to rank each attribute with a voting system taking in votes and normalizing the curve per team member. Some people will naturally have a higher overall bias; we wanted the normalized votes to represent the relative perception of rarity between attributes instead of just how much a dev had a hard on for the project as a whole.
The first structuring of the raw votes was an offset per team member that took an average
of all votes per category *less* that member’s highest and lowest votes in each category.
Now each member has a weighted multiplier for their score per category. This allowed finding a global offset for each team member that would center the voter curve, after throwing out the highest and lowest votes per team member per category.
This way, each team member / voter gets to exercise full voting strength over their strongest and weakest category choices, while still keeping the distribution more or less centered (on average) for each category. The fun stuff comes next!
Now that all votes were normalized, the calculation of attribute hitrates for the generator as well as the ranking score for the “Common/Rare/Epic/etc..etc.” bucketing can be quantitatively solved from the normalized votes.
The topology of the RarityRank assignment / Class Rarity Bucketing and generator model is as follows:
The curve we used for Bucketing / Rarity Class identification is below; where the Horizontal Axis is the % of generated individuals with that rarity rank, and the rank is the “Class Rarity Rank (refactored)”
Hitrate calculation was fairly simple, each category has a 100% chance of being hit by the generator when all individual attributes are added up. Some attribute classes have “blank / none” as a potential hit, and an offset is used to “buff” the “blank / none” hitchance for that catagory. By tweaking a single variable, you are able to “buff” the “none/Blank” hitchance. This was used exclusively for the “Spots'' category with our Solamanders generation. The clever thing is that this separate variable automatically scales the hitrates for every other item in that category.
Finally, the “Hitchance” and “Combined rarity Distribution” curves are applied while the generator is running, so there are two separate systems running concurrently. First attribute combinations are generated based off the probability of hitchance, and then those completely generated solamanders are sorted into buckets depending on the rarity bucket distribution. This gives us a large amount of flexibility in setting up the realized rarity curves without reducing the random variations of the universe and its probabilistic “input”. When a bucket is full, a generator output that wants to continue to fill that bucket is discarded. When a bucket still needs to fill, the generator continues to run (millions) of iterations until a generated salamander with a high enough rarity rank is found. By some definition, the rarest of the rare solamanders might indeed have had less than a one-in-billions chance of existing, just like in real life!
Full per-attribute rarity distribution: https://datawrapper.dwcdn.net/QBOS1/3/