上級

PaperZD

頼むだけでPaperZDの2Dキャラクターアニメーションを作る。スプライトシートからのフリップブック、アニメーションソース、Animation Blueprint、ステートマシン、操作できるキャラクター、プレイ中の確認まで。

Critical Failure StudioのPaperZDは、ほとんどのPaper2Dゲームが使っているアニメーションシステムだ。フリップブックのキャラクター向けに、アニメーショングラフとステートマシンを提供する。FabとGitHubで無料で入手できる。

PaperZD 拡張機能を使うと、Ultimate Engine CoPilotがそれらの構成を作ってくれる。スプライトシートから、プレイ中に歩いて攻撃するキャラクターまで一通りだ。

Unreal Engine 5.7上のPaperZD 2.2.4でテストしている。

必要なもの

PaperZD(プロジェクトにインストールして有効化したもの)。Unrealのプラグイン Paper2D を使うが、これはPaperZDを有効にすると一緒に有効になる。
キャラクターのスプライトシート、または既存のフリップブック。

加えて、PaperZD 拡張機能をオンにしたUltimate Engine CoPilot。

PaperZDがなくても、この拡張機能が害を及ぼすことはない。PaperZDのツールはどれも、プラグインがインストールされているか、有効か、読み込まれているか、そして次に何をすべきかを伝える1つのメッセージで応答する。

セットアップ

FabまたはGitHubから PaperZD をインストールし、プロジェクトで有効にする。Unrealに求められたらエディタを再起動する。
CoPilotで 設定 > 拡張機能 を開き、PaperZD をオンにする。初期状態ではオフになっている。
AIにPaperZDのステータスを確認するよう頼む。PaperZDが見つかったかどうかを報告し、見つからなければ何が足りないかを教えてくれる。

頼めること

「これが騎士のスプライトシート、6列13行。idle、walk、attackのフリップブックを4方向分作って、それ用にPaperZDをセットアップして。」
「Idle、Walk、Attackのステートマシンを追加して。キャラクターが動いているときはWalk、止まったらIdleに戻して、Attackは1回再生したらIdleに戻して。」
「アニメーションがキャラクターの動く向きを向くようにして。」
「移動はWASD、攻撃はSpaceで操作できるキャラクターを作って。後ろにカメラを付けて、キャラクターをスポーンするゲームモードも用意して。」
「walkアニメーションに足音を追加して。」
「ゲームの実行中に、キャラクターを赤いパレットに切り替えて。」

こうした依頼の裏で、AIは次のことができる:

スプライトシートをアニメーションに切り分ける。 1回の呼び出しで、シートがスプライト、フリップブック、アニメーションシーケンス、アニメーションソース、Animation Blueprintになる。複数の方向を持つアニメーションは、1つのマルチディレクショナルシーケンスになる。
アニメーショングラフを作る。 Play sequence、ステートマシン、direction、override slot、boolや数値やenumで選ぶノード、random player、cached animationの各ノードを作り、つなぐ。
ステートマシンを作る。 ステート、コンジット、ジャンプを作り、トランジションは、変数、現在のアニメーションの終了、常に、または一切発火しない設定のいずれかで動かし、優先度と任意の遷移用シーケンスを付けられる。
ノティファイを追加する。 タイムライン上のカスタムイベント、サウンド、Niagaraやパーティクルのエフェクトを追加でき、カスタムノティファイは自分で中身を書ける関数になる。
スキンを追加する。 アニメーションごとの差し替え用フリップブックで、衣装やパレットの切り替えに使え、ゲームの実行中に適用される。
キャラクターを作る。 Animation Blueprintで動く新しいPaperZDキャラクターを作るか、既存のアクターをそれにつなぐ。Level SequenceにPaperZDトラックを追加することもできる。
プレイ中に確認する。 どのシーケンスが再生中か、どこまで進んでいるか、アニメーション変数の値を読み取り、アニメーションを再生、停止、またはジャンプさせて、トランジションを手動でテストする。

避けてくれるミス

