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

Monday, August 30, 2010

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.

Monday, August 2, 2010

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.