Playdateでのゲーム開発方法

Playdate のゲーム開発方法は、通常は以下の4系統となります。

Lua + Playdate SDK
Pulp + PulpScript
C + Playdate SDK
それ以外の言語や独自ツールチェーン（多くは非公式で、実質は C や Lua に落とし込む形）

Playdate 公式も、開発ドキュメントとして Lua と C を用意しており、Pulp も別系統の公式ツールとして提供しています。
さらに公式の開発者向けリンク集では、テンプレート、ライブラリ、エンジン、バインディング類も「コミュニティ製・非公式」として案内されています。

Playdateでのゲーム開発方法
関連ページ

結論

結論としては、以下のように環境を選びます。

一番標準的: Lua
一番簡単: Pulp
一番低レベルで速い: C
Rust / TypeScript系など: 使えなくはないが、基本は非公式で、学習コストや保守コストが増えやすい

公式も「多くのゲームは Lua API を使う」「Lua と C が最良の選択肢」とかなり明確に位置づけています。

通常の開発環境

1. Lua + Playdate SDK

これは Playdate 開発の本命です。
公式の基本ドキュメントである Inside Playdate は Lua API を中心にしており、C の説明ページでも「ほとんどのゲームは Lua API を使う」と明記されています。

特徴

Playdate の標準的な開発方法
2Dゲーム制作に必要な API が一通りそろっている
Simulator 上で試しやすい
公式ドキュメントやサンプル、学習資料が多い

向いているもの

一般的な 2D アクション
UI 多めのゲーム
スプライト、タイルマップ、衝突判定、入力処理中心の作品
個人開発や小～中規模のゲーム

開発フロー

SDK を入れる
main.lua を作る
playdate.update() を毎フレーム呼ばれる入口として使う
Simulator で確認
最終的に .pdx 形式のゲームとしてビルドする

Pulp 用のメタデータ編集記事でも、SDK を使う通常開発の最小構成として main.lua を含む Playdate プロジェクトを作り、SDK でビルドして .pdx を生成する流れが示されています。
SDK は macOS / Windows / Linux 向けに提供されています。

長所

公式サポートが厚い
学習コストと表現力のバランスが良い
Playdate の機能に最も素直にアクセスできる

短所

Lua なので静的型付けは弱い
大規模化すると設計の工夫が必要
超低レベル最適化は C より不利

2. Pulp + PulpScript

Pulp はブラウザベースのゲーム作成環境で、画像や部屋、音、簡易スクリプトをまとめて扱えます。
開発者フォーラムの案内でも、Pulp は「インストール不要の一体型エディタ」で、最初のゲームや小さな実験に向くと説明されています。PulpScript には専用のスクリプト言語があり、エディタ内でコンパイルエラーを検出します。

特徴

ブラウザだけで始められる
マップや会話、簡単なイベント駆動型ゲームに強い
コード量が少なく済む
PulpScript という専用の軽量スクリプトを使う

向いているもの

アドベンチャー
ルーム移動型ゲーム
ちょっとしたパズル
プロトタイプ
ドット絵と演出を素早く試したい場合

長所

導入が最も簡単
非プログラマ寄りでも触りやすい
エディタが一体化している

短所

SDK 開発より自由度が低い
Playdate の全機能には触れない
大きいゲームや複雑なアーキテクチャには不向き

公式ヘルプでも、Pulp は多くのことができるが Playdate SDK の全機能にはアクセスできないと明記されています。逆に言うと、「簡単さ」と引き換えに機能が絞られている方式です。

補足: Pulp で作ったゲームも .pdx として書き出され、そこに SDK 側でメタデータや画像などを後から追加編集する高度なやり方もあります。つまり、Pulp → 必要に応じて SDK で拡張という折衷も可能です。

3. C + Playdate SDK

これはネイティブコードで書く方法です。
公式の Inside Playdate with C では、同じコードから Simulator 用の OS 別ライブラリと実機用の bin ファイルをビルドできると説明されています。SDK には C API のサンプルも含まれています。

特徴

Playdate を C で直接扱う
低レベル寄り
パフォーマンスやメモリ制御を詰めやすい

向いているもの

既存 C コードの移植
パフォーマンス重視の処理
ライブラリ資産を活用したい場合
Lua より厳密に構造化したい場合

長所

高速化しやすい
低レベル制御がしやすい
C 資産の流用がしやすい

短所

Lua より書く量が増えやすい
学習コストが高い
Lua ドキュメント前提の知識を求められる場面がある

Playdate のコミュニティでも、Rust バインディングを使う際でさえ「C API の理解が重要」「C API ドキュメントは Lua 側の知識を前提にしている部分がある」と言及されています。つまり C は強力ですが、入口としては Lua より重いです。

それ以外の言語を使う方法

Playdate 公式が強く推しているのは Lua と C です。それ以外は、基本的に非公式のバインディング、トランスパイラ、コミュニティ製エンジンやテンプレートを使うことになります。
公式の開発者向けリンク集でも、そうしたものは「コミュニティの便利リンク」であり、公式サポート対象ではないと明記されています。

Rust

かなり代表的な非公式選択肢です。
ただし実態としては C API へのバインディングを使う形で、Playdate ネイティブに Rust が公式対応しているわけではありません。コミュニティスレッドでもその前提が語られています。

向いている人

Rust に慣れている
所有権や型安全を重視したい
非公式環境でも自力で調整できる

注意点

公式チュートリアルの中心ではない
情報が Lua/C より少ない
SDK 更新時の追随を自分で見る必要がある

TypeScript / statically typed Lua 系

これは多くの場合、

TypeScript 風言語や型付き Lua 方言で書く
Lua に変換する
生成された Lua を Playdate SDK で動かす

という流れです。

つまり Playdate が TypeScript を直接実行するわけではありません。
あくまで「開発体験を良くする前段ツール」です。公式はこうした方法を公式標準にはしておらず、使う場合はコミュニティツール依存になります。

向いている人

Lua の動的型付けが不安
補完や型チェックを強くしたい
ビルド工程が増えてもいい

注意点

変換後 Lua のデバッグが少し複雑になる
Playdate 固有 API の型定義整備が必要になることがある
トラブル時は公式ドキュメントが直接役立ちにくいことがある

独自エンジン / フレームワーク

公式リンク集には、Playdate 向けのライブラリや小規模エンジン、アニメーション支援、スプライト拡張などがまとまっています。
たとえば Noble Engine や AnimatedSprite などがあります。これらは Lua SDK を土台にした補助レイヤーと考えるのが自然です。

環境選定の目安

Pulp を選ぶべき場合

とにかく早く形にしたい
マップ移動・会話・簡単な仕掛け中心
コードよりゲーム内容の試作を優先したい

Lua を選ぶべき場合

Playdate らしいゲームを普通に作りたい
公式情報を最大限使いたい
一般的な個人開発をしたい

C を選ぶべき場合

既存 C 資産がある
処理負荷やメモリ効率を強く意識したい
Lua より低レイヤで組みたい

Rust / TypeScript 系を選ぶべき場合

型安全や言語体験を優先したい
非公式環境でも自己解決できる
保守コスト増を許容できる

現実的なおすすめとしては、

Pulp → Lua → C

の順で考えるのが自然です。

ただし、「ちゃんとしたゲームを継続的に作る」なら、最初から Lua SDK を選ぶのがいちばん無難です。
Pulp は簡単ですが機能上限があり、C は強い代わりに重いです。公式の整理もほぼこの感覚に沿っています。

Playdate 非公式開発まとめ wiki