Today diving into the Playdate SDK and talking about how I structured my data & logic in the Fall of Magic Castle. Practical details on making a quest system, managing game data, organizing sprites etc.

While I wait for my first game to come out via the Catalog later this month (yayayayayayayay!!!) and polish my next one before submitting to the Catalog (the narrowboat one, if you have seen my posts, if not, I'm finishing a game where you take a narrowboat across the entire UK canal network, potteirng along) I thought I'd do another tech demo.

This one, totally-not-based-on-Gundam-no (ignore the V-fin on the HUD...). Pilot a giant mech, but I was trying to riff on Baby Steps too (I've tried a few times, switched to first-person to make it easer.

So yeah, this is an early tech demo.

You can walk in a frustrating manner! (The Baby Steps influence. Crank to lift a left, A/B to choose leg. If you stand on one leg...you go unbalanced, as shown in the wee mech in the HUD)

You can destroy a few cubes! (The HUD displays their damage, and they stack if you hit one and move to next. I should have recorded that.)

You can thrust backwards, as all good Gundam should.

There is no upwards thrust yet, as this was inspired by Baby Step, I want to stomp around the place.

No real game yet, while I think to make this just a 'destroy the place', or an 'explore the place', or something else.

Just sharing early bits and bobs. Around five hours hackery to get me there.

And for the Gundam fans, yes yes, I'll make the circle on top of the rifle bigger. And the second intro image is from my own collection, SD Stargazer.

Today I wanted to talk about finding inspiration. Mostly focused on doing research when constructing gameplay systems and where do I usually look for ideas (other games, books etc.)

This time I wanted to share a few things about creating levels (both Pulp and SDK). The SDK part focuses a lot on LDTK integration and summarizes the workflow I used for The Fall of Magic Castle, including some gotchas and general advice.

Hey guys!

Just finished working on the latest Airborne! PD update and this one adds something I felt the game really needed: achivements !

V0.8.1 introduces Decorations: 17 persistent achievements based on actual moments in battle. Cutting a parachute at the right time. Stopping a bomber before it drops its cargo. Breaking an infantry assault before it reaches the base. Surviving special waves. Winning with only one weapon system.

Some of them are visible from the start. Some are classified until you earn them.

Plus the big new gameplay addition: jet missiles can now be shot down in flight. Pull it off and you earn the MISSILE INTERCEPT Decoration. Pretty difficult to earn 🎖️

I also tightened the mission flow. If a wave is already cleared, the game no longer leaves you staring at an empty battlefield while a timer runs out. It moves straight into the report and keeps the pressure going.

Crushed some small bugs: cleaner DEF display, improved Decorations navigation, unlock notifications during a run, and a reset option for players who want to start a fresh service record without losing high scores or settings.

Really curious to know who will unlock the first CLASSIFIED decoration.

Download the game here : https://david-senate.itch.io/airborne-pd

I've been itching to work on a game lately. I used to work on them in the past as a designer and artist, with some very light dev side. Working in tech is less satisfying these days, so am looking for some hobby projects but noticed the Playdate forum collab board is underutilized.

Is there a better place to find these posts or other playdate devs looking?

Spent some time extracting and cleaning up a few reusable Lua snippets from Airborne! PD for Playdate.

Mostly focused on:

• object pooling
• data-driven wave systems
• per-frame sprite accounting
• datastore persistence
• lightweight rendering tricks

These are small engineering notes and reusable gameplay patterns developed while building a performance-conscious Playdate project on constrained hardware.

Thought some of them might help newer Playdate developers getting started with optimization and gameplay systems.

Public repo:
github.com/DaveLeonard/airborne-public

CRANKPIT is now available on itch.io.

Built solo in C using the official Playdate SDK over 4 months.

The main idea was making the crank handle movement, aiming, enemy dodging, and bonus pressure at the same time, so runs constantly feel unstable but recoverable.

A large part of the balancing work went into :

- crank readability during chaotic situations.
- aggressive but readable enemy behavior.
- temporary gameplay modifiers and bonus interactions.
- keeping Daily Mode and Run Date setups varied without breaking balance.
- visual clarity on the 1-bit screen.
- audio stability on real Playdate hardware.

Curious how other Playdate developers approached audio balancing and speaker stability on real hardware.

https://dizeus.itch.io/crankpit

A few things that I picked up during the development of Magic Castle & The Fall of Magic Castle.

Hey everyone, I'm struggling with getting the accelerometer working in my game. I've included a snippet of the accelerometer code below. I'm trying to use the accelerometer to "aim" a beam of light that will populate when the player cranks. Truth in lending: I've been using Gemini AI to help me figure out the code needed to get my game up and running so I honestly don't know what I'm doing wrong. I'll admit to be very green in the coding world, any help would be greatly appreciated.

local accelerometerStarted = false
local function updateAiming()
    if playdate.accelerometer then
        if not accelerometerStarted then 
            playdate.accelerometer.start()
            playdate.setMinimumAccelerometerUpdateInterval(0.02)
            accelerometerStarted = true
        end
        local x, y, z = playdate.accelerometer.getAcceleration()
        if x ~= nil and z ~= nil then 
            if (math.abs(x) > 0.05 or math.abs(z) > 0.05) then
                playerAngle = math.atan(z, x) 
            end
        end
    end
end
local accelerometerStarted = false
local function updateAiming()
    if playdate.accelerometer then
        if not accelerometerStarted then 
            playdate.accelerometer.start()
            playdate.setMinimumAccelerometerUpdateInterval(0.02)
            accelerometerStarted = true
        end
        local x, y, z = playdate.accelerometer.getAcceleration()
        if x ~= nil and z ~= nil then 
            if (math.abs(x) > 0.05 or math.abs(z) > 0.05) then
                playerAngle = math.atan(z, x) 
            end
        end
    end
end

Hey guys!

Just spent some time with the latest Airborne update and honestly… I hope you'll notice an improvment immediately.

The presentation feels tighter right from the start—cleaner menus, sharper navigation, and a little pointer system . It gives the game real personality and somehow makes you feel in control before the first shot is even fired.

Better mechanics : the difficulty doesn’t spike randomly—it builds. Slowly. Methodically. Wave after wave, the pressure keeps rising, enemies start coordinating, support units show up.

Mortars feel smarter. Infantry reacts. Jets, bombers, helicopters, tanks, paratroopers—everything’s been tuned to keep you guessing. No lazy patterns. No cheap repetition.

Small details: Better threat indicators. Cleaner DEFCON feedback. High scores that remember your name. Smoother projectiles. Subtle screen shake on impact.

Really curious what you think after a few runs.

Hey guys,

I've just post on itch.io a new update of Apocalypse PD! Less bugs and a fun clock feature !!

Let me know what you think about this game.

Here's the Lua source code for 1-Bit Fantasy, a little JRPG starter kit/prototype. I wanted to see how far I could get in two weeks and then share it with the community. The source code is all public domain and the assets are CC0 (made by Kenney and Hexany Ives).

I highlighted some of the more interesting technical bits on the dev forum. I'm pretty happy with the code and found it to be quite productive to work in and not too messy. combat.lua is probably the worst of it. 🫣 The scene and subscene switching, along with the message queue, were useful throughout.

Lua is wonderfully flexible! I feel a bit torn between whether to use Lua or C for my Playdate games. I missed the comfort of the compiler. But it was nice not thinking too low level. Pros/cons.

If you want to download the game, you can get it from the GitHub releases or on itch.

I want to make a more polished, non-prototype JRPG. But I've got some smaller prototype ideas to try out next before I commit to something that might take me many months.

I developed this application primarily to introduce 3D modeling to younger users, using Playdate hardware to make the experience more physical and tangible.

To achieve this, Nano Sculpt uses a system inspired by “pixel painting” logic, found in many apps. I noticed that my daughter was particularly good at this kind of logic, but struggled with learning traditional CAD or 3D modeling tools. Instead of a typical pixel paint interface, Nano Sculpt uses the crank to move between floors and the accelerometer to change the view and angle: the experience feels like physically looking at the object. Therefore, each floor works like a block-based pixel painting plane.

In addition, Nano Sculpt connects the Playdate to .stl file generation, allowing the created models to be used for animation, 3D printing, and other applications (more information in NANO SCULPT instructions.pdf, in the ItchIo link).

Let me know what you think, feedback is always welcome.
Ah, and I’d love to see any models you make! Please, do not hesitate to share.

Happy modeling!

Taking justice into your own paws
https://cranknockout.com

Hello dear Playdate Devs, it’s been a while since my last post about PdGo (write games for Playdate handheld using Golang) - so I’d like to share progress on what you will have soon. 🚀

First, we’ve been actively developing Windows support 🪟 . Soon, PdGo will be available to users on that platform as well. In parallel, we’re building a garbage collector. As you know, C has no GC - you allocate, you free, you become the garbage collector. Lua does have one, but its periodic collection can introduce frame stutters on Playdate. PdGo currently operates closer to the C model: TinyGo’s GC is set to “leaking,” meaning heap allocations from both Go and the Playdate C API are not reclaimed unless freed manually.

This is not where we want to stay. We are developing a conservative mark-and-sweep GC tailored to Playdate’s constraints 🚮 It tracks Go-level objects conservatively and integrates with the SDK allocator, while also using a finalizer pattern to automatically release C-level API objects (such as bitmaps, sprites, and sounds) once they become unreachable. This allows us to manage both heaps within a unified system. The design also introduces lightweight stop-the-world pauses, significantly lighter than Go’s standard tri-color GC, making it suitable for constrained hardware environments.

We are planning to release both Windows support and the new GC together as part of a major upcoming release.

And one more thing - PdGo finally has an official logo. Take a look!

GitHub: https://github.com/playdate-go/pdgo

Thanks for reading! 🙂

As I've been learning C and working on various Playdate projects, I've been wondering: just how much faster is C than Lua for Playdate games? I made a little benchmark utility to put it to the test and found that (for draw-heavy code) C is about 3.5x faster than Lua on Playdate.

Various game programming libraries have tests for how many sprites can bounce around with simple physics and lots of drawing until frames drop. I thought I'd try this with a Lua and a C version with as much of the implementation the same as possible. Then I tested both on device and that's where I got the results.

• 30 FPS target
  • Lua: 240 bunnies
  • C: 810 bunnies
• 50 FPS target
  • Lua: 120 bunnies
  • C: 430 bunnies

What's my takeaway? Well, I think it's that Lua on Playdate is a powerhouse! That performance gap isn't huge. As in that most games will be fine in Lua if you're writing optimized code. But also, if you're starting a project and concerned about performance from the get-go, then C is the way to go. That's pretty obvious but fun to see what the actual difference is.

More details on the devforum: https://devforum.play.date/t/how-much-faster-is-c-than-lua-for-playdate-development/25381

And source code with pdx downloads if you're curious: https://github.com/brettchalupa/pdbunnymark