Basics

Genre: Rhythmic puzzle game
Links: play it on itch or check out the code on github
Engine: Godot 3.5
Time Spent: May 15th - May 21st (1 week)
Other Stuff: The first few levels of the game are probably too hard. If you almost immediately get stuck check out “the game is too damn hard” below.

Gameplay video

No phones in sight just squares pulsing to beats

The game is about leading the little gray guy into a trap and then making it to the end of the level.

High level thoughts

I really enjoyed the process of building click, click, trick (which I’ll call ‘cct’ for the rest of this post). I made it for the week-long Pursuing Pixels James Jam Game Gam #2. It turns out building a game in a week is a whole lot comfier than building one in two or three days!

I chose to invest more time into the game’s feel than I have in previous games and I think it shows - cct (jank tutorial aside) comes off as more polished than my other games. I can feel myself growing and that’s really exciting!

Unfortunately I think I missed pretty hard on ramping the difficulty and scared away lots of players in the first few levels¹. There’s a good lesson there and I’m confident I can improve at the (very hard) skill of teaching players how to solve your puzzles. But I’m definitely disappointed - this is the first time that a game of mine has really underperformed my expectations.

The game is too damn hard

There are a few key mechanics in click, click, trick:

The movement mechanism
The little grey enemy that follows you around
The traps that kill you and the little grey enemy
The teleporters, which have an unusual “momentum” mechanic

I think the game does a fine job of explaining (1) and (2), an alright job of explaining (3), and a pretty poor job of explaining (4). (4) is easiest shown via some videos:

To make the enemy's sound here I reversed the notes from the player's sound.

On the left video you can see me moving into a teleporter and planning moves once I pop out the other side. In the right video the enemy is planning their move (“two left”) without knowledge that teleporters exist. Their first move carries them into the teleporter and their second move shoots them out to the left of that teleporter’s pair.

This system can lead to some funny gameplay!

I think that once you see this behavior it basically makes sense, but the game doesn’t do a good job of helping you see the behavior enough to internalize it - and so folks bail the first time they need to rely on it to lure an enemy into a trap and solve a puzzle.

I’ve got some ideas of how I could have done better here - likely by repeatedly reinforcing this “teleporter momentum” mechanic and potentially making it more likely to happen by accident. I’ll give it some more thought once the game has had a few days to settle (and I’ve had some time to read about introducing puzzle mechanics to players).

Juicing it

Game devs like to talk about “juiceness” - defined as “maximum responsiveness for minimal input.” Good examples are buttons that shake when you hover or snap when you click them, objects that react or change color when they’re hit, making a character’s eyes follow something relevant on the screen, etc.

So far I’ve felt like my games were pretty lacking in juice. This time I wanted to build something a little juicier!

My initial thought for cct was “what if I could build a game around a satisfying sound?” That idea came from playing Snapdash during Ludum Dare 53, which has a satisfying “snap” in its core gameplay loop. I started by messing around in Logic with an 808 drum machine until I had two sounds (the clicks and the pop that are on beats 2, 3, and 4 of the game) that felt really good.

It’s hard to remember exactly how I got to the final game (I remember at some point I was planning to have you buy traps between levels but scraped that before writing much code) but I think most of it flowed pretty clearly from “make everything move with the music²” - the primary ‘juice’ in the game, the pulsing on each beat, certainly did!

One other interesting thing is that I spent a bunch of time refining the (very simple) art / vibe of the game early on, before I had any gameplay other than a sandbox level. That felt really important because to me cct was about the vibe as much as it was the levels - and I think I wouldn’t have been able to see the game for what it was without consistent art.

Components before levels

One thing that excited me about building a puzzle game was that I thought I could build interesting components without thinking too much about how they’d slot into individual levels and then design a bunch of levels by coming up with interesting configurations of those components. So when building cct I started by just building every component that I could think of. Around day 5 of 7 I finished my last component³ and sat down to start building the tutorial and the levels.

My little sandbox, full of traps

My bet is that my process here was almost right, but that I went a little too hard in the “no levels, just components” direction. It definitely resulted in me rushing out some of the final levels (and maybe the tutorial?!) at the end, and it’s possible that designing some early levels could have informed my design of some of the later components.

Still - I found arranging a couple of simple components into a compelling level to be super fun (and kinda software-engineering-y). I’m excited to build more puzzle games.

Handling disappointment

This is my favorite of the 4 games that I’ve built and the most excited that I’ve been during a game’s development. I think(?) the core mechanic is novel and I’m proud of how the game feels.

So it was initially pretty hard to handle the fact that cct didn’t seem to be doing too well in the jam and that people weren’t really commenting on or reviewing it! I found myself obsessing a bit over what could be going on - was the game’s page too sparse and uninviting? Was the game too confusing? Did I just think too highly of it? (It’s probably a bit of all three).

A particularly hard thing was that I didn’t get any feedback from folks that played the game but didn’t rate it. It might have been easier to hear “this sucks because of reason X” a few times. I like to improve and to fix things, and it was frustrating to feel like I had a failure that I couldn’t learn from.

I’ve been trying to poke at and reframe that feeling in a couple of different ways. I’ve settled on a thing that could be improved about the game (a gentler tutorial that draws you in) instead of trying to find the thing. I’ve reminded myself that the comments that I have received have been very nice. And by far most importantly, I’ve tried to remind myself that I can see all sorts of ways that this is better than something I made a month ago, and that I’m proud of it, and that that’s the most important thing.

So I’ve got some useful takeaways after all! But I still hope that the next one does a little better :)

Avoiding burnout and staying consistent

I’ve told some folks that my goal is to ship a game every 10 days or so. A careful observer might note that Don’t Send me a Puddle shipped a whole 20 days before click, click, trick. So, uh, what’s up with that? A few things!

I worked basically nonstop for 3 days for Don’t Send me a Puddle and needed a break
I started work on a tower defense, but paused that to participate in this jam
I visited my parents for a few days to help them do some chores because I’m the world’s best son

I stand by all of these decisions! It was really important to take a quick break and it was great to visit my parents. And I’m excited to go back and finish up my tower defense.

But I was also a little anxious about not having shipped in over 2 weeks! And I think it would have been easier to ship something sooner if I hadn’t worked so hard during the last game jam.

I believe the most effective way that I’ll be able to improve in the next year is by consistently shipping games, and I think that 3-day game benders probably interfere with that consistency. That doesn’t mean that there’s anything wrong with the occasional one - I love to work obsessively - but it’s certainly something I’m keeping in mind. Maybe I’ll stick to week-long jams for a few months :)

Wrapping up

That’s about it! I’m really proud of click, click, trick - and I’m really excited to wrap up my tower defense and share it here too.

The game has been rated by other game jammers few times relative to how many times it’s been played, and I think that’s because folks get confused early on and give up before they rate it. This idea was partially formed by watching Kevin, the organizer of the jam play the game on stream (and by chatting with some other devs during the stream. It was so cool to see Kevin play the game and super informative! Unfortunately I think twitch archives videos after 30 days so this link is going to die soon - sad. ↩
It’s not the point of this section but starting from the premise “make everything reolve around this music track” was actually really fun and pretty clarifying - kind of like having a theme but much stricter. I’m excited to try similar restrictions in the future. ↩
With the exception of some bugs I hadn’t yet found in the teleporter because they didn’t appear until the later levels where you could enter 2 different teleporters in the same turn. I ended up needing to keep some extra state to prevent a case where exiting a teleporter could warp you! ↩

Game 4: click, click, trick