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!