Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Nov 26, 2016 · View creator page →

Creator of

Recent community posts

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.

(1 edit)

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:

pressure plates

experimenting with odd room layouts

unfinished room

aw heck

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:

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:

title and level select

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:

level 1

level 2???

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:

arcane so far

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.

blocks that matter

so many blocks

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.

testing new blocks

Why, yes! Graphic design IS my passion!

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:

logo drafting

logo so far

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:

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!

save state testing

ShareX thinks my mouse is about 50 pixels to the left of where it actually is. I'm clicking on the save and load buttons here.

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!

Update 3

I gave up on getting blocks to rotate for now, and started working on other things.

I think I want the player to collect things in each puzzle. So I've been drawing gemstones this morning. Here's a quick puzzle room I threw together to show off how the game is looking.

(I don't know why ShareX thinks the mouse cursor is that far to the left. I'm clicking on the blocks, I swear.)

The big red gemstone is the goal of each puzzle. For now, collecting it just resets the room. I've also added little green square gems that essentially act as keys - collect them all to open the doors marked with a square. The doors lose their collision mask when opened, so that you can put blocks where they used to be.

I also added the beginnings of a sidebar menu. Only the reset button does anything, and it just restarts the room for now.

The Save State and Load State buttons are for an idea I've had. I want the player to be able to save the state of a puzzle anywhere while solving it. To do this, I think I'm going to have the game save the coordinates of each item in the room, and restore them when the state is loaded. This means keeping all the objects in play somehow, so that when you restore a state the game doesn't crash trying to find the coordinates of an item which has been destroyed. To avoid this when I try to implement this, when you collect gems, they're not actually collected - they just get moved way offscreen where the player can't get them. This feels dumb, but it seems to work!

I've spent most of my time since this doing programming grunt work. I want to get a control object which can keep track of every significant object in a room, so that I can have it run most of the scripts in the game. Right now, keys and doors are completely separate, and the door has to keep checking every frame to see if it should open. I want the control object to keep track of both keys and doors, making it easier to run the door opening script only when needed. So I started on that this afternoon, also setting it up to save object data for the save-state thing I want to do. It'll probably be another day or two until this is all up and running!

I've also done some work on sprites and music whenever I got bored of the coding, but none of that's ready to show off yet.

Update 2

Did some more work on moving blocks. Now they snap to the grid, it's obvious when they're being carried, and they won't be placed on walls or other blocks.

good block movement

by the way, the floor is a little prettier because I got bored and redid the floor bg

Obstacle detection tripped me up. I wrote code so that a block couldn't be dropped if there was a block at that point, but it kept detecting itself and refusing to be placed. Tip for Game Maker devs, if you're using position_meeting for collision detection and your code isn't working, try using place_meeting instead - that's the one that checks collisions for your object instance rather than a single point.

The next step is to rotate blocks. When the player clicks the right mouse button while holding the block, I want to rotate it by 90 degrees.

I'm completely stuck now, though. When I rotate a block's sprite, the collision mask changes in a way that doesn't match the rotation but which I can't figure out. Like so:

block rotation mistakes

I don't know why the player character is blinking in these GIFs - I don't think she's doing that in the actual game?

I suspect the sprite is rotating around the origin point incorrectly, or that the mask is cut off by the changed dimensions of the rotated sprite. The origin is in the top-left corner of the unrotated sprite, which is why it moves so much when it rotates.

But I can't figure out how to fix it. I can't find any helpful documentation or tutorials online, maybe because they're focusing on I could make separate sprites which are the original sprite rotated by 90, 180 and 270 degrees and change to those, but then I'd have to do that for every single type of block, and write arrays for each block to read to figure out what sprite to change to next. That doesn't appeal to me.

The simplest solution would be to not let the player rotate blocks. That would be fine, and probably easier to design puzzles around, but it's not quite as exciting. I'll sleep on this, and if I don't get any ideas, I'll just cut out block rotation press on with developing the rest of the game.

(1 edit)

Hello, my name's Alex! I'm here to make a game and have a good time!