PaperZDには、きれいにコンパイルできるのに何も起きない落とし穴がいくつかある。AIはそれを知っている:

新しいトランジションのルールは設定するまで「never」 なので、キャラクターはIdleから一度も出られない。
ルールが読む変数は、どこかで書き込まれていなければならない。たいていはAnimation Blueprintのtickだ。きれいにコンパイルできても、ルールが実際に変わる証明にはならないので、AIはプレイ中に確認する。
シーケンスは、自分のアニメーションソースに属するAnimation Blueprintでしか再生されない。そのため、AIはキャラクターごとのアセットをまとめて管理する。
ステートとトランジションは、1回のバッチでコンパイルされる。編集のたびではなく、まとまった編集の最後に行う。
スプライトシートのグリッドは、上から左から右へ読まれる。AIはPaperZDと同じ方法でセルを数える。

コツとヒント

これらは、PaperZDとCoPilotで小さな遊べる村を作った経験から得たものだ。主人公、村人、スケルトンの敵、うろつくオオカミがいる。Unreal Engine 5.7上のPaperZD 2.2.4でテストした。

特に重要な3つ:

シートの本当の行の並びをAIに伝える。 行を0から数え、どの行がアニメーションで、どの行がそれ以外かを言い、各フリップブックの最初のフレームを開いて確認する。
アクターは絶対に回転させない。 フリップブックは平らなカードなので、向きはアクターを回すのではなく、どのアニメーションが再生されるかで決める。
きれいなコンパイルを信用しない。 現在のアニメーションとその変数を報告するプレイテストを頼む。

シートを正確に伝える

シートのどの行にどのアニメーションが入っているかは、AIには見えない。こちらから伝える必要がある。

PixelLabから書き出したシートは、92ピクセルのセルが6列13行で、各アニメーションに南、西、東、北の順で4方向が入っている。行0は回転ポーズの行で、アニメーションではない。
書き出しには、どの行にどのアニメーションが入っているかを一覧にしたレイアウトファイルが付いてくる。それを使う。順序はキャラクターごとに違う。村では、主人公とメイジはwalkが最初、スケルトンはattackが最初、オオカミはidleが最初だった。
0から数え、回転の行を名指しする。あるセッションでは、プロンプトに「行1から4がwalk」と書いた。AIは1から数えたため、すべてのアニメーションが1行ずれ、主人公は間違った向きを向いた。

行は次のように書く:

各シートは92ピクセルのセルが6列13行。行は0から数える。行0は回転の行なのでスキップする。行1から4がwalk(南、西、東、北、6フレーム)、行5から8がattack、行9から12がidle(4フレーム)。

重要な設定

Pixel artをオン。 テクスチャはnearestフィルタリングでmipなしにして、ピクセルをくっきり保つ。
ピボットは下の中央。 どのフレームでも足が同じ位置に留まる。
フレーム毎秒。 望む速度を指定する。AIはすべてに15を使ったため、4フレームのidleが約4分の1秒でループしてしまった。Idleは6、walkは12、attackは14でちょうどよく見えた。
方向の順序。 マルチディレクショナルシーケンスは、上から時計回りに進む: 北、東、南、西。
配置したアクターの値が優先される。 レベル内のアクターに設定したクールダウンや速度は、Blueprintのデフォルトに勝つ。変更しても何も起きないように見えるときは、配置済みのコピーを確認する。

スプライトをカメラに向け続ける

スプライトが回ったり、傾いたり、真横を向いたりするのを止めた構成は次のとおり:

アクターの回転をオフにする。 Controller yawをオフ、orient rotation to movementをオフ、controller desired rotationをオフ。オンのままだと、カードがアクターと一緒に回り、真横を向くことがある。
yaw 0でスポーンする。 スポーン時のyawが180だと、ワールドに固定されたカメラから離れる向きにカードが傾く。
スプリングアームをワールドに固定する。 Pawn control rotationをオフ、pitch、yaw、rollの継承をオフ、collision testをオフ。pitchは-40、yawは-90でうまくいった。
カードは1回だけ傾ける。 カメラが40度下を向いている場合、スプライトにroll -40を与え、足が床に着くように持ち上げる。
アクターのforwardやrightベクトルではなく、ワールドの軸に沿って動く。
向きはSet Directionalityで示す。 Facingという名前のVector2D変数を渡す。Facingは毎tick速度から書き込み、キャラクターが止まったときは最後の値を保つ。

