ᕕ( ᐛ )ᕗ Herman's blog

How I learn (making games for the Playdate)

I (finally) received my Playdate, after about a year and a half of waiting. To be honest, I'd kinda forgotten that I'd ordered it and was pleasantly surprised when it showed up.

Playdate

For those who don't know, the Playdate is a niche handheld gaming console, similar to a Gameboy. It has a black and white screen, and an odd crank on the side. This crank isn't a dynamo for charging the device, or anything like that. Instead, it's a fairly novel input controller which can be used in a game mechanic to do things like reel in fish; crank open doors; and control the flow of time.

This seemed like the perfect gaming device for me. Not necessarily because I wanted to play games on it, but because I wanted to make games for it.

I've written previously about the power of constraints when building creative products. By having a narrow focus and sometimes arbitrary boundaries it can be easier to experiment and do something novel within this smaller possibility space. With traditional game engines the possibility space is huge. You can build anything from a Pac-Man clone, to a real-time, first-person MMORPG.

The Playdate, by comparison, has a much tighter set of constraints:

On to the learning!

I was completely unfamiliar with the Playdate SDK, and had never coded in Lua prior to this project. All the game engines I'd used before had visual scene interfaces and object hierarchies with attached scripts and attributes. The Playdate SDK, by comparison, has no interface at all, so I had to get down and dirty.

When learning a new language or framework I like to break it down into 2 steps:

  1. Figure out what is possible.
  2. Build a small project.

Too many novice programmers get stuck in the tutorial phase of learning. The issue here is that the guardrails never allow them to make mistakes. Mistakes are where the learning happens. Instead the tutorials lead them along the happy path the whole way, and in so doing generally teach them very little.

Here's an analogy: There's good evidence to suggest that using apps like Google Maps for turn-by-turn navigation can make it harder for someone to learn their way around their city. On the other hand, if instead they check the location of the destination and try to self-navigate they, naturally, become more familiar with that area. They need that friction. They need to actually think about what they're doing.

Tutorials are the turn-by-turn navigation of learning. It'll get you to the end of the tutorial, but there's a good chance you won't be able to navigate that language/framework/library once completed.

Figure out what is possible

So while I don't find tutorials useful for learning, what they can do is show me what is possible. I like to watch a handful of them prior to jumping into building just so when I'm confronted with a problem I know what to look for to solve it.

This is like looking at the map prior to heading off on my journey. I don't know the area, but I have a rough approximation of how to get where I'm going. This doesn't necessarily have to be a tutorial, I could theoretically read the documentation, but that's really dull.

After a short bit of scouting I found a great YouTube playlist by SquidGodDev that perfectly illustrated what is possible with the Playdate SDK, and watched about an hour of his videos before continuing.

Build a small project

During my time teaching, one pattern I noticed consistently was new programmers learning a new tool (let's say a game engine) would bite off way more than they could chew for their first project. Instead of creating a small game about trying to cross a busy road, they'd try to build a multiplayer FPS. This generally broke down pretty quickly since they'd get stuck on one complex problem early on, and after a bunch of spinning, give up entirely.

Instead, having a small scope with a pretty solid definition of "done" is an ideal way to learn. Taking a project from start to finish gives a good overview of the larger picture. In the case of the Playdate, it meant building a small game, publishing it for free, and getting actual people to play it.

I also time-capped it at 4 weeks. I had to have something playable and published before Christmas.

And so I created NIGHT RAID, a game set in World War II where you control an anti-aircraft gun (using the crank), as well as a set of spotlights to hold off waves of Axis bombers, zeppelins, tanks, and a few other enemy types.

NIGHT RAID

There are no levels, just an algorithmic increase in difficulty and a high-score system, which meant that I could focus on learning without spending too much time on level design.

And I did it! And it was super fun! Not only did I learn a great deal about Lua and the Playdate SDK, but also about 1-bit pixel art, animation systems, and optimising code for slow devices. I even tried my hand at sound effects but eventually just bought a big ol' library of sounds.

By taking the small project from concept to publishing also taught me about distribution methods of Playdate games, and introduced me to the community. There's a good subreddit and Discord group for Playdate developers, and it's a niche enough device that the players are actually friendly.

Conclusion

This method of learning isn't universally good, but I find it great for craft-specific learning. To apply it to carpentry would look something like:

  1. Watch a bunch of carpentry tutorials on YouTube (preferably involving only the tools you have access to).
  2. Choosing a small project to build, such as a side table, or jewellery box (as opposed to a vanity or large office desk).

And that's how I (usually) learn new skills.

This year I'm going to be working on a Playdate game I've had in the back of my mind for quite a while. Something something ninja something kitty. Stay tuned!

Enjoyed the article? I write about 1-2 a month. Subscribe via email or RSS feed.