スプライトシートの作り方｜サイズ・PPU・書き出し

歩行アニメのドット絵は描けているのに、ゲームに入れた瞬間にガタつく、輪郭がぼやける、拡大するとにじむ。
そんなつまずきは、絵そのものよりもスプライトシートの切り方と取り込み設定で起きていることが多いです。
この記事では、1キャラの歩行アニメを4〜8フレームでまとめ、32x32または64x64の固定グリッドでPNG書き出しし、UnityとGodotに崩さず持ち込む流れを一気に整理します。
実際、フレームごとの中心をそろえて固定グリッド化しただけで再生時のガタ付きが消え、Unityでは Compression を None に戻すだけで輪郭のぼやけが収まり、Godotでもフィルタリングを切った途端に拡大時のにじみが消えました。
スプライトシートとテクスチャアトラスの違いから、PNGの安全な書き出し、Unityの PPU・Multiple・Padding・Filter・Compression、Godotの Hframes・Vframes まで押さえれば、ドット絵の歩行アニメは見たままの精度で動かせます。

スプライトシートとは？ゲーム用素材で使われる理由

スプライトシートは、複数の小さな画像やアニメーションの各コマを、1枚のビットマップ画像にグリッド状やタイル状に並べたものです。
歩行、攻撃、待機のように連続したフレームをまとめる用途で定番で、ゲーム用素材ではこの形にしておくと制作と実行の両方で扱いが整います。
単なる「画像を並べた表」ではなく、エンジン側がどのセルを何番目のフレームとして読むかを前提にしたデータだと考えると掴みやすいはずです。

ゲームでスプライトシートが多用される理由は、1枚にまとめることで読み込み対象が減り、アセット管理も一本化できるからです。
個別画像を何十枚も置く構成だと、差し替えや命名、取り込み漏れの確認に手間が増えます。
対して固定グリッドのシートなら、1キャラぶんの歩行アニメが1ファイルに収まり、エンジン側でもまとめて分割して再利用できます。
描画面でも、同じテクスチャを共有するスプライトはバッチ化しやすく、同一シートを複数キャラで使う場面ほど効いてきます。
たとえば 32x32 ピクセルのキャラを同じシートから複数体描く構成では、テクスチャの切り替え回数を抑えやすく、実行時の負担を素直に減らせます。

制作中の感覚としても、固定グリッドのスプライトシートは初心者と相性がいいです。
座標を個別に持たなくても「1セルが32x32」「横に4コマ、縦に2段」のように見たまま整理できるので、あとから見返したときに迷いません。
Unityなら Sprite Mode を Multiple にしてSprite Editorでセル単位に切れますし、Godotでも Hframes と Vframes を設定すれば分割できます。
最初の一歩では、自動パックされた不定形のアトラスより、同サイズのコマを規則正しく並べたシートのほうが事故が少ないです。

サイズ感の目安としては、入門用なら 16x16、32x32、64x64 が代表的です。
本記事では歩行アニメの見栄えと作業量のバランスを取りやすい 32x32 または 64x64 を前提に進めます。
16x16 は情報量を強く絞る必要があり、1ピクセルの差が印象を大きく変えます。
32x32 はシルエットと動きの両立がしやすく、64x64 は髪や服の揺れなども入れやすい、という違いがあります。

保存形式は PNG が無難で推奨されます。
ドット絵は輪郭の硬さと色の境界が命なので、可逆圧縮を使うのが望ましく（例: PNG、ロスレス WebP）、JPEG のような非可逆圧縮は避けるのが安全です。

なお、スプライトシートはTexturePackerのようなツールで自動生成する方法もありますが、歩行アニメの入門では固定グリッドのまま作るほうが理解しやすく、後工程でも扱いやすいのが利点です。
連続フレームを横並びにしておけば、どのコマがどのタイミングかを一目で追えますし、1フレーム 64x64 ピクセルの画像を8枚並べても、フレーム単位のデータ量は小さいままです。
こうした「並び順が読める」ことも、初心者向け素材でスプライトシートが選ばれる大きな理由です。

スプライトシートとテクスチャアトラスの違い

用途の違いと実務上の言い換え

スプライトシートとテクスチャアトラスは、どちらも「複数の画像を1枚にまとめたもの」です。
ただし、実務ではまとめ方と使う場面で少し呼び分けます。
スプライトシートは、同じキャラクターの歩行や攻撃のように、連続したフレームを順番に並べた画像を指すことが多いです。
1コマ目から2コマ目、3コマ目へと再生順が前提になっているので、アニメ素材としての意味合いが強くなります。

一方のテクスチャアトラスは、UIパーツ、アイコン、小物、地形チップ、エフェクト断片のように、連続再生しない素材も含めてまとめた画像という扱いが一般的です。
こちらは「アニメのコマ表」というより、「必要な素材を一枚に詰めた管理用テクスチャ」に近い考え方です。
同じ画像内に、ボタン、剣、木箱、数字フォントが同居していても成立します。

見かける定番の整理です。
Unityで複数要素入りの画像を取り込むときは、Sprite Mode を Multiple にしてSprite Editorで分割する流れになりますが、その元画像が歩行の連番ならスプライトシート、UIや小物を詰めたものならアトラス、と考えると腑に落ちます。
現場では両者を広い意味で同じように呼ぶこともありますが、初心者の段階では「連番アニメならスプライトシート」「バラバラな素材のまとめ画像ならアトラス」と覚えておくと混乱しません。

