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. 

Innards: Growing Degree Days

Growing Degree Days is one of those wonky agricultural concepts that appears initially to make no sense whatsoever and then you realize that everyone ought to be using this. Like the metric system. (If you are living in a metric country: kudos.)

Here's the basic idea: Plant growth is a function not only of light, but temperature. Sure, plants need to be above a certain temperature to survive, but also above a certain temperature to grow. This temperature is different from plant to plant, but usually it's about 50F. Any lower than that, and it's better for the plant to wait for the temp to rise. Above that point, growth is not purely arithmetical; photosynthesis is temperature dependent (assuming full sun).There's a peak to the photosynthesis rate as well; as temperature rises past that point, proteins in the plant become less stable, and the rates slow pretty quickly. This is one reason that you're not necessarily better off in a greenhouse; if that thing overheats, you'll find growth slowing to a crawl even before heat stress kills your plants. That point is around 85-90F; usually plants will cope up to about 100F, and then flounder. Photosynthesis isn't the only reason for this, of course, but it is a major one.

If photosynthesis and growth were just tied to day length, farmers and gardeners could predict harvest dates with a high rate of accuracy. Unfortunately, while sun exposure is pretty constant, temperature swings way up in the summer. In about two months, the average temperature increases by 30-40F/day, with a corresponding burgeoning of plant growth. The bulk of growth happens in July-August because that tends to hit the ideal temperature range.*

There is a fantastically complex equation for putting all this together and calculating how much heat a plant has gotten, but it's complicated and involves curves and people like nice easy numbers. Growing Degree Days gets you pretty close to the real thing: The average of the highest and lowest temperature for the day, minus your base. If the number is less than 1, no growth happens (but neither is it reversed). You'll notice that most normal temperatures will give you more than one degree "day" per 24-hour period, but that's scientific acronyms for you.

The good news about GDD for FTA is that it gives you a single data point for maturity, and a single data point determining how close the plant is to maturity. The growing degree days to maturity for a given plant does not vary much, if at all; the growing degree days for a given day are easy to calculate and track. As an internal mechanism, it's hard to mess up, since it doesn't rely on anything except one extension.

Each day, the game grabs the high/low temp (Weather presents these as NTemp and Dtemp), averages them, subtracts 50, and adds any result above zero to any living, growing crop. A few crops, like cabbages, actually will grow below 50, so I may need to tweak stuff there.

The downside of this method is I need to track down these numbers and calculate them for any crop I want to put in the game. Despite the niftiness of GDD, pretty much every seed catalog uses plain old days (ie 110 days to harvest). This is subpar, since they rarely tell you where those 110 days take place. 110 days in Georgia are a far cry from 110 days in Maine, so there's a surprising amount of guesswork involved, but at least the chosen numbers will be internally consistent.

(The other nice thing this opens up is letting weather changes affect the whole crop without having to tweak various conditions. Which is nice.)

Small steps, but it's nice to get hold of helpful equations to drive the internal mechanisms - writing those is always the hardest bit.

------

* This also explains why you can plant, say, one tomato plant two weeks earlier than another, and they both ripen at just about the same point. The growth rate later outstrips the earlier growth dramatically, decreasing any advantage the early tomato might have gotten. Also, the earlier tomato may have had to deal with frost risk and a wider spectrum of hungry predators. The moral of this story is to let your neighbors plant the early tomatoes; you won't lose anything if you wait.

Quick update - fishing

Fishing has turned out to be a load of fun to research, in no small part thanks to the New York Public Library's archive of awesome. Did you know hammerhead sharks used to be called balancefish?

In terms of coding, I am way behind. There are a lot of really boring bits to do, like specifying how the game should put together a fishing pole. Because of the way Inform's set up, verbs with two nouns require a lot of repetitive disambiguation and referencing commands. "Doing something with a fishing pole" only counts for one of the nouns in putting it on, so you also have to write a whole series of commands about putting things on fishing poles. Which, you know, gets really old. I totally understand why this is here, but on the other hand: putting something on a fishing pole *is* doing something with it.

