itch.io

Thanks very much for this kind comment! Sorry it's taken so long for me to notice this comment. I haven't logged into Itch in a while.

Anticipating silly commands is a grand old tradition of text adventures, and this is a vampire story, so I kind of had to have "kiss" really. People would complain if I didn't.

The Moonlite - you can push the button at the very end (I think? it's been a while since I made this). The game cuts off before cool things happen, though. Sorry. I think there might be a sequel to this at some point in the far-off future. I'll put it right if I do that. Maybe.

thank you Wudgeous! this was really nice to read!

I'm glad you took to using a text parser. I tried to keep the controls simple and beginner-friendly, and I'm glad it worked. The wrestling game is still in the works, though it's probably going to be a while before it sees the light of day - puzzle design is proving to be a beast.

Thanks again for the kind words. All the best to you too :)

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.

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!

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.

Thanks for sharing, and thank you very much! :)

I adore how this looks! Really looking forward to seeing where this goes!

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 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.

Thank you for your lovely comments!

I'm happy that my talking about Inform 7 is helpful. It's a very quirky engine, and the documentation is overwhelming at first, but it's proving to be very easy to learn by example, so I hope that's being passed forward!

This is a great idea for a game, and your frost effect already looks really cool!

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 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.

Thank you! I am leaning towards making a puzzly game right now, and I like your idea for integrating the monster into that!

Thank you!

Of course, trying to kiss the monster is a grand tradition in text adventures. I haven't decided whether it'll be a viable option here yet, but I respect the player's right to try.

Wow thank you very much! Really kind of you! :)

If you like text adventures like this, you might try Child's Play by Stephen Granade, which was the direct influence for this game's sense of humour!