私自身、最初のうちはこの2つを厳密に分けようとしてかえって迷いました。
ただ、制作フローに落とすと見分け方は単純です。
歩行4コマや8コマを横に並べて再生順まで決めているならスプライトシート、ボタンやアイテムを一枚に集約して必要な場所だけ切り出すならテクスチャアトラス、と整理したら判断が止まらなくなりました。
呼び方の厳密さより、どんな素材をどう切り出すかで考えたほうが実務では前に進きます。

固定グリッドと自動パックの比較

配置方法にも、初心者のつまずきやすさを分ける違いがあります。
スプライトシートは、同じ大きさのコマを縦横に整列させた固定グリッドとの相性がよく、歩行アニメのような連続フレームではこの形がもっとも素直です。
32x32や64x64のセルを並べておけば、どのコマが何フレーム目かを画像だけで追えます。
Unityなら Grid By Cell Size や Grid By Cell Count で切れますし、Offset や Padding、Pivot もグリッド前提で調整できます。
Godotでも Hframes と Vframes を指定するだけで分割できるので、行数と列数が合っていればすぐ再生に持ち込めます。

この導線は実際に触ると差が出ます。
固定グリッドで作っておけば、Godotで Hframes と Vframes を入れるだけで絵が正しく割れますし、Unityでもセルサイズを決めて一括スライスするだけで済みます。
私も最初はフレームごとの座標を意識しすぎて手が止まりましたが、固定グリッドに切り替えてからは「横に何枚、縦に何段か」だけ考えればよくなり、導入の負担が一段下がりました。
見た目と設定項目が一致しているので、ずれが起きたときも原因を追いやすいのです。

対してテクスチャアトラスは、素材ごとの余白を削ったり、サイズの違う画像をすき間なく詰めたりする自動パックと組み合わせる場面が多くなります。
これは空白を減らせるぶん、メモリ効率や管理効率で有利です。
透明部分のトリミングや重複画像の整理まで含めると、TexturePackerのようなツールが得意な領域になります。
ただしこの方式では、画像を見ただけでは各素材の位置と大きさが分かりません。
切り出し用の座標データが別途必要になり、初心者が最初に触るには一段複雑です。

たとえば固定グリッドの歩行シートなら、8フレームを横一列に置いた時点で並び順が完成しています。
64x64のフレームを8枚まとめても、フレーム部分だけなら合計で約128KBなので、連番アニメの管理としては軽量です。
一方で、アトラスは余白削減の効果が見込める代わりに、座標データとセットで扱う前提になります。
UIや小物が増えてきた段階では頼れる手法ですが、最初の一枚としては固定グリッドのほうが扱いを覚えやすく、失敗の場所も限定されます。

初心者に勧める運用開始パターン

入門段階でおすすめしやすいのは、固定グリッドのスプライトシートから始めて、必要が出たらアトラスへ広げる流れです。
歩行アニメを作るなら、同一キャラの連続フレームだけを1枚にまとめる構成がもっとも理解しやすく、エンジンへの取り込みでも迷いが少なくなります。
4フレームでも動きの基本は十分確認できますし、8フレームまで増やすと足運びや重心移動の滑らかさも出しやすくなります。
CLIP STUDIO ASSETSでも1秒間に8枚、8fpsの歩行ループ素材があり、このくらいの粒度は入門の基準としてつかみやすいのが利点です。

Unityでは Multiple で取り込み、セル単位でスライスして並べる。
GodotではAnimatedSprite2Dに SpriteFrames を作り、スプライトシートを Hframes と Vframes で分割する。
この2つは手順の考え方が近く、固定グリッド前提なら「1セルの大きさ」か「分割数」だけで話が進みます。
ピクセルアート案件では PPU の統一も並行して整えると、表示サイズのズレを早い段階で防げます。
16px幅のスプライトを PPU 16 にそろえると、ワールド上では1ユニットとして扱えるので、タイルやキャラの寸法感も揃います。

運用を広げるタイミングは、歩行アニメが増えたときではなく、種類の違う素材が同じ画面に集まり始めたときです。
UI、アイテム、地形チップ、エフェクト断片まで1枚にまとめたくなったら、そこでテクスチャアトラスや自動パッカーを検討すると流れが自然です。
最初から全部を一枚の不定形アトラスに押し込むより、歩行は歩行のシート、UIはUIのアトラスという分け方のほうが、修正箇所と責任範囲が明確になります。

制作が進むと「最初から最適化したほうが良いのでは」と考えがちですが、入門では設定が読めることのほうが価値があります。
固定グリッドなら、画像を見た瞬間に列数と行数が分かり、エンジン側の設定項目とも対応します。
そこで動かせる状態まで持っていき、素材の種類が増えて余白や枚数が気になってきた段階で、テクスチャアトラスやTexturePackerのような自動パックに移る。
この順番なら、概念の違いと道具の役割が自然につながります。

作る前の準備：サイズ・色数・フレーム数を決める

サイズの決め方

歩行アニメの出来は、描き始める前にどの箱へ収めるかで半分決まります。
最初に固めたいのは、1フレームを何px四方で作るかです。
入門で迷ったら、基準は 16x16・32x32・64x64 の3つに絞ると設計がぶれません。

16x16は超小型のキャラクター向けです。
頭身や衣装の情報を削って、歩いている、振り向いた、攻撃したといった動作を記号として読ませる発想になります。
足の入れ替えや腕振りは表現できますが、顔の向きや服のしわまで入れようとするとすぐに飽和します。
抽象化を前提にするとまとまりやすく、タイルベースの小さな画面では強いサイズです。

