Design: Template vs. player guided

I'm feeling a little more able to deal with design issues now that I'm post-holiday season.  Thank goodness.  I spent a little time trying to figure out what I wanted to do with the core house.

Initially, the PC's home base - the place where she eats, sleeps, and stores things - is pretty minimal.  There's a cave that is somewhat sheltered, and possibly another cave (although so far out of the way probably only the initiated would find it).  The primary intentioned shelter is a shed on the farm premises.

As time goes on, the PC can build a nicer place to live, and also improve the starting shed (adding windows, etc.)  I'd originally planned to make this free form, with the playerspecifying which rooms to build, and where the exits would be. Thus, if the player wanted a eight-story house with twenty-six bedrooms and no kitchen, he could.  I figured I might even be able to guess at the nature of a room based on its furnishings - if the PC put in a bed, it probably was a bedroom.  A toilet would mean a bathroom, etc.  I still kind of like this idea, but after some experimentation, I'm not convinced I could pull it off well.

Part of the problem is that I want some meta-commands that will cause issues here.  For instance, I want the option of automatically delivering food to the kitchen, and putting it away.  I want to be able to ">TIDY UP" and have the PC move clothes, dishes, etc. to appropriate locations.  >COOK BREAKFAST should move the PC to the kitchen, where the cooking is done, and then to the dining room, where the food is eaten.  None of this is necessary, of course - it's almost all fluff.  But I fear that without commands like "tidy up", it's far too tedious to expect the player to type out all the commands necessary.

Of course, one could always have the game offer expectations for room use, and allow the player to override these.  But then we run into some issues with size and connection.

