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.