32x32は、最初の歩行アニメにもっとも収まりがいい寸法です。
頭、胴、腕、脚の関係を保ちながら、ベルトや髪の束、靴の先端といった情報も少し足せます。
情報量と作業量の釣り合いがよく、修正のたびに全身を描き直す負担もまだ軽いので、構造を覚える段階に向いています。
私も新規キャラのラフアニメはまず32x32で組みます。
ここで歩き方と重心移動が成立していれば、ゲームに入れたときの見え方を早い段階で判断できます。

64x64まで上げると、表情差分、髪の揺れ、服の面の向き、陰影の段差まで入れられます。
そのぶん、1コマごとの修正箇所が増えます。
同じデザインを32x32で作ったあと64x64へ拡大移植したことがありますが、32x32では省略していた情報を64x64では埋めなければ輪郭が間延びして見えました。
靴底の厚み、袖口の形、前髪の分かれ目など、見えてしまう情報が増えるからです。
表現の幅は広がる一方で、1フレーム直すたびに全フレームへ反映が必要になり、制作負荷は一段上がります。
最初の1体でいきなり64x64に入るより、32x32で設計を固めてから拡張したほうが、破綻の原因を追い込みやすくなります。

サイズは見た目だけでなく、ゲーム内の縮尺にもつながります。
Unityでは PPU を統一しておくとズレが出にくく、たとえば Asset PPU を16にそろえれば16px幅のスプライトはワールド上で1ユニット幅として扱えます。
こういう基準が先にあると、キャラとタイルの寸法感も噛み合います。
制作中にサイズを行ったり来たりしないためにも、最初の時点で「今回は32x32基準」「ボスだけ64x64」などの線引きを決めておくと後工程が安定します。

歩行ループのフレーム数とFPSの目安

歩行ループは、まず 4〜8フレーム の範囲で考えると組み立てやすくなります。
4フレームは「左足前、通過、中間、右足前」の基本が作れます。
記号性が強いドット絵では、この4枚だけでも歩いている感触は十分に出せます。
管理面も軽く、ポーズの対応関係が明快なので、最初の一本として扱いやすい構成です。

8フレームにすると、足が地面を押す瞬間や、重心が上がる瞬間を細かく刻めます。
歩行の気持ちよさは、単に枚数を増やすことではなく、体の上下動と接地のリズムをどれだけ分解できるかで決まります。
その意味で8フレームは、滑らかさとピクセル感の両立が取りやすい範囲です。
入門の実例としても、1秒間に8枚、8fpsの歩行ループは基準に置きやすく、テンポ感を掴むのに向いています。

FPSは作品全体の解像度とキャラの移動速度に合わせて決めます。
小さな16x16キャラで速く走り回る見せ方なら、1コマごとの差が大きい4フレームでも成立します。
32x32や64x64で足運びを見せたい場合は、8フレームにして変化量を細かくしたほうが自然です。
逆に、フレーム数だけ増やしてFPSを上げすぎると、1枚ごとのポーズ差が読まれないまま流れてしまいます。
ドット絵は補間で滑らかに見せるより、ポーズを読ませるほうが強いので、枚数と再生速度はセットで考える必要があります。

私が最初に歩行ループを組むときは、4フレームで接地と重心移動を確認し、そこから必要な中割りを足して8フレームへ広げることが多いです。
この順番だと、どのコマが役割を持っているかが崩れません。
いきなり8枚を全部描くと、似たポーズが並んでテンポが鈍ることがあります。
骨格になる4枚が先に決まっていれば、増やした4枚は「つなぎ」ではなく「押し出し」や「抜重」の補強として機能します。

セルの統一・透明余白・光源のルール作り

アニメがガタつく原因は、絵が下手だからではなく、フレームごとの基準が揃っていないことが多いです。
ここで最初に固定したいのが、1フレーム＝1セル という前提です。
全フレームでセル寸法を同じにし、中心位置や接地ラインの基準点を厳密に合わせます。
歩行アニメでは、とくに足元のY座標がずれると「跳ねている」ように見えます。
私も以前、見た目ではうまく描けているつもりなのにゲーム上で小刻みに揺れることがありましたが、全コマの接地ラインを同じY座標に固定しただけでガタ付きが消えました。
頭の上下動を入れたい場面でも、まず地面との関係を固定し、そのうえで胴体や肩を動かしたほうが歩行として読みやすくなります。

フレーム境界には 2〜4px程度の余白（経験則） を見ておくと、Bleeding を避けやすくなります。
とくにシート運用では、絵の外側に何もない空間を置くこと自体が保険になります。
実運用では、画像側の余白とエンジン側の Padding 設定を併用すると安定します。

光源も全フレームで統一します。
たとえば左上から光が当たると決めたなら、頭頂や肩のハイライト、脚の影の落ち方は全コマで同じ理屈に従わせます。
あるコマだけ右側が明るい、輪郭の出方が逆転する、といった揺れが入ると、動きより先に絵の不整合が目につきます。
光源の向きが揃っていると、体の向きが変わっても立体感が途切れません。

シルエットの統一も同じくらい効きます。
歩行アニメでは腕や脚を動かすので、毎コマで外形が変わりますが、頭の大きさ、胴の幅、足の接地幅といった主要輪郭はぶらさないほうが安定します。
1枚だけ肩幅が広い、髪のボリュームが減る、靴先が急に長くなると、動いているのではなく別の絵に切り替わったように見えます。
アニメの気持ちよさは中割りの数だけではなく、フレームをまたいでも同じキャラだと認識できる輪郭の維持で決まります。

