Crops, Part the First

Crop plants are an entirely different thing than the wild plants, and require a lot more delicacy.  There's kind of a bunch of factors, and I haven't quite sifted out "want to do" from "plausible to do" from "bad idea".  A lot of the crop planning that I did was done either before I started programming, or while learning I7; as such, it doesn't really take into account things like "difficulty" or "memory".

Initial plan: Implement lots of crops, each with lots of cultivars.  (A cultivar is a specific type of a species, like Red Delicious apples or Brandywine tomatos.  There can be dozens or hundreds of cultivars per species, each with a unique set of genes.  Sometimes those genes are better than average - maybe Jonathan apples are unusually resistant to disease.  Sometimes they're worse - Brandywines don't ship well at all.  That mix of characteristics makes it fun to play with, since you can select different cultivars based on what you want to do with a crop.)  Each cultivar would be implemented as a set of genes.  You could choose to cross pollinate plants yourself, and get a range of cross-bred plants with various characteristics, and purify those to a single strain ideal for your needs, or you could just roll with a store-bought variety.

I basically think this would be loads of fun, but I cannot see a good way to run this without horrific memory and parser issues.  A pure graphics game would handle this with more aplomb, but consider: you cross Apple A and Apple B.  You plant only 2 apples' worth of seeds, and get 10 saplings.  They're all crosses of A and B, but they're unlikely to be clones of each other; Inform will want to refer to them separately, and the PC will want to refer to them separately.  I could assign arbitrary ID's, but the player won't have good reason to be able to tell them apart for years.  Much worse is if the PC crosses and plants a field of trial corn.  In that case, there's nothing for it but to fake the cross somehow, holding the genes and then giving the player a couple improved (or unimproved) plants at the end.  That sits wrong for me.  And that's not even getting into memory issues, storage of data for new cultivars, clarifying to the player what's good and bad about specific plants/fruit, tracing the crop back to a specific mother plant, and about 26,000 other issues.  I'm also a trifle unconvinced that there's enough difference between cultivars to be deeply meaningful in 90% of the cases.  In essence, the very set-up of the game determines what uses most of the crops will be put to.  The PC is not running a gourmet kitchen, where a diverse spread of subtle and unusual flavors is important.  It's hard to even describe those flavors without sounding really, really stupid.  (Flavor description is a beast.)  And the difference amongst cultivars is usually smaller than the difference between species - that is, two tomatoes are going to be more alike than a tomato and a bean, so you get more bang for your buck with two species, and less of a rate of return for cultivars.  And cultivar information can be hard to gather and gauge accuracy for.  I can give you ballpark estimates for how many bushels come from a row of corn, but I couldn't tell you whether Silver Queen was better or worse.  And it's likely to vary depending on the part of the country and techniques used.

Given that, I'm reluctantly letting go of most of the cultivar stuff.  I'm not 100% on it, yet, largely because I think some choices are meaningful.  For example, does the PC grow green beans, dried beans, or both?  That makes an impact on play.  Green beans are likely to produce more, earlier, but requires additional time and energy to preserve for winter, during months when there's a lot of other stuff to do.  So it's a time management issue, which seems like a good option to offer.  But as to whether the dried beans are speckly or black or stripey  . . . I hate to admit it, because I *love* that stuff, but there's not nearly enough pay-off there.

