Design and documentation journal for my interactive fiction (text games); also reviews and other miscellaneous stuff.

Tuesday, November 23, 2010

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


Friday, November 19, 2010

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.

Monday, November 15, 2010

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. 

Wednesday, November 10, 2010

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.

Monday, November 1, 2010

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.)