こうした仕様は、絵を描く前にルールとして書き出しておくと制作中の迷いが減ります。
セルサイズは32x32、歩行は8フレーム、接地ラインは固定、光源は左上、フレーム境界には余白を入れる。
この程度でも基準が言語化されていると、途中で1コマだけ別ルールの絵が混ざる事故を防げます。
ドット絵の歩行アニメは、描き込み量より先に「揃える場所」を決めたほうが結果が安定します。

実践：ピクセルアートの歩行アニメをスプライトシート化する手順

32x32・4フレームの最小構成

32x32で歩行アニメを組むときは、まず1枚目と3枚目を接地の基準にします。
1枚目を左足前、3枚目を右足前に置き、2枚目と4枚目を通過姿勢として挟むと、4フレームでも歩行の往復がきれいにつながります。
ここで効くのが、ポーズを大きく変えるのではなく、1px単位の差分で役割を切り分ける考え方です。
前足と後ろ足の長さを入れ替える、腕の前後を反転する、胴体を1pxだけ傾ける。
その積み重ねだけで、ドット絵は十分に歩いて見えます。

足元は接地している側の足のY座標を全フレームで固定します。
これがずれると、前のセクションで触れたガタつきが再発します。
動きを出したい気持ちで足先を上下させたくなりますが、32x32ではその1pxが跳ねに見えやすいので、地面に触れている足は動かさないほうが安定します。
上下動を入れるなら、胸や肩の位置を1pxだけ揺らす程度で十分です。
体幹の揺れも1px以内に収めると、歩行のリズムは出しつつ、キャラそのものが別人に見える崩れを防げます。

腕振りは脚と同じタイミングで動かすのではなく、脚より1フレームほど遅らせて位相をずらすと自然になります。
たとえば左足が前に出るコマで右腕を前、左腕を後ろに置く基本を守りつつ、通過フレームでは腕を脚ほど深く振り切らず、中間位置に残します。
こうすると、脚の入れ替わりが先に読まれ、そのあとに上半身が追随して見えます。
4フレームしかない構成でも、接地足と腕振りのずらしがあるだけで、棒立ちの切り替え感が薄れます。

私が最初に4フレームを組むときは、輪郭を全部描き直すより、1枚目を複製して足と腕の前後関係だけを1pxずつ入れ替えていく方法をよく使います。
小さいセルでは、描き足す量より削る量のほうが効きます。
靴先を1px前に出し、後ろ足のかかとを1px上げ、腕の先端を1px引くだけでも、静止画の印象が歩行へ切り替わります。

64x64・8フレームで滑らかさを上げる

64x64では、4フレームの骨格を保ったまま中間の役割を増やせます。
8フレームにする場合は、左足前と右足前のあいだを単純に等分するのではなく、体重移動を2段階に分けると歩行の説得力が出ます。
接地して押し出す瞬間、体が前へ乗る瞬間、足が抜ける瞬間、次の接地へ落ちる瞬間を分けて考えると、各コマの意味がはっきりします。
これで「枚数は多いのに似た絵が並ぶ」状態を避けられます。

8フレーム構成では、腕と脚の“抜き”フレームを入れられるのが強みです。
接地フレームの次に、後ろ足のつま先がまだ地面に残っているコマを置き、その次のコマで足が地面から離れる、という順にすると脚運びが滑らかになります。
腕も同様で、前に振り切った直後にすぐ反転させず、いったん中央へ戻るコマを用意すると、振り子の重さが出ます。
ここでも差分は数ピクセル単位ではなく、基本は1pxずつ積み上げるほうがピクセル感が保てます。

頭部の上下動は入れても1px程度に留めるのがまとまりやすいのが利点です。
64x64になると情報量が増えるぶん、頭を大きく動かしたくなりますが、揺れ幅を増やしすぎると「歩いている」より「上下に跳ねている」が先に見えてしまいます。
代わりに、腰や骨盤まわりの位置関係で重心を見せると、歩行の量感がきれいに立ちます。
私自身、64x64の8フレームで重心の落ちを1pxだけ強めたことがありますが、それだけで足が地面を踏んでいる感触が増し、同じキャラでも体重が乗ったように見えました。
ドット絵では1pxの沈み込みが誇張ではなく、読ませるための調整として機能します。

1フレーム64x64のRGBA8は約16KBで、8フレーム分をまとめても約128KBです。
この程度なら1キャラの歩行ループとしては軽く、個別画像で切り替えるより、1枚のシートに収めたほうが描画切り替えの見通しがよくなります。
作画段階でも、全フレームを横に並べて見ると頭頂、肩線、接地位置のズレを一目で拾えるので、修正の往復が短くなります。

横一列/グリッド配置とPNG書き出し

作画が終わったら、各フレームを固定セルに流し込みます。
32x32の4フレームなら横一列で128x32、64x64の8フレームなら横長1列でも扱えますし、縦方向に折り返した等間隔グリッドでも問題ありません。
私は歩行アニメだけのシートは横一列に統一することが多いです。
UnityでもGodotでも、左から順に読ませる前提が崩れないので、分割指定の時点で迷いが減ります。
実際、横一列に揃えてからはUnityのSprite Editorでセルサイズを入れる作業も、GodotのAnimatedSprite2DでHframesを設定する作業も頭の中の並びと一致し、試行錯誤の回数が目に見えて減りました。

