(content warning: the text adventure being developed in this devlog contains textual descriptions of gore and violence)

Hello! Thanks for checking out my devlog!

I'm going to make interactive fiction for this jam. This is going to be parser-based fiction, i.e. the kind where you type instructions in (> go north, > get flask, etc). I'm tentatively planning a horror/suspense game in a wintry landscape, based on escaping or otherwise handling a monster (inspired by the wendigo in Algonquian folklore, though I expect to deviate from this). Beyond this, it's all up in the air right now!

I'll be using Inform 7 as my game engine. Inform 7 is used for most parser-based interactive fiction these days (as opposed to Twine for choice-based games). It's a very detailed engine for text adventures, and you can make something functional very quickly, so hopefully programming won't be much of a problem.

I'm aiming to have a complete and publishable text adventure ready by the end of the jam (outside of testing, which can get pretty involved with parser-based games).

It'll be a couple of days before I get going, since I'm busy for a lot of Saturday, but I wrote a Day 0 update post below to explain my thought process and some potential issues.

Good luck to everyone participating in the jam!

Update 1 - Brainstorming, coming up with a concept

The last couple of times I've entered My First Game Jam, I've had a clear idea of what I wanted to make and how it would work. This time, I'm letting the theme guide me - I have no idea what I'm going to end up with, other than knowing that I want to make a text adventure.

Here's the result of my initial brainstorming session:

A mix of ideas - some promising, some not so promising. (Not sure what I was going to do with Baby It's Cold Outside.)

I liked the idea of folding heat into the game mechanics - freezing a river so you can walk across it, say. I have some ideas of how this could work as a fuller text adventure, with the player using heat or light or other environmental effects to change the state of environments. But to do this satisfyingly would require some very involved state tracking, and I'm not confident enough in my Inform 7 abilities to take this on. (I think Metamorphosesby Emily Short (which I haven't played myself) does something similar in interactive fiction, physically simulating the environment, and apparently there are a LOT of moving parts to make it all work.) An idea to shelve for now, perhaps!

Another idea I got hung up on was to explore a cold and barren environment, like the Antarctic. Immediately I thought of that penguin charging towards the mountains 70km away. There's an interesting narrative there, maybe, using an empty environment to explore a character who's had enough. There's not much obvious opportunity for play, though - it would all be in the writing. There's a good text adventure here, but I don't trust myself to write well enough or have enough interesting things to say to make it work. Also, the idea depresses me too much.

So if being in a cold place alone won't work for me as a game jam entry, what about being in a cold place with someone else? Or something else? This is starting to sound like a horror game or suspense game, which works for me - it reflects the Cold theme in a different way, emotional coldness or hostility. At some point here, I remembered that monsters associated with cold exist, and decided to go in that direction.

I'm tentatively looking at loosely theming a game around the wendigo, a being from Algonquian mythology. I had known this as being a beast associated with winter and cannibalism, but after doing a little more research, it holds a lot more symbolism than that. The wendigo is connected to the wider concept of destructive greed, and the destruction of other environments and cultures. Colonialism, in particular, is a wendigo which subjugated and displaced Native Americans when European empires settled on the east coast of North America. I wonder if you can also apply the wendigo on a larger scale, to the capitalist system of resource/profit extraction (of which colonialism is a key part) or the destruction of the climate by richer countries and companies.

(Unfortunately, I'm largely going off the Wikipedia page here, because I don't have direct access to a lot of the journals it cites! Other internet research seems to corroborate all this, but I don't know how reliable it is or how much of it is written by people who actually know Algonquian folklore.)

This seems like the most promising direction for a Cold-themed game so far, but of course, I'm not Algonquian. It instinctively feels like taking the wendigo away from its folkloric roots is part of the cultural colonialism that it represents. (Especially since I'm British, one of the settling cultures which displaced Native Americans.) So although I'm interested in exploring the wendigo legend as a springboard for a game, I don't feel great about helping myself to the folklore. I expect to deviate from the legend and define my own creature at some point, which will also free me up to explore different narratives and metaphors should they emerge from whatever I end up writing.

