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. 

Wednesday, March 23, 2011

Basic rain stats

Finally did an extended test run with the weather extension, just to see how the numbers broke down.  I suspected the rain might be a little high. 

It was. 

Wissotagan gets a fair amount of moisture - there's precipitation of some kind on about 30% of days.  I couldn't find average hours of rain per se, but an average, moderate rain drops 5 mm/hour.  Making huge assumptions that all rain averages out to that point, the wettest months probably get about 20 hours of moderate rain, with a broader range of 4-100 hours, assuming very light or very heavy rainfall, or somewhere between 2-10% of the actual hours will be precipitation. 

And yes, I'm lumping snowfall in with rainfall in terms of hours expected.

I ran 10 simulations out of the box for around 10,000 turns.
There is a lot of variation in the clear and rainy hours, presumably because of the way they're calculated internally.  Weather is essentially a number between 1 and 10; lower numbers are clearer, and higher numbers rainier, and sunny/clear are edge cases, so get extra randomness.  That's not a problem in and of itself. 

The average clear hours are right in the middle of my low/high/ideal ballparks.  The partially cloudy hours are too low - about half where I'd expect them to be, and the cloudy hours are on the high side - just over my most generous range.
But the rain/snow hours are essentially double my most generous guess (all rain being extremely light). 

This makes sense in most cases that the extension would be used, where it's probably more valuable that weather changes and is visible to the player than it is to adhere to a somewhat arbitrary realism.  It's sort of an issue here, though.

The problem is two-fold:
- I'd like to be able to incorporate rain as an actual effect on parts of the simulation, and elevated numbers are going to bork the sim unless I do constant fixing.
- It's vaguely silly to have it raining constantly when you want the world to "feel" real.

These are only going to be exacerbated by any graphic display, emphasizing *just* how often it's rainy/cloudy.

So I added a semi-random tweak that kicks in when the values are high (cloudy/rainy) and makes it more likely to be sunny.  That helped, but also sent clear number soaring into the range of 50%+.  So I added a line that bumps up sunny values on occasion, and I'm getting about a 30/35/30/5 split between clear/partial/overcast/rain.  That falls into default ranges (a little high on cloudy days, still, but 35% is a dramatic improvement over 50%.  The rainfall quantities are still a little high if I use the default rain rates (about double), but I think I can tweak the rainfall rate so that they stay a little light (averaging out 2.5mm/hour rather than 5, which is borderline light/medium rain).  I suspect the easiest way to do that is to make rain start fairly lightly, which will pull down the overall average, but I can't remember how I did it originally.

Other updates

- Graphics continue to kick my ass.  Photoshop is being a gigantic pain, and sprites and layers are coming out of my ears.  I'm kind of overwhelmed there.  But I've got trees down pat - there's a couple maples, an oak, a cherry, a pine, and a willow done; I think a couple more foundation trees will give me really good range to do things.  The oak may need to be redone - there's a good approximation of oak leaves, but I'm not sure it matches the rest of the style.  The color needs to be tweaked on some of the layers, especially the spring ones, but that's be easier to see once I've got groups up.  (I think.)

- Took a crack at making a map that looked drawn by the PC.  I found the right brush settings to make it look charcoally, but not so much with the actual "this looks good" part. 

- Clarified some ideas on the advantages of maps, compasses, watches, and other physical/temporal location tools. 

- Removed some ideas that totally weren't working in terms of animal generation and placement.  (Basically, strict assignment of probabilities by region, with spawning calculations - the whole thing was wretchedly complicated, and added nothing to gameplay.  Also, it was manically bug-prone - the last straw was the spontaneous generation of rabbit burrows in every location in a 12-room block, despite careful coding designed to prevent such a thing.)

- Completed 3 more entries to the Encyclopedia of Doom.  (This sounds trivial, but every little bit helps.)

- Added 10 more things that need entries into the to-do list for Encyclopedia of Doom.  Have started combining entries to save sanity.

- Found a scanned copy of one of the early Sears Roebuck catalogs.  It is awesome - a good reference for prices, and comprehensive enough that it helps remind me of refinements, or clarify choices of use.  Honestly, I haven't added all that much *stuff* from it (YAY), but I have better ideas how to differentiate between certain tools, and a better idea of what sorts of things should be on sale, and some fun new terms to throw into patterns and descriptions.  American frontier needs are surprisingly similar to post-apocalypse survival needs.  One of the watches actually has a calendar and moon phase tracker, which amuses me to no end, because that would be actually useful in FTA. 

