Addled, a classic puzzle with some new twists


I'm writing a puzzle game inspired by the old classic Puzznic. I don't have a device yet and was wondering if someone could let me know how the fps is looking? I'm particularly worried about my title and level select screens as I went a bit mental with special fx on them.

Update: made some changes to improve performance (using frames instead of procedurally generating backgrounds, using pulp songs instead of mp3s, etc).

Hopefully performance is much better now. (2.3 MB)


Some screenshots:-





A quick gif:-



You should post this in the Playdate discord server.Almost all the fans of the Playdate are there.You could easily find someone with a device to test your games.This is an invite to the server..

1 Like

it doesn't load via the sideload feature of the website ( The bundleID field is missing from pdxinfo.)

Sorry about that, I think I've fixed it :slight_smile:

Your fixed build sideloads fine for me.

The title screen runs at about 5-10fps for a couple seconds, then the music cuts out and it drops to something more like 1fps. After pressing A on the title screen, it makes a brief squeak sound (the music still doesn’t come back) and the starfield screen starts at 1fps or so and then each subsequent frame takes progressively longer – by the time the spaceships appear, it’s more like 1 frame per 10 seconds.

I pressed A on one of the spaceships without waiting for the animation to finish, and after 5-10 seconds of loading, the level select screen with the large spaceship flying left runs quite smoothly (looks like ~30fps to me) but with occasional brief hitches (garbage collection?).

After selecting level 1, the animation of the ship flying down to the planet starts smooth (and looks really slick, btw) but freezes for ~2s when the spaceship is down to about 10px tall.

The actual gameplay looks like it runs smoothly but the music cuts in and out a lot. (after the music cut out on the title screen, it didn’t come back at all until after about 30 seconds of gameplay)

Edit: during the periods when the music comes back, the gameplay fps drops to around 10 and the controls lag. When the music cuts out, it returns to ~30fps until it comes back. Also, the selection box sometimes partially disappears when it’s in the top row.

Edit 2: the “level cleared” screen runs quite poorly too (varies from 1fps to maybe 0.1fps), and after completing level 1 and returning to the large spaceship level select, it now runs at about 10fps (it previously did 30 before I played level 1).

1 Like

Wow, thanks daprice, that's a pretty precise report :slight_smile:

I've got a lot to think about !

For what it’s worth, I would imagine that most of the worst-performing effects would work fine if you use pre-rendered sprites (or entire pre-rendered frames) rather than doing a lot of transformations on the fly like it looks like you’re doing now. You could probably even use playdate.simulator.writeToFile(image, path) to write out rendered graphics from your existing code running in the simulator to avoid having to recreate everything.

Those gifs look amazing! Yet another performance idea might be to use video, if there are to many frame for an image sequence. Sounds like a pretty blunt approach though, so I would try the image tables first :slight_smile:

Thanks Nino! Yes, I'm looking at using frame based animations instead.

Not a bad idea daprice, I might do some investigating!

A quick update: I've switched to using animated frames for the backgrounds and have swapped out the mp3s for pulp songs. Some other minor performance improvements too, hopefully will fix some / all of the performance issues.

A gif of the new animated backgrounds:-



A few performance notes for your latest build:

In most cases, the new animated background performs the same on device as in your gif.

Looks like maybe the rotation of the title is still causing a pretty major slowdown (of the frame rate and the music) which goes back to normal when the title finishes animating in.

The large spaceship level select screen is still smooth before playing a level, but worse (only 5-10fps) when returning to it after playing a level.

The animation of the ship flying down to the planet when starting a level still freezes partway through. If you can’t avoid the delay when loading the level, I’d suggest having it wait until the ship has completely disappeared into the planet and the “whoosh” sound finishes playing, then letting it pause to load while only the planet is visible. That way it will look to the player like a normal pause in the animation, rather than a frozen game. I don’t think the loading time is excessive at all – the season games and the OS itself take similar amounts of time to load things – but it shouldn’t happen in the middle of an animation and sound.

The animation of the level scrolling in and the level name scrolling off the screen looks ok on the device (5fps?) but nowhere near as smooth as it does in your gif.

During gameplay, any time a tile is dropped, it falls more slowly (at a lower frame rate) than what your gif shows, but I might not have noticed without the gif to compare against. If I do something to trigger a chain reaction (e.g. moving the middle ghost to the left so it falls down at the start of level A-2), performance slows to a crawl until it finishes.

The animation when I pick “quit level” while in a level runs at maybe 1fps and leaves some things behind on the screen.