そのカメラでは、キーは次のように対応する:

D は+Xに動く。Facingは(1, 0)。
W は-Yに動く。Facingは(0, 1)。
A は-Xに動く。Facingは(-1, 0)。
S は+Yに動く。Facingは(0, -1)。

左右や上下が入れ替わって出たら、Facingのその部分の符号を反転する。補正のためにアクターを回してはいけない。

プレイ中にテストする

トランジションは、ルールが変わりうるようになるまで何もしない。 新しいルールは「never」で、変数を読むルールには、その変数を書き込む何か、たいていはAnimation Blueprintのtickが必要だ。現在のアニメーションを報告するプレイテストを頼む。
Facingに初期値を与える。 キャラクターが動いている間だけ書き込まれるので、最初の一歩の前のattackは0を読む。デフォルトを南にすれば直る。
主人公を対象に向かせる。 攻撃が横にいる何かに当たる必要があるなら、振る前にFacingを最も近い敵の方向に設定するようAIに頼む。

実際のセッション

コラボクリップは、CoPilotのチャットで4つのプロンプトで作った。Claude Codeエージェントを使っている。AIは自分でプレイテストを実行し、見つけた問題を直した。時間は1台のマシンでのものだ。

2体のキャラクターをインポートし、idle、walk、attackのステートマシンを用意: 約2.5分。
操作できる主人公(移動はWASD、攻撃はSpace)、スプリングアームのカメラ、ゲームモード、3点の間を歩く村人: 約7分。
追いかけて攻撃するスケルトンの敵、ヒットポイント、画面上の体力カウンター: 約7分。
うろつくオオカミ、集められる薬草、薬草カウンター: 約7分。

見た目は別の作業

AIが作るのはアニメーションとゲームプレイだ。クリップの見た目はAIではなく、レベル側で設定した:

暖かい日差しとランタンの光。
ブルーム、ビネット、ティルトシフト風にする浅い被写界深度。
キャラクターのアンリットなエミッシブマテリアル。

アンリットのマテリアルと固定の露出から始めること。何度も目で露出を調整するのは、得られるものよりも時間がかかった。

制限

シートの各行にどのアニメーションが入っているかは、AIにはわからない。こちらから伝える必要がある。
敵は主人公に向かってまっすぐ歩き、小物を避けるパスファインディングはない。
ちょうど45度の角度では2つの軸が同点になり、アニメーションは東を選ぶ。
体力は0で止まる。死亡を頼まない限り、ほかには何も起きない。
キーを押し続けている途中のアニメーションステートは読み取れず、AIは推測せずにそう伝えた。

権限

読み取りは自由だ。アセット、グラフ、実行中のアニメーションの確認は、確認を求めない。変更は、ほかのすべてのツールと同じように、Ask Before Edit または Auto Edit の設定に従う。

仕組み

プラグイン同士はリンクしない。 拡張機能はリフレクションだけでPaperZDにアクセスする。そのため、Ultimate Engine CoPilotはPaperZDがインストールされていてもいなくても同じようにビルドされ動作し、拡張機能は同じ設計のPaperZDバージョン間で動き続ける。アップデートで何かの名前が変わった場合、ツールは推測せずに、見つからないフィールドの名前を示す。
どこでも同時に。 ツールはCoPilotのチャット、Claude CodeやCursorのような外部MCPクライアント、そしてコーディングエージェントで使える。MCP連携を参照。
39個のツール。 ソース、シーケンス、ノティファイ、スキン、Animation Blueprint、グラフ、ステートマシン、キャラクター、Sequencerのための、オーサリング、検査、プレイ中のツール。

拡張機能の仕組みについては拡張機能を、AIが実行中のゲームをどう確認するかについてはプレイテストを参照。