グリッド配置を選ぶ場合も、セル寸法と並び順はきっちり固定します。
歩行、攻撃、待機を同じシートに入れるなら行ごとにアニメーションを分ける設計も有効ですが、歩行だけを切り出して検証する段階では、横一列のほうがフレーム順を追いやすく、差分確認も速く進みます。
どちらの配置でも、各セル間に透明のPaddingを入れた版を別に持っておくと事故を避けやすくなります。
フレームの周囲に2pxの透明余白を確保しておくと、拡大表示やエンジン側のスライス時に隣接コマの色を拾いにくくなります。

書き出し形式は背景透過のPNGが基準です。
可逆圧縮なのでドットの輪郭が変質せず、1pxの差分をそのまま保てます。
ここで見落としたくないのが、ツール側の書き出し設定です。
アンチエイリアスが有効になっていると境界に半透明が混ざり、色の自動最適化でパレットが変わると、意図した輪郭や中間色が崩れます。
保存前に、拡大プレビューで輪郭がにじんでいないか、書き出し後に再読み込みして同じ絵に見えるかを見ておくと、後工程での修正が減ります。

シートをまとめていくと、サイズ管理にも目を向ける必要が出てきます。
モバイル向けの実務では、ひとつの大判シートを2048x2048以下に収めると運用が安定します。
歩行だけならここまで大きくなることは少ないものの、複数キャラや複数方向をまとめ始めると一気に膨らみます。
4096x4096で回す現場もありますが、差し替えが頻繁な開発では、巨大な1枚に詰め込むより、用途ごとに分けたほうが更新の手間を抑えられます。
1024x1024のRGBA8でもVRAM上では約4MBになるので、見た目よりメモリを使います。
歩行アニメのようにまとまりが明確な素材は、キャラ単位や動作単位でシートを分けておくと、管理と差し替えの両方で破綻しません。

Unityで使うときの設定：Sprite Mode・PPU・Padding・Compression

Sprite Editorでのスライス手順

Unityへ取り込んだら、まず Import Settings で Texture Type を Sprite（2D and UI） に合わせ、Sprite Mode は Multiple を選びます。
1枚のPNGの中に歩行フレームが並んでいる前提なので、Single のままだと1枚絵としてしか扱えません。
適用後にSprite Editorを開き、そこでセル単位の分割を行います。

固定グリッドで作った歩行シートなら、分割方法は Grid By Cell Size か Grid By Cell Count のどちらかで決まります。
たとえば 32x32 のフレームを横一列に並べたなら Cell Size で 32x32 を入れるほうが直感的です。
列数と行数だけ先に決まっているシートなら Cell Count を使うと、1コマの大きさを逆算して切れます。
ドット絵の歩行素材は 16x16、32x32、64x64 の固定セルで組むことが多いので、この2つを覚えておくと詰まりません。

ここで見落としやすいのが Offset と Padding です。
Offset はスライス開始位置の原点、Padding は各セルの間隔です。
セルの左上からぴったり詰めて並べた画像なら Offset は 0,0 で、そのまま切れます。
いっぽうで、書き出し時に透明余白を挟んだシートでは Padding にその値を入れないと、境界が1コマずつずれていきます。
前の工程で透明余白を入れておくと安全だと書いたのは、ここでの設定と噛み合うからです。
とくに拡大表示やカメラのズームが入る場面では、隣のフレームの色を拾う事故が起きやすく、Padding を正しく扱うだけで輪郭の汚れを減らせます。

歩行アニメのように全フレームが同サイズなら、自動検出よりグリッド指定のほうが結果が安定します。
私も最初は Auto Slice に任せることがありましたが、透明部分の取り方でフレームごとの矩形が微妙に変わり、あとでPivot合わせに余計な時間を取られました。
固定セルで描いた素材は、固定セルのまま切るほうが後工程まで一直線です。

PPU・Padding・Pivotの整理

Unityでピクセルアートを崩さず扱ううえで、スライスの次に効いてくるのが PPU（Pixels Per Unit） です。
これは 1 Unityユニットを何ピクセルとして扱うか を決める基準で、画像のピクセル寸法とワールド上の大きさを結びつけます。
256px 幅の画像を PPU 128 にすると、ワールドでは幅 2 ユニットとして扱われます。
逆に、256px のタイルを 1 ユニット幅として置きたいなら PPU は 256 です。
アイソメタイルの例で 256px 基準が使われるのも、この対応がそのまま効くからです。

歩行キャラでは、32px のキャラを 1 ユニット幅にしたいなら PPU 32、16px タイルを 1 ユニットで扱いたいなら PPU 16 という決め方になります。
2D Pixel Perfectを使う場合も、Assets PPU はこの前提で揃えます。
私はプロジェクトの途中で PPU が 16、32、64 と混ざったことがあり、そのときはキャラと地形のサイズ感がシーンごとにぶれました。
PPU を1つに統一してからは、カメラ距離や拡大率を変えても見た目の基準が崩れず、マップ上のタイル幅とキャラの頭身が安定しました。
ドット絵で「なんとなく大きさが合わない」と感じる場面は、絵の問題ではなく PPU の不統一で起きていることが多いです。

Padding はスライス時の話だけで終わりません。
シート自体に透明余白があり、さらにUnity側でも正しく Padding を読むと、境界のにじみ対策が二重で効きます。
ドット絵は1pxの色漏れでも輪郭が崩れて見えるので、セルとセルの距離を数字で管理しておく価値があります。

