The Playdate. A niche, weird device for people craving a return to the handheld era. It has a crank as a control input. Why? Panic, the creators, say this:

Yes, the crank. Is it a gimmick? Nah. Does it charge Playdate's battery? Nope. Is it really fun? Yes yes yes. It's an analog controller that flips out from the side, allowing you to precisely dial in the action. Not every game uses it, but some really do, like Crankin's Time Travel Adventure[.]

It’s a fun device with plenty of unique games. I highly recommend checking it out.

Two weeks ago, I decided to check out the SDK on a whim. I experimented and came up with a fun little Mega Man Battle Network (MMBN) inspired proof of concept (more on this in the future!).

48 hours after downloading the SDK, I learned about Uncrank’d Magazine’s Pre-Summer Game Jam. I told my wife about it, and she said, “You have to sign up.” Like any good husband, I followed her words. I figured since I had a playable alpha version of my MMBN-like, I could use this game jam as a good learning experience. I could really dive into the SDK, create something fun, and maybe for once finish a game.

Spoiler Alert: I did! I created Piña Rollada, a game heavily inspired by Super Monkey Ball. Here is the story of how I went from never touching the Playdate SDK to creating a fully playable and—dare I say—fun game for the Playdate.

Day 1

The Uncrank’d Pre-Summer Game Jam (game jam from here on out) themes were released at 6am ET on May 2, 2025. The themes, which you could choose one, two, or all three, to inspire your game were: Futuristic, Relaxation, and Golden Hour.

I don’t know if I made it up or not, but I also thought I saw at some point “Fun in the Sun” as part of it. I can no longer find that and maybe I just took the general beach aesthetic and relaxation as fun in the sun. Either way, I pretty much knew instantly what my idea was going to be.

I was reminded by looking into the SDK that the Playdate has a built-in accelerometer. Not recalling any games that use the accelerometer (despite games in Season 1 featuring this control scheme), I thought it would be a good way to stand out in the game jam submissions. I knew I wanted to make a platformer, and I knew I wanted player movement to be handled via the accelerometer. To fit with the themes, the main character would be a coconut. What’s a coconut that rolls? A Piña Rollada! I had my game.

I instantly pulled up SquidGod’s tutorial How to Make a Metroidvania/Platformer | Playdate SDK Tutorial. After a couple of hours of following along here, I started making my own. Thanks to SquidGod’s open source codebases, I was able to begin my work using his tilesets which made my first roadblock, art, passable. To show just how bad of an artist I am, here is the coconut sprite that I drew and used for the first few days of the jam.

As part of a game jam, entrants are typically encouraged to pair up with others to work together within their own skillsets. As seen above, I am not an artist. So I paired up with an artist that was looking to participate, Wilson Diebold. Wilson shared with me early on a very interesting article about sprite sizes for the Playdate. The TL;DR is that since the Playdate screen is so small, yet the pixel density is so high (resolution 400x240), that the 16x16 sprites I was using might be tough on the players' eyes.

So I changed the scale of the whole game! First starting with 32x32, I realized doing so would cause the game to run out of space for tiles on the level design tool. But I had to take a break from working on the project.

Day 2

After sleeping on it, I decided to split the difference and go with a 24x24 grid based system.

Perfect. The sprites were large enough to see well on the device, but also small enough that I could have more freedom in designing the levels. Here is the note I sent Wilson:

I ended up taking it back down in size to 24x24. 32x32 only lets you have 7.5 tiles vertically, but 24x24 lets you have 10. The 7.5 was feeling very restricting for options in level design.

Throughout day 2, I continued to tweak the controls and make new interactive obstacles for the players, but I needed more ways for the game to stand out. The Playdate catalog is filled with platformers. What would make mine unique, besides the accelerometer controls? I brainstormed power-up ideas or unique room physics and one that stuck out to me was recreating a marble labyrinth.

I have always loved the challenge of these games. They’re just the right amount of frustrating, while always remaining fair.

Day 3

I went to work on creating a room that would have this control scheme. It wasn’t too bad. I figured the player would enter a room, get a pop-up that says something along the lines of “welcome to the labyrinth” and then shift the controls. For my testing, I started by removing gravity, tweaking velocity and acceleration, and seeing what happened.

I really liked the way this felt, so I decided to keep expanding on it. Next was to update the level design from a side-scroller to a top-down view. During my quest for getting the perfect marble feel, I reached out in the #dev-general channel in the Playdate Squad Discord. debugChicken, the developer of Wirewalk (phenomenal game btw, check it out), offered some physics help along with a better placeholder for my marble. Suddenly, we had much better physics, a better looking marble, and level design that made sense for a labyrinth.

Day 4

On the fourth day, I started to shift the game entirely to a marble labyrinth. No longer was this going to be a special room, this was now the entire game. I began thinking about scores; how would it work? Is it just to complete each level? Are there pickups? Are there powerups? I decided to add some pickups in each level. To stick with the theme of the jam and name of the game, I figured the player’s goal would be to pick up the ingredients for making a piña colada. Pineapples, limes, cherries, etc… That evolved into just collecting a bunch of different types of tropical fruit. Being the non-artist that I am, I grabbed a random sprite online and used it until I couldn’t bear it any longer.

