Nine Lives post-post-mortem and production notes (spoilers)

So this is my first complete published work of IF, and I hope you all liked it, crude and unfinished as it may be. Even in I7, coding is harder than it looks.

I started the comp intending to finish a game I’d begun years ago, a somewhat serious one about the Angel of Death and three or four clients who need help dying on time. Then I took a troll through IFDB and found someone had done a game with the Reaper as the protagonist, and decided to set mine back on the shelf. I’m not scrapping it, but I’ll publish it another time. Since Inform has had so many updates and I’ve had a few dead hard drives, I’ll have to recode everything I did anyway.

One of my favorite things to do in IF games is find as many different ways as possible to get killed, mostly so I can read the humorous death messages. I find virtual suicide a wholesome and entertaining pastime. Morbid? Not really. I just have a passion to see all possible content, and to find as many bugs as possible, which means doing things that your character isn’t “supposed” to do, to see whether the developer figured out someone might try that. I mean, what the heck is the point of a bottomless pit or fire-breathing dragon if they can’t actually kill you?

Having recently got back into IF after a lengthy absence, I had come back to IFcomp this year to find, to my great disappointment, very few games that allow you to get killed, let alone die in interesting ways. (“Ether” was satisfactory on this front. “Birdland” and “Cape,” despite their virtues, were not.) I therefore resolved to create a throwback to the text adventures of yore, in which the object would be to die over and over.

and thus, “Nine Lives” was born. The first thing I did after taking a long walk and getting the idea to make a game about a cat that dies repeatedly was pick up a pen and notebook, and brainstorm as many ways as possible for a cat to get humorously killed. At first the list was pretty mundane: roadkill, food poisoning, choking, slain by a dog, etc. etc. (For the record, I actually like cats, and I deliberately kept the violence to one-liners to maintain a light mood.) But it was too morbid and not very funny.

Then I decided, what the hell, I’m paying homage to dungeon crawls so I should put some more exotic ones in there. And along came the mad scientist, the cursed sigil, and so forth. (I, uh, may have been replaying ‘Anchorhead’ recently, mostly to remind myself of what a good game looks like.) The cat thinks the house is ordinary, because how would he know better? But that’s the joke. The human player will quickly realize this is not an ordinary house.

the plan was to make repeated deaths a puzzle – notice you can’t die the same way twice, because each time you experience a death, that means of dying is removed. There are at least 13 ways to die, not counting one bugged means which doesn’t work, and the prologue. By the time I got the other stuff done, I was out of time and ideas, so there aren’t very many puzzles, but I plan to release a revised edition with more puzzles.

There were two really difficult parts of making this game. The first was the sequential scenes. As the player loses lives one by one, there should be at least a thin semblance of storyline, but I wasn’t really sure how to key the trigger for these scenes.

At first I did it with scoring, starting the player at 8 lives and subtracting one point for each death. Then I decided that subtracting points was a bad idea, because the purpose of the game is to die a lot, and taking points away from the player would confuse her/him. (It worked nicely in “Janitor,” which makes the point of the first part of the game fairly obvious, but I feared it would be too subtle here, since I didn’t have time to write good cues.)

then when I did a little more reading of the manual, I put the scoring aside and created the life counter. Fine and good, although there’s still problems with this; when the player dies and moves to Death’s Chamber, it takes one turn for the next “scene” to trigger. If the cat goddess hung around that room all the time, a hasty player could give her a kiss and escape before she’s had a chance to make her next speech. So I rigged it: each time the player comes back to life, Kittygoddess is removed from the room, and the player can’t kiss her if she isn’t there, so the player has to wait a turn after dying for her to show up and make her speech.

worse, there’s an easter egg in the game which turns out to cause a bug: if you

type XYZZY

you gain an extra life. Trouble is, the appearance of Kittygoddess is tied to the player’s current life count, and for each life she only appears once … so if you use that cheat, you will get stuck in Death’s Chamber forever … unless you

type YZZYX