I have, finally, got fishing poles to assemble properly, although not automatically, which is the goal. My original idea was just that the character would rummage up some appropriate items for a crude rod, line, and hook. "But then," I thought cleverly, "what if they want to upgrade to a better rod, or I want to break the line? Those had better be separate parts." Then I looked at it and realized the player might actually try to manipulate those parts - untie a line, or specify which hook to use. And players might use verbs like "tie X to Y" to do so, and "tie" wasn't really equivalent to "put on", and from there was madness.

Now I get to buckle down to the real nuts and bolts of the thing, which I have enjoyed envisioning, but am not so much looking forward to implementing.

(Interesting note: Scientific names have changed a *lot* over the past 300 years. Very few fish have the same genus and species names as they used to. Lots of fish are findable under their common names, though - something they don't mention in biology much. Hopefully that period of reclassification is over, but I'm not holding my breath.)

Feelie Creation - the trees

Yeah. Trees are not quite what I want, but I am very proud of my gorge, which emerged after a lot of experimentation and pig-headed erasing.

Here's the no-trees one. Hopefully I'll find a tree style that I like, because it's sort of naked without them.
Woot.

Feelie Creation

I've spent a portion of the last month working on the game map. I've had a general layout in mind for awhile, but I'm trying to firm things up a bit so I have a clear mental picture. Feelies are nice for writers in the same way they're nice for readers - they help set the mood. Especially maps.

A lot of my time has been spent at the Fantasy Cartographer's Guild, trying to figure out how people make maps. (At least, how artistically challenged people make maps - I assume it's easier for those with artistic inclinations to begin with.) Guess what? Map making is hard. Even with tips, things look wrong more often than they look right, and many things don't look okay until you've layered them with a hundred other things.

Today I added a yellowish background to the map. It was originally parchment textured, but I wasn't feeling the texture. I think that'll be one of the last things I do, since it kind of messes with everything. But I love the saturated yellow light the background gives to the map - it's warm, and takes out some of that "LOOK! WHITE SPACE!" feeling.

I'm making the map on a very large scale - much larger than most people will want, but one that lets me get in close and do detail work if I feel like it. The farm and city are close to scale; other things are larger - the main river is not actually 150 feet across - to emphasize landmarks, or important bits of landscape. Making it all to scale just wasn't feeling right. I've tried more foresting techniques than I can shake a stick at. The one I'm liking currently isn't to scale, and it's a pain to implement, but the overall impression is one I like. Each tree is mildly silly looking, no more than one or two sponge-y clicks with a trunk silhouette, but in conglomerate . . . it's kind of foresty. (Except the conifers, which are looking sort of silly. I'm working on it.)

The nice thing is that as a sort of eclectic approach, it doesn't feel really ancient or futuristic, which is good because I want to leave that open for now.

It's not a terribly professional approach - some things are top down, some aren't, some are too big, some are carefully scaled, the color scheme is getting made up more or less on the fly - but it's a nice break from (not) programming. I'm especially proud of the color of the lake. It took me a long time to get that color.

There's still (obviously) a lot of work to do, but considering my art level, I'm pretty pleased with how it's going.

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.

1 Abomasum = x grams?

I was feeling strong and detail oriented, but not up to doing more damn nut trees, so I went tangential, and started working on food and food definitions. At some point I've got to figure out cooking, but that's shelved.

Instead, I got sidetracked into the bizarre and wonderful world of cheesemaking. For quite a few cheeses, you need rennet, which is basically an enzymatic coagulator. Rennet comes in sweet little tablets, which clearly will not be available in post-apocalyptic Michiconisota. But surely old time farmers didn't get their rennet from tablets!

No.

Rennet comes from one of the four stomachs of ruminants. There's something kind of neat about this - using the stomach of the animal to make its milk into cheese. Unfortunately, the game requires me to ask questions that sort of remain unanswered by the internet:

- how much does an average abomasum weigh, anyway?
- does it grow with the size of the animal?

Using Photoshop, I estimate that this kid's abomasum is about 100g. (109g, to be exact, using very rough estimates, so ~100g is about right.) That's dry weight, one assumes. At about a gram of abomasum per pound of cheese, calculations are kind of nice and easy.

It looks like only young animals are good for rennet production, which helps the size issue. Now if only I could find a calf abomasum weight to compare, I think I'd be all set to include rennet.