Pivot も同じくらい揃えておきたい項目です。
Pivot はスプライトの基準点で、Center、Top Left、Bottom Center などを選べます。
歩行アニメでは、見た目の中心よりも 接地の基準をそろえる 発想が有効です。
人型キャラなら Bottom Center に統一すると、地面との接点がぶれにくくなります。
各フレームで頭や腕の形が変わっても、足元の基準が同じなら再生時の“ガタ付き”が出にくくなります。
逆にフレームごとに矩形サイズやPivotがずれると、絵は正しいのにアニメだけ上下左右へ跳ねます。
私はこのズレを作画ミスだと思って直していたことがありますが、実際には Pivot をそろえたら止まりました。
接地系のアニメは、絵の修正より先に基準点を疑うほうが早いです。

Filter/Compression/Max Sizeの確認ポイント

見た目を崩しやすい設定は、スライスよりむしろインポート後の画質項目です。
ピクセルアートでは Filter Mode は Point が基本です。
Nearest 相当の補間になるので、拡大してもドットの輪郭が立ちます。
Bilinear や Trilinear だと周囲の色を混ぜて表示するため、1px線や角のエッジが溶けたように見えます。
Scene ビューでは気づきにくくても、Game ビューでカメラを引いたり寄せたりすると差がはっきり出ます。

Compression は None にしておくのが安全です。
圧縮が入ると、透明境界や高コントラストの輪郭で色がにじみやすくなります。
私も一度、線の周囲にうっすら別色が回って見える状態に悩まされましたが、Compression を None に戻した時点で輪郭の滲みが消え、元のPNGで見えていたエッジに戻りました。
ドット絵の輪郭は1px単位で読ませているので、圧縮で生じたわずかな色混じりでも印象が変わります。

Max Size も埋もれがちな項目です。
ここがシート解像度より小さいと、インポート時に縮小され、正しく切ったはずのセルが内部で別解像度になってしまいます。
たとえば大きめのシートを扱っているのに Max Size が足りないと、にじみの原因を Filter や Compression だと思って設定を触っても直りません。
元画像の解像度をそのまま保持できる値にしておく必要があります。
大判シートをまとめるときは、この項目だけで輪郭の見え方が変わります。

表示確認では、2D Pixel Perfectを入れているかどうかに関係なく、Scene と Game の両方で拡大縮小した状態を見ます。
ドット絵はエディタ上で止まって見える瞬間より、カメラ移動やズームが入ったときに粗が出ます。
PPU を統一し、Filter Mode を Point、Compression を None にした状態で見たとき、輪郭がそのまま立っているならインポート設定は概ね揃っています。
ここまで整うと、歩行アニメをシーンへ置いた瞬間に「絵は合っているのに表示だけ崩れる」という詰まり方が減ります。

Godotで使うときの設定：Hframes・Vframesとピクセルパーフェクト

Texture読み込みとHframes/Vframes

Godotで歩行シートを使うときは、まず画像をテクスチャとして読み込み、AnimatedSprite2Dの Sprite Frames にSpriteFramesリソースを割り当てます。
そこから下部の編集パネルでシート画像を追加し、横の分割数を Hframes、縦の分割数を Vframes に入れる流れです。
なお、SpriteFrames の編集UIや「Separation」に相当する扱いはバージョンやエディタ実装で差が出ることがあるため、使用バージョンの公式ドキュメントを確認してください。

この設定で効いてくるのが、書き出し段階でグリッドをきっちり揃えておくことです。
たとえば 32x32 や 64x64 のセルで歩行フレームを並べたシートなら、Hframes と Vframes をその並びに合わせた瞬間、プレビューが即座に正しい区切りに変わります。
私も固定グリッドで整えたシートを入れたとき、分割数を入れただけで崩れずに並び、切り直し不要でそのまま確認に進めました。
逆に列数を1つでも誤ると、参照するフレーム位置がずれて別のコマを拾うので、見た目は「再生できているのに動きだけおかしい」という状態になります。

シートの管理という意味でも、歩行のような連続フレームは1枚にまとめておくと扱いが安定します。
8フレームの 64x64 ピクセルを1シートに収めても、フレーム総量としては軽く、読み込み後の切り替えも素直です。
モーション単位で画像が散らばる構成より、列と行で把握できるシートのほうが、修正や差し替えの場所も見失いません。

AnimatedSprite2Dでの再生設定

分割できたら、SpriteFrames側でアニメーション名、フレーム順、Speed(FPS)、ループ設定を整えます。
歩行ループなら、左から右へ並んだ順に取り込み、そのまま再生して足運びが自然につながるかを見るのが基本です。
1秒間を8枚で回す素材なら 8fps で並べると意図どおりのテンポになりやすく、ドット絵の歩行では速すぎず遅すぎない基準として扱いやすい数字です。

AnimatedSprite2Dは play() と stop() で制御でき、Inspector 上でも現在のアニメーションを切り替えられます。
まずは待機と歩行を分けるより、歩行ループ単体で違和感がないかを見るほうが早いです。
ドット絵は1コマごとの差が小さいので、フレーム順が1枚入れ替わっただけでも、腰が跳ねる、肩が逆に振れる、足が滑るといった崩れが出ます。
再生速度を先に詰めるより、順番が正しいか、同じコマを重複させていないかを見たほうが原因を切り分けられます。

ここでも 中心と接地基準の統一 が効きます。
前のセクションで触れたUnityの Pivot と考え方は同じで、Godotでもフレームごとに見かけの中心が揺れていると、アニメ自体は正しくてもキャラ全体がガタついて見えます。
私は歩行アニメを組んだとき、再生順もFPSも問題ないのに上下に跳ねることがありましたが、原因は足元の基準が各コマでずれていたことでした。
胴体の中心ではなく、接地位置を揃える意識でシートを作っておくと、エンジン側で余計な補正を入れずに済みます。

