Final update - Ah, screw the whole thing - Postmortem + source code
I'm having a lot of trouble getting back into the swing of this project, and I'm increasingly unsure about its foundations. (Also, I genuinely forgot about it for a couple of days.) With apologies, I'm going to shelve this for now, and maybe come back to it when I have a much clearer idea of what I want from it. This update will be a little post-mortem about the problems I've been having. I'll also post a link to the source code so you can have a play around for yourselves, and maybe borrow the code if any of you want to do something similar in Inform.
Here are some of the problems I've bumped into:
1. Poor research, poor grasp of other cultures
I'd been looking at websites dedicated to preserving Native American culture, such as Native Languages of the Americas. In so doing, I realised I'd made a few wrong assumptions in the foundations of my project.
For example, although I've been talking about the wendigo as a product of Algonquian folklore, I don't think this is actually the case after looking into it further. It seems like the wendigo is part of a broader Anishinabe folklore, of which Algonquian peoples are just one part. In fact, if I'm setting this game somewhere around the Great Lakes, I should be looking to someone like the Ojibwe / Chippewa people, who also had wendigo stories but whose lands were more geographically appropriate.
Having learned that I've been mixing up Native American peoples from the game's inception, I'm now swinging back to feeling like basing the game off a folklore I don't fully know was a bad idea. If I press ahead with this game after the jam, ideally I'd like to get the game tested with Ojibwe playtesters who can read for sensitivity, or who can just tell me not to do this.
Also some of these links suggest that the wendigo is as tall as a tree. This is larger than I had imagined, and presents some logistical problems for letting the player plausibly injure the monster.
2. Simulating a space and finding the fun in Inform 7
I was trying to feel out this game with a "finding the fun" approach - after programming a simple monster NPC, I wanted to investigate what behaviours emerge from it and what puzzles or scenarios that could lead to. An approach like this worked for my previous My First Game Jam project Arcane, where I programmed a simple enemy, noticed how it interacted with other game elements in practice, and then designed puzzles around these interactions.
This works with a project you've built from the ground up in something like Game Maker Studio or Unity, because you know the limits of what's possible. But an Inform 7 project is never a blank slate - it comes with a lot of verbs built in. With that comes a lot of player expectation, and with that comes a certain difficulty in creating a world that feels good.
For example, I made part of the forest in my game a place where trees are tapped. (The Ojibwe people were known for maple sugar, so I figured maybe the protagonist is there to tap some maple trees.) It's easy to put a thing called "tapping equipment" in there. But what about the player who wants to investigate further and play with the equipment? You could just put up a message saying "that's not important" to redirect the player's efforts whenever they touch the equipment - but do this too often and you train the player to ignore the scenery, and then how do you distinguish between unimportant scenery and important puzzle objects? But then you can get lost prototyping a playful object - the player may want to turn the tap, take the bucket of sap, pour the sap out, and all of this comes with its own implementation problems. You don't want to spend hours learning how to code viscous liquids in your game when you're just trying to fill out the world, but maybe you'll have to if the sap is a viable solution to a puzzle?
I found myself caught up like this frequently, wanting to implement an object to make the game world feel good but not wanting to get hung up on things. I think I needed a puzzle design document here - I needed a clear idea of what puzzles I wanted the player to solve so that I knew how much to implement things.
3. Finding an effective tone
Speaking of puzzles, that was another problem. How does puzzle-solving interact with the horror tone of the game?
I wanted to integrate puzzles into the main conflict of the game here (since this doesn't seem like the kind of puzzle game where it's appropriate to have the player stop to solve a combination lock). That means making the player figure out how to hurt the monster. Other than having the player find and use weapons, I had two puzzle ideas: 1) lure the monster to the bottom of the cliff and drop a rock on it from the top; 2) lure the monster onto thin ice out on the lake.
But I'm a little worried that these ideas are a bit slapstick, a bit Looney Tunes-y. That's not necessarily a problem, but it puts the horror tone at risk. I needed to think through the puzzle design and its integration into the atmosphere of the game very carefully, and I didn't have great answers. Probably the best way to deal with this would have been to forsake the wendigo theming (something which, as indicated earlier, I was thinking of doing anyway), and change the setting and tone of the game to something that can more comfortably support slapstick and puzzle-solving.
By the way, as I'm typing this I've just realised that I was doing a text adventure version of the Mr Freeze fight from Batman Arkham City, having a dangerous enemy you need to outwit rather than overpower. Not a complaint or an issue as far as I'm concerned, just an observation.
4. Fatigue
Can't do much about this one right now, but I'm working on it.
Here's the source code - you can copy and paste it into the latest version of Inform 7 (6M62 at the time of writing), and it should be fine. Feel free to carve it up for your own projects if you want to use Inform 7 for a project - the monster NPC is basically completely functional here if you want to put something like it into your own work, though I can't guarantee that the code is the best.
Sorry the project petered out like this! I would have loved to submit something, but poor planning and inexperience with the game engine did me in. Not a total loss, though - I learned a lot about working with Inform 7, and would love to create a larger, wiser project with it soon.