So that's where I'm at so far - a text adventure set in a cold environment, about being pursued by a wendigo or wendigo-like monster (a wendifaux). I'll need to make some big decisions about the gameplay experience - puzzly or not? How dangerous should the creature be? - but I'll start the game development by putting together a map, and I'll feel out the gameplay as I go.

Update 2 - Making a map

I've settled on the idea of the player being pursued by a monster throughout the game. I wanted to start building the game itself by creating a map which the player can be pursued around. I wanted to get this right the first time if possible, because Inform 7 is not really good for rearranging a game world once you've created it.

I had the following aims:

- Vaguely Great Lakes-y landscape (if I'm using wendigo lore as a springboard, I should at least set the game somewhere plausibly Algonquian)
- Different paths to take between areas, so that you won't be trapped in a dead end by the monster
- Relatively compact game world, to save me some work and so that the player can figure out the extent of the world quickly
- No complex exits - keep things simple with basic compass directions

This last point is maybe a little contentious. You probably don't navigate by compass directions very often - more likely, you reach places by following roads or going downhill instead of knowing you need to go east. This has been discussed a lot within interactive fiction communities (example), and there are a few games which experiment with other directions. Aaron A. Reed's Blue Lacuna, for example, has you navigate an island by landmarks, and if you want compass directions you'll have to find an actual compass within the game.

You could argue for doing something similar in my game. Perhaps the player character already knows the landscape and its landmarks, and so doesn't need a compass. It might also work for the opposite reason - if the player can't easily map the landscape by compass direction, it could cause disorientation, which seems perfect for a suspenseful game about being pursued. 

But on balance, I think this might cause too much frustration for the player as well. I think this game is going to have puzzles in it, and few things are more annoying in interactive fiction than knowing you need something and not being able to find it again. It would make the game feel like a maze, and I'd rather have the player be able to move through the landscape fluidly than clumsily. (This was my experience with Blue Lacuna - although navigating by landmark works well enough, I found it difficult to grasp the actual layout of the whole island until I got the compass.)

Here's what I ended up with:

I made this map in Trizbort, a really nice mapping program for text adventures.

The basic landscape is a slope from mountains in the north through a forest towards a lake in the south. I don't want the world to feel too flat and puzzle-gamey, so hopefully this slope and the ravine towards the north of the map add some verticality. The blue line represents a river which will cut through the landscape. I've tried to border the game world by landscape features which make escaping from a monster impossible, though maybe some are more credible than others.

I've marked some rooms on the eastern side as "clearings," or places where the forest has been logged - this helps to vary the landscape and adds a possible background conflict to explore. (Perhaps the destruction of the environment for profit could tie into the wendigo-as-destructive-greed metaphor?) I also added a cave in the northeastern corner and a campsite near the centre, with the idea that the monster and player will begin the game in these places respectively.

I'm trying to think ahead to possible gameplay scenarios and puzzles. For example, dotted lines represent possible routes which the player can take but the monster cannot, so that the player has ways to throw the monster off. I broke my "no dead ends" guideline with the cave, but the dotted line path could buy the player enough time to enter the cave, do something in there, and escape.

The map mostly follows cardinal directions, with a couple of other directions here and there for variety. I'm hoping this makes the game world simple to grasp intuitively without having to make a map - for example, the player who needs to get to the lake will remember that they need to head southwest, maybe. The trade-off is that it may feel artificial as a landscape (another good argument against using compass directions in general!).

The big problem I've made for myself here is that the map is effectively 23 rooms. This is a lot of rooms to implement within a small timescale, so I may have to implement them lightly - that is, not every room will contain something interesting to look at. This is also probably the upper limit of what the player can comfortably grasp, but fitting the rooms into a 5x5 grid could help navigation.

I've already implemented this in Inform 7, but the update is too long already! Next post I make will talk about Inform 7, why it's good, and why it can be a little awkward too.

Update 3 - Starting to make the actual game

I'm using the Inform 7 engine to make my text adventure. Inform 7 is a really interesting game engine geared at interactive fiction. It wants to treat making interactive fiction as a writing exercise rather than a game development exercise. As a result, the program looks more like a fancy word processor than a game development engine:

There's a few different tabs available to use, but in my setup here, the left pane is where you type the source code and the right pane is showing the Inform 7 manuals.

And that actually is source code! Inform 7's most interesting feature is that it tries to use natural language instead of a programming language. So just typing "The Office is a room" is enough to create a room called "Office." The idea, I think, is that you can just write your story and prototype something rapidly without having to learn a programming language first.

Inform 7 is doing a lot of clever stuff here. I've written "South of the Office is the Lobby." I haven't said "The Lobby is a room," but Inform figures out correctly that the Lobby is supposed to be a room, because I've defined it by its spatial relation to another room. I've also put a desk in the Office and a laptop on the desk. Inform has no natural idea what these things are (that is, I could not switch on the laptop and play video games in this story without writing my own code for that). But because the desk has something on top of it, Inform defines this as a "supporter" (something which can support other things), and so guesses that it's some kind of heavy object which I can't pick up and carry away. It's a very good guess, and if it's wrong I can always write another sentence like "the desk is portable".

Here's what this simple Hello World game looks like when it's compiled and played:

Hello World
An Interactive Fiction by wisprabbit
Release 1 / Serial number 200126 / Inform 7 build 6M62 (I6/v6.33 lib 6/12N) SD
Office
You can see a desk (on which is a laptop) here.
>s
Lobby
>n
Office
You can see a desk (on which is a laptop) here.
>get desk
That's fixed in place.
>get laptop
Taken.

As you can see, it recognises what "get" means without me saying anything. Inform 7 has a lot of actions and verbs already defined by default, making it pretty easy to write a Zork-like text adventure quickly. I can't do a lot in this game as it is, but it all works!

Inform 7's natural language processing is really clever and impressive. Unfortunately, it's also very easy to write something which Inform 7 will misinterpret, even though it seems contextually logical to you. For example, "South of the Hut is a room" can't be used to create a room called South of the Hut - instead, Inform 7 will make one room called the Hut, and another room south of that which doesn't have a name. You can avoid this by saying something like "there is a room called South of the Hut", but this also has potential issues. "The kitchen cabinet contains a container called a mixing bowl and a portable supporter called a platter" will create a cabinet and put one singular object inside it named "a mixing bowl and a portable supporter called a platter". (Both these examples are taken directly from the Inform 7 documentation.) Basically, it's very easy to accidentally introduce ambiguity into your source code.

In practice, I've found it best to imitate the Imitable Process of Ryan Veeder. Veeder breaks rooms down into their individual attributes - he gives each room an internal name, like "firedept," and a printed name which the player will see, like "Fire Department". These functions are built into Inform 7, and I don't know why they aren't publicised better, because they seem like the most effective way of helping Inform 7 get its head around complex room and object names.

In other words, the best way to work with Inform 7 is apparently to subvert the natural language interface and treat it like object-oriented programming, Oh well.

After plugging my rooms into Inform 7, I end up with this:

As you can see, I've named some rooms with grid references, just to help me disambiguate between different rooms called "Forest". Each room has a description field, which is what the player sees when they're in that room ("You are standing in front of a white house next to a mailbox," etc). There are no descriptions right now - I'll fill these in as I go along.

I'm using the right pane here to display the Index, a catalogue of all the functions available to you in Inform 7 and all the rooms and objects you've put into your game. This is a very very nice feature - it's an overwhelming amount of data at first, but very useful for looking up how exactly Inform 7 expects the writer and player to type certain functions or actions.

Within the Index pane, I'm showing off Inform's automap, also very nice to have. I've put in my map draft almost exactly as it was. The only major functional differences are those little red and green arrows, indicating where I'm letting the player type "up/down" or "in/out" instead of directions. Both "north" and "in" will let the player enter the northeastern cave, for instead. (Come to think of it, I need to account for "enter cave" as well.)

I've also changed some room names. That cave is now "Lair", and "Ravine" has been replaced with "Cliff". More importantly, I've changed a few of the forests into more clearings, in order to make logging seem like a more drastic threat - I'm interested in chasing this environmental metaphor a little more.

The end result of this is that now I have a landscape for the player to walk around. There's absolutely nothing to look at or do in it, though. I've started implementing more features, such as the monster itself, so that will be the next update.

Update 4 - Monster Factory

I've started programming the game in earnest now. I have a basic monster up and running, some debug functions, and a few other bits and pieces as I think of them. I'll just talk about the monster for now, and save the rest for another time.

First, I should note that when I say I've programmed things, what I usually mean is that I've adapted code from the documentation. Inform 7's documentation comes with a "Recipe Book," full of example code showing you how to program things like an NPC that follows the player. I believe most of these are written by Emily Short. I think they're there to be used (at least I hope so), so I have done, with comments in my source code giving credit where it's due.

Here's the first part of my monster code:

The monster is an animal.
The monster is in Lair.
The monster is neuter.
Understand "wendigo" or "wendifaux" or "yeti" or "snowman" or "bigfoot" or "sasquatch" or "beast" or "creature" or "thing" as the monster.
Description of the monster is "Like you, but colder."

(Sorry, all the code blocks are walls of text in this update. Itch.io's post formatting seems to think that empty line breaks in code blocks are just suggestions.)

One big advantage of Inform 7's natural language code is that it's completely readable without much explanation. But there are a fewdesign choices here to go through.

The monster is a "neuter animal," meaning a being referred to as "it." Inform 7 has a built-in understanding of "animal," "man" and "woman" as types of person, which in turn is a type of thing which can probably be talked to and which probably can't be picked up and carried around. I thought it might be interesting to define the monster explicitly as more human, since the wendigo in folklore seems to be something like an emaciated frostbitten human. (Hence the vague description field, which will appear when the player types something like "examine monster".) But a person, whether animal, man or woman, is always tied to a binary "male/female" property, and you can only escape that by making it an animal and adding a neuter property (and even then, Inform 7 might consider it male if you run a function finding all male people in the game.)

(Yes, this means there's no native support for non-binary people in Inform 7. Yes, this sucks. I'm hoping the next release of Inform 7, which was due last autumn, will address this.)

Also, that long "understand..." sentence is trying to catch different terms the player might use to address the monster. As well as "examine monster," you can now use "examine wendigo," "examine yeti"... I appreciate that this conflates the wendigo, yeti and bigfoot, and that's no good, but I'm trying to make life easier for the player who sees a monster in a cold forest and makes automatic assumptions.

The rest of my monster code is the start of a simple state machine. I create tags for the monster here, and a simple AI that will send it towards the player.

Section - Monster behaviour states
Behaviour is a kind of value. The behaviours are chasing, feasting, and aggressive.
The monster has a behaviour. The monster is chasing.
Section - Monster pursuing the player
[Adapted from Inform Documentation example 39, "Van Helsing"]
Every turn when the location of the monster is the location of the player:
    if the monster is aggressive:
        say "The monster [one of]brays.[or]claws at you![purely at random]";
    otherwise:
        now the monster is aggressive.
Every turn when the location of the monster is not the location of the player:
    if the monster is not chasing:
        now the monster is chasing;
    let the way be the best route from the location of the monster to the location of the player;
    try the monster going the way.

In the "chasing" state, the monster goes after the player. "Best route from [x] to [y]" is an automatic pathfinding algorithm within Inform 7, and I love that it exists, because I was dreading having to do the pathfinding code myself.

You can make doors in Inform 7 by putting them between rooms (e.g. "The front door is north of the Driveway and south of the Porch"). This is how you can make simple find-the-key-to-unlock-the-door puzzles. Oddly enough, the pathfinding code won't use doors by default, unless you specify otherwise (which is as easy as adding "using doors" to your code). This is perfect for me, because it gives me an easy way to make routes that the player can use but the monster can't. For example, I could say that some stepping stones across the river are a door, albeit one that the player can't close, and the monster will have to go around instead of following the player across the,.

In the "aggressive" state, the monster will attack the player. That is, it will print some text which says it's attacking you, but there'll be no real effect because I haven't programmed player health yet. If you look carefully, you might notice that when the player moves, the monster flips from aggressive to chasing, follows the player, then flips back to aggressive in the same turn. This seems inefficient, but it stops the monster attacking the player immediately in that same turn. The monster sticks to the player like glue right now, so this will give the player a little leeway.

It's random whether the monster will "claw at you" or whether it will just roar. I think this is how I want my monster to behave in practice. It exerts enough pressure that the player will be safer escaping it, but the brave player can gamble on the monster not attacking that turn in order to do some puzzle solving. The randomness helps to instill a little suspense into the game - it's looking increasingly like the player will have to lure and manipulate the monster to solve puzzles, which will require predictable monster behaviour, so I want to temper that with a little danger.

The thief from Zork I is basically the model for my monster at this point. He attacks and steals from players who hang out in the same room as him, and the player can either safely flee or risk their life and inventory to try to do something else. I think that's about as random as you can get without being too frustrating.

My monster also has a "feasting" state, which is unused for now. (I can't call it "eating," because Inform 7 stops you doing that so that it won't get confused with the "eating" action the player can do.) I want to give the player a supply of meat, which can be used to distract the monster for a few turns.

I don't know how I'm going to do this yet, exactly. I don't want to give the player unlimited meat because that could be abused easily, if the player just distributes armfuls of meat across the world so that the monster can't do anything. But I'm keen to avoid limited resources, because that could make it easy to render the game unwinnable if the player runs out of meat before running out of puzzles. But maybe that's fine, since the game will be small and probably winnable within a few minutes if the player knows what to do? That is, having to restart the game won't ever set you back too far. I have to think harder about this.

Thank you for reading or skimming all the text. To round off, here's a sample of what the game looks like so far, also showing off the automatic debug function I made to make sure the monster is moving. ("Z" is just a shortcut for "wait".)

Wendigo
An Interactive Fiction by wisprabbit
Release 1 / Serial number 200127 / Inform 7 build 6M62 (I6/v6.33 lib 6/12N) SD
Campsite
>e
Forest
(Monster location: Cave Entrance; state: chasing.}
>z
Time passes.
(Monster location: Clearing; state: chasing.}
>z
Time passes.
(Monster location: Cliff; state: chasing.}
>z
Time passes.
The monster arrives from the north.
(Monster location: Forest; state: aggressive.}
>z
Time passes.
The monster claws at you!
(Monster location: Forest; state: aggressive.}
>n
Cliff
The monster arrives from the south.
(Monster location: Cliff; state: aggressive.}
>z
Time passes.
The monster brays.
(Monster location: Cliff; state: aggressive.}
>w
Forest
The monster arrives from the east.
(Monster location: Forest; state: aggressive.}

Whoops I've just noticed that I'm closing the monster status report with a curly brace instead of a regular bracket. I don't need to fix these because it won't be in the final game, but it will annoy me forever if I don't.

Update 5 - Meat

One of those days where I spun my wheels a lot and didn't get much done, but the monster is coming along nicely. I'll show the code for the expanded monster AI in this update, and I'll also show off the debug functions I'm running.

The player can now distract it temporarily with a cut of meat. There are 5 cuts of meat found in a chest in the starting area, and once they're gone they're gone. (The game will be short enough that I think I can get away with letting the game become unwinnable. This also saves me writing a lot of sophisticated code to stop the player screwing up.)

I wasted a lot of time implementing a way-too-fancy version of the meat. There was going to be a nondescript pile of meat in the chest, from which the player could take cuts of meat. The cuts of meat were actually stored in an inaccessible room, and individually teleported to the player's inventory when they tried to take some meat. I wanted to try this so that I could just refer to "the meat" rather than individual cuts of meat - I think the vagueness is a little more surreal and hostile. But I got lost and frustrated trying to figure out the code, so I went for something a little blunter and simpler.

Because of this, I now have an unused dummied-out room in my game called Meat Dimension. This is fine.

The monster AI is now governed by a single rule running every turn, which is clumsy but ensures that the monster isn't taking multiple turns of its own every player turn.

Every turn (this is the monster AI rule):
    if the monster is feasting: [monster eating meat overrides other behaviour]
        decrease the feast time by 1;
        if the feast time is 0:
            now the monster is chasing;
    otherwise if the monster can touch a cut of meat (called the feast) which is not carried by a person: [monster distracted by meat]
        move the feast to the monster;
        try the monster eating the feast;
        now the feast time is 3;
        now the monster is feasting;
    otherwise if near monster: [monster attacking player]
        now the monster is aggressive;
        say "The monster [one of]brays.[or]claws at you![purely at random]";
    otherwise: [monster searching for player]
        now the monster is chasing;
        let the way be the best route from the location of the monster to the location of the player;
        try the monster going the way.

"Feast time" is just an integer which ticks down. "Near monster" is a truth state (or, as other programming languages might call it, a boolean) which checks whether the monster is in the same room as the player. This was an experiment with factoring my code, but I found the syntax difficult to get right, so I don't want to mess with the code any more for now.

One fun side effect of the monster's behaviour now is that, if it enters the starting campsite which the chest of meat is open, it will just stop and gorge itself like a bear raiding a garbage can. One the one hand, this is frustrating and punishing for the player who forgets to close the chest of meat and then comes back later to find it all unexpectedly gone. On the other hand, it's very funny. So it's impossible to say whether it's bad or not.

The monster AI isn't done yet: I need to implement player health so that the monster can pose a threat, and I need to add more flavour text so that the player can tell whether the monster is eating meat or chasing them. But this was the big hump that I was worried about, so hopefully the worst is behind me. This is good, because productivity is about to be hit by Kentucky Route Zero Act V.

Here are those debug functions I mentioned earlier. They're stored in a part of the source code labelled "Not for release," which means that I don't have to worry about removing these at the end of development - Inform 7 will automatically dummy these out when I make a public version of the game.

VOLUME - DEBUG - Not for release

Book - Run property checks at start of play

[Adapted from Inform Documentation example 2, "Bic"]

When play begins (this is the run property checks at the start of play rule):
     repeat with item running through rooms:
         if description of the item is "":
             say "[item] has no description.";
    repeat with item running through things:
         if description of the item is "":
             say "[item] has no description."

Every turn (this is the report monster state rule):
    say "(Monster location: [location of the monster]; [nearmonstertruth]state: [behaviour of the monster].)[paragraph break]".
To say nearmonstertruth:
    if near monster, say "monster considered nearby; ".
The report monster state rule is listed after the monster AI rule in the every turn rules.

The second one, the "report monster state" block, is just telling me where the monster is and what it's doing, so I can see if I broke something.

The first one is more interesting. It runs through every room and every object in my game, and warns me at the start of a playthrough if I'm missing a description for any of them. This will be helpful don;t the line as I add objects and start doing some actual writing. But because I haven't described most of my rooms yet, every playthrough currently starts like this:

There's a couple of other neat things here that I haven't talked about yet - listing the exits in the status bar up top, and beginning to fill out the campsite - but I'll get to them in future updates.

Update 6 - Now the monster can kill you

Content warning: Textual descriptions of gore and violence

Quick update today because I'm tired. But I think the monster's AI is complete now! Both the monster and the player have a health variable of 3 now, and the monster can now strike the player to take away a hit point. After three hits, the player getsa a game over!

There's an idea in horror writing that it's good to leave things to the audience's imagination, since whatever they imagine will always be wrose than whatever you can design. I want to take advantage of that, especially since player deaths will be gory (by dint of being maimed by a beast) and I don't really like gore myself. I feel that it's easy to be too lurid with gore, so that it becomes more gross than horrifying. I think "its claw splits you open" is exactly graphic enough. It's the only bit of writing I actually like here - the rest needs a redraft, maybe. "The monster finishes devouring the meat" is very clumsy in particular, and needs a rethink.

I've also started letting the player attack the wendigo. I think most attacks will be useless and you'll need to find a particular weapon or think of some other way to deal damage. There is an example in the Inform 7 documentation that will let you hook the pre-existing "attack" command up to items, which will make this work. Unfortunately, in practice it looks like this:

To be clear, it seems like you have to strip out every built-in synonym for "attack," redefine "attack" and then put all the synonyms back in again. I feel like there ought to be a better way.

By the way, note that the attack function doesn't actually do anything to hurt the monster yet. Poor player.

I've given the player character a tomahawk to test this code. I need to let the player throw the tomahawk at the monster as a way of attacking. I also think that maybe I shouldn't let the character start with the tomahawk in the final version of the game - I think I'll put it in the cave and make the player kite the monster around to buy time to get it.

Last thing I did was assign rooms to "regions," basically collections of rooms which you can ascribe properties to. I've not done anything with this yet, but it will help me later on - for example, I can add trees to "the forest region" so that they'll automatically be visible in every forested room, instead of me having to add trees to them individually. Plus, it makes the index map look pretty.

("Backstage" is the source code name for the Meat Dimension, which, again, it's fine.)

Tired of coding for now, so I think I'll fill out room descriptions and narrative details for my next job.

Update 6.5 - Whoops

I haven't actually got anything practical done in the last couple of days, because of a combination of life events and Bad Mood. It'll probably be a couple more days because I can get back to it, since more stuff is happening this weekend and I have other work that needs catching up on more urgently than this.

So uh, it's looking pretty unlikely I'll have a finished game to submit at the end of the jam. Sorry.

This might be a blessing in disguise. If I was keeping to the two week limit, there's one very important factor I wouldn't have been able to account for: testing. I think text parser-based interactive fiction is more vulnerable to developer oversights than most other types of puzzle or narrative-based game. Because most such interactive fictions simulate a space and a variety of actions, players expect to be able to play around. So this means a lot of reasonable actions need to be accounted for, with either an interesting result or a reasonable explanation for why they would be silly to try.*

This is especially important when you have a lot of objects in your game and players think of alternate possible solutions. For example, if I put a locked door in my game that needs to be picked with a hairpin, players will want to know why they can't use the credit card to jimmy the lock instead. The best way to find all of these different cases is with a good phase of testing.

I'll see this jam through to the end and keep working on the game, but if I don't submit, I'll take the time to refine this game a lot more before releasing it properly. I will say, though, that I did meet my other goal of learning my way around Inform 7. So this jam is at least a partial success for me!

* some games get around this by limiting the parser - that is, only letting the player use a small number of actions. This might seem less playful, but it makes the limits and rules of the game much clearer in terms of puzzle design, and it's easier for the author to account for alternative solutions and the like. I think Eat Me (cw: body horror, food) is the most famous example - you might remember a few games websites like Waypoint writing about it a couple of years ago - but also see The Wizard Sniffer and most if not all of Arthur DiBianca's recent games. (All of these are excellent games, by the way.) I'm considering something like this for my game, but I want to do some puzzle design work and see what feels right before I commit to this!

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.