にじみ防止の基本チェック

Godotでドット絵をそのまま見せたいなら、まず テクスチャのフィルタリングを無効 にします。
補間が入った状態では、拡大したときに隣接色が混ざり、輪郭の外周がぼけて見えます。
Nearest 相当の表示に切り替えると、ドットの境界が角まで立ち、1px 線の読みやすさが戻ります。
私も読み込み直後に少し溶けたように見えたシートが、フィルタリングを切った瞬間にエッジの形を保ったまま表示されるのを確認しました。
ドットの境目がシャープに見える変化は、静止画でも再生中でもすぐ分かります。

あわせて、ピクセルパーフェクト系の設定 と拡大率の整合も見ておきたいところです。
カメラ倍率や表示スケールが半端になると、絵自体は正しくてもサンプリング位置が揺れて、移動中だけ輪郭がにじんで見えることがあります。
シートの切り方より表示側のスケールが原因になっている場面は多く、歩行アニメではとくに横移動で差が出ます。
静止時に綺麗でも、移動しながらの見え方まで含めて揃っている状態が基準です。
拡大率やカメラ倍率が半端だと、サンプリング位置がズレて移動中に輪郭がにじんで見えることがあります。
表示側の拡大縮小やピクセルパーフェクト設定と、シートの切り方の両方を確認してください。
加えて、シートの境界や各フレームの配置に微細なズレがあると隣接フレームの色が混ざることがあるため、画像側のセル配置も点検することを推奨します。

よくある失敗と対策

サイズ・中心・余白のチェックリスト

スプライトシートで最初につまずきやすいのは、絵の出来よりも各コマの条件が揃っていないことです。
とくにセルサイズのばらつき、中心位置のずれ、余白不足は再生時にガタつきや色の混入（にじみ）となって表れます。
以下のチェック項目を順に確認して、原因を切り分けてください。

中心位置のぶれも、見た目のガタ付きに直結します。
頭の位置は揃っているのに、足元の接地が上下していたり、逆に足元は揃っているのに胴体の中心が左右に流れていたりすると、アニメ自体は合っていてもキャラ全体が震えて見えます。
私も一度、再生すると妙に落ち着かない歩行になったことがあり、原因を追うと足先ではなく頭頂部が毎フレーム 1px ずつずれていました。
静止画では見逃せる差でも、連続再生するとその 1px が大きなガタ付きとして出ます。
ガイド用の基準線を引いて、頭、腰、接地のどこを基準にするかを先に決めたら、見た目の揺れはそこで収まりました。
Unityなら Pivot、Godotならフレームの中心解釈と接地位置の整合を同じ考え方で揃えると崩れません。

余白不足で起きるにじみも、初心者が見落としやすい判断材料になります。
セル同士をぴったり詰めて並べると、拡大表示や切り出し時に隣のフレームの色を拾ってしまい、輪郭の外に別コマの色がうっすら出ます。
画像側でセル間の Padding を 2〜4px（経験則） 取っておくと、この色漏れを抑えやすくなります。
加えてUnityのスライス設定でも Padding を入れておくと、画像上の余白とインポート時の切り分け条件が一致します。

管理面では、シートを大きくしすぎない意識も効きます。
1枚に詰め込みすぎると差し替えのたびに全体を触ることになり、作業の見通しが悪くなります。
モバイル向けでは 2048x2048 を超える大判シートは扱いが重くなりやすく、用途によっては 4096x4096 の運用もありますが、歩行や待機のような基本モーションは分割して持ったほうが修正箇所を追いやすくなります。
1024x1024 の RGBA8 テクスチャでも展開時はおよそ 4MB なので、1枚にまとめれば何でも得というわけではありません。

チェックするときは、項目を個別に切り分けると原因が見えます。

• 1コマだけセルサイズが違っていないか

書き出し後に絵が崩れる原因は、保存形式と表示設定に集中します。
まず避けたいのが JPEG 保存です。
ドット絵は輪郭の境界が情報そのものなので、ブロックノイズや色のにじみが入る形式と相性がよくありません。
歩行アニメのように同じ色面が続く素材でも、JPEG にした瞬間にエッジの周囲へ別色が混ざり、切り出したあとに汚れとして残ります。
保存は PNG が前提です。

補間設定も、見た目を一気に変えます。
Bilinear のような補間が有効だと、1px 単位で置いた輪郭がぼやけ、ドットの角が丸く見えます。
Unityでは Filter Mode を Point、Compression を None にしておくと、ピクセルの境界がそのまま出ます。
ここで圧縮まで入れると、元画像が PNG でも表示時に輪郭が鈍ります。
静止画では許容できても、アニメ再生で足や腕が交互に動くと、輪郭の甘さがちらつきとして見えてきます。

フレーム数を増やしすぎて管理が崩れるパターンもよくあります。
歩行は枚数を足せば滑らかになるわけではなく、12枚以上に増えたあたりで、どのコマが効いていてどのコマが重複か分からなくなりやすいのが利点です。
まずは 4〜8 枚で1周を成立させるほうが、修正点が明確に見えます。
実際、1秒間を 8 枚、8fps で回す構成は歩行ループとして収まりがよく、中間フレームは必要な違和感が残ったときにだけ足すほうが破綻しません。
自動補間で枚数だけ増やす方法は、ピクセルの置き方まで補ってくれるわけではないので、ドット感が崩れやすくなります。