(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.

1. Hi there! What's your name? Want to introduce yourself?

Hello I'm Alex! This is my third MFGJ, and I'm hoping to make a text adventure this year!

2. Did you participate in the last jam we held? If so, what do you plan on doing better this time? If not, what's your reason for joining?

I've done My First Game Jam Winter 2018 and 2019! Last time I submitted a prototype puzzle game which I never got around to expanding on (maybe someday, though). This time, I'd like to make a complete small game without any big plans to expand on it. (Outside of bugfixes, of course.)

3. What games are your favorites? Did any of them inspire you, or made you want to make your own?

This year I want to make a small piece of interactive fiction. I've been getting into text adventures over the last couple of years, and I've found myself drawn to the big puzzly games - that is, the classic style "> get ye flask" kinds of games.

Two of my favourites so far have been A Beauty Cold and Austere (by Mike Spivey) and Curses! (by Graham Nelson.) There's a lot of really good interactive fiction out there, but these two share something inspirational between them, I think. In both games, the authors wanted to share their passion for something with the player - ABCaA is Spivey introducing the player to the history of mathematics, and Curses is Nelson giving the player a tour of British history and mythology. They're both really fun games (albeit super difficult, in Curses' case!) and they both left me sharing the authors' passion.

I'd like to put a similar amount of love into my games, if I ever make more. That said, I'm going to use the theme as a prompt this year, so I have absolutely no idea what my jam entry will be about yet!

4. Do you have experience with game development? What did you do/with what engine?

I know my way around Game Maker Studio 1.4, and make my previous MFGJ entry with it, but that's not what I'm planning to use in this jam. I've been taking a course in Unity, but I'm not confident with it yet. I have some very slight knowledge of Inform 7, which is the engine I'm trying to very quickly learn for this jam.

5. Tell us about something you're passionate about!

Since the last time I answered this question, I have gotten a lot more interested in sports, particularly football (i.e. soccer). I used to write football off as just overpaid athletics, but I had a moment of clarity this year after I got fed up of professional wrestling. I had enjoyed wrestling because it was more about the soap opera than the actual sport, and I eventually realised that a lot of organised sports are like that. It's not about the football so much as it's about the atmosphere of a match, the community that forms around it, the big personalities that pass through and shape your team for better or for worse. Such a fascinating and weird part of human culture; I think I've fallen in love with it.

It also probably helps that my team, Sheffield United, are doing well at the moment. Maybe a few years from now Sheffield United will collapse again, and I'll decide that football is for idiots after all.

6. What are your goals for this game jam?

• Finish something! I want to end up with a complete game and a cohesive story or atmosphere, no matter how small. Other than bugfixes and better testing, I shouldn't feel like I ought to add to the game after submission.
• Learn Inform 7. I've been poking at the engine and documentation recently, trying to learn my way around the program ahead of time. I would like to gain more familiarity with it, and hopefully write more text adventures after the jam.

7. Any advice to new participants?

• Give yourself days off. Build days offinto your timetable, if you're planning that far ahead.
• Scope as small as you can, and don't be ashamed to make your scope smaller if time isn't on your side. You can always add those optional features back when your core game is done if you have a bit of time left.

8. What can the admins do to improve your jam experience?

Nothing - always had a lovely time in this jam!

9. What are some of the past works you've made for the jam? Show off your favorites!

I had to pull out of the Winter 2018 jam because of computer trouble. But I made a puzzle game called Arcane for Winter 2019! (Windows download only, sorry!) I still want to return to this someday, but building levels in Game Maker was a bit of a kludge - I think Unity would be better for turning this into a long-term project.

thank you! glad you enjoyed it!

aa thank you! Very kind of you! You're probably right about the saturation - I'm not an artist, so I was just using the colours in Game Maker's sprite editor, which are all very bright. I'll look at tweaking it if/when I come back to Arcane. Thanks so much for playing!

This game was one I was excited about from reading through the devlogs, and I'm glad it turned out so good! The art and presentation is beautiful, especially considering you're using an engine meant for Lucasarts-style games. I enjoyed poking around the room a lot, it's a very rich environment for three screens. (I like the lighthouse photo joke.) I like that combination lock puzzle - putting the clues in the room together was satisfying. I didn't spot any bugs or glitches.

The one big thing that bothered me was that the inventory items should have descriptions - the letters repeat their contents, which is great and exactly what I wanted, but I think the photos should do that too (especially since one of them has a puzzle clue!) - right now the photos and the hat are just "some junk in my inventory," which conflicts with their importance in the story. Maybe that's just because of game jam time pressure, though? Anyway, your game is great :)

Game Title/URL: Arcane

Pitch/Information: A puzzle game inspired by classic tile-based puzzlers like Chip's Challenge and DROD. The main gimmick is that certain blocks can be teleported to anywhere they'll fit in the room  in order to weigh down pressure plates, block enemies, etc.

I'd like feedback on: Anything, really - I made the game solo, so any comments or criticism will help. I'm especially interested in comments on the puzzle design, since I think I'd like to expand Arcane as a full-fledged puzzle game.

This grappling hook is a lot of fun to play with! I'm very bad at this kind of platformer (I only managed half the levels), so the fact that I still enjoyed it is a sign of pretty good design!

Thank you! Very kind!

Looking at it again, I think Level 17 is a bit too obscure, and could do more to hint at its solution - it's okay as a final puzzle, but if I come back to this game, maybe that would become a secret/bonus puzzle.

Submitted my game!

I got fed up of working on this, so I built the game and submitted it. Thank you to anyone and everyone who's been following this project! I'll do a postmortem in a few days, probably.

Update 11

Sorry for no update yesterday - a lot of real life things kept me busy, but I managed to fit in more gamedev.

I mostly fixed the door sounds! I don't like the solution, because it involves toggling variables to stop the game playing the sounds every turn and I had no idea where to put the variables. The code looks even messier now. I did my best to comment what I was doing in detail, but I can't help but feel that if I update this game past the jam, there's going to be some horrible audio bug in a year's time that has its roots here which I absolutely will not be able to track down. There's still a think where pressure plate door opening/closing sounds play when a state is loaded, which isn't consistent with other types of doors, but whatever, it's FINE.

I added a few more sound effects, including a jingle for the game end screen, a key collecting sound, and a little chirp for the Hungry when they chase you. I don't like this last one because it sounds very farty, so I may change it. Also I've stopped liking the name The Hungry, but that's how it's referred to throughout the code and it's too late to change it now.

I tweaked the player death state, so now it reloads the last saved state instead of restarting the room (and potentially undoing player progress). This should effectively restart the room if the player hasn't saved a state yet, since the Control object automatically reads the state of all objects to build itself. I also now have the enemy sprite on top of the player sprite during death, which I think looks better.

With all this, I think the game engine is done! There's nothing else I absolutely need to add or change. Now I can focus on puzzles. Looks like there'll be 17 levels in total.

This will probably be the last update until I finish and submit the game. Good luck as we enter the last few days, all!

Some last screenshots:

Update 10

Not much to report today, which is a good thing! All the programming is nearly done, and I've been putting energy into making puzzles and adapting the test puzzles I made during development.

I have about nine puzzles ready to go so far. Something I have to think about is how elements are introduced. I'd like to introduce puzzle elements one at a time, giving two or three puzzles for the player to get a handle on each one, and then a series of harder puzzles putting things together to test the player and finish the game. So in designing puzzles, I have to think about both the difficulty curve and teaching the player. This is tricky!

I'm ordering puzzles as I go to get the difficulty curve right, but the problem is, I made the puzzles, so I know how you're supposed to solve them. The player has to understand how an element works, and then how to apply that element to solve the puzzle. What seems natural to me may be obtuse to everyone else. I hope the level select mitigates the problem of difficulty spikes, and I hope that the sidebar text in early levels helps players to get to grips with the game engine itself. I also hope this isn't read as a lack of confidence in the player! I'm trying to explain how to control the game, and what things are, without giving away everything you can do with them. This is a surprising lesson: it's easy to made a hard puzzle, but it's really hard to make a puzzle that's easy but not trivial, that teaches the player without patronising them.

Here's a puzzle screenshot, to break up the text:

(This puzzle has a much harder iteration where you also have to weigh down four pressure plates outside of the box!)

I did a bit of work on the game engine too. I started adding sound effects, using a function which checks if the jukebox has been muted first. I was hoping that doing this would be quick, but I've had a few problems. All the sounds are very loud, so I've had to fiddle with their volumes. I've had to completely rework the sound effect for clicking, which was especially loud and sudden, like being punched in the ear. Also the door opening and closing sound effects play every turn, so I need to debug that.

I also made a little victory screen, just a few paragraphs thanking people for playing the game. With this, the game engine is basically complete! I just need to fix some sound effects, maybe add a couple more for picking up keys, and do a test export of the game to see if everything works. Things are looking good for a submission on Saturday!

Update 9

Today I accidentally deleted the notes I keep to tell me what I added since the last update, so this might not be complete.

The title screen looks nicer now, and has a functioning level select:

As you can see, the logo outline is glowy now. I also added a cursor, more for fun than because it's necessary (there's like five other coding jobs I need to do before I'm completely happy with the engine).

The level select is just an array which finds the next X rooms in the resource tree and assigns a number to them. Because the automatic room data solution I was trying yesterday didn't work, I'll have to set X manually, as well as number all the rooms myself when I'm done. (I understand there's a thing called ds_list or ds_map that you can use to manage data like this? I think RPGs use these to manage enemies and inventory. But I don't understand how they work, and apparently you get big memory leaks if you don't handle them correctly, so I'll stick to my idiot solution for this game jam.)

As for the game itself, I added right-click to cancel block placement. I added a few sprites to the buttons; they feel more responsive to press now, and they're greyed out when you carry a block, to show that they can't be used in this situation.  I also tweaked the level complete and you died messages, so that they're legible and nicer to look at. (I forgot to get pictures of these.)

I was hoping to be done with programming today, but there's a couple of big jobs I need to do. I need to hook the sound effects up to objects and the mute button, and I need some kind of ending screen. I was going to have an instruction screen, but I'll just use the sidebar for tutorial information for now. I think there's a few other tweaks to make here and there if I have time, such as making the game font a touch smaller.  (It also looks really wonky in places, but from experience I think Game Maker just sort of does that to your fonts arbitrarily.) Other than this, it's all puzzle design until the deadline!

To round off today's devlog, here's a puzzle I made today. I finally figured out how to work the jam theme into my game!

Update 8

Took the day off yesterday, kind of. I made a bunch of sound effects. The sound effects, like the music, were made in LMMS. In particular, I used the SFXR plugin that comes with LMMS. This means the sound effects are very NESsy compared to the rest of the game, but it's fine.

Today, I did a lot of little jobs:

I made a quick title screen, and started making a level select system for the title screen. I made a few new buttons, with the intention that the player will be able to scroll through a list of puzzles.

I made a music player and a mute button. Actually, this is a cheat: the mute button IS the music player. It's a persistent object you can click on to toggle the music, and it's going to decide whether or not sounds can play once I put them in the game.

Here's the current title screen:

The black background and the shell of a level select system don't look impressive, and I probably won't spend much time on redesigning this screen, but there they are.

I've done some work on the main game, especially the side panel. For a start, I tweaked the menu buttons so that they don't respond if the player is carrying a block. This is to prevent exploiting the save states in any way (I don't know if it's possible, but I don't have to risk it!). This creates a new task: I need to grey out the buttons when the player is carrying a block, so that it's clear they can't save and load states in this situation.

The player character now has an actual win state, which pauses for two seconds and then brings up the next level. I added some text to pop up in the sidebar, but this needs revising, because it doesn't fit and overlaps some text I added later - I may put it across the main screen, Dark Souls YOU DIED-style.

I rearranged the sidebar a touch to look neater. The sidebar menu is created and placed by the Control object at the beginning of each room, and this same object now also draws a nice purple border around the two panes of the main game screen.

I made a template room, which I can duplicate to set up a canvas for puzzle design. I made a couple of puzzles in this just to get started on puzzle design, and to form a basis for my final job for the day, level information.

Each puzzle has a couple of variables in the room creation code, holding a level number, a name and a little blurb to tell players about new game elements. (I like when puzzles like names, as in the Talos Principle or Stephen's Sausage Roll. It adds a bit of character, and a hard puzzle becomes a nemesis when it has a name you can cuss at.) I wanted these variables to be drawn in the sidebar in the Control draw event (the same event which draws the new border around the sidebar), to fill the space a bit.

Would you believe that this is the programming task that completely defeated me? I could NOT get this working. The Control object was supposed to stitch these room variables together into a text string to print in the sidebar, but the compiler would swear blind that these variables didn't exist. I thought maybe it was to do with event order - like, the room creation code gets run after all objects are created and start being drawn, maybe - but I tried rearranging events and gating code with "if this variable exists" conditions... nothing. Then I realised that the error message said "Gem.(unknown variable) hasn't been defined." WHY ARE YOU TRYING TO READ THE GEM OBJECT. THE GEM IS NOT RELEVANT TO THIS TASK

I don't know what I was doing wrong (it might even be a problem with the Game Maker IDE), but I had to go for a hacky solution. Every room now has a RoomInfo object hiding just offscreen, which has the variables in a place which can be read without crashing the game. I don't like this because I wanted the variables to be directly connected to the room asset, so that the level select screen can read them. But I don't have the time or patience to keep troubleshooting this. I'd have coded this at the start of the jam if I'd known this was the hard part.

That's enough complaining. Here's what Arcane looks like now:

Puzzle numbers and blurbs are temporary. I'll renumber them when I have more levels and a good order for them. That pressure plate one won't actually be the second level in the game.

Here's a GIF of the game in action, text glitches and all:

I'm a bit cranky after an hour of failed programming, but I've just been staring at this GIF for a few minutes thinking "wow... I made this." It's easy to focus on your failures, and I do that all the time, but I've achieved a lot so far, and I'm trying not to forget that.

I'm very pleased with myself. Which is good, because nobody else will be pleased with me when that nine-block shape-fitting puzzle makes it into the finished game.

Tomorrow, I'll poke at level select, sound effects and some bugfixes. Did I say I was going to do the level select today? I said I was bad at time management.

This is looking great! Even the lineart without colour looks really polished. Also I've tried using AGS before, so I know you've done really well to hack it into shape for your game.

Oh this is looking very cute! Good work! I love your people sprites.

I'd imagine the game will be busy enough once you're managing four couples at once, so I wouldn't worry about it not being fun yet. If you need a puzzle element, though... maybe each person only says they want something hot or cold or sweet or savoury, etc, and you have to serve a meal which both diners like?  (though that's a lot more coding to add this far into the jam) Or maybe some couples are completely incompatible and you have to spot them and move them on quickly to make room for couples who'll have a better date?

Update 7

Last night I drew blocks while catching up on MBMBaM.

I think pentominos can wait for when I have a spare week.

Here's some of the new blocks being tested. This also shows off a rearranged menu, with a Quit button and a placeholder logo.

The big sidebar and the black border around the whole thing are bothering me a little. I think the layout basically looks fine, but I was intending to use the black space for things which won't come together now. I was going to use the space at the top and bottom for level and room names, but I think they won't look good smushed between the puzzle and the edge of the window like that. The extra sidebar real estate was for talking to NPCs, but they won't be appearing in this game jam, so I might use that for level names or other tidbits.

So that was last night. Today was for working on save states, but I'm having one of those days where my brain is full of fluff, so I did some of the more fun creative work to begin with. I drafted a nicer logo:

This looks mostly fine, but the outlines between the N and E run together into one thick line which bothers me a lot. Also I think the ends of the C look a bit too chunky? I'll probably tweak this again later.

I also finished the music track for the game. It's six minutes long and quite low-key, which I hope means it can loop indefinitely without annoying the player. Here it is if you want to listen:

https://clyp.it/xkiekay3?token=18759554a1c1e733e6c7da91799e79c8

Having run out of ways to put it off, I started coding the save system. First I rearranged the big horrible arrays so that they find all the objects they need to store first, and then grab their data. This allowed me to split the data grabbing off into a saving function which the player can use at any time.

The load state function is largely just the save state function with the variables swapped around, so that instead of changing an array value to an object's position, it changes an object's position to an array value. I then point it to the Control logic which checks keys and doors, so that it can close doors which shouldn't be open anymore. I think there's some redundant code here from the sloppy way I cut up and rearrange the code, but screw it.

Finally, I attached this code to the buttons, and made a testing ground.

The result - after a quick tweak to update enemy sprites correctly when loading state - looks good!

I now have a system where the player can set their own checkpoint in a puzzle and rewind to it if things go bad. This is super nice to have for both the player, and for me testing puzzle ideas and elements (not that I'm going to add any more elements for now). I need to set player deaths to rewind to the last save state rather than just restart the room, and I need a proper victory state when the player reaches the gem, but other than this, I think I have a pretty good puzzle game engine ready to go!

With that, time to take a day off and forget how everything I've coded today works. More presentation work next time, I think!

Update 6

Today, I've added three elements to Arcane!

Firstly, pressure plates:

All pressure plates in a room need to be pressed to open the grey doors. The doors close again if just one plate is released.

This was surprisingly easy to implement! Because pressure plates are fixed features of a room, I don't need to do anything to their coordinates or variables - I just have a few lines of code that run every turn and check if the doors need to be opened or closed.

In my flowchart, I had some idea that doors can close on objects and destroy them. I decided not to go this route, just because it was easier. I think the consequences of this are interesting when you put a pressure plate next to the door it opens:

The way that objects are processed right now is that players and blocks move before pressure plates and doors are checked. So if the player moves onto an open door and that door closes on the same turn, the player is standing on the door. This offers protection from enemies - closed doors are walls, and enemies can't move into walls! Similarly, a block can't be placed on closed doors, but it can be placed on an open door even when that door closes the same turn. There's some sneaky potential there for shuffling a block into a space it shouldn't be able to get to.

Speaking of places a block shouldn't get to, I made anti-block zones:

Just tiles that stop blocks being placed on them. This will help me to control what the player can do when I get around to designing puzzles. As seen in the GIF, they're made to complement pressure plates. This will lead to some cool situations in the actual game, I hope - maybe the player needs to lure an enemy to a pressure plate she can't get to but which can't be weighed down with a block?

Finally, I added another type of key, by copying the code for square keys, finding "square", replacing with "triangle." Here's a GIF of the triangle key in action, in a simple puzzle I mocked up using anti-block zones.

(I screwed up here and put the wall tileset on the wrong depth layer, which is why the top of the Hungry's head disappears as it eats the player. If I keep working on Arcane past the jam, I need to sort out depth. I'd want to code it so that objects south of over objects will always be in front, to preserve the faux-3D effect of the wall tileset.)

These are probably the last elements I'll add, other than different shapes of blocks (I'm planning to make a bunch of those this evening while I catch up on podcasts). I think I have enough elements now to make some cool puzzles with a bit of variety. At this point I want to take stock and think about the project as a game jam entry, and rescope it a bit.

I'm very happy with the progress I've made, but there's not much of an actual game yet. I want to set aside a lot of time to make some good puzzles for the game. Let's say 5 days to make at least 15 puzzles. So I want to be done with the game engine by Monday. And I'm planning to take Saturday off to rest and check out everyone else's projects (I haven't... been a very good community member so far.....), so that's only a couple of days to finish the heavy coding work.

I had a couple features I wanted to add. I wanted to let the player wander from room to room to solve puzzles in their own order, but I'm going to scratch this for now, since I haven't started on this idea yet and I don't know how to do it. I won't have game-wide save data for the same reasons, and the player probably won't need it anyway. On the other hand, I'll keep the idea of letting the player save state within a puzzle, since I've been working towards it for a while and it would be really nice to have.

Also I forgot that there needs to be a framework to interact with the game. So that means a title screen, some way to select levels, maybe an instructions screen and a victory screen, and a way to quit levels. Also I need to fix the menu I've got so that it's attached to the Control object, to make it easier to put it in levels.

Also I want to finish that music track that's half done, and maybe add sound effects if I have time.

So that's a lot still to do! I think I'll try to get the save system working tomorrow, and scratch it and move on if it doesn't work out. Maybe do some simple title screens and music work on Sunday to relax? I've never been good at timetabling.

Update 5

I've created a monster!!

I've been working on an enemy today! I'm calling this little guy The Hungry. It wants to close the gap between it and the player, and will choose the move that makes this gap the shortest.

I liked spriting this little guy, but the design could be more exciting. I mentioned in the OP that I want Arcane to be occult-themed. Enemy design is a great opportunity for this, and I wanted to draw from medieval demonology, or maybe tarot cards. (Classic puzzle game The Fool's Errand does a great job of mining the Major Arcana for design and puzzle inspiration.) But I couldn't quite find anything that seemed simple enough, and I didn't want to spend all day on Wikipedia (not while I'm on a game jam time limit). I ended up subconsciously drawing from that most demonic of game series, Kirby - the Hungry is a lot like a ground-based version of Scarfy.

Programming was much more complex than I expected, and I spent all afternoon working on it. The Hungry's AI has to check four different possibilities for movement (east, north...) and find the two best, the second-best being a back-up for edge cases where the Hungry's preferred move is obstructed but another move would be acceptable. The Hungry discards moves that increase the distance to the player. This required a whole lot of mathematical problem solving. 

I ended up separating a lot of things into different functions - the Game Maker project gone from 8 different scripts to 14, most of which are little mathematical functions which will be helpful for other enemies in the future if I keep working past the game jam.

I'm quite proud of how the AI works with directions. I use the digits 0-3 to represent east, north, west and south in that order, and functions tell the game how to interpret the digit as changes to x and y coordinates. By representing directions as numbers, I can use a simple for loop to check all possible moves for the Hungry. (Yes, the numbering of directions starts from the east and goes counter-clockwise. This is the way angles are coded internally in Game Maker, for reasons unclear to me, so I'm doing it the same way just to be consistent.)

After a few hours, I'd written the AI and incorporated enemies into the Control system. I also added a death state for the player, which just turns the player red and immobile, waits a second, and restarts the room. Again, this was all kind of stressful - I wasn't sure how much of this could be tested while writing it, so I just checked and double-checked everything, and typed carefully.

Here is the result of my first test (before I implemented the changing enemy sprite):

Oh! That's... very aggressive.

It turns out I made a coding goof on the first day of the jam. 

What I thought this did was register the player's keyboard input and move the PC appropriately. What it actually does is process every frame as an attempt to move the character, because there's nothing to check if the player is or is not pressing a keyboard key before this movement code runs. I fixed this, and took the opportunity to add a wait option, where the player skips a turn if they press the space bar.

(At some point, I need to replace that tower of if statements with a switch statement. But I'm not confident with those, and this works well enough for now. Bethesda once made a running train in their game by having a man run around underground wearing a giant train hat. If it works, it's fine.)

After this, the Hungry seems to be working fine! It's quite good at closing down the player, but the player has opportunities to trap it in corners and keep it at bay. There's two interesting unintended consequences of the Hungry's AI:

1) It always goes through possible moves in the same order. I'm not exactly sure, but I think this leads it to always prefer certain directions - if both are equal, it would rather move west than south, because west was the first to be selected the best direction to move. But it would rather move north than west if those are equal! Hold onto your butts because I'm about to talk about DROD again: in DROD, most monsters have a quality called "vertical preference" where if a monster chasing the player hits a corner, it would rather move north-south than east-west. This makes it absolutely predictable how a monster will move in a complex puzzle, and a few DROD designers exploit this behaviour in especially hard puzzles. Here, the Hungry's behaviour is a little more complex to predict, because you have to be aware of the order in which it checks directions. I wonder if that's a good thing? If it's too complex, I might be able to tweak it by changing the assignment of directions to 0-3.

2) When the Hungry is right next to you (including diagonals), there's nothing you can do to lose it. That's surprisingly scary (I'm glad I gave the Hungry a scary face when it reaches the player), but also pretty exciting! How about a puzzle where you're chased by a Hungry as soon as you enter a certain chamber, meaning you have to set up movable blocks from outside because you won't have the time to move anything once you enter?

That's it for today! A lot of words, sorry, but I hope they were interesting ones!

Update 4

All the work I've done today has been programming, so this is going to be a dry update. I've made good progress today, but don't have anything visually exciting to show off. 

Today's job was to start implementing that flowchart I made yesterday. A lot of the flowchart's work will be done by the Control object, which will process the result of the player's last turn and decide how enemies will move, which doors need to be opened, etc. The turn-based part is controlled easily with a yes/no variable which the player character and the Control object look at to decide if they can do anything yet.

Since I already had keys and doors prototyped, I worked on getting the Control to keep track of keys.

The above is for when the room the player is in starts. The Control looks for all the instances of square keys and dumps their data in a big horrible array. This does not feel neat, but it's preparing for when I implement a save state. When the player saves their progress, I want this array to update itself with the present coordinates and status of the keys, so that they can be put back how they were when the player loads state. (This array is initialised elsewhere, and it's 384 elements long. This is the maximum amount of keys that can fit into a 16x24 puzzle room, assuming there's nothing else in the room. I just want to be prepared for edge-case scenarios.)

Then I implemented the beginnings of the Control turn, where it goes through the keys and checks if the square doors should be opened. This is some of the most difficult programming I've done so far, and I got stumped for a while. To help myself get to grips with this, I wrote down what I wanted to happen in plain text:

(if you're curious, "new 1" is a personal statement for a job application and gostak-dictionary.txt is my notes for The Gostak, a great text adventure I started a week or two ago that's like a cross between reading Jabberwocky and being concussed)

Writing down the logic I needed to follow turned out to be a huge help! I recommend trying this if any other game jammers are having trouble with coding. if I think it's probably the same principle as the Rubber Duck method of troubleshooting, where just talking about what you're stuck on helps you realise what you've done wrong.

Here's what that text looks like in Game Maker Language, with a few tweaks on the fly:

I'm being VERY careful with commenting my code this time. This is going to get messy if I add other types of key - I'll have to optimise this into one template function which can read a type of key and figure out all the variables and objects it needs to check. For now, though, it's fine.

Programming this was scary because it's a lot of work without being able to test it until you're done. But I'm pleased to report there were only two bugs with this that I noticed! The first was a fatal error related to the big horrible array which I fudged a workaround for... but in writing this post and looking through the screenshots I took, I've just figured out what I did wrong:  line 14 in the first screenshot above misspells "square" as "sqaure." Oops. I'll fix that tomorrow. There's probably other bugs relating to the array and how it stores data, too but I won't find them until I'm handling save states.

The second bug is that when you restart the room, you stop being able to collect keys. I haven't fixed this yet, but it's something to do with Control being a persistent object, an object which sticks around when the room is changed or restarted - I think a second Control object appears when the room restarts, and the two Controls get in the way of each other. (Unchecking the "persistent" box for Control fixes the bug, but I want it to be persistent because I want it to eventually handle music as well without restarting the music whenever the room changes.)

That's basically everything so far. Thanks for reading all the words - if you're more of a programmer than I am, I hope it's interesting reading how someone less good at coding solves problems.

Thank you!! I hope it actually works!

Aaa thank you for the offer!

Wow thank you!! Please do not learn at my feet, I have no idea if anything I'm saying will work!

Update 3.5

Very little progress today! Busy working on my CV and job applications.

I realised I don't really have a clear idea of how I want to structure the core game loop. So pretty much all the game jam work I've done today has been planning game states on a flowchart:

I think when the player moves, the initial collision checking is just to check if the control phase needs to do something. For example:

- player picks up key
- that key's "collected" state is switched on
- enemy objects move
- the game checks all the keys: all "collected" keys get moved offscreen, and if all keys are "collected", the game makes a note for when it moves on to checking if the doors need to be opened

This flowchart needs refining a bit (here, the player can die when a door closes on them, but the player needs 2 turns to move to the other side of a 1-tile-wide door - that means fewer opportunities for puzzles which require precise timing, so that idea wants tweaking). But it gives me a stronger basis from which to work. I have a better idea of what code should go where, and how to control the player's movement.

Boy, I have a hard time with programming. I get why some aspiring game devs just want to be idea guys.

I spent my free time replaying The Talos Principle instead. I'm going to pretend this is game jam research because the Talos Principle does something that a lot of great puzzle games do - its puzzles are based on consistent sets of elements, and solutions come from figuring out the implications of these elements. Like how a cube hexahedron can weigh down a pressure plate, or act as a platform or a stepping stone, or block a laser beam, or slow down the player's movement. DROD does this better than any other game, I think - every element has some kind of logical interaction with almost every other element which you can either intuit or experiment with ("if my sword can reflect the aumtlich's laser beam, maybe I can lure an enemy with a sword  to stand in the right place to reflect  it while I do something else on the other side of the room...") With as a strong and varied a library of game elements as DROD has, there's so many opportunities for puzzles to test spatial reasoning, lateral thinking, and so on. I don't think I have the time to implement many different game elements, but I'd love to get a few different ideas working in Arcane before I have to knuckle down and get the game finished.

Also the Talos Principle does my favourite thing in puzzle games, which is puzzles that completely disregard the structure of the game and force you to think outside of the box. No one solved that Sphinx puzzle by themselves.

Okay, more progress tomorrow, I hope. I have to get back to writing a personal statement explaining why I'm suitable for a job I'm unsuitable for.

Thank you, J! (My icon is the rabbit character in TeeKO, objectively the best character)

That's a helpful link, thanks for finding it! It looks like "offset" was the word I was looking for, not origin. I think I'll ignore getting rotation to work for now while I work on other bits of the game, but I'll come back to this later!