Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Arkenstone]

A lot of real-life gems have lots of variations in color due to very minute amounts of impurities. At the moment, DF represents this by having multiple different gemstones with similar names and characteristics.

But this creates a few problems:

• Deposits of gems across a site are usually completely homogeneous in terms of variety. Finding Wood Opals means nothing good for your prospects of Wax Opals.
• Dwarves which prefer one variety care nothing about any others. (Not necessarily a bad thing, but still.)
• Rare sub-varieties have to be shoehorned in with ENVIRONMENT_SPEC and CLUSTER_ONE under separate raw entries.
• The different entries for sub-varieties of one variety of gem are easy to get mixed up among the other gemstones, becoming a pain to find. (Especially if you don't know they exist.)
• Fine-tuning the balance of frequencies between different varieties and sub-varieties requires a fair amount of algebra.

So, I thought that if the different sub-varieties could be grouped together somehow, then most of these problems would be fixed; and I realized the framework for such a solution already exists in creature castes.

If gems had something akin to castes, then things could be a bit simpler.  All variations on a gem would be in one place, and it would be easier to mod and generate. The different varieties can still be treated as different substances, just like materials (bones etc.) from different castes.

Let's call this the [VARIETY:<gemname>] tag.


Other than the appropriate tags for describing the different attributes of each variety, there is one additional tag needed:
[VAR_RATIO:<X>:<Y>:<Z>]

Now, it'll take a second to explain this. First, I need to describe how I figure varieties fit into worldgen.

Worldgen should proceed as before up until the point where a gem is to be chosen as a mineral deposit (however it is that is done). At that point, a new step is added: choosing the primary deposit type. This is where the first number comes in. One variety is chosen as the primary variety; the assumed basic variety for the entire deposit. (Figuring out which works exactly like figuring out a caste with [POP_RATIO:<X>] tag.)

The second two numbers come into play when it comes time to generate individual tiles. You see, each individual tile has a <Y>% chance of being the primary variety, where <Y> is the second number from the [VAR_RATIO:<X>:<Y>:<Z>] tag. (I figured that some varieties could be more homogenous than others, so it's better to leave the option open.)

If a tile isn't filled with the primary variety by this method, then the variety is chosen at random with the third tag, again treating it just like a caste's [POP_RATIO:<Z>]. (I know this allows for it to be the primary variety anyways, but it doesn't have to be perfect.)



Doing this would fix all the problems mentioned above save #2, which is still easier to fix because of it. There's lots of room in that one tag for a large variety of different distributions. Some varieties might only occur when they predominate a deposit, others could never be the primary variety. One could have a variety that is dominant in name alone, falling back on the final random choice each time (i.e., <Y>=0). And best of all, there's more variety to the gems your dwarves find mining.

[GreatWyrmGold]

I like this idea, especially if there could be a few procedurally generated rare gem subtypes per world.

[breadman]

If this will reduce the number of tasks available in the jeweller's workshop, I'm all for it.