GodotでもUnityでも、設定名は違っても見る場所は同じです。
画像は PNG、表示は Nearest 相当、圧縮は切る、という軸を固定しておくと、どの段階で崩れたか切り分けやすくなります。
もし再生したときだけぼやけるなら、絵の問題ではなく補間設定を疑うほうが早く、静止時だけ正常で移動中ににじむなら拡大率やピクセルパーフェクト側の整合を見ると原因が絞れます。

書き出しまわりで見るポイントは次の通りです。

• 保存形式が JPEG ではなく PNG になっているか確認してください。
• Filter Mode が Point になっているか確認してください。
• Compression が None になっているか確認してください。
• 自動補間で輪郭がぼやけていないか確認してください。
• アニメ枚数を増やしすぎて、順番と役割の管理が崩れていないか確認してください。
• 大判シートになりすぎて、読み込みや差し替えの負担が増えていないか

次に作るべきゲーム用素材

歩行アニメを1本シート化できたら、次に手を付ける素材はもう見えています。
そこで止めずに、同じ設計思想のまま周辺素材へ広げると、ゲーム全体の見た目と実装が噛み合っていきます。
私自身、歩行の次に何を増やすかで迷ったとき、歩行から待機、待機から攻撃という順で伸ばしたほうが、ポーズの基準線と重心の考え方を流用できて手戻りが減りました。
難度が少しずつ上がる並びなので、いきなり派手な攻撃演出へ飛ぶより、作業の破綻が起きにくい流れになります。

アニメ拡張

まず横展開しやすいのは、待機（Idle）、攻撃（Attack）、被弾やダメージのリアクションです。
歩行で作った頭・胴体・足元の基準が揃っていれば、待機はその延長線上で呼吸や揺れを足すだけで成立し、攻撃ではシルエットを一度大きく崩しても戻り先を見失いません。
被弾モーションも、前のめりか後ろのけぞりかを決めておくと、戦闘中の読み取りが安定します。

ここで一緒に作っておきたいのがエフェクト素材です。
たとえばヒットスパーク、斬撃、着地時の土煙、魔法の発光といった短いアニメは、キャラ本体より小さなセルでも成立します。
キャラだけ丁寧に作っても、攻撃が当たった瞬間の光や衝撃が弱いと、ゲーム内では手応えが出ません。
逆にエフェクトを最小限でも揃えると、同じ攻撃アニメでも見栄えが一段締まります。

背景や地形へ進めるなら、タイルセット化が自然な次の一歩です。
16x16 や 32x32 のタイルで床、壁、段差、小物を切り出していけば、キャラで使ってきた固定グリッド運用がそのままマップ制作に転用できます。
Unityで 16px を 1 ユニットとして扱う設計にしておけば、タイル幅とワールドの区切りが一致し、キャラと背景の縮尺がぶれません。
歩行アニメを整えた時点で、すでにマップ素材の下地もできています。

UI素材

ゲームとして形にする段階では、UI素材も並行して揃える価値があります。
ボタン、アイコン、カーソル、フレーム、ゲージの端パーツなどを個別PNGのまま増やすと、試作の序盤は回っても、後で差し替え場所が散らかります。
UIはアニメキャラよりサイズも形も不揃いになりやすいので、ここではスプライトシートよりテクスチャアトラスの発想が向いています。

実務では、同じ画面で同時に使うボタン類とアイコン類をまとめて1枚のアトラスに収めておくと、管理の軸がはっきりします。
たとえばメニュー用のボタン、所持品アイコン、カーソルの先端、チェックボックスのオンオフを1セットとしてまとめれば、UI改修のたびに探す場所が固定されます。
アニメ用は等間隔のグリッド、UI用は不定サイズを含むアトラスという切り分けにすると、素材の役割ごとに整理できます。

スタイルガイド

素材が増え始めたら、見た目の統一は記憶ではなく文書で持つ段階に入ります。
ここで作っておきたいのが、プロジェクト用のスタイルガイドです。
内容は難しいものではなく、セルサイズ、PPU、Padding、使用パレット、光源方向、Pivot の基準位置を1枚にまとめるだけでも効きます。
人が増えなくても、自分で数週間後に触り直したときのズレ防止になります。

とくに PPU と Pivot は、あとから無言でズレやすい項目です。
Unityではアセット全体で PPU を揃えておくと、ピクセルパーフェクト運用の前提が崩れませんし、Godotでもフレームの切り方と中心解釈を一定にしておくと、SpriteFrames に追加したアニメ間で位置合わせが楽になります。
光源方向まで決めておくと、キャラ、タイル、UIアイコンのハイライト位置が揃い、別日に描いた素材でも同じゲームの部品として見えます。

外部ツール

Asepriteはドット絵の作画、フレーム管理、アニメ確認、シート書き出しまでを1本で進めやすく、歩行から待機、攻撃への拡張でも作業の重心を保ちやすい道具です（メニュー名称や逐語的な手順はバージョン差があるため、必要に応じて公式ドキュメントを参照してください）。
一方で、UIや小物、サイズ違いの素材が増えてきたら、TexturePackerの自動パックが効いてきます。

トリミングや重複検出を使うと、似た部品を含むアトラスの整理が進み、無駄な余白を減らしながらデータをまとめられます。
1枚の大きなシートは一元管理の安心感がありますが、更新が頻繁な段階では差し替え単位が大きくなり、かえって手が止まります。
将来的に関連記事を追加して内部リンクを増やすことで、読者の回遊と参照利便性が向上します。