Tuesday, March 15, 2011

I love the Internet.

I love the internet.  Not just as the best tool for procrastination ever, either.  Did you know that you can search flickr within a certain area, and the pictures you look at tell you when they're taken?  Hugely useful for the stuff I'm doing on relative bloom times for the various sprites.

Most bloom times are actually controlled by day length and weather, but there's way less calculation involved if you go with a straight date range, with flowering starting somewhere in there.  There is risk that the daffodils will start blooming in the middle of a spring snowstorm, but trying to derive the specific flowering factors for unimportant species and translate those into game terms does not sound like a good time.

I'm still working on sprites.  It's slow, but still fun.  Birch has foiled me completely - it's really hard to get white trunks to look good.  I finished willow this morning.  I think if I get a couple evergreens, an oak or two, and another maple, I'll have a good basis for the majority of the forest backdrops; a few flavor trees (plum, dogwood, hickory, basswood, and/or elm), and a couple bushes, and I can make it pop.  I'm finding that my monitors really *do* display colors differently, just like they tell you they do, but there's no good way around that.  I'm having an issue that the light/bright leaf colors practically glow in night scenes.  I don't really want to create night sprites for every tree/season combo, so I'm looking for alternatives.  The leading alternative is to put a semi-opaque black filter over everything that is not the moon.  Since the moon comes from behind the trees at some points, this is actually a bit of a sticky widget, since the moon should be in front of the darkening filter, but behind the trees, and the filter needs to be in front of the trees to work right. 

I'm looking for ways to make the initial player map look handmade.  (Well, the current one looks handmade in Paint - I'm looking for one that looks handmade with paper/charcoal.)  I haven't found a convincing filter/brush set yet, but we'll see.  I think the change from saturated, fully featured might make the display a little less distracting - there's less going on.  

No implementation this week.  Did a few more encyclopedia entries.  Thought about the horrific tangle that cooking represents in the design documentation.  Had to go sit down with a cool compress.  The documentation for cooking was written very early, and basically calls for an impossible level of programming skill/manipulation.  Seriously have no idea how that could be both workable and not hysterically awful in its output. 

Thursday, March 10, 2011

Graphics Stuff

Cautious optimism about graphic stuff continues apace.  I'm basically thinking a top frame with a landscape made up of various sprites.  I think by layering the sprites and triggering them at different points, I can get a nice landscape that gives the player instant access to a bunch of info.  It's work, but it Fun Procrastination Work, not Maybe I Should Take Up Newt Catching as a Hobby Instead Work. 

Above is a .gif of a maple with its seasonal sprites.  Let me know what you think about the style - it's the first one completed, so there's time to turn back, but only for a narrow window.

Sunday, March 6, 2011

FTA Update (3/6)

Not much actual work-work this week.  I did some work on the graphical stuff that I am tentatively pleased with but is extremely unfinished; I'm basically sitting on it for a week or so to see how I like it, since its adoption means creating a non-trivial number of sprites and then doing a bunch of tedious implementation stuff.  Also, thanks to the interlibrary loan, I got my hands on a copy of Vegetation of Wisconsin, which was written in 1956, but is extremely detailed and helpful - he gives some very helpful numbers and breakdowns, as well as listing species that will be very helpful when the time to write descriptions comes along.  (It's also really good for suggesting location names; all kinds of glades and groves and sinkholes.)  I also spent a couple hours on the help, filling in actions and their specs.  It feels weird to write a general informational paragraph about "taking".  The worst part is knowing that I'll need to revisit these pretty frequently to refine/add stuff, but it'll be nice to get them to an alpha level. 

I still need to fix hunting, which is kind of hanging out unfinished.  And I found an issue with the sleep code; since the game never forces you to sleep, you can go indefinitely, and then if you ever do sleep, you'll make up all that sleep at once, which can be thousands of hours.  Oops.  (Fortunately, you can't starve to death now, either, so . . . )

Which reminds me: I need to create some sort of sleep debt system, and probably also make the PC collapse from exhaustion eventually.  The same sort of thing needs to happen for eating, incidentally; right now, the game will stop you from eating if you're too full, but "full" is directly tied to "having enough calories".  I'm thinking of a sort of bank account for calories; at the end of each day, the PC's surplus or deficit over his daily needs is socked away; if the deficit is too low, the PC starves, and if it's too high, the surplus is lost.  That does have the downside of having the PC starve to death at the same time each day, which is not awesome; maybe there can be an hourly starvation check or something.