Describing Color

I've always loved colors. Madly. The paint swatches, and their improbable names, always gave me great delight. Color has always been a part of my world-building "requirements", up there with materials.

Color is currently in-game by using shades, which are really just text snips that can complete the sentence "The sky is _____". So sometimes it's a recognizable color, like "blue," and sometimes it is descriptive, like "caramel colored". These are sorted, somewhat arbitrarily, into tables by color family. Here's the beige one.

Table of Beige Names
Color name
"almond colored"
"barley colored"
"beige"
"buff"
"champagne colored"
"dust colored"
"fawn colored"
"khaki"
"sand"
"tan"
"taupe"
"tawny"
"wheat colored"

This is actually surprisingly workable from a coding and text perspective. The game can pull the shade of something at any time, so generated description text can always discuss the turquoise sky or the steel gray storm. Since shades are grouped by family color, it's relatively easy for the game to randomly assign a new shade within the color family, so the clouds may be silver one afternoon, and iron gray the next.

There are some things that are sacrificed in this model, though. First, many colors are close enough to fit into more than one family, or at least different families depending on who is assigning them. Consider the color rose. Is it pink? Red? Both? What about fuchsia? What about magenta? Listing colors in more than one family can cause serious errors; because there's built in checks to determine what family a color is in, a double-listed color can "jump" the object from one family to another.

For example: So much depends on the red wheelbarrow, whose shade is "tuscan red". If "tuscan red" is listed as an entry in brown as well as red, the red wheelbarrow may well show up in lists of brown objects. (Well, not currently, but if I used definitions rather than decisions . . .) Game breaking? Probably not, but not the sort of thing I want floating around.

So borderline shades are a little arbitrary.

Another downside is that it's hard to determine intensity and hue. "Olive" and "viridian" are both green, but only one is an appropriate color for new maple leaves. One solution would be smaller families of color, and overlap them:
To decide if (S - an indexed text) is green:
repeat through the Table of Light Green Names:
if S is the Color Name entry, decide yes;
repeat through the Table of Medium Green Names:
if S is the Color Name entry, decide yes;
repeat through the Table of Dark Green Names:
if S is the Color Name entry, decide yes;
decide no.

This only creates more border cases, though. And then do you need Tables of Intense Light Green Names? This could quickly get unworkable.

I wonder how difficult it would be to set up a system with color values that included enough information to:
- do intensity work (intensify, deintensify)
- do graying (is this saturation? hue?)
- combine colors (if you mix red paint and white paint . . . )
- tell a html page the closest color, for display purposes*

This might indicate a need to change colors from text values to their own value (either named or numerical with a text string). I suppose I could use straight hex values, but I suspect that would cause me trouble. Better might be a xxx.xxx.xxx format using numerical values, or a list.

The downside would be that it would concretize what a color "actually" is. I may have a different idea of goldenrod than another player, but the game would only reflect my sensibilities. I generally think players can suck it up. Also, of course, in terms of actual gameplay, what does it add?

It would make it possible to mix and use dyes in a sensible way; actual dye color would depend not just on what the dye was, but how much was used and what it was mixed with and whether a mordant was used. That would be *cool*, but would it *add* anything?

It would make it possible to do neat things with weather and time: sky lightening and darkening throughout the day, growing grey with clouds and ominous for serious storms. That would provide a use for sky watching, especially if it was integrated into part of the UI. (I'm thinking a band across the top of the game screen with essential information; the background might indicate time and weather conditions, with player status and other essential stats in a contrasting color.

It would at least float the possibility of the player being able to choose their own color schemes for maps and such.

It would allow for realistic color aging and decay of colored objects from sun exposure, age, rust (?), etc. Which is nice, but how many people would notice? It would be intensely satisfying to know that somewhere in the world, a player forgot to wash her scarlet sweater separate from her ecru socks, and now she has faded pink socks. I'm not sure it would make the game better, but I would take pleasure in that.

On the other hand, color doesn't affect play as intimately as materials do, so I can shelf it until I feel motivated to do the research. There must be equations and stuff for combining colors. And since I go in cycles of design, programming, and research, I'll get there one day. No need to force it, though. What I've got is perfectly adequate for experimentation.

*This is currently sort of a pipe dream, since display programming is really NOT my strong suit. But having a display that could pull colors from the game would give intriguing possibilities for mood setting or information: Want to know the color of your sheep? Here it is, right on screen. (Maybe in a box of color, or maybe the shade of the text, or maybe as a filler of some froofy graphic.) I don't know how possible it is; it's certainly beyond my interests to program such a thing, but someone else might have done the work already. Or would do it.