I'm not terribly bothered by letting the player expand the house semi-indefinitely, except that it complicates writing descriptions tremendously.  But there's a real issue in terms of connectivity - it's very easy to let the player decide the living room should be north of the entry, and the guest room north of the living room.  But you've got to either limit most rooms to one connection, or deal with the time-space continuum when the player puts the guest room south of the entry as well.  (Nor am I convinced, based on a few unscientific experiments, that players are good at creating layouts they'll remember better, which was one reason I got into this in the first place.)

I may revisit this one, especially if I follow up random generation for the outside maps.  But for now, I've got a pre-fab blueprint that the player can build room by room.  There's a limit - I think the total constructed size of the house including cellars and storage is around 4000 sq ft, which is enormous (more than 10 times the size of most of the places I've lived), but not exactly impossibly large (ignoring the basements, it's within one standard deviation of the average house size in the US).  (Wow, people in the US have a lot of space.)

The advantage is that almost every room is within two moves of the main living area, with the only exception being some of the most distant storage areas (three moves).  Most diagonal connections have been removed, which makes navigation easier.  I'm still tweaking connections a bit; I would prefer there to be only n/s/e/w/u/d, but it's a little difficult to do.  I also threw in Emily Short's Approaches, which is great, and makes it easy to get places.

I need to refine the construction process, which currently consists of typing ">BUILD KITCHEN" and having it appear by magic.  So figuring out what materials the PC needs to have on hand (and what "on hand" means - holding, in storage shed, in general vicinity of the room to be built?), figuring out how long that should take, adjusted by PC skill, and what (if anything) to do about various miscellaneous things like roofs and doors.  Doors especially - there's currently no reason to actually have a door, and I need to figure out if there will be or not, and if doors should be tacked onto doorways, or if they're just a distraction.  Then I have to figure out windows.  Windows are hard, especially if you want there to be actual things to look at.

Still, though, getting to this point was less difficult than I expected.  Hopefully it will stay easy.

Color Manipulation: Multiply, Saturate, Gray, Brighten, Lighten, Convert, Blend

Free time has been scarce the last couple weeks, due to end of the year holidays and real life complications.  What little I have had has gone into gathering some tools for color manipulation.  (I also did a little more work on the map, room descriptions, and other things that don't require active design integration.) 

Preserved for posterity (and because I have the nasty habit of accidentally saving over code that's difficult to replace): Simple Equations for Color Manipulation, and Inform 7 Code for the Same.

The first big issue is that Inform uses decimal numbers to represent colors.  This is essentially worthless for our purposes.  The only realistic way to work with color is to use the hex or RGB value.  I could also, I suppose, have used HSV, but that's even more complicated to derive than hex/RGB.

Inform doesn't handle hex as a value, and it's not something I'm willing to fool with, so RGB it is. 

An RGB is a kind of value.   255-255-255 specifies an RGB with parts rgb-red, rgb-green, and rgb-blue.

On my first coding draft, I used R, G, and B as parts of a RGB.  Not a good idea - it makes them hard to search for in the code in case you need to replace something.  All my non-temporary variables are now getting real names. 

The downside of making RGB one value instead of three is that you have to be pretty careful with calculations.  The parts are interconnected internally, so careless arithmetic can have very unexpected results.  You also can't unilaterally change parts of a RGB value (ie "Now the rgb-blue part of sky blue is 44.").  This can be a little unintuitive.  Also, you need to watch input: this setup does allow for R values of greater than 255.  And you have to use glulx, because of the size the Inform thinks the values are - it doesn't see 255-255-255, but some conglomerate number.

RGB values are essentially hex values in disguise.  The current version of hex color values uses 6 digits of base 16 to represent a color.  White, the highest number, is FFFFFF, with the first two digits being red, the second two digits representing green, and the last green.  RGB is just the decimal-converted values of hex, with dashes between to mark the color separations. 

So converting from RGB to decimal requires, essentially, converting to pseudo-base 16, and then to base 10.

Section - RGB to Decimal

To decide what number is the decimal value of (colorspace - an RGB):   
    let R1 be rgb-red part of colorspace; [pull out ind. parts to prevent Issues]
    let B1 be rgb-blue part of colorspace; [in hex would be R1R2G1G2B1B2]
    let G1 be rgb-green part of colorspace;
    let r2 be the remainder after dividing r1 by 16; [remainder is second digit of hex]
    let G2 be the remainder after dividing G1 by 16;
    let B2 be the remainder after dividing B1 by 16;
    now R1 is R1 divided by 16; [division w/o remainder is first digit of hex]
    now G1 is G1 divided by 16;
    now B1 is B1 divided by 16;
    now B1 is B1 multiplied by 16; [conversion to decimal]
    now G2 is G2 multiplied by 256;
    now G1 is G1 multiplied by 4096;
    now R2 is R2 multiplied by 65536;
    now R1 is R1 multiplied by 1048576;
    decide on (R1 + R2 + G1 + G2 + B1 + B2);  [sum of conversions]

In all this code, I've gone for steps, rather than one giant equation.  Giant equations have a habit of going horribly wrong, and it's easier to tweak like this. 

Converting from decimal to RGB is similar, except now you're converting to pseudo-hex, but without the actual hex part.

Section - Decimal to RGB   
   
To decide what RGB is the RGB value of (colorspace - a number):
    if colorspace is greater than 16777215:
        decide on 255-255-255;
    if colorspace is less than 1:
        decide on 0-0-0;   
    let count be colorspace;
    let b2 be the remainder after dividing count by 16;
    now count is count divided by 16;
    let b1 be the remainder after dividing count by 16;
    now count is count divided by 16;
    let g2 be the remainder after dividing count by 16;
    now count is count divided by 16;
    let g1 be the remainder after dividing count by 16;
    now count is count divided by 16;
    let r2 be the remainder after dividing count by 16;
    now count is count divided by 16;
    let r1 be the remainder after dividing count by 16;
    now count is count divided by 16;
    now r1 is ((r1 * 16) + r2);
    now g1 is ((g1 multiplied by 16) + g2);
    now b1 is ((b1 multiplied by 16) + b2);
    let temp-hue be the RGB with rgb-red part r1 rgb-green part g1 rgb-blue part b1;
    decide on temp-hue;

All this is pretty straightforward, although it is sort of embarrassing how long it took me to figure out base conversions again.  I think the last time I did that was sixth grade, and it did not stick.

If you're going to be fiddling around with changing the color of text or background, keeping things legible is a primary concern.  Black/white is pretty much always the best option, but you can get surprisingly good results by figuring out how "bright" a color appears and then using black on brighter backgrounds or white text on darker backgrounds (or vice versa, if you're modifying text colors).  I find the middle values can still be a little challenging, but acceptable in small spaces (ie the status bar).  This decision is how I decide what color text to use on color backgrounds. The equation was yoinked from Nbd-tech.

Section - Dark or Bright   

To decide if (colorspace - an RGB) is bright:
    let X be the rgb-red part of colorspace;
    now X is X multiplied by 299;
    let Y be the rgb-green part of colorspace;
    now Y is Y multiplied by 587;
    let Z be the rgb-blue part of colorspace;
    now Z is Z multiplied by 114;
    now X is (X plus Y plus Z);
    now X is (X divided by 1000);
    if X is greater than 126:
        decide yes;
    decide no.

 So now we're down to the fun stuff.  Pretty much all of this I had to figure out on my own; there's plenty of talk online *about* color, but the actual equations used to make changes are few, far between, and usually written in a computer language I don't speak, often with calls to library functions that I don't have.

The equations are mine, but spit out answers within a small range of error of Photoshop and Gimp (where those values agree) and Photoshop (when they don't). 

Gray

100% desaturation gives you pure gray, which should be about the same shade, but minus all the color.  You can this by taking the highest value of R, G, or B, and making it the same (R-R-R if red was the highest value). 

Section - Pure Gray
   
To decide what RGB is the pure gray value of (colorspace - a RGB):
    let temp-gray be the rgb-red part of colorspace;
    if the rgb-green part of colorspace is greater than temp-gray:
        now temp-gray is the rgb-green part of colorspace;
    if the rgb-blue part of colorspace is greater than temp-gray:
        now temp-gray is the rgb-blue part of colorspace;   
    let pure-hue be the RGB with rgb-red part temp-gray rgb-green part temp-gray rgb-blue part temp-gray;
    decide on pure-hue;    

If you have a hue you want to make more gray, find the difference between the pure gray value and the color and add it to the color.  This can be modified by using a percentage, letting you pull a little color out or a lot.

Hue + (Gray - Hue)(percentage change) = Grayer Hue

Section - To Gray A Color

To decide what RGB is (colorspace - a RGB) grayed/greyed by (amount - a number) percent:
    let pure-gray be the pure gray value of colorspace;
    let R be (rgb-red part of pure-gray minus rgb-red part of colorspace);
    let G be (rgb-green part of pure-gray minus rgb-green part of colorspace);
    let B be (rgb-blue part of pure-gray minus rgb-blue part of colorspace);
    now R is (R multiplied by amount) divided by 100;
    now G is (G multiplied by amount) divided by 100;
    now B is (B multiplied by amount) divided by 100;   
    now R is R plus rgb-red part of colorspace;
    now G is G plus rgb-green part of colorspace;
    now B is B plus rgb-blue part of colorspace;       
    decide on the rgb with rgb-red part R rgb-green part G rgb-blue part B;

Saturation

This one stumped me for quite a while.  Saturation is intensity of color - the opposite of gray.  Turning "up" the color in terms of numbers isn't intuitive - what do you actually *do*? 

As saturation increases, you're removing gray, so you're going to see the lowest value go to 0.  The highest value, the place where the most pigment is, will stay the same.

Full Saturation Color:
First find the saturation value.  Saturation = (Highest - lowest)/highest. 
Highest value: Highest Value
Middle value (if any):  (Middle - Lowest)/Saturation
Lowest value: changes to zero.

In Inform terms:

Section - Pure Saturation   
   
To decide what RGB is the pure saturated value of (colorspace - a RGB):
    if rgb-red part of colorspace is 0 or rgb-green part of colorspace is 0 or rgb-blue part of colorspace is 0:
        decide on colorspace;
    let rgb_high be rgb-red part of colorspace;
    let rgb_low be rgb-red part of colorspace;
    if rgb-green part of colorspace is greater than rgb_high:
        now rgb_high is rgb-green part of colorspace;
    if rgb-green part of colorspace is less than rgb_low:
        now rgb_low is rgb-green part of colorspace;
    if rgb-blue part of colorspace is greater than rgb_high:
        now rgb_high is rgb-blue part of colorspace;
    if rgb-blue part of colorspace is less than rgb_low:
        now rgb_low is rgb-blue part of colorspace;   
    let saturation be 0;
    if rgb_high is not 0:
        now saturation is 100 multiplied by (rgb_high - rgb_low) divided by rgb_high;
    let R be 0;
    if rgb-red part of colorspace is rgb_high:
        now R is rgb-red part of colorspace;
    otherwise if rgb-red part of colorspace is rgb_low:
        now R is 0;
    otherwise:
        now R is ((rgb-red part of colorspace - rgb_low) multiplied by 100) divided by saturation;
    let G be 0;   
    if rgb-green part of colorspace is rgb_high:
        now G is rgb-green part of colorspace;
    otherwise if rgb-green part of colorspace is rgb_low:
        now G is 0;
    otherwise:
        now G is ((rgb-green part of colorspace - rgb_low) multiplied by 100) divided by saturation;
    let B be 0;   
    if rgb-blue part of colorspace is rgb_high:
        now B is rgb-blue part of colorspace;
    otherwise if rgb-blue part of colorspace is rgb_low:
        now B is 0;
    otherwise:
        now B is ((rgb-blue part of colorspace - rgb_low) multiplied by 100) divided by saturation;   
    let saturated_hue be the RGB with rgb-red part R rgb-green part G rgb-blue part B;
    decide on saturated_hue;

 Saturating colors by percentages is very similar to the process we used with graying colors, but this time, we know that fully saturated colors will never have highers values than the original color, so a few signs get switched around.

To decide what RGB is (colorspace - a RGB) saturated by (amount - a number) percent/--:
    let pure-sat be the pure saturated value of colorspace;
    let R be (rgb-red part of colorspace minus rgb-red part of pure-sat);
    let G be (rgb-green part of colorspace minus rgb-green part of pure-sat);
    let B be (rgb-blue part of colorspace minus rgb-blue part of pure-sat);   
    now R is (R multiplied by amount) divided by 100;
    now G is (G multiplied by amount) divided by 100;
    now B is (B multiplied by amount) divided by 100;   
    now R is rgb-red part of colorspace minus R;
    now G is rgb-green part of colorspace minus G;
    now B is rgb-blue part of colorspace minus B;       
    decide on the rgb with rgb-red part R rgb-green part G rgb-blue part B;   

 Brightness

This isn't directly related to the function earlier to decide whether a color was dark or bright.  Brightness occurs when the color hue stays the same, but it's pushed towards white; a fully bright hue has one or more values at 255. 

To convert to the brightest shade of a particular color:
Low values (anything that isn't the highest value in the RGB): Low(bright) = Low * 255 / Highest
Highest: Highest = 255

Section - Pure Brightness   
   
To decide what RGB is the brightest value of (colorspace - a RGB):
    if rgb-red part of colorspace is 255 or rgb-green part of colorspace is 255 or rgb-blue part of colorspace is 255:
        decide on colorspace;   
    let rgb_high be rgb-red part of colorspace;       
    if rgb-green part of colorspace is greater than rgb_high:
        now rgb_high is rgb-green part of colorspace;
    if rgb-blue part of colorspace is greater than rgb_high:
        now rgb_high is rgb-blue part of colorspace;   
    let R be 0;
    let G be 0;
    let B be 0;
    if rgb-red part of colorspace is rgb_high: [highest brightness requires the high values to be 255]
        now R is 255;
    otherwise:
        now R is (255 multiplied by rgb-red part of colorspace) divided by rgb_high;
    if rgb-green part of colorspace is rgb_high:
        now G is 255;   
    otherwise:
        now G is (255 multiplied by rgb-green part of colorspace) divided by rgb_high;           
    if rgb-blue part of colorspace is rgb_high:
        now B is 255;       
    otherwise:
        now B is (255 multiplied by rgb-blue part of colorspace) divided by rgb_high;   
    decide on the RGB with rgb-red part R rgb-green part G rgb-blue part B;   

 Brightening and darkening use the same machinery as for saturating and graying colors. 

Section - Brightening a Color

To decide what RGB is (colorspace - a RGB) brightened by (amount - a number) percent/--:
    let pure-bright be the brightest value of colorspace;
    let R be (rgb-red part of pure-bright minus rgb-red part of colorspace);
    let G be (rgb-green part of pure-bright minus rgb-green part of colorspace);
    let B be (rgb-blue part of pure-bright minus rgb-blue part of colorspace);
    now R is (R multiplied by amount) divided by 100;
    now G is (G multiplied by amount) divided by 100;
    now B is (B multiplied by amount) divided by 100;   
    now R is R plus rgb-red part of colorspace;
    now G is G plus rgb-green part of colorspace;
    now B is B plus rgb-blue part of colorspace;       
    decide on the rgb with rgb-red part R rgb-green part G rgb-blue part B;   
   
Section - Darkening a Color   

To decide what RGB is (colorspace - a RGB) darkened by (amount - a number) percent/--:
    let pure-dark be 0-0-0;
    let R be (rgb-red part of colorspace);
    let G be (rgb-green part of colorspace);
    let B be (rgb-blue part of colorspace);   
    now R is (R multiplied by amount) divided by 100;
    now G is (G multiplied by amount) divided by 100;
    now B is (B multiplied by amount) divided by 100;   
    now R is rgb-red part of colorspace minus R;
    now G is rgb-green part of colorspace minus G;
    now B is rgb-blue part of colorspace minus B;       
    decide on the rgb with rgb-red part R rgb-green part G rgb-blue part B;   

Additive vs. Subtractive Color 

There's basically two ways to combine color.  Color can be pigments, in the sense that they absorb all but the color that you see, or they can be light, in that they give the color you see.  Pigments are subtractive, because once all of a certain color is absorbed, there's no way to see it again.  If you layer black marker over a sheet of paper, and then use a yellow marker, you're still only going to see black.

However, if you've got a dark room, and you shine a yellow light, you'll get yellow.  Add a blue light, and you'll get yellow + blue light.

 Multiplying

One of the filters I use most in Photoshop/Gimp.  Multiply is a way to simulate subtractive color combination.  The basic formula for each value is to multiply the two corresponding values together and divide by 255.

Red1 * Red2 / 255 = RedMultiplied.

It's a useful function if you're simulating paint, dye, or filtering out light.  (For this scenario, we're pretending white paint doesn't really exist - real life is, as always, more complicated than the model we create.)

Section - Multiplying Colors

[Multiply is used for *subtractive* color mixing - paints, dyes.  Things will grow darker as combined.  The formula is each part of the color, multiplied by its partner, divided by 255.]   
To decide what RGB is (basecolor - a RGB) multiplied by (topcolor - a RGB):
    let R be the rgb-red part of basecolor;
    now R is R multiplied by the rgb-red part of topcolor divided by 255;
    let G be the rgb-green part of basecolor;
    now G is G multiplied by the rgb-green part of topcolor divided by 255;
    let B be the rgb-blue part of basecolor;
    now B is B multiplied by the rgb-blue part of topcolor divided by 255;   
    decide on the RGB with rgb-red part R rgb-green part G rgb-blue part B.

Lightening

For additive color combination, you take the highest value of each part of the RGB value.  Confusingly, there's no actual addition involved.  It sort of makes sense if you think about what happens if you use a flashlight in full sunlight - things aren't brighter unless you shine the light where the sun isn't.  Brightness isn't purely additive.

Section - Adding or Lightening Colors

[Lightening is *additive* color mixing, as used with light.  Lightening takes the highest of each of the RGB values given.]

To decide what RGB is (basecolor - a RGB) lightened/added by/to (topcolor - a RGB):
    let R be the rgb-red part of basecolor;
    if rgb-red part of topcolor is greater than R:
        now R is rgb-red part of topcolor;
    let G be the rgb-green part of basecolor;
    if rgb-green part of topcolor is greater than G:
        now G is rgb-green part of topcolor;
    let B be the rgb-blue part of basecolor;
    if rgb-blue part of topcolor is greater than B:
        now B is rgb-blue part of topcolor;               
    decide on the RGB with rgb-red part R rgb-green part G rgb-blue part B;

Blending 

Finally, I've included a way to blend colors.  If you use a image editor, it's similar to the way opacity works between layers, and is actually a good model for that white paint mixing problem left over from multiply.  It's also a way to fade or transition convincingly between two colors.

Combination = Original - ((Original - additive)*percentage of additive used)

 Section - Blending a Percentage

[This is an all purpose color-blending option, similar to the general "brighten/saturate" commands.  It is equivalent to the opacity layer in photoshop, where the pigment is a layer on top of the colorspace.]

To decide what RGB is (colorspace - a RGB) blended with (amount - a number) percent of/-- (pigment - a RGB):
    let R be 0;
    now R is rgb-red part of colorspace minus rgb-red part of pigment;
    let G be 0;
    now G is rgb-green part of colorspace minus rgb-green part of pigment;
    let B be 0;
    now B is rgb-blue part of colorspace minus rgb-blue part of pigment;
    now R is (R multiplied by amount) divided by 100;      
    now G is (G multiplied by amount) divided by 100;      
    now B is (B multiplied by amount) divided by 100;      
    now R is rgb-red part of colorspace minus R;
    now G is rgb-green part of colorspace minus G;
    now B is rgb-blue part of colorspace minus B;
    decide on the RGB with rgb-red part R rgb-green part G rgb-blue part B;

These tools allow for pretty fine color control.  Inform/glulx aren't highly accessible in terms of color, but it is possible to make some minor changes that aren't too distracting.

I'm hoping to come up with an automatic sunset generator next. 

Caveat: This is all in beta still, but it seems to work as expected.

Because of the way Inform handles small values, there's always going to be a little variation as numbers approach each other.  A few digits one way or another in a RGB is not readily visible to the naked eye, though, and is well within the margin of error of computer monitors.  There are more complicated formulas that would afford greater accuracy, but it's a lot of extra processing power for very little benefit. 

Ongoing Color Work

Color stuff is evolving - I've come a long way since June.  It makes a nice break from actual mechanics because it's so self-contained; apart from hooking it up to test code, I don't need to think about how this piece will have cascading effects into other areas of the world.

Which is awfully nice.

Also, I realized that the color schema had gotten completely out of hand.  I've spent hours and hours importing a variety of shades, only to realize too late that most of the colors were too saturated, too garish, and too neon to work well, and were far too short on grays, browns, and shades that were variations on each other.

So I spent some time thinking about what I needed, and did some palettes and color-mockups.

Seasonal sky/earth colors: Spring, Summer, Fall, Winter, plus temp scale along bottom (alpha)

But in addition to that, I've made the first steps towards an internal color-handling system.  For now, it converts RGB values to decimals and back again (necessary for the way Inform passes colors to the interp), and determines their brightness.  This is particularly useful if you change the color of the status bar; dark colors can be paired with white text and light colors with black text.  It's remarkably legible.

I don't know how strongly people feel about their interp's color choices, though.  I've left the main window alone, but I'm not sure how changing the status bar/borders works with various interps.  Honestly, I've considered messing with the main window, but people's vision is different enough that that's a dangerous area to play with; I've got severe astigmatism and there's quite a few websites that are illegible to me due to the blurring of text. Better to leave that alone, I think.

It's excrutiating to find clear-cut information on standard color manipulation online.  Playing around with Photoshop/GIMP a little, it looks like brightness, saturation, and color mixing are biggies I'd want; other helpful things would be the ability to determine what color family a RGB value is from the value alone.

Naming is a pretty big issue; until now, I've been using color names (ie midnight blue, cobalt blue, etc.) to indicate both shade and color family.  I'm sure there's a way to determine what named shade a particular value is closest to, but it's hard to think of one that isn't time consuming, and it's not really worth it for large numbers.  

Possibilities:

- cut out shade names entirely.  Sort of tempting, honestly; many of the color names are sort of silly.  Have you looked at a paint sampler lately?  "Roycroft Adobe"?  Really, Sherwin Williams?  (Downside: no "Ur-grue Black" anymore.)

- have names for the shades that I actively reference in-game, and let the rest go.  (Downside: some shades will look nearly identical but one will be named and the other won't.)

- randomly generate names.  I love the theory of procedural generation, but experience tells me that generated stuff needs a lot of tweaking to be even sort of okay, and I'm not deeply invested in color names. 

- carefully control what gets drawn from what, and make the names derivative.  That is, a mixture of rose + medium gray would be "faded rose", a more saturated version of moss green would be "vibrant moss", etc.  (Downside: time spent with dictionary and thesaurus is approaching infinity.  Fiddly.  Potential for multiple similar shades (moss green + 20% saturation vs. moss green + 50% saturation.)  

- ??

Current development window: three-sided border

Current display border mock-ups look something like this:

The status bar is correspondent with sky color; this gives players access to weather changes and day/night shifts.  What's actually in the status line at the moment is time and date, but I'm also hoping to get goals/reminders up there once they're implemented.  (At the least, emergencies should be easy to put in there.)

There's actually only one description bar implemented (left), but it looks like whatever bug I was experiencing with the interps is gone, so full framing works.  Currently, the bar only changes when the character examines something, but I'd like there to be a somewhat static location bar (for color/mood purposes, mostly).

The bottom line is temperature, although it needs tweakage (particularly the greens).

This setup gives a surprisingly large range of borders; these are a little bit cherry-picked to provide nice contrast, but not much; all the colors (except black) are from the palette above, or the dawn/twilight palettes I'm working on separately. They're by no means perfect, but even playing with the pre-alpha, untweaked versions, I'm pleasantly surprised how much I like them, and how much they add to the sense of the world.

Morning, winter

Midday, early fall

Afternoon, summer

Summer sunset

Dawn

Cold cave

63% of Bugs are Stupid Mistakes

It turns out that this:

When During Starvation begins:
    discover During Starvation;
    if the player is awake:
        say "You are ravenous."

and this:

When During Starvation begins:
    if the player is awake:
        discover During Starvation;
        say "You are ravenous."

are radically different things.  In this case, it produced a bug where the PC could wake up after a refreshing nap and have *no idea* she was starving to death.  Oops.

I accidentally copied from the sleeping status scene, because the only reason exhaustion would start during sleep is if it'll get cancelled out moments later.

When During Exhaustion begins:
    if the player is awake:
        discover During Exhaustion;
        say "You are very, very tired."

 Man, that is a winning bit of prose there for the exhaustion scene.  I bet I thought it was funny at the time.

IF Comp 2010: Mad Scramble

Am trying to get as many games done as possible before the deadline.  No time to take notes!  No time to let things percolate or sink in! Quite a few of them I'm not voting on, but some are pretty clear. 

I seem to have hit the "horror" section of gameplay.  Or, er, something.  Horror that doesn't seem to want to terrify.  It's like some authors bought all the horror tropes on sale after Halloween last year, and wants to put them to good use, so they're just scattered through the game.  Look, a corpse!  (Booga-booga.)

I *like* horror, dammit, enough so that I was procrastinating on gameplay by watching the borderline hilarious-awful Black Water last night.  I mean, that's dedication to the genre right there.  Black Water was all about the setup, with horrible followthrough.  Spoilers to follow (for the movie, not any particular game.)

Clueless tourists go out into the Australian outback in a boat.  This is not the first clueless-tourist-in-a-boat-in-the-outback movie I've watched, and I know now that boats with tourists are the equivalent of bacon-wrapped doughnuts for crocs.

They are almost immediately hurled into the water, and the rest of the movie is spent with tense music as the characters invent excuses to get close to the water so we can wonder if they're going to be eaten this time.  It is horrendously boring.  (A little actual research would have made the movie minimally plausible and infinitely more scary; crocodiles are predators, and territorial, but not necessarily loners.  They also don't kill people for the fun of it, or leave corpses floating around in the bog.)

The horrible climax involves the girl being dragged around, half-drowned, and carried by the crocodile to a sand dune.  Sole damage to girl: a broken finger.  Then she managed to kill the croc with a single bullet from a gun that has been in the water for at least 24 hours. 

The final shot is the girl rowing out of the marsh.  It's one of those glorious stock shots, because you know what's coming: the camera pulls back, and you see a crocodile!  Or: the camera pans right, and you see a crocodile!  Or: the camera pushes forward, and suddenly a crocodile overturns the boat!  Or something.  But no.  (There is a tiny little frog-splash off-screen, but no pay-off.  Fail.)

I have a point.  What was it?  Oh, right.  I don't give a toss if you include tropes in your story, but your have to make them pull their weight.  I think sometimes people think the set dressing *is* the horror - dead bodies are scary, so having one or two cavalierly strewn about is adequate.  Dying yourself is scary, so including some random and unfair deaths is horrific.  But the more expected and mundane those elements are, the less effect their mere presence has.  Ho hum, says the player, *another* corpse?

Horror is not about the presence of horrific things, or even about horrific actions (although we're getting closer, there).  There's plenty of movies about horrific things (war, rape, murder, Enron executives) that are clearly not genre-horror.  90%, 95% of it, is atmosphere, and to do that, authors have to go there, and embrace what's happening.  Several games I felt were faintly embarrassed by their chosen genre, and never went for the potential their concepts had.  (Or were so unclear as to leave me completely puzzled as to the desired theme, story, or goal of the game.)

So: horror.  Embrace it.  Horror's a neat genre, in that the goal is to provoke emotion.  A lot of genres are defined by the props they bring: if there are unicorns, it's fantasy, if there are werewolves and London, it's urban fantasy, if there is shiny tech, it's sci fi (even if the story is all mythology, it's still classified as sci fi - ask me about Star Wars sometime.)  Horror starts with a definitive goal: make the person on the other side of the screen feel something.  Creep them out, scare them pantsless, give them pause the next time they go to turn out the lights.  Text has the power to do almost every flavor of fear out there.  You don't get jump scares, but that's cheating anyway.  But since you're doing all this with text, you have to craft your writing, even more than usual, because to be successful, you *have* to tap into players' emotions.


In other news, Aotearoa is making me weep soft tears of joy.  The tutorial mode is sort of like a overly friendly puppy that just has to sit on your lap and lick your face this instant, but man.  I want to take this game home and pet it and feed it and call it George.

Ranting aside, I enjoyed this comp way more than last year's.  Better games, I think, and being in the community some really has helped.  I've had a couple interesting dialogs with authors.  I feel burned out, though.  I just don't feel like playing *that much* IF, and I'm sort of embarrassed to realize it.  I don't mind playing 50 hours of video games in six weeks.  But I'm slower with text, and I like time to process everything. 

Automatic Dressing

After a lot of fiddling, I have the foundation of a clothing system I'm pretty happy with.  It's strongly based on "What Not to Wear".  I added a bunch of body parts, in preparation for injury and discomfort work and because it's weird that the PC might be able to examine her thighs, but not her arms.

In short:
- Human is now a subset of person, holding both men and women.  This helps tease out animals from people (obviously), but also makes it easier to assign appropriate body parts.  I don't have current plans to implement extensive body parts for animals, but this leaves the door open. It also leaves the door open for gender-change for the PC.  I'm assuming she's a woman, but making this will make it trivial to change, as well as clearing up some awkward checks.
- Humans have 10 standard issue body parts: head, neck, torso, and a pair each of upper arms, forearms, hands, hips, thighs, calves, and feet.  The upper/lower distinction for legs and arms lets me fiddle with clothing (long-sleeved vs. short-sleeved, pants vs. shorts), which helps a lot with the upcoming work on warmth. 
- Not breaking up the pairs into left/right saves a lot of disambiguation stuff that was making me cry.  If it seems important later, I can handle it internally to the object.
- Most of the relations (overlying/underlying) are similar to the original example.  However, the way layering was set up was not robust and required a lot of delicate testing, and didn't work well with things covering multiple limbs (sleeved stuff especially).
- An article of clothing has a list of numbers, which is usually just one long, indicating where an article goes.  The first number indicates the area of the body, to help diminish confusion for future additions.  The second indicates layers away from the skin.  So, layers on the torso go (theoretically) from 10-19, with 11 being the first layer available to clothes.  I don't think I officially assigned limbs numbers, but the torso is theoretically 10.  So 11 is stuff like bras - skin contacting, tight clothing.  12 would be undershirts, 13 would be shirts, dresses, blouses, or other "normal" wear.  I think the highest layer I have is 18, for coats.  (There's a few empty layers in the middle where I could imagine things going, but didn't want to implement them.)
- There's code to "initialize the clothing layers", run at the beginning of the game, which explicitly details the overlaying relations (now every scarf overlies every neck).  Interestingly, if there's more than one layer involved (every bra overlies every torso, every shirt overlies every bra), but the initial article doesn't have an implemented object, just a kind, weird bugs start popping up - the relations only carry through if there are real, physical objects.
- There's some very basic code to get automatically dressed.

>get dressed

(first taking the black bra)
(first taking the old pair of underwear)
(first taking the black dress)
(first taking the black pair of socks)
(first taking the pair of shoes)
You cast about for underwear and put on the old pair of underwear and the black bra.
You put on the black dress over your underwear.
You slip on a black pair of socks, followed by a pair of shoes.

I am not pleased with the spacing, nor with the command clarifications.  And, uh, the writing itself is not the most stellar description of getting dressed ever to appear in literature.  It's still a step up from:

(first taking the black bra)
You put on the black bra.
(first taking the black dress)
You put on the black dress.
[repeat ad nauseum]

Getting a coherent paragraph when there's a bunch of options is a genuine challenge; I'm not quite sure what to do about it.  Maybe it's the price you pay for convenience.  In good conscience, I can't really *not* give a meta-command for stuff like this. There's some significant tweakage to be done, but the core is pretty solid.

Wish List:
- Automatic dressing when the PC leaves the house.  (Harder, because the PC may have to go to a closet or bedroom or other storage space for clothes, get dressed, and then leave.  Also sort of overrides nudists.)
- Automatic dressing/undressing when the PC sleeps.  (Easy, but more difficult when you're detecting for situations where the PC really oughtn't change to pajamas - say, napping in the hammock or freezing to death because the fire's gone out.)
- Dress for temperature changes: if it's 95F, the PC will wear linen, short sleeves, shorts, etc.  If it's -20, the PC will wear multiple layers in heavier materials.
- Corollary to the above: punish the PC for wearing inappropriate things, via messages or more serious in-game consequences. 
- Outfit appropriateness for cleanliness, wear, etc. - PC should prefer clean clothes in working condition.
- Gender - right now, the player will wear a random outfit in the location.  Some of us don't mind men in skirts, but others might care. 
- Habit.  This would really be the ultimate goal, right?  Watch what the player wears voluntarily, and try to copy that.  Not worth the time sink in clothing, I think, but worth considering how the game might detect player preferences, because it would be awesome elsewhere. 

Immediate goals:
- Materials (cotton, wool, leather) for clothing.
- Consider clothing manufacture, and the randomness vs. customization ratio involved.
- Fix the command clarification lists for getting dressed.

Frivolous self-indulgence:

>embroider dress
(with the scarlet thread)
You embroider the black dress with a bunch of huge triangles.

>embroider shirt
(with the scarlet thread)
You embroider the shirt with a couple running dogs.

 >embroider socks
(with the scarlet thread)
You embroider the black pair of socks with a border of fearsome circles.

... okay, I might need to take another look at which modifiers are applied to shapes.

IF Comp 2010: How long is 2 hours, anyway?

(Dear authors I've betaed for: this is not directed at any specific game/comment, past or present.) 

I keep sheets for stuff I should do to be a better beta.  I love betaing, but it's an acquired skill, and I'm acutely aware when reviews go out with stuff I missed or thought but didn't mention.  I feel culpable, you know? Especially if it's stuff I wouldn't notice as an author.  That's one reason that my beta reports are full of nitpicky details.  If some player complains about misplaced modifiers, I want plausible deniability from my own conscience. 

The new note reminds me to set a timer and input times for the author in fifteen or twenty minute chunks.  "Playtime: 15 min."  The thing is, playtime doesn't really correspond to the transcript.  Maybe I spent ten minutes thinking about the problem before getting the answer; maybe I was just fooling around.  I tend to input commands as I think, so I don't stare at a wall of text.  I'm a fast reader, so I may well have a high command:seconds ratio.  Then again, in traditional games, I'm usually well behind the bell curve in actual "progress".  (It floored me when someone mentioned that Portal was an afternoon's project for her; my reflexes suck for a long-time gamer.)

I'm guessing IF - good, juicy IF, where you want to kick the heads and examine things and soak in the environment - is even more variable than most games, but that doesn't mean it's not worth checking in with the authors about, for exactly the same reason you let authors know that their puzzles require psychics with degrees in astrophysics to work out. 

Every year, there's some games that seem wildly short and some that seem wildly long.  By the time betatesting comes around, often bare days before a comp, there's not much time to change that, but hopefully it'll give the authors some sense of rhythm.  And when I say "authors", I mean me, too. 

I've got an idea I'm tickled about, won't leave me alone, but is this an hour game?  A five hour game?  Suitable for IF Comp 2011, or not so much?  Clearly, it's hugely variable, but everyone seems to agree that A quiet evening at home is short, and Anchorhead is long.  

(Sidenote: I'm kind of a shitty judge, in that I have the tendency to wander off and make dinner, and come back to the game, and judge when I feel like it.  I've done pretty good this comp at finishing the games I've started, even if the endings aren't the most positive ones.  But: a) assuming I remembered to check the clock when I started, and b) noticed it was more than two hours since I finished, I don't try to remember what I thought the score was at the two hour point.  In fact, I come up with scores that change as I play other games, and as the experience sinks in.  It's kind of like scoring food on the first bite - that's part of it, a big part, but there's other flavors to come, and maybe after you have a bite of that cheesecake, your brownie won't seem like a 9.)