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

Monday, July 26, 2010

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.

Tuesday, July 20, 2010

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.

Monday, July 19, 2010

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.

Sunday, July 11, 2010

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.

Friday, July 9, 2010

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.

Wednesday, July 7, 2010

Intro Comp 2010: Plan 6 from Inner Earth

Since I'm not on a feed, and no one but me reads the hot hot development journaling, I'm not going to bother giving a long and complex spoiler tag. Why bother? Still, it's sort of interesting in a stream-of-consciousness sort of way. Still, it's not like I'm James Joyce, so maybe we should begin.

Spoilers follow.

Random Thoughts:

Hey, shout out to Lubbock, Land of Baptists!

Second sentence in, and I have a niggle. After ellipses, the next word is usually not capitalized.

Also, show titles should be capitalized like titles. Also also, that should be "one of the biggest boondoggles". (I will try to stop now.)

I don't spend countless hours shaking damp hands. Was this character a politician before she went to work in the bunker lab?

Buttons aren't implemented, even though there's "a plethora" of them. Nor is my favorite chair. Nor can I switch off the lights. Nor are posters portable.

>x laser beams
They are red. Doesn't look like a "Don't touch me" warning?

>touch laser beams
You feel nothing unexpected.


Right-o, then.

Wait, was I able to win? I had 0 points. Also, security person in Lubbock uses a mixture of British and American spellings.

Summary

This needed beta-testing. And then more beta-testing. I think the idea has potential. Even if you set aside the rampant grammar and underimplementation issues, the game feels half-assed. The room layout doesn't make any sense. The lack of guards doesn't make any sense. The description of the terminal doesn't make any sense (what YEAR is this?).

Some of those things are okay if you've got good suspension of belief, but the whole thing just feels really shallow.

Interest I'd have in playing more if the rest of the game was like this: 0.
Interest I'd have in playing more if the game was polished to within an inch of its life: 50%. The premise isn't that interesting, and I wanted a Laser Pistol, dammit.

Note: Transcript of play is archived here.

Intro Comp 2010

Random.org tells me that my sequence of playing should be:
1 Plan 6
3 Tourist Trap
4 Waker
5 Memento Moratori
2 For the Love of Ornery Blue Yaks
9 Cryptozookeeper
7 Peanut Orchestra
6 Closed Circles
8 Fang vs. Claw
---

Since this comp is about how much you want to play them after you're finished, I suppose I'm going to start by ranking them in order of how much I want to play them, based on their titles.

None of these are screaming to me, to be honest.

1: Cryptozookeeper. Because cryptozoology is nearly as funny as evolutionary psychology, and I can only hope this game is like Zoo Keeper 2, except you have to create a good habitat for your chupacabra and make sure your Bigfeet are adequately amused.
2: Plan 6. Because I'm a sucker for those old sci fi serials, and this one sounds like Commander Zorba from Mars should be showing up shortly with his Laser Pistol.
3: Tourist Trap. Hopefully one of those grisly murder-mystery-horror stories set in Disneyworld.
4: Fang vs. Claw. No doubt Jacob and Edward finally get it on. Er. With a plausible deniability level of slash.
5: Peanut Orchestra. I have no idea what this might be about, but it's more intriguing than the others.
6: For the Love of Ornery Blue Yaks. Can I just say that this sounds like one of the Intentionally Whacky games? Tread carefully, FTLOOBY. (No extra points for having an acronym that make a spitting noise.)
7: Closed Circles. No doubt a melancholy look at the risks of time travel.
8: Waker. Please, please let it be the story of that guy in Puritan churches whose job it was to hit people on the head when they fell asleep.
9: Memento Moratori. As horribly pretentious as I am, I have something against it in game titles.

Tuesday, July 6, 2010

Productive Weekend

The holiday weekend was good; I spent a significant amount of time every day on various stuff. The most obvious thing was actually pretty easy, considering the time I'd put in on graphics last week, but all those small things are good, too. I didn't make a full list, which I should have, but I:

- downloaded the new I7, which fixed a nasty bug I was having. (See, sometimes the bugs aren't my fault!)

- played with borders. I had toyed with the idea of doing a border on every side of the screen. Gargoyle HATES that. White gaps appear by magic. Windows overlap in weird ways. The bottom border would mirror a strip of color under the status bar. This does not appear to be tweakable - no matter what I did, the borders remained deeply weird.

- reworked what I wanted to do with the screen appearance. I still like the idea of a window with the room description in it, but I'm not doing it for now. Right now, there's a temperature bar over the status bar, and a couple others, basically doing a 3/4 frame of the screen, leaving the right side open. This seems to test well, and can be turned off easily.

- tweaked Ish McGravin's Weather Extension to better reflect the weather of Minnconigan. For some reason, Inform 7 would not let me amend the Table of Months, so I had to go in and directly tweak. Sorry, Ish.

- made the temperature change throughout the day, rather than having night and day temps only. Now it changes hourly.

- set up a temperature bar that indicates the current temperature by displaying a color. This is actually pretty neat, and something I'm proud of. The programming was simple, but it actually does improve my experience, even only in a test room.

- made the temperature scale depending on the time and expected high. 3 pm and 3 am are the hottest/coldest parts of the day, although some very slight randomization means that it might vary slightly.

- made the story track snowfall rate (how much snow is falling per hour, in mm) and accumulated snow (how much snow is on the ground, in mm)

- made accumulated snow melt if temperature rises over freezing (10mm per hour, plus 10mm/10 degrees over freezing)

- added snowdrift and snowfall backdrops, so descriptions of snow can be elaborated on. (The current descriptions are bare bones.)

- added rainfall rates, and checks for whether it's raining lightly, moderately, or heavily

- added weekdays. Now it can be Monday in the apocalypse!

- added negative checks to a slew of weather conditions, so now it's possible to say "if it is not snowing". Excruciatingly boring, but saves a lot of coding irritation down the line.

- created recordkeeping for rain. It will track 12 individual days, plus monthly and yearly totals. This was a pain, just because I couldn't quite envision what I needed coding-wise. What I have isn't quite perfect, but it is more than adequate.

- cleaned up the worst of the color table, adding a range of grays. It still needs some work - I think I'll discover more missing shades I want as time goes on, but is it workable now? Yes.

- cleaned up a few errors in weather - for instance, before, the arrival of precipitation meant the game would decide it was no longer cloudy. Yeah.

Things I just thought of over the weekend that should be added:

- fiddle with temperature extremes (I'm betting that there's very little temp variation from average right now, and that's an issue)

- make snow rate vary (right now it is a flat .3 inches/hour)

- add a "path plowed" toggle for rooms, or maybe a path_snow depth (?)

- dynamic snow description, based on depth, rate of snowfall, whether there's snow falling or on the ground, whether a path's been cleared, etc.

- way to tell what the condition of the ground is, based on recent rainfall history - i.e., if there's been 2 weeks of rain, there should be mud. If there hasn't been rain in 3 months, everything is a drought.

- decide whether cloud cover should lower temperature

- think about wind. Are random messages enough, or should I be looking at something *slightly* more robust?

----

I am going to do at least 3 trees' worth of data entry today. I've got to at least start back on that beast. After that? By next Tuesday, I want to have:

- automatic dynamic generation of trees for every wild location. Nothing fancy, just trees - a number and species appropriate to the location. They don't have to have any special characteristics.

- mapped out a few different auto-generate maps to see if I can see ways they could be less awful

- some thoughts about underbrush. At least 3 ideas for handling, and a core list of what it should be good for or do.

- basic rules for trees: fixed in place, inedible, etc.

- At least two rewritten responses to the most egregious action results (I suspect these will be "climb" and "take") for trees.

- At least five random atmospheric messages written for weather. (They don't have to be in the game yet, just written and ready for insertion.)

- looked at library message replacement extension.

All this is doable, I think - let's see if I can stay focused. Trees first, though. (I WILL get through that damn list.)