I’d need to add more than one level too, so I added a level end-goal and the ability to load into the next level.

It was around this point that I realized how limiting the 24x24 size grid was still. I shifted the tiles back to 16x16. There was so much more space to design now.

Day 5

I couldn’t take it anymore. Using random sprites wasn’t fun. I needed my game to feel fun. So I tried my darndest at making some fruit sprites. They turned out pretty good for someone with my skills and would tie me over until Wilson could get me his work.

I also added some more obstacles. Moving beach balls and water guns would be fun challenges.

I now had the art bug!! I kept going and changed more of the sprites. I added a wood texture so that it would feel like a wooden labyrinth, I added dialog boxes (shoutout to SquidGod again for open source code) to inform the player of the goal, and I added some more challenging levels.

I had my wife play the game on the device. She said it was hard to see what was going on. I didn’t consider the white on white on white on white of the textures on tiles. So I took a little bit and made my own tilesheet entirely. Thanks SquidGod, but no more of your stock assets!

I finished the day by having a buddy of mine animate some pineapples for me. Animating the fruit would let the player see that they’re different than floor obstacles.

Day 6

The gameplay was in a good spot, so it was time to start working on some of the more polish/admin side of things. First off, we needed a menu system. I worked the whole day to put together this title screen and level select.

The level select needed to show the proper amount of columns and row dynamically, along with the fruit collected and max possible fruit per level. I think it turned out pretty well.

What I noticed now that I had art was that performance was getting shot. Some levels were playing at 18fps. This was not okay. I spent some time refactoring the way I was loading images by pre-loading them on launch, which increased performance a decent amount. The 18fps level went to 21fps. Still not good, but better.

Then I learned about object pooling. Time to implement an object pool manager. I did this and we had success. The 18fps level was now up to 28fps. I really couldn’t see a reason for this not staying at a solid 30fps, but it’s a game jam. It was time to move on and get back to more levels.

Day 7

Okay, a whole day was spent on the menus and optimization. We needed more levels and more gameplay. Wilson had a cool idea of some pistons shaped like barrels. He also started to give me some of his animated sprites. We were in business. I also added tiles that will influence the player’s direction. The culmination of all this? A very simple “pinball” level.

Wilson had a great idea for a level and use case for the pistons. He drew it up and sent it to me, and I tried to implement it. This required me to re-think how pistons would work, but it would be worth it. I needed to add the ability to handle the barrels in different orientations and, rather than forcing the player up like a pinball machine, I needed to alter the hitboxes to push the player out to the end of the piston and ideally knock them back.

This was not easy!!! Having them in line and animating was easy, but I needed to delay the animations into a wave of sorts. So I tried to use playdate.performAfterDelay(delay, function()) to get them to delay. In theory, this should work. For some reason, this was the result.

This would have to wait for the last day. I was too tired to keep going. I had spent four hours already and made no progress.

Day 9

The last day. I woke up at 6:30am and got right to work. Lack of sleep? Nothing a little coffee can’t fix! I spent the following six hours of my day trying everything I could for these stupid pistons. One of the biggest issues I was facing was getting a second collideRect to draw and move with the animation. I had to manually map out the animation frames and then call barrelLid:setCollideRect() for each frame. This was working, except for the fact that when the player was touching the collideRect and it got re-drawn, the player would get shot into the wall and the level would reset. The collideRect was drawing on top of the player. How????

I had to call it. I couldn’t work on the barrels anymore. I ended up using playdate.graphics.sprite.querySpritesInRect(lidX, lidY , 16, 4) to check if the player was inside the animation frames.

If they were, then move them:

other.yVelocity = -0.75
other:moveBy(0, -lidYOffset)

Okay. The pistons worked. I wasn’t not happy about it, but they work.

I now had just a few hours left, but the game still only had 6 levels. I needed to get busy. I ended up only having the mental capacity to design 5 more levels for a total of 11 for the game jam entry. I would’ve really preferred to have more, but it is what it is.

I wanted to make a quick credits screen to let the world know about the team behind the game. Some quick animations and huzzah!

And with that, it was time to submit. I wrote up a quick blurb, made sure I had given credit for all the sound effects, open source stuff, and images I used. I was pretty happy with the results. I think I ended up making a really fun game in such a short amount of time.

I pressed submit and called it a night. I finally made a game. I went from only ever messing around with tiny example code projects in different languages to having a real, fun, challenging game for the Playdate in 11 days. I could not have done this without the incredible community that the Playdate has fostered. I am extremely grateful to all of the developers out there who helped me with beginner questions.

What’s next now that the jam is over and the game is submitted? Well, I have a lot more I want to do for Piña Rollada. I think this could be a worthwhile game for people to play on their device, more than just a 9 day game jam entry. I’m excited to continue to work on it. I have a long to-do list, but would love feedback and ideas from people after they play the demo.