I Want to Make a Puzzle Game: Not a Guide

Started
Published
Last updated (Update 5)

I want to make a puzzle game.

This is not a guide.

Why

Aliensrock and Patricia Taxxon.

Aliensrock is good at puzzle games, and his videos showed me how deep and interesting puzzle games can be.[1] One of Patricia Taxxon’s videos[2] made me aware of Microban, which I have been working through in an incredibly slow and abortive fashion on Sokoban Online. I’ve only done twenty-six of the puzzles at time of writing.

My inspiration came to a head when I watched Aliensrock’s video on The Electrifying Incident. The Electrifying Incident is a mini-sequel to A Monster’s Expedition, which is logically a masterpiece because it got someone who is good at puzzle games to play it for dozens of hours.

Here, listen to the unused-in-the-game-but-used-in-the-video soundtrack while you read:

The video was good,[4], but it was Tyler’s[5] negative review in the comments that really got me thinking, particularly this part:

I’m just fucking sick of plain boxes, man. To me, they represent the most soulless lack of creativity imaginable. Why play puzzle games for creativity, curiosity, or mystery when you could instead roleplay as a warehouse worker? Boxes are fine if they’re purely supplemental to the actual mechanics of the game, like in so many great puzzle games I’ve played, but trying to squeeze depth out of the box itself is infuriating. We already know how boxes work, they suck.

If you’re making a puzzle game, try this thought experiment for fun: remove boxes from your game altogether. What happens to the game then? Does it still work? Can the box be replaced with something more interesting, like a cylinder, functional sphere, or anything that behaves uniquely? What new consequences could possibly arise from this change? Challenge yourself to literally think outside the box.

…

But man, it sucks that lately, so many good puzzle designers have been caught up in pretending that there’s still “novelties” to be found with the box, when it’s all just mental reskins of concepts already fleshed out in existing games.

It made me realize that there’s so much to explore in this space, and that I could possibly make something that people want to play.

I then spent about three and a half hours writing a Sokoban solver in Guile.[6] Today, I changed the board implementation to an immutable handful of bitboards, which inspired me to make an extremely simple game engine that does input, undo, and restart for free.

I can play Sokoban in the terminal now. What a revolution!

Now What

This blog post will be updated eventually, success or failure.

Maybe I’ll make something great, maybe not. Either way, it’s going to take time and practice, so I’d like to have some kind of record to reflect on.

Update 1

April 30, 2025

I made a proof-of-concept Sokoban player with 3d graphics and undo in Godot, which thanks in part to my aforementioned sokoban implementation experience, only took about 90 minutes. Bodes well, but as I said in a chat message:

i’m glad that that was as straightforward i hoped

because EPIC SAD PLOT TWIST the hard part is making compelling, unique, and deep mechanics along with dozens of well-designed levels

Still good, though. My main takeaway is that using a game engine[7] is an unshockingly good idea. Just having vector types that work with everything is a huge boon, and I haven’t even used UndoRedo! I’m a Godot fan. And I even use GDScript because I’m such a stand-up, pragmatic guy!

End of update, I suppose.

Update 2

May 1, 2025

The Sokoban proof-of-concept is complete! It’s got over 150 levels. I didn’t make a single one, though, I just plugged in the aforementioned Microban 1 by David W. Skinner.

I’m slowly synthesizing stuff, but ideation is unpredictable. I don’t know. I don’t expect Baba is you-level conceptual genius, well, ever, but I still think I can make something decent and original.

Then again, A Monster’s Expedition is a simple concept explored impeccably. Doing things impeccably is kinda hard, though.

This whole puzzle game thing is kinda complicated, huh?

Update complete.

Update 3

May 3, 2025

The game has mechanics now! Like, it’s not sokoban. Here, just watch this video:[8]

Everything is very much in flux, but things are going places![9] Basically, balls[10] have a “logical velocity” lvel that moves when time does. But you, the player, can move and push to your heart’s content, only advancing time when you press a button. This is a lot of freedom, which is kinda contrary to the positioning-centric gameplay I vaguely had in mind, but I think this can be interesting.

With good level design.

Oh gosh.

Update 4

May 4, 2025

Great update!

Instead of writing levels in text, which is fun but clunky and limited, I am now editing them as scenes directly in Godot. I’m just snapping to the grid, which works well enough for my purposes.[11]

But all of that is irrelevant!

Because I enjoyed playing the game!

Here’s the story: I made a tiny change to make balls reflect off walls.[12] I then played around in the existing levels, and I—wait, what? I played around. I now know that the emergent complexity is interesting to more than zero people because I had fun.[13] I am very happy about this, but let me restate something for the umpteenth time:

Amazing level design is critical.

But hey, I feel now that with a few hundred hours of work, this could be decent. I couldn’t say that before today.[14]

Update 5

May 6, 2025[15]

First, video:

So, the game looks good! Like, visually. I am especially proud of the sun moving with time. Like a sundial!

The arrows help convey the subtle-bordering-on-bizarre mechanics, which I’m happy with. You can see some updates mid-step in slowmo. Slowmo is sick, but it makes things real challenging—interactions have to hold up under close scrutiny or they’ll just be confusing. It helped me discover that a ball colliding from the left is different from colliding from the right. It’s consistent (I sort the pieces before stepping) but bad and confusing.

For that reason, am going to, one, plan out the mechanics so that they are less dumb while still being interesting, and second, I’m taking a break for a little over a week.

I’ve really been enjoying working on the game, but it’s a big distraction (and I hurt my hand a bit).

I’m looking forward to returning with renewed energy and passion to make things consistent before I start on the big work: level design! I’m thinking of making a graph of concepts—quirks of the mechanics—and their dependencies, and making levels that explore them.

  1. No, I haven’t watched most of his mega puzzle game playthroughs, but their length and the parts I have watched were enough. ↩︎
  2. No, I don’t remember which one :P ↩︎
  3. Pun acknowledged ↩︎
  4. Like, shockingly[3] good. The editing for the few of Tyler’s puzzle game videos that I’ve seen has been great, but this flawlessly mixed the narration with sped-up gameplay unlike anything I’ve seen before ↩︎
  5. I don’t know the guy, but I’m so sick of writing Aliensrock; it sounds unnatural ↩︎
  6. By implementing Dijkstra’s algorithm and a terrible priority queue! ↩︎
  7. Just for the record, I am aware of PuzzleScript and have been checking out some of the games on there. It’s a really cool engine! Good for protoyping, but I want to do stuff that I can’t do in PuzzleScript. Y’know, push the mold or break the bleeding or whatever ↩︎
  8. I’m moving around weirdly to try and show things off (and pretend like I don’t know the solutions) ↩︎
  9. The code is already getting pretty bad ↩︎
  10. Look, Ma Aliensrock, no boxes! ↩︎
  11. I offset the pieces by half a meter so that they are in the center of the grid squares, which is hacky but not overly so I hope ↩︎
  12. The actual change is one line ↩︎
  13. Perpetual motion is possible at this phase of development. Cool endgame trick? ↩︎
  14. It’s worth noting that I write these updates at night, which often goes past midnight for me. It’s technically May 5th for me. Deal with it ↩︎
  15. I worked on the game too late and had to write this the next day :P ↩︎