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

Thursday, March 31, 2011

Building in Testing Commands

I'm in the process of building in test commands for graphics, although by necessity, they sort of spill over into time/weather/season territory.

It's kind of a pain, but a useful pain, and it's better to do it now than wait until I've lost the pieces of what's happening.  Testing commands vary from the pretty simple, like >DAWN, which starts the transition from night to day, to the all encompassing >GRAPHICS REPORT, which theoretically will dump a boatload of information so I can pick apart things going wrong.

Thankfully, most of the commands are fairly straight forward; what I do need is a hard reset for sprite values.

Weeping willow in late summer
What happens now is a daily check for sprites that might be in transition.  Most sprites have a number of different images they can display, and then flip over at some point.  That point works best when the edges are fuzzy; that means not all sugar maples change color at the same time.  This is nice aesthetically, as it gives the forest a much more diverse, interesting look during periods of transition, but it's also nice because it makes it impossible to pigeon-hole the date, so there's no pinpoint accuracy.  At the same time, because the edges are fuzzy, there's a much more accurate sense that the seasons are moving, and it's easier to tell where in the season you might be.  Summer and winter tend to be relatively stagnant; I suspect this will be less of a problem with summer, which is bracketed by two active transition periods, and is only a couple months long, and more of a problem with winter, where one essentially looks at snow from the end of December (ish) through the end of March (ish), with a few periods of thaw towards the end.  I'm not quite sure what to do about that; I'm pretty married to the long, hard winter concept. It might be okay, in that most players will probably be doing more time consuming activities in the winter, so days may appear to go faster because there's fewer turns on average.  (This could be wrong, too - some of the farming activities are pretty time consuming, too.)  Still, it's possible that there might be other ways to provide a little visual variation.

The transition periods are then unique, depending more on random number checks than anything else.  Each April 15 is going to be slightly different.  That means that when I want to test, say, April, I really need to start in March, and wait for the turn-over - or have a hard graphics reset, which sets each thing to its ideal stage for the specific game state.  This is easier to program than blending, so it'll probably be the first implementation phase for the transition into Inform.  I don't expect the transition programming to be especially difficult - I suspect that a daily run through of sprites with the "wrong" image for the season, combined with a n increasingly likely chance they'll turn, should be adequate, but I am anticipating some excitement as sprites get remixed and reveal Issues.

Main Triumph:

Dawn works now; it needs a little more data tweaking, but the framework is in place.  Essentially, a scene called Dawn starts about 45 minutes before sunrise; the sky gradually lightens to gray, then to a randomly chosen, appropriate dawn color (still working on this bit) as the sun hits the horizon, then to a second color, then to the appropriate sky color for the day (blue or gray, depending on weather.)  The transition is a bit clumsy - you can't do straight from yellow to blue, because it goes right through green and looks absolutely wrong, so the first and second dawn colors needs to be different and carefully chosen.  This is somewhat more of a pain than I expected.  I was hoping to have general ranges, but I think now I'm better off with a list of approved colors, *possibly* with a few tweaks (ie random saturation/desaturation, brightening, darkening, etc.) to get variation.  Two color transitions is just about right, I think.  I tried it with three, and it felt overwrought.  From full-on darkness to morning is 55 minutes; about 25 of those involve unpredictable color shifts. 

Sunset will be similar - moving from blue to a couple peak colors, possibly followed by a "twilight" dark blue/purple for a time, then black, so I'm hoping I can reuse the code, with a few tweaks.  After that, it's testing, and then getting a few people to test it to see if I missed anything egregious.  Other sky-related stuff should probably wait until I'm looking at the full-on, everything-in-its-place version. 


  1. For winter, how about having the snow line gradually rise (and maybe fall a little bit sometimes) as winter goes on. This past winter in Vermont, the banks of snow by the side of the road were definitely getting higher and higher and higher.

  2. That's a good idea! There's already a measure for quantity of snow on ground, so it shouldn't be too hard to hook into that.

  3. Cool stuff, can't wait to see it in action!

    I wonder if you could make use of a quiet addition to the 6E/6F builds of Inform: the figure-name type can now carry properties. You could use a property (or more than one) to organize state changes; e.g., "if the image the sprite object is currently displaying is of the type 'transitional', then change to the next image in the sprite's queue". This might be a fairly compact way to store information about transitions and so on.

  4. Erik - ooh, much better than the monstrosity I had sketched out.