This is actually my second game jam, because I participated in the Winter 2018 My First Game Jam. But I didn't complete it because my computer broke. I'm hoping to use this jam to relearn my way around GameMaker Studio and to learn a few new tricks along the way.

I'm going to do this by making a puzzle game!


I want to make an old-fashioned puzzle adventure game, like DROD or Chip's Challenge or Adventures of Lolo. Games like this appeal to me because they're full of ideas and full of personality. I think the top-down character control of these games will be easy enough to program from past experience, and easy to build on and extend.

I'm calling my game Arcane for now. This will be an occult-themed turn-based puzzle adventure with a block-moving gimmick. The player controls a character with the keyboard, Chip's Challenge-style, but can rearrange certain blocks in the room with the mouse, to clear or block paths, weigh down switches, etc. I'd like each level to be an assemblage of individual puzzle rooms as in DROD, so that levels can be easily rearranged and puzzles can be swapped in or out, and so that the player can tackle puzzle in a non-linear order.

(People who were around for My First Game Jam Winter 2018 might remember me doing something similar last year. I made most of the battle system for a puzzle RPG I wanted to make, which also involved shuffling blocks around. I still want to make that, but I think the programming I've done needs to be redone from the ground up, since it's very patchwork, borderline unreadable, and impossible to extend without breaking everything else. This game is being coded from scratch using a different way of handling blocks - perhaps I'll learn something from this which I can bring into the puzzle RPG!)

Goals (in rough order of what I want to do)

This is the minimum I want to accomplish to make a functioning puzzle game:

- Get a character moving around a room and colliding with objects and walls
- Get a system of picking up and placing blocks and objects with the mouse working
- Get the character-moving and the block-moving working together (e.g. make sure that the player can't place blocks on their character)
- Add an objective for the player (I haven't decided what yet - collect things? Reach a goal tile?)
- Add a simple enemy type, whose AI is integrated into the turn-based system (probably nothing more complex than "is the player in Direction X? If so, move in Direction X")
- Add one or two other basic puzzle elements (e.g. floor tiles which blocks can't be placed on)
- Build some basic puzzles
- Make a nice HUD / menu

Once the basic game is functioning, if I have time, I can work on some bonus features:

- Make the player able to move from room to room
- Add some extra puzzle elements as I think of them
- Add some simple NPCs (nothing more than walls with dialogue, really)
- Make pretty tilesets and scenery objects
- Make some good tunes to listen to while the player solves puzzles
- (advanced) Get checkpoints working so that the player can save progress in a room and doesn't have to start over if they make a mistake
- (really advanced) Figure out how to save games! If this idea is good and I want to make a full game out of it, I want to know how to work with save data


First big decision is how big to make the game screen. I want to have a main window where the puzzle lives, and a sidebar to display game information and menu options. This suggests that a widescreen ratio would be best, so I'm working with a resolution of 640x360 (to be blown up to 1280x720 when you play, so that you're not squinting at the screen).

Normally you'd work with 32x32 sized tiles in Game Maker and other applications. Here, I'm working with 20x20 tiles. This allows me to fit more puzzle space onto the screen - my puzzle window is now 24x16 tiles, leaving space for a border and a sidebar. The small tile size lends itself to simple chunky pixel art, which is probably good for making the levels as readable as possible. You can't divide a 20x20 tile as neatly as 32x32, but because everything in this game is going to snap to a grid, that shouldn't be an issue.

With this decided, I made a little player character to control.

Player character screenshot

here she is!

I want an occult theme for my game, so I made the PC a black cat for now. The sprite is 20x30, with a 20x20 hitbox, so that the top of the PC's head overlaps the tile above without colliding with it. I've done this because I think it looks neat.

Next step was to make the PC move. I've forgotten how to code in Game Maker, so the programming here is not so good, but here's where I ended up:

PC movement

there she goes!

The game adds or removes 20 pixels to the PC's coordinates depending on what you press, so that she stays snapped to the grid. You can use WASD or the arrow keys here. (Something I need to think about is how to set up different control schemes or let users define their own controls, since I know that WASD doesn't work for every keyboard!)

Walls next. Wall obejcts are just big purple rectangles in the room editor .The game canels your control input if your move puts the PC on a wall. I tried using tilesets here, a skill which I've never tried in Game Maker without a tutorial; I made some simple wall sprites which I painted over the top of the actual walls.The game looked like this when I was done:

PC wall collision

This looks surprisingly pretty, imo! The advantage of tilesets seems to be that you can add extra sprites and make your levels look fancy while keeping the number of objects to check for collisions with low. My main concern is that if I use a lot of tilesets at this early stage, it'll be more work rearranging levels when I need to test something. I ended up removing the tiles for now, to be put back when I've built the engine up more and can start thinking about puzzle design - you'll see the base purple walls in the next GIF.

The PC is functioning. Time for blocks.

In my last game jam project, I did a puzzle RPG battle system about moving tetrominoes to match a larger shape as closely as possible. Each tetromino was generated from individual blocks whose coordinates were stitched together into an array representing the entire tetromino. This allowed randomisation of tetrominoes, reduced the number of sprites and objects I had to code, and was good for the shape-matching system I created, but the code was dreadful to write and read. I commented it as well as I could, and I still don't know how it works now.

This game will require hand-crafted puzzles rather than randomisation. So this time around I'm going to make block shapes individually. This will mean a lot more sprite work, but the game engine isn't complex, so the code should be far neater. In fact, I can set up a basic block as a parent object, and all other blocks as children no matter what their shape is. It also allows me to expand the types of puzzle possible in this engine - for example, locks could be sprited as jigsaw pieces to make a picture.

I've started with a basic 1-tile block, which will carry the code that all other blocks inherit:


Most of the sprites in Arcane are flat saturated colours so far, so I think this greyscale gradient is an interesting contrast. Hopefully it'll be easy to spot in a busy puzzle room.

I coded a state machine for the block that tells it whether it's being picked up for stationary, and a state machine for the PC that tells her whether she can move or not. Clicking on a block picks it up, and disables the PC until the block is placed again. Thinking about it now, this probably should be one game-wide state machine rather than individual state machines talking to each other. But I worry if if I try to do everything in one state machine, I won't be able to disambiguate between blocks (that is, if I try to pick one block up, all of them end up moving).

Right now, all that happens is that a moving block sticks to the mouse until you click again to place it. The result looks like this:

block movement

i'm not sure why the cursor is so far away from the blocks in the recording.  You click on the blocks directly to move them. Also no tileset anymore in case I need to rearrange the walls for testing later

It's clearly unfinished - the blocks don't snap to the grid and don't collide with anything. But it's a start!

There's another problem with this, actually. Clicking on a block seems unresponsive - it feels like it takes a quarter of a second to register (whereas moving the PC with the keyboard feels much quicker). Perhaps this is because the block is using precise collision checking, which checks the sprite exactly rather than using a hitbox. (This is an investment in later collision detection with more complex block shapes, where using a simple hitbox won't do the job right.) Or perhaps it's because the code for picking up blocks is a twelve-car pile-up of if conditions.

I think I might be the coding equivalent of those people in infomercials who throw bowls of popcorn all over the floor and turn to the camera like "there's GOT to be a better way!!!" Anyway, I'm worried about how slow it feels to pick up blocks, but once they've been picked up they move around responsively. And it's only a turn-based game, so it's not like any lag spikes are going to trip players up. But if it gets significantly slow, I'm going to have to rethink the engine a bit.

Anyway, that's where I'm at, 8 hours into the game jam! So far so good!

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

Hello! I'm Alex! I just finished a PhD and now I'm unemployed!

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 did the jam before last (Winter 2018), but I got stopped in my tracks when my computer broke. That shouldn't be a problem this time?

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

I like puzzly games like Deadly Rooms of Death, which I'm planning to take inspiration from (rip off) for my game jam entry.  Undertale and Night in the Woods are other big favourites - I love the personality that comes through in their writing.

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

I've poked around a few different engines, but GameMaker Studio 1.4 is the one I'm most confident with currently. I used it for my last game jam, and I'll most likely use it for this one too.  

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

Right now, I'm getting back into books! I don't read as much as I feel like I should, so I've started reading some old classics. Just finished Les Miserables, which is  a brilliant story and a fascination exploration of just about every facet of French culture and history in the 19th century, but also really damn long.

6. What are your goals for this game jam?

Get something working! I'm aiming to create a game engine which I can build on easily, even if I don't end up with a complete game, and I'd also like to learn how to work with save data in case I want to expand my project into something long-form.

7. Any advice to new participants?

I'm not a very organised person, but I found that keeping to a schedule helped enormously - setting aside a couple of hours a day to implement something helps you feel like you're making progress. Also, even if you're really shy like I am, making a devlog is a good idea. The community was really kind to me during my last jam!

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

Nothing I can think of!

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

For My First Game Jam Winter 2018, I started making a puzzle RPG prototype. I never made much more progress than this, because I ended up having kind of a stressful 2018, and now I want to start from scratch because the code is difficult to extend and leaves a lot to be desired! Hopefully what I learn from this game will feed into my second attempt at this.


I got a new laptop a few days ago, but between catching up on my actual work and  the family dog getting very ill (he's recovering now!), I haven't had the time or inclination to get back to my game or get stuck into everyone's submissions. Things are settling down now, so I want to write a quick post-mortem of my failed submission to get myself back into it!

Puzzle Wizard was an attempt at a new type of Puzzle RPG battle system using Tetris blocks instead of match-3 gameplay. I tried to assemble the prototype in GameMaker Studio, because I'm most familiar with that engine from tutorials (in comparison to Unity, which might be better for developing a full-scale game out of this but which I'm far less comfortable in). I had to put the project on hold because of technical difficulties, but I got enough done to have a sense of what I'm proud of and what could be better. I want to use the post-mortem here to talk about a couple of the challenges I faced during development.

Programming / coding

This game was programmed in GameMaker using a combination of its drag-and-drop events and code written in GameMaker Language (GML). GML doesn't seem like a hard language to pick up, relatively - it looks a lot like Javascript, and the help files for GameMaker are really good - but I'm not a natural coder and I had to figure a few things out as I went along.

In that respect, I'm really happy with the programming work I did. I've had this idea for years and put it off because I didn't think I could program it, but the progress I made in the last couple of weeks is a huge confidence boost. I'm particularly proud of my ability to solve problems using what little I know about programming. For example, the target shapes that the player must match to attack the enemy are stored as 64-character strings in each enemy type, and built character-by-character as they are required. There are probably more efficient ways to program this, but building it this way allows me to write the shapes for different enemies directly in a text editor without extra programming, and I'm quite pleased with myself for this.

However, being a novice at programming comes with two major pitfalls. One of these is debugging, which I am not good at. I spent a whole afternoon searching the wrong function for a mistake which stopped it working (the REAL mistake was that another function immediately over-rode that one in the same frame, causing no visible results and no error messages). I'm sure every programmer has frustrating moments like this, but it's something I need to get used to. The other problem is code organisation. My project is a mess of scripts and functions jammed in wherever they're most likely to work. I'm commenting and rearranging as best as I can, but I think an actual good game developer would take one look at my code and scream and scream and scream.

I think my biggest takeaway here is that programming is a skill which I'm still learning. I know a lot of basic programming theory from all the different tutorials I've taken, but those are tutorials at the end of the day. I can learn how to play Fur Elise perfectly on the piano, but that's not the same as learning to play the piano. Similarly, I haven't actually learned how to code yet, but I'm getting there. I still need to learn strategies for debugging and code organisation, but I will get better at this. I hope.

Working as an individual

In this game jam, I worked solo. This is because I want to pick up on a lot of different skills as a game developer, and taking on a few different roles proved to be quite fun. I enjoyed being able to work on art or music as a break from programming. I guess the problem here is that my art isn't really very good, though many of you seemed to like it (and thank you for saying so!) - I worry that the full project may get to a stage where I would be better off hiring an artist for characters and backgrounds especially, but I'll cross that bridge if I come to it.

I also enjoy having complete creative control over my idea, at least for now. That sounds like kind of a jerk thing to say, and I want to stress that I'm not opposed to working in a team (there are some really good submissions in this jam by teams!) - it's just that if anyone is going to ruin my game, I'd prefer it to be me.

I think the big problem with working as an individual is that even a small scale game can feel overwhelming if you're doing everything yourself. I definitely didn't expect to get as far as I did in this jam. I really liked having this jam as an unofficial support network, and I found your compliments really motivating. Thank you all so much.

What next?

I plan to keep trying to develop Puzzle Wizard. I want to finish developing the prototype as outlined in the original post (minus the elements idea, which I now think won't read well with the differently-textured blocks) , and maybe take the extra time to spruce it up a bit before publishing.

Battle system

My big idea for the puzzle system is still to have enemies attack with miniature logic puzzles, which would be randomly generated. This is a huge challenge to me right now - it's going to mean coding a variety of logic puzzles, coding a generator for each of these which will always return a solvable puzzle, and being able to generate these on demand in the middle of the battle system. This idea could also be bad from a design perspective, as when you have a variety of puzzles to do, there's always going to be a few types you hate, and having to fight, say, 20 bats with 20 Kakuro puzzles will be torture for some. I hope I figure it out as I go along. Before that, I want to be sure I can actually code the thing first.


As for the game outside of the battle system, I have two big ideas to choose between for my dungeons/field screens.  The idea I'm favouring is to make dungeons in the style of the Professor Layton games: a little web of single-screen environments with hotspots you click on to find puzzles and monsters you click on to battle (there'd be no random encounters). Puzzles would be larger-scale logic puzzles and pictoral puzzles (like spot-the-differences and mazes); simpler puzzles would bar progress through the dungeons, and more complex puzzles would lead to items and bonuses (so that the player doesn't have to, e.g., spend two hours on one Killer Sudoku just to get a step closer to the endgame).This is easy to code, I think, and makes the puzzles the focus of the game. But since there wouldn't be much gameplay in the dungeons themselves, the art and writing might need to be very good to compensate.

On the other hand, I could make top-down dungeons in the style of Earthbound or any other SNES RPG. If I do it this way, I think I would actually crib from the Deadly Rooms of Death series  of puzzle dungeon crawlers. What I love about DROD is how it brings all sorts of elements of dungeon crawling into its puzzles - you usually have to manipulate the monster movement to solve puzzles, e.g. baiting a monster towards you so that it blocks the path of another monster trying to escape. I'd love to do something like that, but this is another level of complexity on top of what's already quite a big coding project, and I also think switching between keyboard-controlled dungeons and mouse-controlled battles would be a pain.


I haven't discussed story at all in this devlog, because I haven't worked it out to a degree that I'm happy with yet. The basic concept (at the time of writing) is that the player character will take part in a series of wizard duels with a ranking system, cribbed from No More Heroes - dungeons and the puzzles within them are designed by the bosses of those dungeons, the wizards themselves. This offers great opportunities for characterisation and humour, by placing something of each wizard's personality and history in their puzzles and their possessions. (This aspect is wholly inspired by Undertale, in which boss characters inform their sections of the game to fantastic effect, e.g. building a friendship with Papyrus before facing him, or learning about the anxieties and fears of monsters before facing their champion Undyne). I'd like the wizards to be inspired by high-fantasy archetypes, like Gandalf-type wizards, necromancers, etc., but I'll happily throw this out for a really good boss idea. 

Executive summary

Gamedev is fun, coding is hard, thank you for supporting me, I hope I do the gamedev well!

I think it's just that some people are crunching and other people have to quietly drop out of the jam - I wouldn't worry about it. Your game is shaping up very nicely! I think the colours are fine - I can't think of a good palette that would be both readable and breakfasty, anyway.

aah thank you! Can't wait to get back to it!

Thanks! I'm sorry I might not get a playable prototype going now because my computer just broke, but I'm glad you like the look of it! I'd love to extend the battle system with blockout squares like you suggest, or squares that can move.

(I have some vague idea that the Boy is going to be a boss battle when I start adding a story to the game...)

So there's been a small technical hitch: my computer seems to be broken. It looks like the mandatory Windows 10 updates finally claimed my laptop. I'm doing my best to fix it, but I don't think I'll be able to work on the game any more before the jam is up. Really sorry!

Still, at least I was forced to stop, rather than giving up myself. What I really wanted out of this jam was to get more comfortable with writing code and problem-solving. I think I managed that in  the last ten days. I'm very proud of what I've made so far and I regret that I may not get a chance to show it off properly (depending on how fast I can fix my laptop or buy a new one).

I backed up my work yesterday, so I haven't lost any progress. I'll keep working on Puzzle Wizard when I can. Thank you all for being such a supportive community! Hope I can get back to this before the jam closes!

Congratulations on getting your game playable! Your level design is very good so far - it eases you in, but Floor 7 still caught me out. Well done, hope the rest of your level design goes smoothly :)

I really love the whole look and feel and idea of this game, and I keep meaning to tell you that your devlog is enormous fun to read through. Good luck on getting it done, it's looking really good so far!

Update 08

I took the day off yesterday, so I wanted to hit a big milestone for this update to make up for it. Today, I got damage calculations working.

The calculation takes a base attack stat and multiplies it by a number based on how much of the shape you filled and a number based on how much time you had left in that round. I forget exactly what I did because I kept fiddling with the maths until it felt okay, but you need to fill in most of the shape to do any worthwhile damage. If you fill in every shape but one, you get a x2 multiplier, and if you get an exact match, your damage output is boosted like crazy:

Other changes since last time:

  • There's a Defend button now. It doesn't do anything except skip the player's attack for now, but when I implement enemy attacks, it'll be useful. Mostly, the Defend button is there to help me build a command menu structure which can disappear and reappear.
  • The tetrominoes for this turn show up in the battle menu now. The idea is that if the player can remember what the enemy's target shape is (there's the game jam theme!!!), they can decide whether it's worth attacking or whether they'd be better off defending. It's not going to be balanced in this prototype - I'm pretty sure it'll always be better to attack than to defend - but it helps me pin down the gameplay loop of the battle system.
  • Enemies support multiple possible target shapes. You don't see it in the above GIF, but Dragonman has an alternate shape that's the mirror image of that one.
  • Blocks have different textures as well as colours. I don't know if they're the most colourblind-friendly or readable, though, and I'm not happy with some of them. They'll do.
  • That big red bar is the player's health bar, which might do something later.
  • Enemies are now front and centre, in proper Earthbound-like style. I'm very happy with how that placement looks, and the big black square behind the target shape makes the battle screen still readable. Plus, putting the sprite there supports extra-large sprites for bosses.
  • I found the option in GameMaker that makes large sprites look terrible and turned it off. Everything's a lot crisper now.