I think that energy can be better spent on creating a mechanics heavy crop system, where species have certain qualities that affect growth.  In this scenario, there's far fewer individual checks, and a lot more sweeping categories and behind-the-scenes gears.  So instead of talking about species, the game would mostly be dealing with frost hardy plants, or edible-fruit plants, or cutworm vulnerable plants, or whatever.  Get enough of these categories, and the species start sorting out in interesting ways.  And, at least in my theoretical role-play scenarios, it encourages the sorts of play I want to encourage: crop diversity, attention to insects or disease, interest in the general traits of various species.  It means the player has to keep less info straight - before, the player might have had a dozen cultivars of apples growing at any one time.  In case of insect infestation, the player would need to remember or look up the resistance of each cultivar, and treat the vulnerable ones.  That info would never be retained into another play session.  And, honestly, there's just too much time in between pollination and the time the player sees results.  It's at least a growing season, sometimes more, before the results become clear, and a lot of players aren't going to go beyond one season.  (And I'd be surprised if the first year is anything except "quick, plant stuff!")

This is the first design decision I've made that really hurts, and not just because I've already done a fair amount of research.  It changes the mental picture I'd had coming in, and although I believe I'm making the right decision, it's no longer my fantasy game.  Of course, no implemented game can actually be a fantasy game - already there's stuff implemented that's a compromise or outright re-neg, but the cultivar and plant breeding piece was big, and I miss it. 

There are still a lot of implementation issues to deal with, so I'm not ready to start coding yet.  But I've got some preliminary lists of crops I'm looking for info on.

Currently, there's a couple broad divisions by type of crop, with rankings as to which to I'm leaning towards implementing first.  I have no doubt that I'll get bored at some point, so it would be nice if the mechanics allow for easy additions.  That means not implementing all the grains first - that radically increases the chances that I'll never get around to tomatoes, because it's so much work.  If I start with corn and tomatoes and beans before moving on, it means less work adding stuff.  It also means that pre-alpha testers can get a better sense for how things might progress.

All this is tentative.  1st pick is the single thing from a category that I'd want, if I couldn't have any of the others; I'd like to get the first picks done before adding other stuff.  2nd tier is the stuff I'm pretty sure I'd like to get implemented; 3rd tier is stuff I'm not sure about and/or have trouble getting info on, but haven't outright rejected.  Things are mostly listed in order of preference in tiers.  I'm pretty confident I can get through about half the 2nd tier stuff, but less confident after that.

Grains: Botanically, this category shouldn't include some of the stuff it does colloquially, but I've always suspected that botanists just don't have enough to do with their time, so I'm going colloquial on this one.
First pick: corn.  Wheat would work, too, but Winnegan is much more a corn state than a wheat state.  Besides, it's one of the three sisters, so it has nice symbolic importance, and it has a lot of finickyness.  If I can get the mechanics right for corn, that sets up real nice for a bunch of other, more forgiving, crops.
2nd tier: wheat, barley, rye, oats
3rd tier: buckwheat, millet, amaranth, spelt

Roots: One of those weird, fuzzy categories, encompassing some roots, some rhizomes, even a thickened stem or two, I think.
1st pick: potatoes, hands down.
2nd tier:  carrots, beets, sweet potatoes, turnips (I'm a little vague on the differences between beets and turnips, so maybe just one)
3rd tier: radishes (3rd tier because it's less a calorie crop than most, and how many people voluntarily eat many radishes?  I eat a ton of the big Asian varieties, but the hot thumb-joint size ones?), parsnips, rutabaga, sunchokes, scorzonera (almost definitely out, but weird and sort of tasty, so not bumped yet)

Legumes: an actual botanical category, having something to do with . . . um . . . the way the pod splits open?  Yeah, I dunno.
1st pick: beans.  The normal kind, both green and dry.  Another three sisters pick.
2nd tier: peas, soybeans
3rd tier: fava beans, peanuts (people do grow these in Minnchicon, but . . . really?)

Fruiting vegetables:
1st pick: tomatoes - should be squash to round out the three sisters, but I think tomatoes are a bit more classic.

2nd tier: squash (winter), peppers, melons (musk), squash (summer), eggplant, cucumbers

3rd tier: tomatillos, gourds, melons (water), artichokes, okra, luffa, bitter melon

Greens:
1st pick: spinach.  Yes, probably should be lettuce, but I don't like lettuce, and if anyone gets to make petty decisions based on personal preference, it's me.
2nd tier: chard, arugula, kale
3rd tier: mustard, lettuce (okay, yes, this should probably be tier 2, but ew.)

Brassicas and stuff:  Actually, a bunch of brassicas are in other categories.  Maybe this is a miscellaneous bitter green category?
1st pick: cabbage.
2nd tier: uh . . . actually, not that sure I want other brassicas.
3rd tier: broccoli, asparagus, cauliflower, endive, rhubarb

Berries: Again, the non-botanical sense - canes or ground plants or vines with berry-ish fruit.
1st pick: grapes.
2nd tier: raspberry, blackberry, strawberry
3rd tier: blueberry, hardy kiwi

Tree fruits:
1st pick: Apples.  Purely a versatility/popularity choice.
2nd tier: pears, plums, cherries (sour and sweet?)
3rd tier: crabapple, Asian pear, peach, apricot


Oil plants: Several other plants give oil, of course.  Ah, well.
1st pick: none.  This would be a strictly 3rd tier optional venture.
3rd tier: poppies, sunflower.

Aliums and things:
1st pick: onions.  (Garlic's a close second, but because of the way it's used, I've reclassified garlic as an herb.)
2nd tier: leeks
3rd tier: fennel, shallots

Herbs:
Very 3rd tier in general, as these're reliant on a cooking system that might utilize them (or being picked up by another craft system).
1st pick: garlic
2nd tier: basil, oregano, parsley, dill, chives, sage, thyme, lavender, rosemary, marjoram
3rd tier: anise, caraway, horseradish, shiso, sorrel, chamomile, horehound, bayberry, borage, hyssop

Nuts are available only in the wild at the moment; I suppose I could change that.  Something to think about, anyway.

Graphics Speed Optimizing

Procrastination is dead.  Long live procrastination.  Yes, that is one of those fluffy flavor graphics I wasn't going to make until everything else totally working.  Sue me.

I'm feeling good about the project again, which is awfully nice.  I'm sketching out the speed boost for the graphics, which mostly consists of doing something about the *cough*mumble* hundred tree sprites. 

If I were very very careful, I think it would be possible to collapse all foreground layers to a single sprite with seasonal changes.  It would mean setting things up in Photoshop and snapping a "picture" of each season.  That would be fastest, and I'm not wholly opposed to it.  The downsides are: loss of flexibility and loss of variation.  The loss of flexibility is more serious - what if I touch up the "bare earth" layers, which I'm not happy with?  Instead of just saving new versions of the changed layers to the materials folder, I'd need to open the original Photoshop file, retake the pictures, and replace them.  If there's any kind of misalignment or color tweak, this would need to happen every time.  Those extra steps add up, and if I ever lost the master file, I'd be screwed.  (It would be a pain to recreate the master file from the current materials folder, but doable.)

So step 1 is making backups of the essentials - both the master photoshop file where I do tweaks and check general layout concerns before going into the canvas editor, and the original, large-size sprite files. 

After that, I'm planning on turning umpty hundred trees into a handful of layers: 3 backdrop tree layers, to give the forest on the horizon depth, and 1-2 foreground layers.  I'm planning to drop the interstitial layer between the front wave of grass and the back wave of grass, and merge the grass layers in-game, although I might add some seasonal herbaceous plants or flowers in there.  That frees up a layer for the cliffs, which have always been in the plans, but need to go in the far distance, behind the forest on the horizon. (Yes, it used to be bluffs - cliffs with a flat top - but now it's just sort of craggy hill things.  Turns out they're easier to make - bluffs are hard, and I couldn't find a top that I liked.  A for effort, but C- for graphical accuracy.)

In order to cut down on the work, I'm creating little tree groves - maybe a couple maples and a basswood, or five oaks and some bushes.  Arranging these tree packets is quick, and flipping stuff over and putting them in different positions makes it harder to spot that placement is not entirely random.  I practiced yesterday on the cliffs I made.  The forest is mostly in a place that won't be seen, but it was very informative.  Random placement is not as good as beginning at the back and working to the front - all kinds of overlap issues begin to crop up if you do that.  That means switching between sprites more often (so you get more diversity) or working over a larger area than the cliffs provided.  The grassland area should be fine.  Also, things get choked up with layers pretty darn fast - I'm planning on grouping every tree group into its own folder this time, and periodically combined/flatten out the various layers to speed things up. 

Or, you know, maybe your view will be of a prairie.  Writing all this out makes me tired.  Fortunately, it's definitely something I can do in little bursts of procrastination as a break from rewriting the damn hunting function, or implementing fish, or something.

800 width pixel crop - the small end of what I expect people to use.  I'm not thrilled with this one, but it does have some framing.  I think some branch/trunk might be better - but perhaps a bush under the tree would round things out.

1200 pixel crop - probably about where most people will end up.  Notice the complete lack of forests on the horizon.  Pretty sweet moon, though.  Notice how it's got a blue background during the day, just like a real moon?  Also, I think I better shrink the celestial bodies again.

1800 pixel crop - probably about as big as I plan to design to.  I feel like something should go on the left-hand side.  The dense pine forest is the experimental part of yesterday.  I think it looks pretty credible zoomed out.  (Zoomed in, it's pretty clear that I have exactly 2 pine sprites, and have trouble drawing cliff shadows with the mouse, and not enough patience to use more than one brush size.)

Cliffs, without trees. Something here is the wrong color.  Cliffs too white?  Back hill too blue?  Clouds?  I'd like to find a way to give the snowy hills some softness, but haven't been successful yet.

In other news, I fixed a couple minor things in clothing, and began to do the necessary work to make it possible to make clothes.  (Baby steps, but still.)  I stripped some old graphics code out of a couple places, where it was really gumming up the works, made some design changes to the way I want plants to behave, and investigated the Multitudes extension for the gathering of wild plants, and possibly a switch in tree calculations. 

FTA: Cooking

Mushroom cloud-shaped cake.  I worry about people sometimes.

One of the first IF games I wanted to write was a Iron Chef style competition.  Your PC would have access to a kitchen and supplies, and would have to fricassee, blend, saute, and garnish her way to victory.  At the end of a game, the judges would give ridiculous reviews of your hideously complicated dish, and you'd win if you'd managed to garner enough points. Or maybe you'd just win.

I got as far as the beginnings of a taste mechanic.  I figured if you were able to decide what combinations of flavors went well together, and assigned ingredients a specific flavor profile, you could have a fairly flexible system that would predict taste outcomes.  For instance, lemons and chicken are classic, so the game would give a certain number of secret bonus points for an bitter/sour poultry combination, plus a bunch of extra points if it wasn't in an expected "list" - lemon chicken in itself might not win you any prizes, but what about tonic water chicken, which would have a bitter/poultry combination? 

The mechanic really encouraged some bizarre combinations, some of which sounded remarkably unappetizing (blackberry bacon potatoes), but no worse than some of the real cooking competitions.

(I still think this game has potential to be hugely fun.  Someone should make it.)

My first impulse in FTA was to give the PC the ability to do something similar.  Sanity returned, though, and I realized I needed something way less intrusive and fiddly.  Most people do not carefully craft new dishes every meal.  I don't even think most *chefs* do that. The focus of the game isn't cooking, so it doesn't *really* matter if the potatoes you grubbed are pan-seared or not.  And God knows I'd get fed up with a game that required careful construction of three meals a day, over years. 

I've had some trouble clarifying what I do want, and this is part of that - nothing's set in stone yet.

Goals

The PC should be able to autonomously choose what to eat, cook it, and consume it.

Autonomous consumption should use food resources in a mostly appropriate manner.

The player should be able to force the decision to eat certain foods when necessary.



Desired Behavior

>EAT APPLE

 The apple is sweet and crisp.  You toss the core in the compost heap.

 >MAKE DINNER

You dine on fresh trout, steamed spinach, and roast potatoes, washed down with a couple mugs of ale.  For dessert, you polish off the last of the cherries.

>MAKE DINNER WITH APPLES

 You roast nearly a dozen apples before your hunger is satisfied.

 >MAKE BEEF STEW

You make beef stew, thick with chunks of top round, carrots, and onions, simmered in red wine, and set it aside for later.  

So there's four things here, in order of increasing difficulty.

Eat

When the EAT command is paired with an edible food, that is consumed, with nothing else.  (EAT [meal] redirects to MAKE [meal].)  If the food can be eaten raw, it is; if it can only be eaten cooked, an autocook reaction is probably in order.  If the food is a discrete unit, like an apple, the PC will eat only one.  (Maybe.  It seems like there should be an option like EAT APPLES that would loop until hunger was satisfied or the food was gone.)  If there's a lot of them, like berries, or it's a fluid or powder, like cornmeal, the PC will eat/prepare up to a given serving size - maybe a bowl full? - or caloric intake - if she's hungry, she'll eat until she's not, and if she's not, she'll eat a small meal/snack, up to the point where's she's too full to eat any more.

I kind of waffle on this bit - perhaps a single serving is appropriate under all circumstances.  If you eat stew, you eat a single bowl of stew.  If you eat bread, you eat a single slice (or roll, or whatever).  Not sure what the player's intentions would be.  I think either is potentially fine, and the single serving is less complicated, but jury's still out.

If different cooking methods are used to cook foods (ie boil vs. saute), eating would use the least demanding and/or quickest method of preparation.   EAT OATMEAL pretty much means cook up a batch of hot cereal, not turn it into cookies or bread or bake it.  (Although baked oatmeal is kind of amazing, and I should totally make some tomorrow.  Also, I should not work on food design when hungry.)

Make a meal

The PC decides, on her own, what the most appropriate meal is.  This requires looking at the hunger state of the PC to decide a calorie target for the meal.  (Obviously, if the PC's too full to eat, she's too full to eat.)  There's a location that is basically the "home kitchen" of the PC - initially, this is likely to be a campsite or cave.  Later, it should be the Kitchen room.  The game will look at the food available in the inventory, the home kitchen, and any nearby food storage rooms (the cellars, for instance).

From the available choices, the game will make decisions about what to eat.  This bit is kind of blurry - for instance, should there be a preference for breakfasty foods at breakfast?  But here's a first stab:

- Meals may consist of a main dish, plus 0-4 side dishes, something to drink, and optional dessert.
- Main dish, by order of availability:
    - non-preserved, very short shelf-life food - fresh meat or fish especially
    - calorie dense foods near their expiration, or shortish shelf life foods - breads, fresh green beans, corn on the cob, farmer's cheese, most vegetables, eggs
    - less calorie-dense foods with shortish shelf lives, combined with something a little richer- lettuce, tomato, with cheese, oil
    - moderate shelf life foods - things that might last days or a couple weeks - cured meats, potatoes, onions (with other calorie-dense food if possible), winter squash, other "keeper" vegetables 
   - long shelf life foods, preserved foods - dry beans, dry grains, canned goods, dried fruit, jerky, hard cheeses.

Side dishes - a variety of other categories of foods, either chosen to round out a food pyramid type thing, or by chance (or both).  Main + 2 veg/fruit + 1 fat/condiment + 1 grain is a pretty rough start, but yields something that at least pretends to be a balanced meal: bacon, buttered toast, tomatoes and potatoes is a better breakfast than I usually get. Of course, I'm fudging a lot of random stuff I'd be bound to get: trout, squash, corn on the cob, cheddar and oats is kind of weird.  And it would be awhile before there's much chance for randomness - most PCs are going to be eating a lot of spam, spam, spam, spam, and spam (or whatever they brought).

The nice thing about having a tier is that it seems to respond more to actual events than it does.  Since fresh meat is preferred, a successful hunt will mean that the PC can sit down to a nice bit of roast rabbit the same night, which seems like a natural response to running across protein.  And it doesn't require secret checks into whether the PC *did* go hunting - it just looks for the proper foods available.

Make a meal with something

This would be the flip side of EAT APPLES if I don't implement a "eat X until you're full" policy.  This would allow either specifying the main, or more likely, consuming as much of a food as can be managed.  Useful for trying to consume a supply of food before it goes bad - if the PC shot a deer in July, but had no curing facilities, she needs to consume as much of that meat as possible before it goes green.  But standard meal practice will only include a serving size (possibly two, if the PC is very hungry) of the fresh meat with each meal, unless there's nothing else to eat.  

Alternatively, the command could be used to force a main dish - if the PC has a fresh rabbit on hand, but wants to turn it all into jerky, there should be a way to easily dodge the default behavior of eating it for dinner.  At that point, MAKE MEAL OF BEANS should work.  This could be a totally extraneous command, depending on how EAT [something] is handled, but it's worth noting that the behavior does some nice things.

Make a specific meal

There's basically two parts of this command, one pretty froofy and one pretty necessary.

Cooking and eating takes place simultaneously.  I toyed with the idea of a meal object, but there's a bunch of problems with it that I just couldn't fully resolve.

One thing not covered would be a case where the PC would want to pack a meal to eat later - say, if she was going hunting.  This sort of thing would have to be covered by carrying edible food and then EATing it.


The necessary part: being able to make food *without* eating it, and being able to make food that takes sort of a long time against future use.  It's possible to limit this to just a couple foods, I think, but the best example is bread.  Making bread isn't part of normal meal prep.  It can't be part of normal meal prep, at least for rising breads.  It takes time, and a fair amount of work time.  So it makes sense to make bread when you have the opportunity, and eat it later.  This is a totally sensible thing for the player to expect, and really helps with time management.  (And bread's a pretty key comestible for a bunch of English speakers.)  It makes sense from the PC's point of view as well - it makes sense to take your lunch with you if you go cut down trees or hunt deer or fish trout, rather than hiking an extra few miles back to camp to slowly cook something.  Pretty much every culture has portable food for trips and situations where you can't get home.

It's a logical extension of being able to MAKE BUTTER or MAKE CHEESE.

With the theoretical tools planned, it's possible to have dried meat or fruit or something, but I'm not entirely that justifies an inability to make bread.  (Especially since it's cheaper and easier to lay hands on flour than meat or fruit.)

The less justifiable bit would be a list of specific foods and cooking methods.  This one's super tempting, but also one of those holes you'll never fill.  It would be kind of awesome to MAKE POACHED EGGS, but even I have trouble justifying it.  And it's bad enough for stuff that has a recipe - I can give a pretty good argument that most chocolate cakes contain more or less the same stuff.  (There's always exceptions.  Don't email me.)  But what is a stew?  What goes in a stew?  Meat, sometimes.  Root vegetables, sometimes.  Other vegetables, sometimes.  But hardly ever green beans.  Why?

I think I could assemble a recipe using either a specific ingredient or a kind, plus an amount.  So a stew might have 6 oz of meat, 10 oz of root vegetables, and a list of optional additions (1 bay leaf, 1 bottle of wine, 2 tsp ground pepper).  But holy fuck that's a lot of work, and it's hard for me to believe that it's worth it for anyone involved, especially since that stew will stay fresh less than a day, and in the meantime get all congealed and gross.  And let's face it - there would never be enough recipes to satisfy people, and knowing me, there'd be some kickoff as to whether the proper crust for a key lime pie is graham cracker or wheat flour, and the world would end.  (Graham cracker.  Also, no whipped cream and certainly no meringue.)

I *think* I might be able to do a decent job with a few cooking methods: MAKE APPLE PIE wouldn't work, but ROAST APPLES would.  I don't know if that's better or worse than doing nothing.  Worse, I suspect, but it's still mostly on the table, whereas the whole recipe thing . . . yeah.  Not unless I can find a way of doing it that is easy, straightforward, and just requires a couple easy-to-remember inputs into a table.

Heh.  We're moving right along on the list of features no longer under consideration.  On the up side, I never even started the recipe collection, so I'm going to count myself about 100+ hours ahead of where I would have been.

But I do need to chew over what, besides bread, the PC should be able to make and store.  It seems reasonable to me to put a few desserts on the list.  I'm looking for stuff that's fairly common - bonus points for having cultural significance.  For instance, cake seems like a real possibility.  Sugar is hard to come by, but possible, and it seems reasonable to let the player set by a dessert or two.  Also, cakes have a bunch of nice connotations - if I were post apocalypse, I'd totally try to find a something to celebrate my birthday.

If you, dear reader, think of anything else, let me know.  Preservation is a whole other issue, so dried fruit and meats, cured sausages, canned stuff, cheese/butter, and alcohol is handled elsewhere.  Also, I was going to make a joke here about how there's no apocalypse cookbook and that's totally a market niche, but I was wrong.   Then I was going to make a joke about there being no post-apocalyptic cookbook.  D:

Design Diary, April 25

Spent a good chunk of the weekend with a friend in the hospital, but hanging out in the hospital gave me some nice reading time.  (He was in for non-emergency reasons, so it's not like I was reading about mushrooms while he bled out or anything.)  Read about mushrooms and bogs.  Turns out bogs are cool, and contain some useful stuff, but aren't productive enough to sustain life on their own.  (So it's just as well that mine are located on the far north part of the map, well away from intended habitable areas.)  I'm basically using bogs as one of the world barriers - you can go in a bit, and walk around, and drop things in it (never to be seen again, usually), but that's about it - beyond that point, it's too easy to get lost, or too unstable to continue.  I'd previously considered letting the PC harvest peat as fuel and rejected it, partly because there are literally square miles of forest to harvest, and because I couldn't find good data.  I think that was a good decision; American peat bogs tend to be wetter than their European counterparts, so the peat harvested is less ready to burn, requiring longer dry times.  Not worth it in terms of PC effort or programmer effort.  I do need to make sure there's a cranberry harvest, though.  (I have no idea how people can bear to eat cranberries without *serious* quantities of sugar, but I suppose hunger is a great motivator.)  Sphagnum moss is a possible resource - it's super absorbent, and might make a good field dressing if injuries ever make it in.  Seems like there might be other uses there, but I can't think of any off the bat.  The other big thing mentioned is the presence of white cedar, which is one of those great rot-resistant woods, and thus awesome for fences and shingles (and everything, really).  I am pretty sure that there's enough of it growing around that the player won't need to hike out to the bog (and since there's no rot in-game, it's not a big advantage anyway).  There's not usually much animal life in the poor bogs; plant life is pretty limited, and nutrients are tied up, so it's a good border land; it's poverty should hopefully encourage the player to focus attention elsewhere.  (And, yeah, there's messages to redirect the player, but it's nice that there's subtle in-game reasons to turn aside, too.)
The book noted a lot of different bog types, which will hopefully be helpful in writing descriptions.  

I managed to get my hands on a good field guide to mushrooms in the Iowa-Illinois area, which I'm assuming is close enough to Minnesota-Wisconsin for my purposes.  All the mushrooms I double-checked extended farther north.  I'm so used to edible foods being non-native that it's sort of surprising that so many of the edible wild mushrooms I recognized were native species.  (Chanterelles, oyster mushrooms, lion's mane, and a couple others I can't recall off hand.)  I knew intellectually that identifying mushrooms is a tough thing, but I was taken aback just how difficult it is, even from the carefully chosen pictures that emphasize identifiable characteristics.  I tested myself with the key a couple times, and would have confidently eaten a mushroom that would have melted my kidneys. Oops.

I was also surprised just how many species are "edibility unknown", and how many more were only mostly poisonous - some appear to poison some people but not others, and others are only intermittently poisonous. 

The primary goal for mushrooms is as a wild food source, and I think that will be fairly straightforward.  A lot of the species are strongly associated with a plant species or community, and a lot of them remain in the same place year after year, so first implementation stab is to "seed" appropriate locations with appropriate mushrooms, and then have them show up at appropriate times.  I'd like them to appear in locations in addition to being available via a gathering action (similar to the way wild animals should show up now and then).  If the PC learns where the morels are each spring, more power to her. 

I don't actually want kidney-melting to be a possibility in game, which means that the PC probably needs some sort of way to figure out edibility of mushrooms.  There's the traditional taste test, but for the seriously poisonous mushroom, this is a bad way to go.  I don't really want to encourage people to go around taste-testing random mushrooms, so I'm considering requiring some sort of handbook or a skill check or something.  Lots of possibilities here, but I think it would be worthwhile to reward a player who thought to take a wildlife survival guide or something along; perhaps give them access to some easy to identify shrooms, and more to those who got a dedicated book or something?  I dunno.  A more immersive option would be a requirement to have ID initially, and let the PC gain familiarity with individual species as she IDs them on her own.  (How long does it take to learn the difference between a real morel and a false morel?)  There's some implementation fun to be had with disambiguation and privately named stuff, especially if I let the PC pick mushrooms and ID them somewhere else, rather than IDing before taking.  Worst case scenario is a basket full of a mix of mushroom types, pre-ID.  ("In the basket are some mushrooms, some mushrooms, some mushrooms, and some mushrooms.")  An ID-before taking rule would prevent this, and with some limits to growth patterns, mean there would only be one unidentified mushroom per location at any given time. 



I'd like to at least leave hooks in case I decide to let the PC cultivate certain varieties.  Under ideal circumstances, each species would have certain requirements to fruit, and if those were met, it would fruit, whether those circumstances were artificial or not.  That's a *little* tricky to pull off, though, and would require some serious investment beyond the "mushroom X lives here and here, and has a 1 in 10 chance of fruiting after it rains during the spring" setup that I have in mind.  I don't know quite what to do about that; honestly, cultivation isn't a huge interest for me, but it's a reasonable thing for the player to try, with a modest potential reward.  One option might be to keep soil mushrooms wild, and restrict potential cultivation to stump or log-grown species.  There's only two or three of them, and if the PC is clever enough to haul an elm log to a shaded spot near her house and inoculate it with spores from the elm-growing mushroom, she probably deserves a few years of mushroom crops before the log disintegrates.  This seems potentially exploitable; I don't really want locations with hundreds of logs of mushrooms, although I guess it is a legitimate strategy.  Hopefully the higher irritant factor and relatively low caloric density of mushrooms will make it non-worthwhile; I might also look at realistically quick wilt or storage times, so even if there are fields of mushrooms, the PC can only get so many harvested or eaten before the rest go bad. 

So I guess hookwise, I'd like to set aside mushrooms that grow on wood as their own kind.  Let the mushrooms be associated with certain inoculatble species.  Inoculated logs will have similar chances of sprouting mushrooms under the right conditions that inoculated locations will.  Maybe prevent inoculated logs from being moved/used for anything (because they're too decayed/damp/whatever).  Have a few decay/appear each year.  That would give hooks for deliberate inoculation later, if it seems appropriate, without drawing too much attention initially.  There would probably need to be some additional details at that point (freshly inoculated logs shouldn't just sprout mushrooms the next day, it's more important to make sure the log is somewhere sensible, and not in the kitchen or something).

Side notes:  Mushrooms are a good dye source.  Don't forget to implement them if I ever get around to dyes. 

Random thought: it also seems like there might be uses for the poisonous ones, even if the poison is fairly slow acting.  Maybe as a fish poison or homemade pesticide/deer repellent or something?  It seems plausible that dusting your plants in ground Amanita might discourage locusts, even if I can find no indication anywhere that anyone has ever tried it.  (I'm not about to, because I like my kidneys/eyesight/life, but it seems a shame to just let a perfectly good deadly poison go to waste.)

I got a couple hours to hit bugs last night.  It was . . . surprisingly fun, actually.  As frustrating as programming can be, it's deeply satisfying when I can actually get in there and fix stuff.  A lot of the stuff I'm tweaking is second or third generation code - stuff cannibalized from examples or extensions, then tweaked a couple times and merged with stuff cannibalized from other extensions.  I'm not aware of looming bugs at the moment, except for some disambiguation issues that I'm ignoring.

Hunting

Google seems to have gotten into the spirit of my odd inquiries, and now it thinks I might want to know how to kill undead bears.  Which I don't, actually.  Just regular, old-fashioned grizzlies and black bears. 

I've got a pretty good map on the hunting action now, I think.  (Thanks for the suggestions on flow chart tools - they were all better than what I'd been trying, and Cmap was indeed just about perfect.)  For most of the FTA stuff, I feel like I have some sort of footing in real life.  I've gone fishing (years and years ago, but how different could it be?).  I garden.  I take walks.  I own animals.  But I've never gone hunting, nor have any interest in going hunting, and the only guy I know who hunts is not the sort of person one wants to talk to.  So I've been spending a lot of time in hunting forums, which is interesting, but is only marginally helpful.  (Also, my browser history now includes people who think the apocalypse is actually coming any minute *and* people who are extremely enthusiastic about guns.  Including a thread by someone who wondered whether you could kill a bear with an AK-47.  I can only hope that person was working on a game, too. 

I'm just about to get cracking on implementation.  I'm going to start with a barebones implementation of the functions/odds, with really basic debugging reports attached.  Once I get that ironed out, I can start on the text and the random variations of the text. 

There's a few basic checks that show up over and over that involve things that aren't implemented at all, or haven't been merged in yet, so there's going to be more loose ends than usual to tie up, but it'll be nice to have a general flow to work with.  Programming-wise, I expect it to be pretty straightforward.  The truly tricky bit is going to be balancing the thing. 

It's a challenge to decide what the odds should be for any one piece of the puzzle.  There's a couple issues going on:
- the actual quantity of huntable animals - the hard population.  Theoretically, this could fluctuate, but it's probably not noticeable except for larger predators, so right now it's stable.
- the PC's ability to find huntable animals, which boils down to knowledge of the land, knowledge of animal behavior, and knowledge of the clues left by the animal behavior.  (I'm not sure these will be separate skills at all; I suspect land knowledge will be some amalgam of rooms explored and time passed, and the rest will be either tracking alone, or tracking + some other factor.)
- the PC's ability to sneak close enough to an animal to do damage.  Part pure skill, part environmental.
- the PC's ability with a weapon, and the animal's . . . resistance to damage?  I mean, even you're *really* good at throwing rocks, there's a difference between nailing a rabbit and a grizzly bear with one.  This is especially tricky given the shoddy weapons available to the PC - I mean, it's certainly possible to kill a bear with a bow and arrow, but maybe not with the one you made from a random branch, old fishing line, and a sharpened stick. 
- the PC's self perception.  I'm not exactly thinking of implementing this in itself, but it plays a factor in the choices I make the PC make.  Because, honestly, unless I was really desperate, I would not go around shooting at dangerous things.  Moose are like the hippos of the north - they look all funny, but those things kill.  I would have to be really sure of myself, my weapon, and my escape route before I shot at a moose, and I think the PC should have some of the same sense, rather than "Look!  A deadly animal!  Let's kill it!"  This gets a little sticky, since the player may very well prefer the PC to be more aggressive, so I may experiment with asking the player what she thinks instead. And then have the moose attack the PC.  (Never let it be said that my games are not educational.)

I'm working on the theory that in Winnesogan, animal populations have grown and sort of balanced out in the years since large human populations.  Some of the extirpated species have moved back in, including the occasional bison herd or grizzly.  (Essentially I look at the population dispersal projections pre-1700's, and if the range includes a reasonable chunk of Minnesota, Wisconsin, or Michigan, it's in, as long as I can think of something interesting to do with it.  Sadly, this does not include rice rats.  RIP, rice rats.)

It should be totally possible to survive by hunting.  It should also be totally possible to starve by hunting, especially for the inexperienced.  One way to address this is to set up some measurement of weapon quality and weapon skill vs. animal size.   Difficulty scales pretty well to the weight range of the animal, but I may need modifiers for the extra quick or predatory, because by that measure, bobcats would be *way* easier to kill than deer, and that seems off to me.  Also, should bison be twice as hard to kill as bears?  Hmm. 




Basically, I'd like to see minimally skilled hunters with adequate weapons be able to bag something small an average of once every 1-2 days, with the major difficulties being tracking prey and killing it.  To alleviate the sting of the tracking prey issue, I'm planning on increasing encounters with wildlife, especially garden-variety wildlife (rabbits, squirrels, small birds when they're implemented), so that the PC can "hunt" animals that he just runs into.  The first jump or two in weaponry skill should get the PC to the point where he can regularly get small game - probably not enough to be his sole food source, but a significant contribution if the player chooses to go that way.  By my rough estimates, an average wild rabbit would provide the player with ~1500 calories, which is nothing to sneeze at.  This may be on the high side, since some number were for domestic rabbits, which are bred to have better meat characteristics.  By contrast, an average rainbow trout might provide ~1300 calories.  So a couple rabbits would be just over subsistence level living. 



Average hunters with adequate weapons - fire-hardened spears or crafted slings or average-quality bows - should be able to count on small game - a good catch might be 2-4 smaller animals, with the occasional deer or lone coyote.   

Expert hunters with good weapons will probably experience only a slight uptick in the amount of food brought in, but they can probably bring down most any animal, although very large prey (e.g. bison) and large predators (mountain lions) or those in packs (wolves) remain dangerous and may take some luck to bring down.    


I also need to look at the relation of seasons to availability of prey.  I strongly suspect that winter needs the odds scaled back, and autumn needs them scaled up, but I don't know that for sure, and I'm not sure if that should be tied to a particular thing or just the general season. 

So: today - get the basic functions in place, do some testing to see how things are shaking out.  Set up hooks for future features like injuries.  Test more. 

Fun fact of the day:  A moose bit my sister once.

House update: Building Materials

The building action and the house itself is coming together nicely.  Indoor rooms have walls and floors, and the walls have materials.  When construction begins, the game will ask for the material to use to build the room in question; right now the choices are wooden boards or bricks.  Logs are much too difficult for a lone person to manipulate, stones aren't something I want to fiddle with right now, and earth houses like adobe or sod just don't seem to be a legitimate possibility in Minneconsigan-type climates.  But boards are relatively straight forward, and trees are already implemented.  Bricks are a bit of an experiment, and they're largely unimplemented at the moment, since they have the potential to be a significant memory sink.

Rooms have a size which can be used to extrapolate the surface area of the walls; that's used to calculate how many boards or bricks are needed to build a room.  Each room is built separately, so the outside walls are a single layer of material, while the interior walls essentially get built twice - once for each room.  I'm essentially okay with this, although padding the outside walls for insulation might not be a bad idea.  Looking at plank houses of the past, many of them were a single layer of boards, but these were often in clement climates (such as Washington).  I would not want to be living in a single-plank thickness house in a serious winter condition. 

Brick number estimates were made using running bonds (laid with each brick lengthwise, so the most surface area is exposed), but plenty of older houses were built with alternate construction, especially in colder climates.  My favorite is the "rat trap construction", with little holes between two layers of bricks to hold rodents.  I sure am sad not to live in the good old days.  In good conscience, I could probably raise the number needed by another 50-70%, but I'll wait to see how balanced it is. 

Then, of course, there's material waste - broken bricks, ruined boards, misplaced structural elements, etc, which would add onto the quantities of stuff needed.  In short, there's plenty of room to yoink the numbers up to increase difficulty. 

I pulled stats for bricks laid per hour for professionals, and halved them.  It may still be on the high side, but at least it's a working figure.  Complete construction of the house in brick would take a little over a year, which seems reasonable, if slower than I'd have guessed.  As it stands, a wooden house would take ~4-5 months of nonstop work, which seems a little low, honestly, but I'm holding off on tweaking until I see how it plays. 

Windows are just coming into existence.  They can open, close, be broken or dirty.  I still have to connect open and broken states with weather, create WASH WINDOW and FIX WINDOW commands, and other miscellaneous stuff, but I have implemented a basic "when you look out a window, you see what's on the other side" thing.  It works suspiciously well.  You can't look through windows into the house, but life is short. 

Fireplaces and all their attendant woes are untouched.  Descriptions remain a problem, as there's not much stable about the description of an indoor room at the moment - you can have a kitchen that's essentially no different than a bedroom, except by name, and you can't really talk about delicious smells or sunlight on the parquet floor when the PC is much more likely to be eating cold turnips in the dirt.

Notes:

- Roofs still don't exist; they probably should, even just for aesthetics. 

- Foundations have been totally blown off.  I mean, uh "As you begin construction, you uncover the original foundations of the house.  Despite the years, the foundations are in excellent condition, and will no doubt support whatever you build on top of them."

- I haven't figured out the temperature controls' relation to inside, how fast heat and cold move through indoor rooms, and how best to calculate that.

- Windows shouldn't be automatically glass-equipped - either they should be open holes in the walls, or boarded up holes in the walls, or not placed at all until the PC explicitly does the work.  All of these options have drawbacks and associated weirdness.  I probably need a glassless window-type variable-thing.  Other people have used paper and such in place of glass, but I don't really envision the player making paper, so . . . hmm.  I do envision some glass capability at some point, but that point is a long way off, and I was thinking more glass blowing than glass sheeting, or whatever it is one does to get flat panes of glass.  Maybe the player would like to have holes in the wall that she can board or unboard instead.  (I can also offer the player curtains, which are less research than glassblowing.)

- Descriptions of rooms will be easier if some furniture is implemented; that way, its absence can be mentioned, the same way I'd remark on a kitchen these days without a sink, or incorporated into descriptions.  Conversely, if they're present, sunlight can then stream through the gaping hole in the wall to highlight the fine maple counters the PC has recently installed. 

- Still don't know what to do about doors.  I come to a different decision each time.  It seems weird to let the player board up windows/holes, and cave entrances probably should let you build a entrance blocking thing for protection and warmth, and then not have doors in the actual house.  But it's sort of complicated, and there's no real payoff yet.

- Tools would be another obvious direction to go next, along with material gathering.  I'm not ready to tackle bricks, clay, kilns, and fire, but I think I could handle figuring out how many 2x4's can come out of an old growth oak tree.  Come to that, I'm not entirely clear on how one makes planks, anyway, if you don't have a saw.  And I need to figure out the Nail Question.  It's important to me that the player can build shelter more or less from scratch.  Maybe I can describe interlocking notches or something.  Traditional plank houses of the coastal Native Americans were bound with cedar ropes, but ropes are notorious for kicking ass and taking names of IF programmers, and there's no way the player would know that information organically.  Not that most people know any more about mortise jointing, but at least that solution doesn't introduce a rabid wolverine into the game mechanics.


Fun fact:
The scientific name for bison is Bison bison bison.  

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.

Integrating Help

One of my ongoing goals is to integrate as much help as possible into the game.  FTA isn't really meant to be a beginner IF, but there's a number of new actions and complications that aren't meant to bewilder. 

A tutorial option is Plan A.  I'm putting it off until I'm got most of the mechanics in place, for fairly obvious reasons.  It's a bit tricky, since integrating the tutorial into the current beginning of the game means dealing with different choices people have already made.  Since players have a chance to buy stuff before "arrival", they need guidance through the "what to purchase" phase as well as the "what to do with it" phase.  At this point, I'll probably do a tutorial "build": set all the difficulty toggles to easy, give the stage a set of standard equipment, including the various kinds of things the player should know about.

A separate tutorial that segues into the main game is an option, but the immediate lead-up to the game opening is travelling, not survival, so I'd have to set the tutorial in another time/place, which I'm not thrilled about.  I suppose I could do a separate mini-game theoretically unrelated to the main game, but I really don't like that option - playing a game to get to another game just seems like work.  Besides, I like built-in tutorials in other games.

Of course, not everyone is going to play the tutorial, even if I encourage them to do so.  So there needs to be a readily accessible option for players that are in over their heads and don't want to restart, or for players who played the tutorial but can't remember the specific details.

Secondary to that is a universally accessible set of quick references: the player can type "HELP ON [something]".  For verbs, that includes a description and quirks, the specific command structure to use it, and related topics the player might want to check. 

  Here's the entry for the climbing verb:

This part of the world is relatively flat, according to the survey maps you’ve seen.  There’s a few boulders and maybe an old limestone cliff or two in the region, but there’s bound to be a path somewhere that doesn’t include risking life and limb.

If you’re really determined, you can always try CLIMB CLIFFS.  If you’re feeling less adventurous, you can also CLIMB STAIRS.  Related verbs: Go.  Related topics: Injuries.

In this case, the verb help is mostly a redirect - letting the player know that climbing isn't an important part of the game.  (It's alpha text, in case you couldn't tell.)

Other help topics cover the major kinds of things and game concepts: a brief overview, followed by specific uses of the thing in question, or the rules governing it, and the commands for making or using it, with pointers to related topics or verbs used.  The nice thing about this is that (theoretically!) the player can type the name of something she's having difficulty with, and get the proper command structure directly:

>PUSH COW

Bessie doesn't even budge.

>TAKE COW

Bessie doesn't even budge.

>HELP ON COW

[Other info, verbs here]

You can move a herd of animals, or a single animal, with MOVE [animal] TO [place].  You can also use the verb DRIVE instead of MOVE.  You'll most often want to MOVE HERD TO BARN or DRIVE COW TO EAST PASTURE. 

In this example, there's partly a failure on the part of the author, but there's also an easy recourse for the player - rather than playing too much guess the verb, she can skip ahead.  Of course, if I forget to mention something in help, the player is screwed, but if I get it right, then the lack of mention means the player doesn't have to worry about it.

The major upside to doing this is that I'm finding it clarifies a lot of the details of verbs.  I've had ideas for movement, but having to make it concrete, even in a alpha kind of way, helps other things fall into place.  It's sort of like design documentation, but it has an in-game purpose, which makes it easier to write and follow. 

Part of the difficulty I'm having is that I'd like to speak to the player-as-character as much as possible, so ideally I'd like both verbs and topics to be a sort of mental dialogue.  I thought about separating verbs (which are clearly mechanics) from topics (which are actually things a character might think about) by using different commands for them, but immersion loses out over playability here.  Also, by the time the player is asking for help, immersion is already gone; getting her back quickly is more important than pretending she's still there.

Ideally, this is available in a menu-based help system, for those that prefer it, but I'm not sure how feasible that is.  (Also, I hate menus as both a player and an author, so I'm sure that bias factors in.)  A separate, printable document with lists of help topics available might be just as useful.  

The big thing is making sure the interlinkages are present; ideally I'd like to have a response to HELP that redirects the player to a few main topics, which send the player on to specific things.  Sort of a tree thing.  I can't quite come up with a good structure yet, so they're all currently individual (and mostly unfinished).

Plan C was gentle nudging messages; after failure of a certain verb or a certain number of tries at something.  This is basically a redirect to the verb used, but I'm finding it incredibly intrusive and irritating, so it's been dropped for now. 

Other helper type things: The character has a goal list for overarching projects, so if there's nothing to do, she can check her list and go work on a project.

I'm considering how feasible it would be to give the character a sort of "memory" to help prevent crisis.  So if the animals haven't been fed all day, and the character tries to go to bed, she might remember suddenly that she forgot to feed the chickens.  Some damage will have already been done, but not nearly as much as it would be later.  I like this idea, since it's somewhat true to life, and would be easily toggleable for harder difficulties. 

Speed increases and liquids

Spent most of the morning moving "every turn" rules that fire hourly to the same minute. This speeds things up nondramatically. Also, I fixed the longer wait actions so they're much much faster, as a byproduct of the fixing the every turn rules. The wait functions are dramatically sped up, and this will make things like sleeping much better when implemented.

Most of last week and a big chunk of the week before was dedicated to liquids. I stripped the ideas out of Emily Short's Measured Liquids extension, which is great, and reimplemented them in a more object based sense.

The issue was that Short's extension creates "liquid containers" - containers that only hold liquids - and "liquids" are then a value that are pretend-held by the liquid containers. Liquids aren't actual objects. It's a pretty nifty idea, but I ran across some issues that I thought were pretty serious - serious enough that I wanted liquids implemented as objects instead.

I thought this would take me two days, tops. Turns out that making liquids into objects requires a bunch of extra work, and while my new liquids section appears to be behaving, I feel sure there's bugs to be worked out yet. In addition, I ran into giant disambiguation issues that I just couldn't quash. As a result, I installed the number disambiguation extension. I sort of hate the idea of typing in numbers - maybe it's too CYOA for me or something, but I like the way the extension is handling things. I'm still going to try to quash the disambiguation bugs, but at least for now I can refer to things I want.

Consistency is a value now - liquids join solids, powders, and malleables. Malleables are objects that tend to occur in clusters and are handled as a group rather than individually. Nuts, hay, raspberries, feathers - things that tend to be small and negligible individually. I'm not sure what to do about intermediate objects, like apples, which would make sense to handle individually for some things, but not for others.

I removed the idea of liquid containers entirely - if I were a player, I would not be pleased to not be able to put things in any reasonable container. Containers are now waterproof, powderproof, or, I'm ashamed to admit, unliquidproof. (Naming is a problem for me.) Waterproof containers can hold anything - these would be things made of metal or glass or wood. Powderproof containers can hold finely ground things, but not liquids. This includes things like some baskets, cloth, and leather. Unliquidproof containers can hold only significantly large objects - baskets or harvest bins. I cheated a little on the last, because clearly a slatted apple crate will not hold raspberries very well, but:
a) I'm still not sure whether normal crops will all be malleables or not (I'm leaning towards "yes" right now, since the alternative is some bizarre amalgam that makes my head hurt to think about)
b) What's the added play value? For one thing, most people know what's waterproof and what's not - holding small vs. large objects is a matter of construction. Am I willing to implement large-slatted vs. small-slatted crates? No. And since this isn't a visual game, it's hard to describe a large vs. small object container in addition to everything else. One has to draw the line somewhere. I don't think much is lost. If I change my mind, I can always implement leaks or something.

The upside to all the coding is that I have a much better handle on rulebooks, rearranging rules, rewriting rules, replacing rules, and cursing. I expect all but the last to come in handy.

I've got a very basic template up and running for Events - scenes that are significant enough that the player probably won't want to lounge around doing nothing while they're going on. These would be things like sheep in the garden, or tornados, or even just player hunger. There's a meta command (helpfully called with ">EMERGENCIES") that mentions the emergencies the player knows is going on. (Of course, if you haven't seen your corn field with the cows in it, you may go on blissfully fishing at the lake. This I consider to be a highlight, not a bug.)

It's much harder to work with scenes than objects, so several things I wanted to do I've let go, albeit reluctantly.

I also set up a helpful toggle to shut down random events entirely - at least the ones listed in my handy new Random Events Rulebook - and tweak the frequency of catastrophes. All this was surprisingly okay, which makes me nervous, because any seeming programming success is just hiding the giant bug to come.

Oh, and I merged a couple projects to one big one. For some reason, this meant my "When [Moon Phase]" Scenes stopped working. Why? Supposedly it clashed with something else, but there were no other moon phase things anywhere else. Changing the names of them all to "During [Moon Phase]" fixed the problem. This didn't enlighten me at all about the source of the problem, but at least it compiles. Also fixed an extension bug that caused the year to change a month early.

The way I was doing colors is impossibly slow if I want the player to be able to refer to an item by its color. Not sure what to do about that.

All in all, a pretty productive couple weeks. I really want to get into the meat of materials next, but I'm having some planning issues, so I'm procrastinating by doing other useful things. And when I get bored, I'll define some containers or something.

Nut Trees and Headaches

I was working with some loose ends on trees. (I still can't get the game to recognize "pin oak" - it always defaults to northern pin oak, regardless of where it's defined or what the "should the game choose" or "does the player mean" values are set. I may have to take it out entirely. No huge loss, but it is irksome. I've had better luck with swamp white oak vs. white oak. Why? An excellent question.)

So I thought: Self, this is a good time to define some nut trees. Nut trees are a kind, and contain just a little extra information. Fruit trees are going to be pretty complex, but nut trees are an older, more primitive thing.

Basically: each species has a constant called max_harvest. (Actually, this is on every tree, in case I do get around to letting the player "improve" them. I might move this to a global constant.) There's also an interval variable, which indicated the frequency of "good years". Nuts tend strongly towards big crops followed by several years of smaller crops. This is calculated for each tree separately; I think real-life species tend to follow the same patterns, but I couldn't quite bear to have the entire walnut crop fail at once. There's also some luck involved. Each species can have a good year or bad year (+/- 10% of crop weight), and so can each tree. There's also an overall harvest_luck variable that does the same thing. So in a really good year, trees can produce 130% of max_harvest, which is a mid-high guess for wild nut production numbers.

What I need to do: factor in age and size. Immature trees shouldn't produce at all. Trees that are smaller than max (or maybe a percentage of max) should produce a scaled quantity of nuts. (That is: a 30' oak should produce 3/5 the nuts that a full-sized 50' oak would produce given the same numbers.) Right now, trees have neither ages nor sizes. Age is easy; size is not, since it means completing the Table of Dendric Doom.

In lieu of that, I've created a scene, During Fall Nut Harvest, that goes from mid-September to mid-November. Once a day during the nut harvest, nut trees can drop some of their nuts. Theoretically. They calculate the right weight to drop, anyway, and I think I finally got them subtracting the drop weight from their current_harvest correctly. (Testing is definitely needed.) I'm having difficulty with the nut objects, though.

The problem: Nuts are kind of like liquid. You don't really >TAKE 1000 NUTS, nor would I want to model such a thing. You take weights or volumes. (Volumes, actually, but weight is easier for me to work with.) So the same way you might >TAKE A CUP OF WATER or >FILL BUCKET WITH MILK, you might >TAKE HANDFUL OF NUTS or >FILL BASKET WITH NUTS. And you don't really want to take inventory and find that you have:
- a handful of acorns
- some acorns

So I decided I needed some sort of combine command, where objects like nuts or water could be smushed together by weight and variety. So instead of two discrete acorn objects, there would be one with the weight of them both, and the second object would go poof, or never exist in the first place, depending.

This sounds awesome on the surface, right? But it's sort of like introducing a rope to your game. After a few minutes thought, the problems start emerging. Then you have to sit down somewhere quiet. Then you have to have a stiff drink.

For example: nuts don't last forever. Are you just going to mash the old rotting ones together with the fresh ones? And sometimes, it is appropriate to combine things - say, cold water and hot water, but you'll need to recalculate values. Not that I intend to have cold and hot water modeling. Worse, you need some way to communicate the difference between these two things to the player, and differentiate them to the parser. So the parser should distinguish between the older nuts and the newer nuts the player is carrying. When do you try this combining thing? Before taking? After taking? Instead of? Each has some problems. What if the player tries taking more water than she can carry? The game should do the same weight/volume checks as for normal objects, but should it adjust the total?

What about commands like >PUT NUTS IN BASKET - how should the game behave to that?

So the more I flailed, the worse the whole situation became, until my brain shut down for self protection. So, nuts are sidelined for now. Maybe I'll go by "[weight of nuts] [nuts]" for now, if I can get that filled out to marginal satisfaction. Or maybe I'll put a big red star there and come back to it.