How Bennett Foddy created punishing Playdate puzzler Zipper

Back in 2015, Bennett Foddy of Getting Over It and QWOP fame was asked by Playdate maker Panic to create a game for the radiant crank-laden handheld. When I caught up with him last year for this Q&A I knew almost nothing about the project other than it's name: Zipper.

After going hands-on with the tactical, turn-based puzzler in recent weeks, however, I feel comfortable saying that Zipper is one of Playdate's most compelling Season One titles -- a punishingly brutal fable that sets players on a path of revenge as they take on the role of a swift swordsman delivering vengeance upon a castle full of enemies.

The project is based on 8-bit isometric classics from the ZX Spectrum and MSX era, and according to Foddy is actually the culmination of an old Flash prototype he made back in 2007 when, by his own admission, he was "a total novice of game design."

To learn how the New York-based developer pulled that prototype into Playdate era, we caught up with the man himself.

Game Developer: Panic said that one of the most exciting things about Playdate is that it actually gives creators some constraints -- providing a different kind of challenge to more conventional development. With that in mind, what excited you about the hardware from a technical point of view?

Bennett Foddy: When Cabel pitched me on the device, in early 2015, the hardware was still more of a giddily-described set of ideas or aesthetics rather than something that was locked down. I think at that point in history I was still captivated by the idea of working with the semiotics of retro aesthetics. As Jesper Juul describes in his book, I think a lot of indie designers were using historical visual styles to signify a 'handcrafted', artisanal style in their designs, and I was interested in what it would be like to work on a device that sounded a bit like an OG Gameboy, and a bit like an original Macintosh. The game I chose to make heavily evokes the isometric styles of the monochrome games I grew up with on the ZX Spectrum.

I see it a little differently now, of course! The industrial lines between 'indie' and 'commercial' are so amazingly blurry now that retro styling no longer feels radical or even useful as a signifier. But along the way I have also made a lot of games in Joseph White's Pico-8 fantasy console, which uses retro aesthetics mainly as a source of useful constraints, and Joseph's amazing talk where he explains the idea of 'cute' or 'cosy' design spaces really opened my eyes to the value of this idea. Pico-8 is a lot like the Playdate, except that it only exists as a digital 'console' — it's got a low-color, low-resolution display, simple controls, and everything is coded in Lua. These constraints guide and enclose your design choices in a way that is incredibly freeing. On the Playdate, it pushed me into a design zone I would not usually go to, making a turn-based game.

It would be remiss of me to not mention the crank. Was it difficult to bring that decidedly unconventional feature into play in a way that felt natural, or is it actually rather intuitive? If you didn't use the crank -- what was it that turned you away?

It's funny - a lot of my favorite old arcade games use a rotary controller, like Tempest, 720°, Off the Wall, or Tron, and if you look at the games I've worked on, a lot of them use 'virtual' rotary controls. Getting Over It, Ape Out, Super Pole Riders - all of those require the player to use a stick or a mouse as a rotary-style control. When I first heard about the Playdate's hardware I envisaged myself making something like the classic Mac game 'Dark Castle', which also would have worked great with a crank!

But I started work on my Playdate game a long time ago, back in the Spring of 2015. At that point, the crank was definitely in the hardware roadmap but I didn't have hardware, and I wasn't sure how easy it would be to use or how robust it would be - the final thing is a really strong, precision-made mechanism but in 2015 I didn't feel like I could rely on that being the case. In fact, if memory serves me right, I don't think it was even a given at that point that the crank would be revealed to players when they were playing the first few games! I'm a designer who really has to hold a hardware input in his hands to understand it, so I decided to base my game primarily around the D-pad and buttons. Much later, I found that my design wanted an extra input, for moving time back and forward, and at that point I did implement the crank.

What were some of the most challenging aspects of designing Zipper, and how did you overcome those hurdles?

Of course working with the hardware constraints posed a certain kind of challenge. For a one-bit display the device has plenty of RAM and storage, but the CPU headroom is low, particularly if you work in Lua. And when I got started, the spec only allowed for a 20Hz LCD display (this was later increased significantly). Although those are technical constraints, you have to solve them in with design first, so selecting a design that could work under those constraints was an interesting challenge.

Apart from that, there was the long lead-time. The idea for the device, I think, was to evoke the best of original Gameboy games, which tended to be modest experiences that could be enjoyed in bite-sized ways, in the cracks of dead time people have when they commute, or wait in line, or before bedtime. In other words, a tiny-scope, tiny-budget game. But it's a strange production challenge to make a small game over six years! Sometimes I would get a little rusty in my Lua coding skills, but the more serious problem was scope-creep, a hazard that I did not totally avoid. My designs are always incredibly minimalistic but on that kind of time-frame, you don't really wind up cutting features.

Conversely, I'm curious to know what went right during production? What aspects of development played out exactly as intended, and how did you set yourself up for those successes?

My game, Zipper, was based on an old Flash prototype I made in 2007, at the tender age of 29 - a total novice of game design. Making turn-based games takes a certain amount of mental discipline that I still don't have a ton of, but at that point I just didn't know how to make something like that work. It was gratifying to come back to an 8-year-old design and find that it wasn't as fundamentally flawed as I had thought it was on the first time through. I have always had a creeping suspicion that we have all our best ideas early and our best implementations late, so it makes sense to raid the cupboard for abandoned prototypes.

But apart from that initial prototype, I didn't really have concept art or design docs. It was a purely iterative process, with one or two aesthetic pillars. Let's say 'Sanjuro meets Highway Encounter'. One of the only real pleasures of making games by yourself is that you don't have to abide by a plan.

How accessible are the Playdate development tools? Which ones did you lean on the most, and how did they influence and inform development?

I've only used the Playdate SDK, working in Lua from a Mac. Using Panic's excellent 'Nova' IDE, everything is totally integrated and it is really nice -- you just write your code, hit two keys and the game is running either in the excellent simulator or on the device. The API is nice and short, similar to Pico-8, but it does offer an optimized native-code call for just about any performance-critical thing you can think of (not just sprites and sound but pathfinding, layout, and so on). It's hard to imagine any code-focused system being easier or more pleasant to use. My main advice would be to use a process that takes advantage of the tiny iteration times! You can be playing the game on device from the first moment you start work, and you can make tiny adjustments on the fly without waiting for anything to compile.

My understanding is that the hardware is going to be unlocked for people who want to side-load their own games on it, and I think that's probably the most exciting thing about the device! I expect the homebrew scene to be incredible.