SDK development

Start with the official tools

Panic provides a Playdate SDK for supported desktop operating systems, including Lua and C APIs, the Simulator and reference documentation. Pulp is a separate browser-based authoring option. Choose the route that fits the project, then retain the SDK version and example project used for the first successful build. Consult the matching documentation when updating the toolchain.

For a first experiment, implement one controllable object or a readable text screen. Add assets and game systems only after compilation, launch and input work. This small baseline is useful later: if a new build fails, you can distinguish a toolchain problem from a change in the game.

Minimal Lua starting point

A Lua project's source directory contains its entry point, conventionally main.lua, and the assets needed by that project. The SDK compiler pdc produces a PDX package. The following small example uses the documented graphics API and update callback:

import "CoreLibs/graphics"
local gfx = playdate.graphics
function playdate.update()
    gfx.clear(gfx.kColorWhite)
    gfx.drawText("Hello, Playdate", 20, 20)
end

Compile the source directory using the installed SDK's pdc command, open the resulting PDX in Simulator and inspect any reported error. Check the SDK path configuration if the compiler cannot find its libraries. Keep the example deliberately small until the same package also runs on the handheld.

Build a hardware test routine

Test each input independently, including crank movement and its stowed state if the game uses them.
Check text and motion on the real screen under ordinary lighting. A large desktop window can conceal readability problems.
Measure demanding scenes rather than relying on an empty test level. Use the SDK's profiling tools to find expensive work before optimizing it.
Test leaving the game, locking the device and resuming. Check that the intended state is preserved through the supported lifecycle.
Verify sound and controls with the settings players may actually use. Include an accessible alternative when an interaction otherwise requires precise movement.

Save data and release identity

Choose a stable bundle identifier before publishing builds that people will keep playing. Treat changing that identifier as a migration decision. Write down the save schema, include a version field when appropriate and test upgrading an older save on a disposable copy. Simulator data and device data are separate test environments; success in one does not establish migration in the other.

Keep source code, build instructions, asset licenses and a release checklist in version control. Package the compiled game with its version, controls, minimum system requirement and support address. Test the exact archive users will receive on a clean installation, then test updating an existing installation with progress.

Use official sideloading routes to distribute test builds. Preserve personal device progress with the backup workflow before testing save-format changes. Community libraries can help, but their SDK requirements and licenses need their own review.

Sources and review

Reviewed October 11, 2026. The linked manufacturer and project documentation establishes supported behavior. The diagnosis checklists and preservation suggestions are original editorial guidance. Menus, services and project support can change; verify the linked instructions before an irreversible change.