Puzzle Game Design Postmortem

It's been a while since I posted a postmortem! This time, it's all about puzzle game design. Personally, I don't like puzzle games. My brain is just too smooth for them. But, I'm also a game designer (full-time at Bippinbits now!), so to get better at game design, it was suggested I read up on how puzzle games work, and that's what Space, Yarr! is.

Game Data

• Jam Submission Date: 2023/10/02 (https://ldjam.com/events/ludum-dare/54/$379300)
• Genre: Phyrics puzzle
• Project Length: 3 days (about 14, 16, and 10 h respectively)
• Project Budget: our time, a bit of food and energy drinks, and tea
• Peak Team Size: Actually, I'll talk about that further down
• Hardware Used: Our epic gamer gaming pcs 
• Software used: Godot 3.5.1, Clip Studio Paint, probably other stuff I don't know

This sure was a team

At gamescom 2023, I met Adam, Crashtroid everywhere online, and composer for Peglin. He's a super cool dude and friend and made the music for Space, Yarr!. He has so many contacts, and managed to get Voltergeist (whose socials I don't have) on the team to do the character art at the last minute because the artists we originally had planned did not show up sadly.

Additionally, I scrambled a few friends in the forms of Jazz, who did the phenomenal voice acting, and Zephiris, who was moving during the jam and slept on my couch, so I forced them to do pixel art (that's where the game gets its ship sprites.)

I did all the coding and game design, without anyone to bounce ideas with, which meant that I had so much to do all the time. Bug fixes, coming up with new mechanics, implementing them, etc. All of the environments are fever dream-induced programmer art, and, ironically enough, the background is literally the same one as in Sunless Horizon. It just looks so good. So overall the team was 5-ish people big, but with very uneven work loads. Next time, I'm gonna try and have this structured better beforehand when working in a team on a jam.

What are puzzles, even?

Like I said, I don't really vibe with puzzles at all. So I read up and watched up on some design talks / insights by Jonathan Blow (Braid, The Witness, mildly insane Twitter takes), Arvi Teikari (Baba is You), and Brett Taylor (Linelight), and even retained some of the things I learned in my long-term memory.

One common thread throughout was that puzzle games aren't designed top-down. As a designer, you try to create as little mechanics as possible (to keep the game elegant and simple to understand), and create levels through emergent gameplay and recombination of those mechanics. Since Ludum Dare 54 started at midnight my time, I basically looked at the theme (Limited Space), had like 30 minutes of improv thoughts, went to sleep, and started the first day by having a few more ideas and prototyping like 3 different games. When I talked to Adam about the different things I had worked on (and sometimes abandoned bc coding is hard), he latched onto the poly bridge / angry birds fusion the most, so I went to work on that and make it into an actual game with features.

For the individual levels, I followed what Arvi outlined with his work with Baba is You, that you often have to reverse engineer solutions; You know the solution, and then have to backsolve a challenge into it. What you should avoid here, according to Arvi, are busywork and red herrings. This coincides with Brett Taylor's approach with linelight when he talked about Noise, and I've also seen outlined in many incidental convos about puzzles. You don't want stuff that distracts from the point of the level. Sometimes I succeeded with that, but ultimately, I placed too much emphasis on only having working tech, and expanding the tool box, rather than just having a good level with what mechanics I already had. Also, the boosters kinda trivialize everything.

From a tech standpoint tho, I am astonished that the peg property overriding just works. for any level, I can define any restriction on cannon angle, shot power, booster strength, inventory space whatever. It all works.

Another issue I was aware of and still just plowed into was the "why won't it let me do it" phase of gameplay. I've seen several people say how they know what the level wants from them, but they either don't know how to get to that point, or it would just take too long to get there and fine-tune everything. The trial-and-error involved in some later levels in insane. (But tbh this reflects my relationship with any puzzle game ever. Brute-forcing is how I learned to complete puzzle challenges, which is why I don't like them.)

Any thinking involved is bad, imo

Jonathan Blow outlines “I understand” vs “I finally figured it out”. If you ask me, I don't get the distinction. Any rules in a game are arbitrary, so there is no meaningful difference between understanding the emergent properties of a system, and figuring out how they were constructed. The only difference is the amount of apply-head-to-wall that preceded the epiphany. If your player (or user) asks "how do I do this", you failed as a designer.

Amount of iteration: Very little

Finding rules and puzzle after implementation and only during testing is a thing that can create many intuitive and syntactically-close puzzles to a common ancestor puzzle. Unfortunately, due to the time constraints, this basically didn't happen for Space, Yarr! One of the few variations on rules are the teleporters, which can be uni- or bi-directional, but that's more an emergent property out of spaghetti code, because in truth the bidirectional ones are just two unidirectional ones with their start and end points at the exact respective locations of their counterparts. 

Postum, what could be added? Definitely a better UI lmao

But mechanically? Much much more freedom. The circular pegs are useless (bc they effectively randomize the flight direction), the vortexes basically so. Walls could be abstracted / generalized to n-edged lines like in poly bridge.

Also, I thought of Angry Birds a whole lot during development. So soft / hard win cons could also fit here. i.e., you can win with basically zero effort, but getting that extra mile (such as in-level collectibles you have to hit with the ball, or a score that actually matters) take extreme effort. Each shot should be a success, not just the nth data gathering operation in an arduous process of trial-and-error-ing your way through a level.

Vox Populi

There is basically consensus as to the quality of Space, Yarr! that I could gather from the comments.

1. The music slaps
2. The VA is super sweet and endearing
3. The UI and controls are wonky and unintuitive at best, and unusable at worst... Some examples include

   
   

   1. The pegs only being removale at their center
   2. Many people never even figured out how to adjust the cannon
   3. Voice lines could've been incorporated more smoothly

In summary, this reflects the team structure to a tee. The amount of production value that a custom OST and VA bring to the table is insane, but it needs to be underpinned by solid gameplay and UX, for which I just didn't have much time.

Conclusion

Team coordination is difficult. I wanna get better at doing that. Also, production value is really fucking neat!! But so would be having a second programmer!!

I'm way more satisfied with the time management this time around as opposed to what happened during Sunless Horizon. I decided the game was finished about 6 hours before the LD deadline, and I was ready to collapse so I just called it a day, submitted a working web build, and went outside. Joy.

List of videos

• Puzzle Game Magic Secrets (Brett Taylor at GDC)
• Talk & Dev: The making of Baba Is You - Arvi Teikari (Independent)
• Jonathan Blow - Truth In Game Design (GDC)
• How To Design Deep Games with Jonathan Blow (Braid, The Witness)
• How Jonathan Blow Designs a Puzzle (GMTK)