which costs you a life. And because I did a lot of the game on deprived sleep, I kept miscounting and having to rewrite scenes. (I briefly considered sending out a game where Kittygoddess says the same thing each time you die. ‘Taghairm’ reminded me why that was a terrible idea.) I’m still mulling over better ways of arranging sequential scenes.

a worse problem was the death shutdown (the “you have died, want to restart?”) message. I went about this all the wrong way, though I’m still contemplating how to do better. What I should perhaps have done was printed a fake death message and not actually killed the player at all. Trouble is, if the player ignores the fake “you have died, wanna restart?” message and types any in-world action command, the game responds as normal and the whole death effect is spoiled. So instead, I meddled with the “shutdown rules” rulebook, which caused some weird effects, because when play ends, several things happen that I didn’t necessarily want to have happen. I also had to make a tweak to prevent the player from REALLY restarting or restoring. I could have simply made these actions fail, but I hesitated to remove them altogether. So instead I went dicking around with the shutdown rulebook, which required a lot of nail biting and head banging as I tried to make Inform behave the way I wanted without crashing, and also so there could be a permanent ending that would really end the game. I did take away “Undo” using the example in the manual, so players wouldn’t assume their first death was a wrong move and undo it.

in fact, I7 gets a little loopy with “when play ends” vs. “when play ends finally.” After I’d tinkered with the “when play ends” not-permanently, putting in a “when play ends finally” sent the software into an infinite loop! Uh-oh. I jury-rigged a solution to this: adding Basic Screen Effects and a “end the game abruptly” command. Unfortunately, this sudden stop spoils the AMUSING command, because if the program halts you can’t use AMUSING. This is a bug that needs to be fixed.

The other bug that really needs fixing is the squirrel on the roof. Up until 5 minutes before I released the game, the squirrel would be there insulting your mother, tantalizingly out of reach, until you jump off the roof for the first time. Unfortunately I screwed this one up and now the squirrel is not there at all, and jumping while on the roof gives you a blank message instead. Error! Error!

in other difficulties, having an animal PC presents a few complications; default parser messages must be rectified, I had to rack my overtaxed brain to come up with appropriately feline flavor text (originally Kittygoddess was going to be an angel or the grim reaper, but there’s no reason a cat would have a supernatural friend with feathered wings, or one who looks like a person). Normally this is no-problemo, I view default message tweaks as one of the best opportunities to improve a game. But in a speedIF where time is of the essence, it might be better to pick an ordinary human PC so as not to use valuable time on these little details.

things I did correctly: brainstormed in advance, sketched a map (which took longer than I expected), came up with a good and funny idea, beta-tested a weeny bit. I’m also rather proud of the way I replaced most of the default messages (try jumping, examining yourself, meowing, purring, examining the trippy colors, etc. etc.) and included colorful descriptions of just about every object in the game. Nothing annoys me more than not being able to get a better look at things.

things I would do differently next time: more advance planning before I sit down to code, which would have saved time; don’t dick around with the shutdown rules (or at least know more about what the hell I’m doing first); beta test MORE MORE MORE. I alpha tested a lot, which got rid of the worst bugs, but there’s got to be some beta bugs lurking, and of course I didn’t plan ahead and waited till the last minute to submit my game, being too chicken to call for testers. Thus the only testers were my hapless relatives, who know little about parser-based games, though they were politely supportive, bless them.

anyways it was a great learning experience, and I had sufficient fun that now my folks are suggesting I become a computer programmer. I dunno if I can take that much headbanging, but there’s good money in programming…

Hi! So I figured I’d respond to your call for critiques here instead of in the review thread, though you actually addressed a lot of what I’d say in your post mortem anyway. It’s good that you can recognize where the technical problems lie. Practicing with Inform is going to help you find elegant solutions to the problems you encountered.

One suggestion I can make is to use the “wait for any key” activity in Basic Screen Effects to help create sequences that happen right after the other. As an example, you might type out a fake end-the-story text that will take the player back to heaven when they try to type RESTART or UNDO. This would save you from having to mess with the shutdown rules entirely!