We're now in the last few days of the game jam, so it's time for me to think about finishing this off. There's a few odd glitches and imperfections I want to fix as well, though. Below, I've written a list of what I'd like to get done by Friday, in order of priority. This is just me thinking out loud, but I thought it might be nice to show the state of the project here:

HIGH PRIORITY (need these done before I submit):

  • Finish off the core battle loop: allow enemies to attack, implement player damage and time-up scenarios, allow victory and game over states
  • Put enemies in the title screen so that the player can choose what to fight (at least two to demonstrate the battle system)
  • Make a how-to-play / about / credits screen

MIDDLE PRIORITY (highly desirable):

  • Implement the music and sounds I made
  • Intelligent snapping: keep tetrominoes within the playing area, and stop them from overlapping
  • Better rotation and placing: the blocks lag just slightly behind the mouse so that when the player clicks to rotate or place, they might not click on the block, which could be frustrating when the player is against the clock

LOW PRIORITY (not really necessary but they'd be nice to do):

  • Some way for the enemies to show damage (a health bar would be easiest, but damage sprites like in Mystic Quest would be much more fun (also I forgot how wild it is that the tutorial monster of that game can score a critical hit and murder you))
  • More sounds
  • Better backgrounds
  • Particle effects for Maximum GameFeel
  • Maybe remember to remove the Refresh button before I publish

Sorry for all the text - thanks for keeping an eye on my devlog! Here's one more GIF of a secret bonus enemy I made a few days ago just to push the battle system:

Oh this idea rules! It's like those programming puzzle games except you don't have to set several dozen commands up front. Hope it goes well!

Update 07

Quick devlog tonight - it's beginning to come together!

The string setup works! I now have a simple way to make target shapes for each enemy. That lets me make fun shapes like this Pac-Man ghost shape for the ghost enemy. I think it's probably easily extendable? I hope it is!

Getting the game to count how much of the shape is filled was the hard part, and the code that does it is a total mess of if conditions which has to read object names rather than what type of object it is. It works, though!

Also I tried drawing a little window for the enemy to appear in, but the more I look at it, the less I like it. It doesn't gel with the rest of the game. Oh well.

Thanks! I'm not shooting for the Earthbound style, but I think it's inevitable that it ends up in that sort of pixel art wheelhouse, which is fine by me. I'm obviously not an artist but doodling monsters in GameMaker is very soothing.

Update 06

I took the day off yesterday to avoid burning out, after struggling so much with programming the day before. Today, I decided it was time to take on one of the jobs I've been dreading: coding the actual turn-based battle system.

I have no idea how this is supposed to be done, so the first thing I did was sketch out a highly professional state machine draft on the nearest envelope.

And here's what I've managed to do so far:

The battle screen is fed whatever enemy type the player has encountered (just the bat for now) and harvests variables from it and the player's statistics. The player gets a menu, and goes to the state for whatever action they choose - just the attack option for now. I haven't built anything for processing player attacks yet, so that's as far as they can get. I won't go into all the details because the code is kind of a mess. Half of the states I've "implemented" don't actually do anything, because everything they need to do can be done directly in events run by the battle controller and menu buttons.

I quite like the idea of making the menu bar the attack timer - it just looks neat to me.

Also, it's not GIF compression or anything, the font really does look that bad. I'll have to tweak that.

Here's what the enemy variables look like for the bat:

I'm trying something a bit risky for building the target shapes for each enemy. I'm storing the shape as a 64-character string, which will be converted into an 8x8 grid by going through the string character-by-character. 0s are empty space, 1s will be one of the component squares of the shape. The advantages here are that it forms an easy visual way of building target shapes in code, and that I can implement extra types of target space square - for example, an X could be a square that must be avoided. The disadvantage is that I have absolutely no idea if this will work or not. Here's hoping!

Also, the bat's stats are just made up for now. I'll tweak those with playtesting, I expect.

One more big thing: I made a battle theme for the game! I'm very happy with how this sounds. This uses the free GenesiSF soundfont by The Eighth Bit.

Finally, I don't think he'll make it into the prototype, but here's a dragonman enemy I made:

Thank you! I'm glad to see you say that - one of the big reasons I'm trying to do frequent devlogs is to prove to myself that you can make a big project bit by bit even when you have no idea where to start. I'm very happy with how it's shaped up over the last week :)

Update 05

I wrote a very simple rotation system today, which doesn't actually rotate anything - all the block sprites remain at the same angle, but the component blocks of the tetromino are rearranged around whichever block you click. I've done it this way because a) if the block sprites are going to have shapes on them  so that colourblind people can read them better, they ought to look consistent no matter how the tetromino is rotated; b) I'm using the top-left corner of each sprite to align it to the grid, which is more intuitive to me than using the center, and rotating the sprite might mess with this; and c) doing it properly with vectors sounds like hard work.

Unfortunately, this simple system didn't work at first, so most of my effort today has gone into troubleshooting about seven lines of code for two hours. It always turns out to be some silly mistake I forgot when I have trouble with coding. As it turns out, my rotation code works perfectly (as far as I know), but it was being overruled instantly by the code which keeps blocks together while the mouse is carrying them around.

So here's what Puzzle Wizard looks like now:

As you can see, I'm thinking about how the game is going to be laid out now. I'm not happy with this yet, but I like the target shape being right in the centre. (I think each enemy type will have its own unique shape, though I probably won't get to make many enemy types before time is up.) Please excuse the placeholder boxes, they look much uglier than I expected.

(I've also made the target shape slightly larger than the grid - I think that little white border around a full target shape looks really good.)