So I wrapped up the wildlife community data-collection yesterday (or at least Phase I).
The current table deals with quite a few specifics; there's a few things that will probably only be used as internal checks, but most have a direct impact. 49 "regular" communities that might be auto-genned or created through natural succession processes, plus a few different lakeshores, a couple cliffs, and a cave environment. Because of obvious game balance issues, those last categories do not auto-spawn.
These are not, of course, the descriptions or anything - just raw data to work with. But it was a boatload of work, and I feel very good having a first run-through.
These are the categories of data:
Fertility: A rough overall measure of soil fertility. I have no intention of tracking this for wild places, but it becomes important if the player wants to farm a particular location, or when determining succession. (I seemed to start by using high/moderate/low and switched to rich/moderate/poor later. Yeah, that'll have to be fixed.)
pH: Combined with moisture and fertility, these are the most predictive of plant types. pH is one of those things that will probably stay static. Right now, pH range is a list of two values, so: {65, 75}. The first is the lower range of pH in the community, the second the upper. If I wanted to, I could then categorize a particular room as acidic or neutral. I haven't done the coding yet, but it's straightforward enough.
Slope: From flat to cliff, in list form. Wetlands tend to be the flattest subset of communities, and things roll more in the drylands (and, of course, cliffs are cliffs.) Good for helping determine drainage, likelihood of flooding/drought, erosion for farmland, and nice immersion opportunities for wilds. I'm considering features like gullys and things, and stream placement.
Moisture: A tremendous determiner of plant-life and succession. Change the moisture level, and everything changes. Significant in farming, although wetlands would probably be drained, and moisture levels will depend more on precipitation and soil type than natural environment. These values range from saturated to dry.
Climax: Signals whether or not to check community for succession without an event. Every community gets checked when there's fire or something, but natural passage of time changes some communities (grassland -> savannah -> forest) but not others (a mature old-growth forest is an entity unto itself).
Soil Depth: I may take this out; it contributes to windthrow likelihood and erosion, but doesn't seem as important now as it did a few weeks ago. Still, I probably won't remove it until I know I won't use it. An uncomfortable number of the entries are sheer guesses.
Succession Possibilities: Given the natural passage of time, options for what a community may turn into. This is a brute force way of handling succession. It's not as complete as I'd like, since understanding the dynamics at work is challenging at best, and my data is very incomplete. Without disturbance, does a dry prairie turn into an oak barrens, or a pine barrens? Either? This list needs checking over.
Flood, fire, and beavers: These tend to knock succession "back" or change it significantly. Increased flooding may kill trees. Fire may kill fire-vulnerable trees, or all trees. Beavers can redirect streams, increasing or decreasing water flow. I'm well aware this category is mostly raw guesswork, but brute force manipulation is better than nothing, and keeps every room in the game from proceeding directly to forest and staying there.
Likely Nearby Types: What communities tend to be nearby. Some of this was helpfully provided by Michigan. Some of it was made up by me. (Michigan's lists tend to be shorter; I made mine by association.) I intend for this list to affect map generation, increasing the likelihood that a bog will be near a muskeg. This list is related to the succession possibilities and flood, fire and beavers lists, but tend to be a little longer.
Canopy Range: Hard numbers at last. Like pH, canopy range is a list with two numbers, bracketing the range. Canopy is a neat shorthand for tree density, size, and shading. Tree density is inadequate because some rather dense forests still let lots of light in; there may be tens of thousands of aspen per acre, but on the forest floor, you've still got dappled sunlight. Under an oak forest, with fewer trees, you get deeper shade because the canopy is closed. These tend to be guesses, but guesses based on examples. I have no doubt I'll need tweaking. The idea is that during generation, the number, age, and type of tree will create a canopy in the range given. When the shade in a location exceeds the canopy range, it might kick up to another community. For example, if enough oaks grow in an oak savannah, it may transition to a southern dry mesic forest (essentially an oak dominated forest). If no forest-y succession type is listed for a location, it will check and see if it can "match" current conditions with more canopied communities.
For example: A bog is essentially unforested: it has a canopy range of o-10%. Anything over that, and it will look at its succession possibilities column. Muskeg is the only option, but if nothing was listed, it would look for a community matching its current statistics, and become something new.
The difficulty of getting the coding right for the latter bit is what made me do the Succession Possibilities column in the first place. I plan to do it, but hope it will not ever need to be used. Things being what they are, there's probably multiple options that can create communities with statistics that fall outside the normal range. For example, our bog is now a muskeg. A bog has a pH range of 3.0-5.0 ({30, 50}), and a muskeg has a range of 3.2-4.3 ({32-43}). What if our original bog had a pH of 3.0?
My idea right now is to implement a sort of regression to the mean, where numeric values will gradually "pull" towards the mean value of a range. It's not actually cheating; biologic and chemical values do change over time, often showing this tendency to move away from extremes. But it's something I'm not going to implement for quite a while, because a better idea may occur to me.
Tree density: So, canopy is awesome. It is. But sometimes, a quick check is better. How many seedlings to try planting in a place per year? What's the likelihood there will be 10 young trees vs. 1 old tree in a prairie? Besides, canopy requires math. Kind of a lot of math. (Take sum of: each tree, look at its height and species, multiple density of species by height.) Tree density is quick.
Wind Risk: How much wind hits a place, and how likely is it to cause damage? Mostly windthrow, but may also play a role in events.
Flood Risk: How likely a place is to be flooded. Floods can trigger succession, wipe out crops, sweep away items, and in extreme cases, may be catastrophic.
Fire Risk: Chance of significant surface fire. Fires can trigger succession, but they can also maintain communities; dry prairie would quickly become something else if there were not regular fires. The risk ranges from low (as rare as once per 1,000 yrs.) to high (as often as every 10 yrs.) to regular (as low as 1:10).
Fire's deeply problematic from a play view: on one hand, having a wildfire sweep through and destroy the player's house, barn, crops, animals, etc. is kind of awesome and I approve. (Sort of. Maybe not the animals.) On the other hand, it's random destruction that is completely catastrophic, and sort of a break of trust. (And I'd be pissed if it were me playing.) Plus, fire is kind of like a rope: the permutations for how it should behave and what it can do are really, really troubling. I may have to do fires more or less locally: only in the location that spawned them, plus surrounding fire-vulnerable places. Or maybe I should drop the idea altogether.
Forest Types: So the foresters of America have a very long list of different groups of trees that tend to be found together. These are not communities in any sense of the word: they're both less specific, in that certain forest types are found all over the US in huge gloms, and more specific, in that they specific groves and smaller associations of species than communities tend to. Unfortunately, I haven't been able to find a good source for this data online, except scattered far and wide. So this column is there to remind me to hit the research library and see if I can get a reference book.
Dominant trees: What I hope will be the basis for forest types later. The trees most likely to be found in a location, usually comprising about 80% of the trees. This is for initial world generation, as well as future seeding purposes.
Minor trees: The other 20% of tree species. Usually there are more of these. For example, a prairie fen is dominated by tamarack, but occasionally you'll also find yellow birch, red maple, or American elm there. The minor trees are extra nice because there's a decent chance that two otherwise identical communities will actually have different minor trees, some quite rare. The opportunity for a player to find a grove of wild plums amongst a large deciduous forest is pretty neat. It also gives some trees true dominance: maples, oaks, spruce, balsam fir are all over the place, both as major and minor species.
--
I'm hoping all this info will help me do two things: create a world that feels unique and interesting and real, and then model changes to the world over time in a way that provokes curiosity and pleasure, but doesn't require too much head-scratching for the player - if she doesn't notice, that's okay, just as in the real world.
There's no way to do this to the extent I'd like to, but hopefully there's enough to give the world a solid veneer.
Tuesday, June 29, 2010
FUCK.
Somehow, I must have copied, pasted, and compiled the wrong thing into my Tree Experimentation folder.
Apparently, all my tree experiments and careful constructions are gone. I had a backup, but it was a post-fuck-up backup, which is not helpful at all.
Fuck.
Apparently, all my tree experiments and careful constructions are gone. I had a backup, but it was a post-fuck-up backup, which is not helpful at all.
Fuck.
Saturday, June 19, 2010
Data Entry
A big portion of FTA is data entry. When I get lucky, the data has already been gathered in one place, and just needs to be copied into the appropriate tables (usually with some minor modifications). I've written before aboutsome of the easy bits; naming turned out to be pretty simple.
I am not finished with what I'm calling wildland communities - a small breakdown than biomes, but similar idea - partly because my main source does not have consistent information. For some communities, all the information I want is in the documentation, and it's just a matter of teasing it out. For others, the abstract is essentially a brief overview. This is, of course, totally fine; Michigan doesn't owe me the canopy cover numbers on every community. But it often means I have to make stuff up. (Canopy cover is a percentage of how much land in a community is under trees; grasslands tend to be 0%, but can have occasional trees scattered through them; forests can be as low as 60%.) It's also the short hand I'm using for determining how shaded a particular location is. This matters annually in the wild, when the game determines what is sprouting, and also on the farm, when crops under trees are penalized and animals checked for protection from wind/rain/sun.)
Once you've got a baseline, of course, making stuff up is easier - you just copy and paste from a similar place. But it takes a while, and sometimes no number seems quite right.
There's a lot of extrapolation required. If trees in a mesic prairie meadow can grow enough to turn it into an oak savannah, you need to know that if you cut the trees down, you may get the meadow again. There are probably ways of handling these interactions that don't require cross-referencing; for instance, if I had enough numbers and measurements properly handled, the game could decide the range of options for succession on its own. But that's very iffy, since the numbers available tend towards general. Acidity of the soil is a range; it's helpful, but not determinative. Since I don't trust an automated process to be either realistic or fair, a more brute force approach is required; and almost undoubtedly less work than trying to figure out spontaneous in-game generation. (If it was more work but would work smoothly, I might try it; as it is . . .)
So there's data entry and data creation, which gets boring pretty quick. I'm about done with the wetland communities, which will be lovely, but I've got all the dryland ones to go. Thankfully, I'm eliding a lot of those. Does one really need limestone cliffs, granite cliffs, and sandstone cliffs to be separate communities? (Answer: YES, if you're an ecologist or geologist.) I think maybe I'll use one or two or those, or decide that exposed rock in this world is always limestone. The only cliffs in the game are going to be ones that I put there, so it's not like the player is going to care.
Imputing dozens of communities feels like overkill at this stage, but I think the differentiation adds something to the game as it stands, and gives the basis for a lot of very interesting future options. Unfortunately, the future is not now, so a lot of the work is slogging. Not fun slogging, either. And I may have taken a few weeks off because I was just that tired of trawling through multiple sites hunting for random obscure bits of info.
And the trees are still half finished, as well, for pretty much the same reason; I think I was using five or six sources plus internet searches on each one, and that was beginning to grind. I've cut back on the amount of information I'm inputting, but I am still woefully short of the 200th species mark.
I have no doubt that I'll get smarter as I go; I also need to plan ahead more. But a lot of this is just work that has to get done, that I can't give to a peon. (Dear self: find peon.) I'm okay with that. Some days I don't mind doing data entry, and on the days which I can, I'll input another entry or two, just to keep the process moving forward, even if it's mostly symbolic.
I am not finished with what I'm calling wildland communities - a small breakdown than biomes, but similar idea - partly because my main source does not have consistent information. For some communities, all the information I want is in the documentation, and it's just a matter of teasing it out. For others, the abstract is essentially a brief overview. This is, of course, totally fine; Michigan doesn't owe me the canopy cover numbers on every community. But it often means I have to make stuff up. (Canopy cover is a percentage of how much land in a community is under trees; grasslands tend to be 0%, but can have occasional trees scattered through them; forests can be as low as 60%.) It's also the short hand I'm using for determining how shaded a particular location is. This matters annually in the wild, when the game determines what is sprouting, and also on the farm, when crops under trees are penalized and animals checked for protection from wind/rain/sun.)
Once you've got a baseline, of course, making stuff up is easier - you just copy and paste from a similar place. But it takes a while, and sometimes no number seems quite right.
There's a lot of extrapolation required. If trees in a mesic prairie meadow can grow enough to turn it into an oak savannah, you need to know that if you cut the trees down, you may get the meadow again. There are probably ways of handling these interactions that don't require cross-referencing; for instance, if I had enough numbers and measurements properly handled, the game could decide the range of options for succession on its own. But that's very iffy, since the numbers available tend towards general. Acidity of the soil is a range; it's helpful, but not determinative. Since I don't trust an automated process to be either realistic or fair, a more brute force approach is required; and almost undoubtedly less work than trying to figure out spontaneous in-game generation. (If it was more work but would work smoothly, I might try it; as it is . . .)
So there's data entry and data creation, which gets boring pretty quick. I'm about done with the wetland communities, which will be lovely, but I've got all the dryland ones to go. Thankfully, I'm eliding a lot of those. Does one really need limestone cliffs, granite cliffs, and sandstone cliffs to be separate communities? (Answer: YES, if you're an ecologist or geologist.) I think maybe I'll use one or two or those, or decide that exposed rock in this world is always limestone. The only cliffs in the game are going to be ones that I put there, so it's not like the player is going to care.
Imputing dozens of communities feels like overkill at this stage, but I think the differentiation adds something to the game as it stands, and gives the basis for a lot of very interesting future options. Unfortunately, the future is not now, so a lot of the work is slogging. Not fun slogging, either. And I may have taken a few weeks off because I was just that tired of trawling through multiple sites hunting for random obscure bits of info.
And the trees are still half finished, as well, for pretty much the same reason; I think I was using five or six sources plus internet searches on each one, and that was beginning to grind. I've cut back on the amount of information I'm inputting, but I am still woefully short of the 200th species mark.
I have no doubt that I'll get smarter as I go; I also need to plan ahead more. But a lot of this is just work that has to get done, that I can't give to a peon. (Dear self: find peon.) I'm okay with that. Some days I don't mind doing data entry, and on the days which I can, I'll input another entry or two, just to keep the process moving forward, even if it's mostly symbolic.
Wednesday, June 9, 2010
Game Concepts: The Midas Touch
I probably should not have jumped right into The Biggest Project I've Ever Programmed without doing more practice in I7 first. Inform is deceptive; it looks simple, but the rabbit hole goes all the way down, and there's some subtleties that are . . . interesting. Plus, the more you use a tool, the better you get at it. I once swore never to touch lists; I'm coming around. I haven't come around on procedural rules yet; I don't get rules on a fundamental basis, and don't feel comfortable messing with them.
I also go through cycles of interest in this project. This is normal for me. And while I'm invested in the outcome, unless someone else releases a complicated apocalyptic farming sim with all the features I want, this is really more about the journey - there's no deadline. I work on it when I want.
So I keep thinking, as I survey my coding bits, that it would be a Good Idea to finish and polish a smaller piece. It would be good practice, for one thing, and undoubtedly teach me a lot about myself, programming, and the bits that come after programming - beta testing, bug fixing, release, fame and accolades . . .
Unfortunately, I don't seem to really click with small projects. They don't capture my imagination. This sucks, since I'm well aware that even a "small" project can mean months of work.
The most workable idea I have at the moment would be a game based on the story of Midas and his golden touch. Midas could be a fun character, I think. I don't have a voice for him, but he's a greedy, impulsive man with a clear love of life. (You don't hang out with Bacchus if you're a stoic.) And he's in the midst of a massive comeuppance.
The other great thing is that if everything you touch turns to gold, the range of actions is automatically limited. You can't cut things with a gold sword. You can't hug people without killing them. You can't burn, or tie ropes, or kiss, or eat. You can look. You can talk. You can touch things (that then may or may not become useless.)
It does have potential to be sort of a humorless preachy game, or a predictable quest game, but it's sort of nice that there's a clear preset goal: get rid of the touch, so you can eat again. And rescue your daughter, if you go in for that version.
I think there are some interesting puzzles that could be done with a golden touch, although I'm not much of a puzzle person. But the key to an interesting game like this is probably strong writing and storyline.
At first draft, I'm thinking something like this:
- Story opens just after you get the power. Cue glee as you run around touching things. (I think most players know what's coming, but Midas's glee should be enough to carry the scene.)
- Midas touches his daughter, or she touches him, or something. Cue the realization that gold is not really the most awesome thing ever. Probably about this point the servants find out. I suspect their response is not "Yay, the king kills by touching people."
- Quest assignment. Midas prays, or Bacchus shows up, or both, or someone advises him to go to the oracle, or something. Midas has to go either to an oracle to find out how to get rid of the touch, or to a river to wash his hands.
- Midas sets out, having to pass through the city and countryside to the mountain to the oracle/source of river.
- As he passes through the land, he has adventures. Maybe he meets peasants, or bandits, or whatever; these are essentially chapterlets of interest. Puzzles are simple, and can be solved a variety of ways.
- Midas reaches his goal, and is allowed to choose his reward. There's a variety of things he can wish for, although the most obvious is to have his normal touch back. To finish the game, he must go back through the land to the castle; at this point we see the effects of his actions on the way out.
- Ending text differs depending on overall choices and opinion of the populace.
I also go through cycles of interest in this project. This is normal for me. And while I'm invested in the outcome, unless someone else releases a complicated apocalyptic farming sim with all the features I want, this is really more about the journey - there's no deadline. I work on it when I want.
So I keep thinking, as I survey my coding bits, that it would be a Good Idea to finish and polish a smaller piece. It would be good practice, for one thing, and undoubtedly teach me a lot about myself, programming, and the bits that come after programming - beta testing, bug fixing, release, fame and accolades . . .
Unfortunately, I don't seem to really click with small projects. They don't capture my imagination. This sucks, since I'm well aware that even a "small" project can mean months of work.
The most workable idea I have at the moment would be a game based on the story of Midas and his golden touch. Midas could be a fun character, I think. I don't have a voice for him, but he's a greedy, impulsive man with a clear love of life. (You don't hang out with Bacchus if you're a stoic.) And he's in the midst of a massive comeuppance.
The other great thing is that if everything you touch turns to gold, the range of actions is automatically limited. You can't cut things with a gold sword. You can't hug people without killing them. You can't burn, or tie ropes, or kiss, or eat. You can look. You can talk. You can touch things (that then may or may not become useless.)
It does have potential to be sort of a humorless preachy game, or a predictable quest game, but it's sort of nice that there's a clear preset goal: get rid of the touch, so you can eat again. And rescue your daughter, if you go in for that version.
I think there are some interesting puzzles that could be done with a golden touch, although I'm not much of a puzzle person. But the key to an interesting game like this is probably strong writing and storyline.
At first draft, I'm thinking something like this:
- Story opens just after you get the power. Cue glee as you run around touching things. (I think most players know what's coming, but Midas's glee should be enough to carry the scene.)
- Midas touches his daughter, or she touches him, or something. Cue the realization that gold is not really the most awesome thing ever. Probably about this point the servants find out. I suspect their response is not "Yay, the king kills by touching people."
- Quest assignment. Midas prays, or Bacchus shows up, or both, or someone advises him to go to the oracle, or something. Midas has to go either to an oracle to find out how to get rid of the touch, or to a river to wash his hands.
- Midas sets out, having to pass through the city and countryside to the mountain to the oracle/source of river.
- As he passes through the land, he has adventures. Maybe he meets peasants, or bandits, or whatever; these are essentially chapterlets of interest. Puzzles are simple, and can be solved a variety of ways.
- Midas reaches his goal, and is allowed to choose his reward. There's a variety of things he can wish for, although the most obvious is to have his normal touch back. To finish the game, he must go back through the land to the castle; at this point we see the effects of his actions on the way out.
- Ending text differs depending on overall choices and opinion of the populace.
Tuesday, June 8, 2010
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.
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.
Subscribe to:
Posts (Atom)
