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.

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.

Organization

The biggest programming project I've ever completed was a few hundred lines of code. Not Inform code, where lines seem to multiply like bunny rabbits when you look the other way, but C++ code. Not very advanced.

Inform doesn't lend itself to counting length the same way, but we're around 28,000 words, including all extensions but the standard rules. I've been putting more things in extensions as I finish them, which helps keep the main text clearer. The extensions will not, I fear, be very helpful to anyone else, but they do help me to set aside code that I'm done with (for the moment).

I like the idea of working on one central project, but the practice is pretty dreadful. Despite the content index, it can be hard to find things, especially variables. Rain falls at a certain speed - did I name that rain rate? Rain_rate? Precipitation_rate? Rain_fall? Good luck finding that!

I think Inform could be better at offering these variables up. The index is great for browsing, but less great for finding that one damn variable name. Around 10,000 words, I notice my productivity drop dramatically as I flail around in the source code trying to find things. Until then, I can map out where I am and find what I need - after that, things begin a precipitous slide.

I'm trying to stay on top of things by doing excel spreadsheets for the various stuff going on, but I often don't update them immediately. So I'm also trying to add headings to every section. That works pretty well overall.

I'm also playing with the idea of just doing series and series of extensions. It isn't particularly elegant, and there's the possibility it'll slow things down, depending on how Inform handles them, but worst case scenario, I can always copy and paste them to one central source.

The extension thing does get harder as more things interlock, though. I'm deliberately starting with some of the foundation stuff, but even that can be pretty recursive. I've managed to keep most of the "to decide" functions pretty self-contained, but it's only a matter of time before they're accessing multiple game ideas at once - game ideas that call to one another.

So . . . yeah. Organization. Hard.

Precipitation, Gen. Update

I suspect one of my analyzing functions is broken, because I keep getting reasonable results when I test the amount of snow that might fall in a month, and really odd results when I test the amount of rain. (It's 0 far too often, and then occasionally it's something like 4m. WTF?)

Regardless, I know that I'll have to play with rain - I have to do some calculating, but I'm pretty sure that it rains too often, especially since I have rates of fall in there now. Snow fall is currently a flat 7mm per hour; rain varies from what Wikipedia tells me is light to what Wikipedia tells me is heavy.

Since rain's more important than snow, because of the crops, this needs to be looked at. Still, though - good snow numbers. That's something to be grateful for.

For now, I'll assume that everything gets the right amount of water, and try to remember to extrude areas where detailed calculations will need to be added after I've fixed the weather.

Did a lot of fiddly work yesterday - Inform did something weird when I defined trees in a table, and made their printed plurals all "trees". So a room description looked something like:

Cobblestone Path
You see six trees, five trees, three trees, and seven trees here.

Dear Inform: Fuck you, too. Since the manual simply assured me that it had a very complex and accurate plurality detecting mechanism (which apparently it doesn't always like using), I implemented the hackiest hack ever ("The printed plural name of a tree is usually [item described]s" and then spent a big part of the day fixing trees that didn't fit that mold, and then making sure that Inform understood "maples" as the plural of red, striped, black, mountain, sugar, and silver maples.

Looked at Disambiguation Control. The documentation is sort of confusing. I'm not having difficulty now with the parser's disambiguation, but surely it's only a matter of time. I'm not sure how much I prefer having the parser ask lots of questions vs. just doing something. There's no puzzles to solve or anything. Still. (Shelved until I start seeing problems and have energy to deal with lots of fiddly bits.)

Looked at library message replacement. The extension looks straight-forward, although coming up with umpteen thousand innocuous messages certainly won't be. (Shelved.)

Not enough stuff is easily accessible in the Index. I still do a lot of trawling through code, looking for variable names. I should really do my own database for that. Damn.

I have an overall layout I like for the map overall. Farm layout is still kind of subpar, though. Distances are a little odd, but I think I've got it worked out.

Beginning farm size is about 25 acres, although a good portion of that is overgrown and rocky. I'm guessing I'll give the average difficulty one section of the kitchen garden, the orchard, a field, and one fenced pasture for somewhere around 10 acres (mostly pasture, in case Kendra brought lots of animals). Five might be even better -this is one of those things I'll have to play to really know, and difficulty might alter this some. Expansion is possible to around 100 acres - almost certainly more than one person can handle, but this would allow for ample pasturing of breeding flocks, letting Kendra specialize if desired. (I suspect 10 will actually cut it for the vast majority of players, but who knows?) Potential farm area is mostly forested.

At the scale I'm doing, that means it's about three-four miles to the edge of the map - a reasonable walking distance for going to town or a major landmark, and that gives an overall area of around 50 square miles, which sounds okay. Certainly there's more packed into the game's 50 sq mi than most places, but that's all right, too.

Intro Comp 2010: Tourist Trap

Spoilers for Tourist Trap follow.

>ask man about luggage
[In this game, you don't need to specify a person or topic when talking. Just type TALK, or T for short, and I'll show a menu of things you might want to say.]

And then the game goes ahead and pretends I typed TALK anyway.
I can practically feel the game standing solicitiously behind me and rubbing my temples. That's nice. Keep going.

Oh. That was short. But yeah, I totally want to play more of this. I like the idea of travelling with someone else - maybe more than one someone else - and the game is warm and forthcoming. Besides, the afterword promises debauchery.

Interest in playing more: 95%. (Hey, I can't be too easy.)
Interest in playing more if it were polished to within an inch of its life: Uh, it played well for me, although I didn't beat about the corners.

Transcript saved for posterity.