I left the level select screen with the large spaceship running on my device while writing this, and at some point a few minutes in, it froze for 5 seconds (both graphics and music), then came back and played the music ridiculously fast to catch up.

Sometimes the game doesn’t register quick repeated presses on the dpad, but other times it does, which might be performance related.

The level cleared screen still runs poorly (maybe 2-5fps?) all the way through.

A few notes that aren’t performance related: (sorry if these are things you just aren’t finished with yet)

Pressing B to undo a move sometimes leaves things in a weird state (e.g. on level A-2 when I moved the ghost as described above, then press B, it only undoes part of the chain reaction and leaves tiles floating in midair). Pressing B all the way back to the level name screen causes the background of the level name overlay to get stuck on screen.

Choosing “About” from the menu while on the title screen crashes with attempt to call a nil value followed by an empty stack trace. Choosing “skipped levs” from the menu on the level select screen also causes this.

Choosing “Quit level” from the menu while a tutorial is on screen crashes with:

game.lua:1342: attempt to index a nil value (global 'hintPanel’)
stack traceback:
  game.lua:1342: in function
  game.lua:1309: in function ‘quitLevel'

Hi daprice.

Thanks again for the detailed response :slight_smile: It looks like my biggest problems are caused by performing scaling and/or rotation in screen updates to perform animations. The playdate is ok doing scaling and rotating occasionally but doing it every frame kills the cpu, I'm guessing. I can get rid of most times I use this, but I really like how it works with the spaceship landing so I might try some more tricks to keep this bit in.

The slowdowns in-game are worrying, I'm not doing anything flash when moving the blocks about. And as you've noted, some parts of the game aren't finished yet, there's no About screen and I've still got some bugs to iron out like the 'undo' move recording sometimes when it shouldn't. But I'm happy with the progress :slight_smile:

thanks again :smiley:

This looks like a good test case for the "only profile slow frames feature" (Profile slow frames only), also trying to figure out what's going on with that occasional hang (garbage collection, almost certainly), so I'm playing around with this today. Should I post bug reports here as I hit them, or would you rather have them in DM?

First thing I noticed running it under the profiler: In that laggy title screen it's spending almost all of its time calling sprite:setScale() and sprite:setRotation(). Those functions redraw the sprite's images immediately, which means you're doing redundant drawing if you're using them both on the same sprite. setRotation() has optional scale arguments so you can handle both scale and rotation in one go. The other thing there is it might be more efficient to skip the image backing and instead use a draw function that calls drawScaled() or drawRotated(). That will draw directly to the screen's frame buffer instead of adding an extra step of drawing to an image, and will clip off-screen drawing if the rotated image is bigger than the screen.

I'm tempted to add that as an option for image-based sprites, like a "cache transformed image" flag you'd turn off to have it do the scaling/rotating at draw time. I'll file it and think about it. Generally I'm against fiddly bits that make things more complicated, but I can see this being pretty useful.


Hi Dave,

thanks for looking into this. After looking at the suggestions from yourself and everyone else on here I've decided to try 3 things to improve performance:-

  1. No more dynamic rescaling and rotating. This is a bad habit I got into from writing games for iOS, I tend to underestimate their effect on performance. Now I create pre-scaled and rotated assets.

  2. Storing frequently used images in a global cache and just pointing sprites at the images in the shared cache. I was destroying and re-creating graphical images too often.

  3. Flattening my layers. Now I just have a foreground and background layer, where before I was using 5 layers in-game, to very little benefit.

I've attached my latest build, hopefully it has much better fps. (1.4 MB)


Whoa, that's incredible! All the memory churn that was causing the slowdowns is completely gone. I was even able to set minumumGCTime to 0, reducing GC time from a steady 30% down to just a bump every now and then, and the collector can still keep on top of memory growth. Amazing job!

Thanks Dave, that was really worrying me for a while!

I think you've given me enough confidence in the game's performance to consider releasing it on so ta muchly !

p.s. Did you notice anything strange about the music? (That was another point I remember being brought up).

1 Like

I didn't notice anything odd about the music, no. In the older build it would slow down along with the game, but everything is running fast and smooth now.

One bug I ran into a lot with the older build, but didn't see it in this one until I got to A-17: sometimes after rewinding to the beginning of the level the title stays on the screen. Seems like it happens when I hit B too fast. If I restart the level a new title animates in and out and this one stays there. Quitting the level and starting it again makes it go away.


okay, looks like if I hit A while the title is animating in after I rewind all the way back to the beginning it'll do that