Godot ドット絵設定と素材読み込み｜ぼやけない表示の最短手順

Godot 4.xでドット絵ゲームを始めると、最初につまずくのは絵作りそのものより、にじみ・ブレ・半端な拡大です。
実際、16x16の歩行スプライトをLinearのまま拡大したときは縁が溶けたように見えましたが、Default Texture FilterをNearestへ切り替えた瞬間、1pxのアウトラインがくっきり戻り、見え方の前提が一気に整いました。
この記事は、これからGodotでピクセルアートを扱う人に向けて、初期設定からPNGやスプライトシートの読み込み、Sprite2DAnimatedSprite2DとTileMapLayerでの実運用までを最短距離で整理する内容です。
基準解像度を320x180にしてviewportの3x拡大で960x540にそろえると、タイル境界は長方形に崩れず正方形のまま保たれ、画面全体にレトロな密度感が揃います。
ドット絵ではフィルタ設定だけでなく、Stretchの選び方、整数スケーリング、座標の整数化、カメラとUIの混在まで含めて設計しないと、あとから見た目が破綻します。
どちらのStretch modeが正解かではなく、画面全体を低解像度で統一したいのか、くっきりしたスプライトと高解像度UIを両立したいのかで選ぶのが筋です。
その判断軸ごとに、ピクセルアート特有の落とし穴を踏まずに進める手順をこのあとまとめていきます。

Godotでドット絵ゲームを始める前に押さえたい基本

Godotでドット絵ゲームを始めるときは、絵そのものより先に、エンジン側の前提をそろえることが仕上がりを左右します。
Godot 4.xではテクスチャフィルタ、Stretch、座標の扱いが噛み合ってはじめて1pxの線が意図通りに立ち、ここを曖昧にしたまま進むと、あとでスプライトもタイルも同じ種類のにじみに悩まされます。

Godotの特徴と現在のバージョン

GodotはMITライセンスで公開されているオープンソースのゲームエンジンで、2Dと3Dの両方に対応しています。
一般公開は2014年で、エディタはWindows、macOS、Linuxで動作し、書き出し先もPC、モバイル、Webまで広く押さえています。
ドット絵ゲームの文脈では2D機能ばかりに目が向きますが、構造の基本はノードとシーンです。
キャラクター、UI、マップ、カメラをそれぞれノードとして積み上げる考え方なので、画像を読み込んで置くだけの段階から、のちのアニメーションやTileMapLayerまで同じ発想でつながります。

この記事ではGodot 4.x系を前提に話を進めます。使用中のバージョンに合わせて公式ドキュメント（GitHub Releases

なぜ初期設定でドットがぼやけるか

ドット絵が初期状態で甘く見える理由は、ひとつの設定ミスではありません。
まず、テクスチャフィルタが線形補間のままだと、拡大時に隣り合うピクセルの色が混ざります。
さらにStretchで画面全体を拡大する場面でも再サンプリングが入るため、素材単体では崩れていないのに、表示結果だけがにじんで見えることがあります。
そこへオブジェクトやカメラの座標が小数で動くと、ピクセル境界に半端な位置で描かれ、1px線の輪郭が揺れます。

この症状は、実際に小さな素材を拡大すると一目でわかります。
デフォルト設定のまま32x32のアイコンを200%表示したとき、スクリーンショットでは本来カチッと止まるはずの外周が少し溶けたように見え、角の黒線が1段階だけ灰色を挟んだような印象になります。
等倍では気づきにくいのに、2倍にした瞬間だけ境界が甘くなるのは、元画像ではなく表示経路の問題が表面化しているからです。

Asepriteから書き出したPNGでも同じです。
背景透過のキャラクターに1pxのアウトラインを付けた素材は、Nearestを当てる前だと輪郭の外側にうっすら色がにじみます。
詳しい書き出し設定やAsepriteの基本操作については、当サイトの解説「Aseprite 使い方｜初心者向け 基本操作と便利機能」を参照してください。

この記事の前提と読み進め方

ここから先は、ドット絵向けの設定を最短距離で固める流れに絞ります。
順番は、プロジェクト設定、素材読み込み、表示確認、アニメーション、TileSetの順です。
先にアニメーションやマップ制作へ進むと、あとからインポート設定を直したときに見え方が変わり、フレーム単位の調整やタイル境界の確認をやり直すことになります。

素材読み込みではPNGやスプライトシートをどう扱うかに触れ、表示確認では基準解像度とStretchの噛み合わせを見ます。
そのうえで、キャラクターならSprite2DやAnimatedSprite2D、複数プロパティまで含めるならAnimationPlayer、背景や地形ならTileSetとTileMapLayerへつなげます。
ドット絵ゲームでは「表示が合ってから動かす」という順序のほうが手戻りが少なく、UIを高解像度で重ねるのか、全体をレトロな低解像度で統一するのかという判断も、この並びで読むと整理しやすくなります。

まず行うべきプロジェクト設定｜解像度・Stretch・Nearest

ドット絵の見え方は、素材を入れる前のプロジェクト設定でほぼ土台が決まります。
ここで基準解像度、Stretch、テクスチャフィルタ、座標の扱いを先にそろえると、スプライトもタイルも同じルールで表示され、あとから「この素材だけぼやける」「UIだけ妙に浮く」といったズレを切り分けやすくなります。
最短でくっきり表示へ持っていくなら、まずは4項目だけ固定してから作業を進めるのが筋です。

基準解像度を決める

最初に決めるのは、ゲームを何ピクセルの世界として設計するかです。
Project SettingsのDisplay > Window > SizeでWidthHeightを設定し、この値をゲーム側の基準解像度にします。
ここが曖昧なまま素材制作やUI配置を始めると、あとで文字サイズ、タイルサイズ、カメラの見え方まで連鎖して調整が必要になります。

基準解像度として定番なのは、16:9なら320x180か640x360、クラシックな比率を意識するなら320x240です。
320x180は情報量を絞りやすく、1マス16x16のタイルを置いたときも画面密度が素直にまとまります。
640x360は同じ16:9でも表示できる情報が増えるので、少し広いマップや細かいUIを入れたい場面に向きます。
320x240は4:3の画面設計と相性がよく、古いPCゲームや家庭用ゲーム機寄りの雰囲気を作りたいときに収まりが良い寸法です。

この基準解像度は、配信や録画時の最終サイズではなく、あくまでゲーム内部の原寸です。
私自身、320x180を先に決めてからレイアウトを組むと、16x16や32x32の素材が画面に何個並ぶかを即座に読めるので、背景密度とUIの占有面積を同じ物差しで判断できます。
基準解像度を後回しにすると、1pxの線が立っていても画面全体の設計がぶれます。

Stretch modeの選択と整数スケーリング

基準解像度を決めたら、Project Settings > Display > Window > StretchでModeとAspectを設定します。
初期値として押さえやすいのは、Modeをviewportまたはcanvas_items、Aspectをkeepにする構成です。
ここで迷うポイントは、どちらが正解かではなく、画面全体を低解像度で統一したいのか、ゲーム画面と高解像度UIを共存させたいのかという優先順位です。

viewportは、基準解像度でいったん全体を描画し、その結果を拡大して見せる考え方です。
レトロゲームらしい均一な粗さを保ちやすく、マップ、キャラ、エフェクト、UIまで同じ密度に寄せやすい反面、粒子表現や細い文字もまとめて荒く見えます。
320x180をviewportで組み、3xの960x540にそろえたときは、タイルの水平1pxラインも垂直1pxラインも崩れず、床の境界が途中で太ったり痩せたりしませんでした。
整数倍で拡大したぶん、1ピクセルがそのまま3x3の正方形として伸びるので、縦横比1:1が保たれます。

canvas_itemsは、ウィンドウ解像度側で描画しつつ、2D要素の基準として内部解像度を参照する考え方です。
こちらは高解像度UIや滑らかなカメラ移動と合わせやすく、現代的な見た目を混ぜたい構成に向きます。
その代わり、意図を整理しないまま使うと、ゲーム側はドット絵なのにUIだけ別ルールで拡大され、画面全体の密度が揃いません。
たとえばゲーム部分のスプライトはNearestでくっきり保ちつつ、メニュー側だけ高解像度のTextureRectを使って文字やパネルを細かく表示すると、戦闘や移動シーンはピクセル感を残したまま、装備画面だけ読みやすく保てます。
こうした役割分担を最初から想定するなら、canvas_itemsのほうが収まりやすい構成です。

ここで一緒に押さえたいのが整数スケーリングの考え方です。
基準解像度が320x180なら、運用する表示サイズは2xの640x360、3xの960x540、4xの1280x720のように、整数倍でそろえるのが基本になります。
半端な倍率で引き伸ばすと、1ピクセルが2.5ピクセル相当の幅で配分される場面が出て、線の太さがフレームごとに揺れます。
ドット絵で見た目の芯になるのはこの1:1の縦横比なので、Stretchの設定は拡大方式ではなく、ピクセルを何倍で並べるかという視点で見ると判断しやすくなります。

Default Texture FilterをNearestに

くっきり表示の必須設定になるのが、Project Settings > Rendering > Textures > Default Texture FilterをNearestに変えることです。
ここがLinearのままだと、基準解像度やStretchを整えても、拡大時に隣の色を補間してしまい、輪郭に中間色が混ざります。
前のセクションでも触れた通り、1pxのアウトラインが溶けたように見える原因の中心はこの補間です。

この設定は、プロジェクト全体の既定値として効きます。
新しく読み込むPNGやスプライトシートも、この既定値に沿って表示されるので、最初に切り替えておくほうが手戻りが少なくなります。
Asepriteで書き出したキャラクター、16x16のタイル、アイテムアイコンのように、ピクセル単位で色を置いた素材ではNearestの差がそのまま画面の印象差になります。

ただし、既存プロジェクトや途中から追加した素材では、画像ごとのインポート設定が残っていることがあります。
その場合はImportドックで該当画像のFilterをオフにしてからReimportします。
プロジェクト既定をNearestにしても、その画像に個別設定が残っていると、そこだけぼやけたまま表示されます。
複数のPNGの中で1枚だけ甘い見え方をしているときは、ほぼこの個別設定が原因です。

Snap設定と座標の整数化

エディタの2Dスナップ機能（例: "Pixel Snap" や "Snap 2D Transforms to Pixel" と表記されることがあります）を有効にします。
項目名やメニューパスはGodotのバージョンによって表示が異なる場合があるため、使用中のバージョン（例: 4.5.2-stable）に合わせて公式ドキュメントで該当設定を確認してください（。
これにより編集時に半端な座標で配置してしまう事故を減らせます。

素材読み込みの基本｜PNG・スプライトシート・TileSet

素材をGodotに入れたあとに迷いやすいのは、画像の見た目を整える段階ではなく、その画像をどのノードやリソースで扱うかの切り分けです。
単体画像ならSprite2D、名前付きアニメならAnimatedSprite2D、背景や地形のように面で敷くならTileSetとTileMapLayerという整理で見ると、読み込みから配置までの流れが崩れません。
PNGを基準にそろえ、インポート時の設定を先に整えておくと、その後の分割や登録も素直につながります。

対応画像形式とPNGを選ぶ理由

画像の入口としてまず押さえたいのは、Godotが複数の形式を受け取れる一方で、ドット絵用途ではPNGを中心に据えるのがもっとも安定するという点です。
透過を素直に持てて、可逆圧縮なので、16x16や32x32の小さなピクセル情報を崩さず持ち込めます。
キャラクター、アイコン、タイル、UIパーツを同じ形式でそろえられるので、制作ツールがAsepriteでも画像整理の段階で迷いません。

BMPも読み込めますが、対応しているのは1/4/8/24/32ビットで、16ビット/ピクセルのBMPは扱えません。
形式として通るかどうかを毎回気にするより、透過付きのPNGに統一しておくほうがワークフロー全体が安定します。
とくにドット絵では背景を抜いたアイテム画像や、1枚のシートに複数のコマを詰めたスプライトシートを多用するので、アルファチャンネルを自然に扱えるPNGの利点がそのまま作業速度に出ます。

実際、私もAsepriteから書き出した8方向のアイテムアイコンを16x16のPNGで読み込むことがありますが、この手の小さい素材は画像自体よりインポート時の補間設定で見え方が崩れます。
輪郭が少し甘く見えるときでも、PNGで持ち込んだうえでImportのFilterを外すだけで、斜めの縁や1pxの記号がきちんと立ち直ります。
書き出し形式で悩むより、PNGにそろえて読み込み後の設定を整えるほうが、表示結果を予測しやすくなります。

素材名の付け方も、この段階で決めておくと後が楽です。
たとえば player_walk_0.png、player_walk_1.png、player_idle_0.png のようにキャラクター名、動作名、フレーム番号を並べる命名にしておくと、あとでAnimatedSprite2Dへ登録するときに並び順で迷いません。
同じ素材をタイル素材として切り出す場面でも、用途や系列がファイル名だけで判断できるので、フォルダを開いた時点で整理が済んでいます。

Importドックの基本

画像を読み込む手順は単純ですが、ドット絵ではこの数クリックの差がそのまま見た目に出ます。
FileSystemへPNGをドラッグ＆ドロップしたら、対象画像を選び、Importドックで設定を調整し、Reimportを実行します。
前のセクションで触れたプロジェクト全体の既定値とは別に、ここでは画像ごとの個別設定を持てるので、にじみが残る素材をピンポイントで直せます。

ドット絵素材で最初に見る項目はFilterです。
これをオフにすると、拡大時に周囲の色を混ぜず、1pxの輪郭がそのまま残ります。
必要に応じてMipmapsもオフにしておくと、小さいスプライトやUIアイコンで余計なぼけを持ち込みません。
設定を変えただけでは反映されないので、Reimportまで押して画像を再取り込みする流れが一連のセットです。

この作業は、単体PNGでもスプライトシートでも同じです。
16x16のアイコンが並んだ1枚絵を読み込むときも、まずインポート設定で輪郭を固めてから分割へ進んだほうが、あとでHframesVframesを設定した際の見た目が安定します。
逆に、ぼやけたまま分割やアニメ登録を進めると、「切り方が悪いのか」「表示側の設定なのか」が混ざって原因を追いにくくなります。

Sprite2D/AnimatedSprite2D/TileSetの使い分け

用途別の整理では、Sprite2Dは単体画像、または1枚のスプライトシートを等間隔で区切って表示する役目です。
キャラクターの立ち絵、アイテム1個、エフェクト1枚、あるいは歩行コマが格子状に並んだシートを表示するなら、まずここから始めるのが筋です。
1枚のシートを使う場合はHframesVframesで列数と行数を指定し、必要なコマを選んで静止画として出したり、簡易的なアニメの土台として使ったりできます。

たとえば、横4コマ×縦2列の歩行シートなら、Sprite2Dで分割設定を入れるだけで1コマずつ参照できます。
アニメ切り替えまではまだ要らず、待機ポーズだけ置きたい、UI上に1コマだけ見せたい、当たり判定確認用にコマを固定したいという場面では、この軽さが効きます。
1枚のスプライトシートを素早く画面に出すという意味では、Sprite2Dがいちばん直線的です。

AnimatedSprite2Dは、歩行、待機、攻撃のように複数のコマをまとまりとして切り替える用途に向いています。
ここではSpriteFramesリソースにフレームを登録し、walk や idle のような名前付きアニメとして管理します。
1枚のシートからフレームを切り出して登録してもよいですし、player_walk_0.png のように連番付きで分けたPNGを並べて入れても構いません。
命名規則がそろっていると、読み込み順とアニメ名の対応が崩れず、差し替えや追加が発生しても追従しやすくなります。

この命名の効き方は、制作が進んでからいっそうはっきり出ます。
たとえば player_walk_0.png から player_walk_5.png まで並んでいれば、AnimatedSprite2Dではそのまま歩行アニメとしてまとめられますし、派生素材を増やすときも player_walk_sword_0.png のように系列を拡張できます。
ファイル名の時点で意味が入っていると、どの画像がどの動作なのかをプレビューで探し回る時間が減ります。

背景や地形、床、壁のように同じサイズの絵を面で敷き詰めるなら、TileSetとTileMapLayerの組み合わせに切り替えます。
TileSetはタイル画像をアトラスとしてまとめ、どの矩形を1タイルとして使うかを定義するためのリソースです。
そのうえでTileMapLayerに配置していくと、草地、崖、室内床、装飾ブロックのような繰り返し要素を高速に敷けます。
キャラクターを1体置くSprite2Dとは考え方が違い、マップ全体を構成するための下準備に当たります。

ドット絵ゲームでは、プレイヤーや敵はAnimatedSprite2D、宝箱や単体の看板はSprite2D、背景と地形はTileSet＋TileMapLayerという分担にすると、編集単位がきれいに分かれます。
どれも同じPNGから始められますが、表示したいものが「1枚の絵」なのか「切り替えるフレーム群」なのか「面として並べるタイル群」なのかで、選ぶ先は変わります。
この切り分けが早い段階で決まっていると、素材整理、命名、インポート設定、シーン構成が一本の流れとしてつながります。

スプライトシートを動かす手順｜AnimatedSprite2DとAnimationPlayer

画像をGodotに入れた後は、その1枚をどう使うかで扱い方が分かれます。
単体表示ならSprite2D、歩行や待機のようなコマ送りならAnimatedSprite2D、地形や床を面で敷くならTileSetとTileMapLayerという切り分けです。
対応画像形式はいくつかありますが、ドット絵では透過を自然に扱えて劣化のないPNGが中心になり、実制作でもまずここを基準に組むと後工程がぶれません。

AnimatedSprite2Dで基本アニメを作る

ドット絵の歩行や待機を最短で動かすなら、AnimatedSprite2Dがいちばん素直です。
ノードを追加し、Sprite Framesで新規リソースを作成したら、walk や idle のようなアニメーション名を先に切っておくと、あとで攻撃やダメージを足すときにも見通しが崩れません。
1枚のスプライトシートの取り扱いや出力設定については、当サイトの「スプライトシートの作り方｜サイズ・PPU・書き出し」も参考にしてください。

ドット絵の歩行や待機を最短で動かすなら、AnimatedSprite2Dがいちばん素直です。
ノードを追加し、Sprite Framesで新規リソースを作成したら、walk や idle のようなアニメーション名を先に切っておくと、あとで攻撃やダメージを足すときにも見通しが崩れません。
1枚のスプライトシートの取り扱いや出力設定については、当サイトの解説「スプライトシートの作り方｜サイズ・PPU・書き出し」も参考にしてください。

Sprite2DでもHframesVframesを使ってスプライトシートを分割できますが、役割は少し違います。
Sprite2Dは1コマを固定表示したいときに向いており、表情差分の確認や、アイテム1枚を置く場面では軽快です。
歩行、待機、攻撃のように複数コマを名前付きで管理するなら、AnimatedSprite2Dに寄せたほうが、アニメーションの切り替えが整理されます。

背景や地形はこの流れに乗せず、TileSetとTileMapLayerへ分けるのが定石です。
TileSetでタイル画像の区切りを定義し、TileMapLayerで床や壁を敷いていく構造なので、キャラクター用の歩行シートと同じ感覚で扱うものではありません。
プレイヤーはAnimatedSprite2D、看板や宝箱はSprite2D、マップ全体はTileSet＋TileMapLayerという分担にすると、シーンの役割が混ざりません。

AnimationPlayerで柔軟に制御する

AnimationPlayerは、コマ送りそのものより「複数の変化を同じタイムラインに載せたい」ときに力を発揮します。
Sprite2Dの frame をキーフレーム化してスプライトシートを送るだけでなく、position、scale、不透明度までひと続きで制御できるので、跳ねる、のけぞる、点滅する、といった演出を1本のアニメーションとしてまとめられます。
歩行だけならAnimatedSprite2Dのほうが速く組めますが、演出を伴う瞬間はAnimationPlayerのほうが構造に無理が出ません。

実際、攻撃アニメではこの差がよく出ます。
私もAnimationPlayerで frame をキーフレーム化し、剣を振り切るフレームと同じタイミングで当たり判定ノードの有効化を入れる構成をよく使います。
見た目の1コマと当たり判定の発生がずれると、当たった感触が薄くなりますが、同一タイムライン上で同期させると、ヒットの説得力が一気に増します。

AnimatedSprite2DとAnimationPlayerは対立ではなく、役割分担で考えると収まりが良いです。
基本の歩行、待機、簡単な方向別アニメはAnimatedSprite2Dに任せ、攻撃時の踏み込み、ダメージ時の点滅、UIと連動するカットインのような複合演出はAnimationPlayerへ渡すと、ノード構成が素直に保てます。
ひとつのノードに何でも背負わせるより、定番動作と演出制御を分けたほうが修正箇所も追いやすくなります。

表示確認では、絵そのものより配置のほうで破綻することがあります。
座標が整数値から外れていないか、ノードの scale が 1.0 のままか、フィルタがNearestになっているかを都度見ておくと、フレーム自体は正しいのに見え方だけが甘いという事故を避けやすくなります。

歩行4コマの推奨FPSと注意点

歩行4コマは、フレーム数が少ないぶん再生速度の印象差がはっきり出ます。
私が横4コマの歩行を何度も見比べた範囲では、まず試す値は FPS 6〜8 が基準です。
6だと1歩1歩の接地が見えやすく、足が地面を踏んで進む感じが残ります。
8まで上げると反応は軽くなりますが、移動速度との噛み合わせ次第で足だけ忙しく見え、接地より足踏み感が前に出ます。

この境目は、左から右へコマが進む4フレームの接地タイミングを見るとつかみやすくなります。
等速移動のキャラクターをFPS 6で流すと、前足が出るコマと重心が乗るコマの差が目で追えます。
一方で同じ移動量のままFPS 8にすると、足の切り替えが先行し、胴体の進みより脚だけ細かく動いて見えることがあります。
私はここを“スライド感”と“足踏み感”の境目として見ています。
FPSが低すぎると地面の上を滑っているように映り、高すぎるとその場で小刻みに回している印象へ寄るので、歩行速度とセットで決めるのが筋です。

4コマ歩行では、シートの並び順も見た目に直結します。
接地、つなぎ、中割り、つなぎのような意図で描かれているのに、等間隔だからと順番だけで再生すると、左右の足運びが不自然になります。
見た目が落ち着かないときは、FPSをいじる前にフレーム順そのものを確認したほうが原因へ近づけます。
スプライトシートの分割が正しくても、並びの解釈を誤ると歩幅がねじれて見えます。

あわせて、表示の粗れをアニメの問題と取り違えないことも欠かせません。
整数座標から外れた配置、ノードスケールの変更、フィルタ設定の戻りが混ざると、コマ送り自体は正しいのに輪郭が泳いで見えます。
歩行アニメの評価は、1フレームごとの絵、再生FPS、移動速度、表示設定の4つが揃ってはじめて判断できます。
ここが噛み合うと、4コマでも十分に気持ちよく歩かせられます。

TileSetとTileMapLayerで背景を組む

背景用の画像は、キャラクターのようにSprite2DやAnimatedSprite2Dへ直接載せるのではなく、用途ごとに扱いを分けると破綻が減ります。
単体の看板や宝箱はスプライト、歩行や待機のようなコマ送りはスプライトシート、地面や壁のように繰り返し敷く素材はTileSetとTileMapLayerへ渡す、という整理にすると、マップ制作と演出制作が混線しません。
画像形式は前述の通り複数扱えますが、透過と管理のしやすさのバランスが良く、ドット絵ではPNGを中心に据えるのが定番です。

TileSetを作る

TileSetは、同じサイズで切り出せるタイル画像をひとまとめにし、グリッド単位で配置できるようにするための土台です。
1枚絵をそのまま背景に置く方法だと、地面を少し広げたいときや崖の形を変えたいときに画像編集へ戻る必要がありますが、TileSetなら必要な部分だけ描き替えて再利用できます。
さらに、同種の地形を自動でつなぐ設定や、タイルごとの当たり判定も持たせられるので、見た目とロジックを同じ単位で管理できます。

素材の区切りは、元画像のタイルサイズに正確に合わせます。
トップダウンのドット絵なら 16x16 を基準にしているケースが多く、このときTileSet側のグリッドも 16x16 に揃えます。
ここが1ピクセルでもずれると、境界線がにじむというより、そもそも別の絵をまたいで切ってしまい、崖の角や床の模様が不自然に欠けます。
背景づくりでは拡大設定以上に、最初のグリッド一致が見た目を左右します。

作業の流れとしては、まずインポート済みの画像からタイルアトラスを作り、区切り線が素材のマス目と一致しているかを確認します。
単体のスプライトシートをSprite2DやAnimatedSprite2Dで使うときは、フレームサイズを指定して hframes やアニメーション用のフレーム群を設定しましたが、TileSetでは同じ「1枚の画像を分割する」発想を、背景配置向けに発展させるイメージです。
キャラクターは時間方向にフレームを送って見せ、地形は空間方向に敷き詰めて見せる、と考えると役割の差が掴みやすくなります。

私が16x16のトップダウン用素材で組んだときは、地面、崖、草や小石の装飾を最初から別用途として切り分けました。
地面は繰り返し敷く前提、崖はつながりの規則がある前提、装飾はランダムに散らす前提でTileSetに登録し、衝突は見た目のレイヤーとは別にタイルコリジョンで持たせる構成にすると、あとで崖の形だけ差し替えても当たり判定が崩れません。
背景の修正頻度が高い制作ほど、この分離が効いてきます。

TileMapLayerで地形・装飾を描く

TileMapにTileSetを割り当てたら、実際にマップへ敷いていく場がTileMapLayerです。
ここでは地面、装飾、衝突、手前にかぶさる木の葉といった役割ごとにレイヤーを分けると、描画順と編集単位が噛み合います。
床と装飾を同じレイヤーへ混ぜると、草むらだけ消したい、崖際の影だけ足したい、といった修正で余計なタイルまで触ることになります。

特にドット絵では、どのタイルが手前でどれが奥かが1マス差で印象を変えます。
地面を最下層、崖や壁をその上、花や看板などの装飾をさらに上、プレイヤーの前にかぶる葉や屋根の縁は別レイヤーへ分けると、Z順の調整が素直です。
背景全体を1枚に焼き込む方法では出せない「キャラクターが木の後ろへ半分隠れる」といった表現も、レイヤー分離なら無理なく作れます。

私が16x16のトップダウンマップでよく使うのは、地面レイヤー、崖レイヤー、装飾レイヤー、衝突用レイヤーの4分割です。
見た目には草が生えていても通り抜けられる場所と、何も描いていなくても入れない場所を分けられるので、デザイン調整の自由度が上がります。
崖の見た目を描き替えても、コリジョンを持つ別レイヤーが残るため、プレイヤーが突然めり込む事故を避けられます。

カメラ移動時のガタつきにも、レイヤー構成は関わります。
タイル自体はグリッドに吸着していても、ノードの位置や描画座標が半端な値になると、輪郭がフレームごとに揺れて見えます。
背景用ノードの座標を整数で保ち、手前・奥の重なりもレイヤーとZ順で決めておくと、マップをスクロールしたときの落ち着きが違います。
ピクセルアート向け設定を詰めていても、ここが崩れると床の目地や斜めの縁が泳いで見えます。

等角タイル（Isometric 32x16）の設定例

等角マップでは、四角いトップダウン用タイルと同じ感覚で進めると、段差や重なりでずれが目立ちます。
32x16 の等角タイルを使うなら、TileSet側でタイル形状を Isometric にし、タイルサイズも 32x16 に揃えて、ひし形の見た目とグリッドの基準を一致させます。
ここで正方形グリッドのまま切ってしまうと、坂道や段差のつながりが崩れ、斜面の稜線が1段ずつずれて見えます。

等角では、タイルの大きさだけでなく、投影の向きと原点も見逃せません。
見た目の中心と配置の基準点がずれていると、同じ座標へ置いたつもりでも、段差の縁だけ横へ逃げたり、壁の足元だけ浮いたように見えたりします。
私は32x16の等角素材で斜面を並べた際に、いわゆる“段差ズレ”が出たことがあり、画像そのものを描き直す前にTile Originとスナップ設定を見直しました。
基準点をタイルの接地位置へ合わせ、ペイント時のスナップを等角グリッドに揃えたら、斜面のつながりが収まり、段ごとの横ずれも消えました。

等角マップは、装飾の重なり順もトップダウン以上にシビアです。
木、柵、建物の角、坂の上に置く小物などは、どのレイヤーへ載せるかで空間の読み取りやすさが変わります。
床だけを1レイヤーで敷き、その上に段差、装飾、前景を分けると、プレイヤーが坂の上にいるのか下にいるのかが視覚的に伝わります。
座標を整数で保つことも同じで、等角ほど斜線が多いぶん、半端な位置のブレが目に付きます。

32x16の等角設定は一見すると特殊ですが、考え方自体はトップダウンと同じです。
素材の1マスとTileSetの1マスを一致させ、TileMapLayerで役割ごとに分け、重なりと原点を整える。
この3点が揃うと、ひし形の床も斜面も、編集段階で破綻しにくい背景として回り始めます。

よくある失敗と対策｜ぼやける・ガタつく・UIがにじむ

ドット絵の破綻は、絵そのものより「どこで補間が入ったか」を見つけると整理できます。
ぼやける、ガタつく、UIだけにじむという3つの症状は別々に見えて、実際には Filter、Stretch、座標、カメラ、表示先解像度のどこかでピクセル境界が崩れていることが多いです。
私自身も、見た目の違和感を素材側の問題だと思って描き直しかけたあと、設定と座標の見直しだけで収まった場面が何度もありました。

表示がぼやけるときの確認ポイント

画面全体が少し溶けたように見えるときは、まず補間の入り口を順番に潰していくのが近道です。
最初に見るべきなのはプロジェクト側の Default Texture Filter で、ここが Nearest 以外だと、どれだけ元画像がシャープでも拡大時に境界へ中間色が混ざります。
次に、画像ごとのインポート設定で Filter が有効のまま残っていないかを見ます。
プロジェクト全体を Nearest にしていても、個別テクスチャの設定が上書きしていると、その画像だけ輪郭が甘くなります。

続いて見落としやすいのが Mipmaps です。
ドット絵素材では、縮小用の段階画像がかえって輪郭の濁りを呼び込みます。
UI用アイコンやタイル画像で Mipmaps が有効だと、等倍付近でも線の芯がにじんで見えることがあります。
素材読み込み時の挙動で違和感が出るなら、Godotのイメージのインポートで扱う設定項目を思い出すと、どこに補間が入っているか切り分けやすくなります。

それでもぼやけるなら、Stretch の拡大率を疑います。
ピクセルアートは 1px を何倍で見せるかがそのまま輪郭の安定に直結するので、非整数拡大になると Nearest でも線幅が揺れます。
私が配信画面向けに 1920x1080 へ載せる作業をしたとき、基準解像度を曖昧にしたまま広げるとタイルの縁がフレームごとに落ち着かず、細い罫線だけ妙に太く見える場面がありました。
基準を 640x360 に固定して 3 倍で扱う構成へ寄せると、タイルの縁が安定して、床の目地も均一に止まりました。

症状を追う順番は、Project の Filter、Import の Filter と Mipmaps、Node 側の見た目、Stretch の Mode と Aspect、表示先の解像度が整数倍か、の流れで見ると詰まりません。
1か所だけ直しても残る場合があるので、表示経路を上から順に確認すると、原因が重なっていても見失いにくくなります。

ガタつき・ちらつきの原因と回避

キャラクターや背景が移動中だけ揺れるなら、画像ではなく座標を疑うべきです。
ノードの位置が 100.5 のような小数を含むと、ピクセル境界の間に絵が置かれるため、フレームごとに線の出方が変わります。
タイル背景の上をAnimatedSprite2Dで歩かせたとき、キャラの位置が 0.5px ずれているだけで、背景タイルとの境目に干渉線のようなちらつきが出ることがあります。
私も一度、歩行アニメの違和感をフレーム絵のせいだと思い込みましたが、実際は位置の端数が原因で、表示前に floor() の発想で座標を丸めるようにしただけで収まりました。

エディタ側の2Dスナップ設定をONにしておくと、配置や移動の時点で半端な値を踏みにくくなります。
正確な設定項目名はバージョン差で変わることがあるので、該当する表記は公式ドキュメントを参照して確認してください。
カメラ側も揺れの発生源です。
Camera2Dのスムージングは見た目を滑らかにする代わりに、中間値の座標を毎フレーム生成します。
ドット絵ではこの中間値がそのままサブピクセル描画になり、プレイヤーは止まって見えても背景の縁だけが泳ぐように見えます。
カメラスムージングを切ると止まる症状なら、原因はほぼここです。
追従感を残したいなら、補間そのものを使うより、整数フレームでズームや位置更新が止まる設計に寄せたほうが、ピクセル境界を保ちやすくなります。
カメラ側も揺れの発生源です。
Camera2Dのスムージングは中間値の座標を毎フレーム生成するため、ドット絵ではサブピクセル描画になり背景の縁だけが泳いで見えることがあります。
カメラスムージングを切るか、整数座標で更新する設計に寄せると改善します。
設定名や挙動はバージョンで変わることがあるので、必要に応じて公式ドキュメントで該当項目を確認してください（。

UIだけにじむときの設計見直し

ゲーム画面は締まっているのに、HPバーやアイコン、文字まわりだけがにじむ場合は、ピクセルアート用の描画スケールと高解像度 UI の扱いが混ざっています。
背景やキャラと同じ拡大規則を UI にもそのまま当てると、ドット絵に合わせた整数倍拡大と、読みやすさを優先した UI のスケーリングが衝突します。
その結果、ゲーム側はくっきりしていても、UI の枠線や記号だけ中途半端に補間されます。

UI 用のTextureRectも個別設定が効きます。
ドット絵アイコンを UI に載せるなら Filter を切って輪郭を立てる必要がありますが、装飾パネルや高解像度画像まで同じ扱いにすると、今度は曲線や細い文字が角張りすぎます。
StretchMode の選択も影響が大きく、画像をどの基準で伸ばすかが合っていないと、UI だけ線幅が揃いません。
ドット絵アイコンはピクセル単位を守る設定、高解像度の UI 素材は滑らかな表示を前提にした設定へ分けると、同じ画面内でも破綻しません。

必要ならスクリプトで動的に素材を読み込む

インスペクターで画像を差し込む方法は最初の一歩として十分ですが、ゲーム中に見た目を切り替える段階になると、スクリプトから素材を読み込める構成が効いてきます。
Godotでは load(path:String) で実行時に Texture2D を取得できるので、キャラスキンの切替、装備による見た目変更、ユーザーが追加した画像の反映まで同じ考え方で扱えます。

Sprite2Dに差し替える

キャラクターやフィールド上のオブジェクトなら、Sprite2Dの texture に読み込んだ画像を代入するだけで差し替えられます。
基本形はシンプルで、パス文字列から Texture2D を受け取り、そのままノードへ渡します。

var tex: Texture2D = load("res://sprite.png")
$Sprite2D.texture = tex  # テクスチャを設定

この形が役立つのは、インスペクターの固定設定では吸収できない場面です。
たとえば装備によって主人公の見た目を変える、敵の色違いを同じシーンで切り替える、イベント進行に合わせて看板の絵柄を変えるといった処理は、起動後に差し替える前提で組んだほうが素直です。
画像を差し替えてもノード構造や当たり判定はそのまま使えるので、見た目だけを入れ替えたいケースと相性が合います。

私がよく使うのは、スキン名だけで参照先フォルダを変える簡易構成です。
たとえば res://skins/{name}/player.png のようにしておくと、name が default なら標準スキン、blue なら青系スキンという形で管理できます。

var skin_name := "blue"
var path := "res://skins/%s/player.png" % skin_name
var tex: Texture2D = load(path)
$Sprite2D.texture = tex  # テクスチャを割り当て

この方式はフォルダ単位で差し替えられるぶん、画像枚数が増えても整理しやすく、ドット絵の差分管理とも噛み合います。
ただし、ファイルが存在しないパスをそのまま読むと想定外の表示欠けにつながるので、存在確認とフォールバック画像は最初から用意しておくほうが安全です。
実運用では default フォルダの画像へ戻す逃げ道を作っておくと、スキン追加中でもシーンが壊れません。

TextureRectでUIを差し替える

UI 側の画像差し替えでは、TextureRectに Texture2D を入れる形になります。
インベントリのアイコン、ショップの品目画像、タイトル画面のバナー差し替えなどは、この方法がそのまま使えます。

var tex: Texture2D = load("res://ui/item.png")
$CanvasLayer/TextureRect.texture = tex

TextureRectで動的読込を使う利点は、UI とゲーム本編で素材更新の頻度が違っても、表示先だけをきれいに分離できることです。
前述のように UI はワールド描画と前提が異なるため、同じ画像差し替えでもSprite2Dとは管理の粒度が変わります。
商品一覧の選択中だけアイコンを切り替える、言語やテーマに応じてパネル画像を入れ替える、季節イベントでロゴを変更するといった用途では、シーンを複製するよりテクスチャ差し替えのほうが構成が軽くなります。

ユーザーMOD対応を見据える場合も、TextureRectは扱いやすいノードです。
UI 素材を res://ui/skins/dark/ のような階層でまとめておけば、テーマ単位で差し替える設計に広げられます。
パス命名がばらつくと管理が崩れるので、アイコン、フレーム、背景のように用途別の置き場を先に固定しておくと、差し替え対象を追いかけやすくなります。

preloadとloadの使い分け

preload() と load() はどちらもリソースを扱いますが、使う場面は分けたほうが整理できます。
preload() はスクリプト読込時点で確定している素材向けで、起動時に読み込んでおく前提です。
一方の load() は、ゲーム中にパスを組み立てて選びたい素材向けで、実行時に動的読込する役割を持ちます。

たとえば常に使うプレイヤー基本画像なら preload() が向いていますが、スキン名や装備IDから参照先が変わるなら load() でなければ回りません。
コード上の差は小さく見えても、設計上は「固定資産」か「後から選ぶ資産」かで分かれます。

var default_tex: Texture2D = preload("res://skins/default/player.png")

func apply_skin(name: String) -> void:
	var path := "res://skins/%s/player.png" % name
	var tex: Texture2D = load(path)
	if tex:
		$Sprite2D.texture = tex  # テクスチャを適用
	else:
		$Sprite2D.texture = default_tex

このようにしておくと、標準画像は最初から確保しつつ、追加スキンだけを実行時に差し替えられます。
大量の差し替えを扱う場合は、処理そのものよりアセット構成のほうが詰まりやすい部分です。
キャラ、UI、アイテム、イベント画像を無秩序に並べると、どのパスがどの用途なのかコードから読めなくなります。
動的読込は便利ですが、真価が出るのはフォルダ構成と命名規則が揃っているときです。

まとめと次のアクション

Godotでドット絵を崩さず扱う軸は、表示経路を最初に固めることです。
Default Texture Filter を Nearest にし、基準解像度と Stretch の方針を決め、座標を整数でそろえる。
この土台ができると、PNG の1枚絵、スプライトシート、タイル背景を同じ基準で積み上げられます。

ここでは扱う素材を、キャラクターならSprite2DやAnimatedSprite2D、背景ならTileSetとTileMapLayerという役割分担で整理すると、シーン構成がぶれません。
演出を増やす前に、まずは「ぼやけない表示」を確認してから歩行アニメとマップ作成へ進む順番にすると、途中で設定を巻き戻す手間を減らせます。

次のアクション

1. PNG を1枚読み込み、Nearest で輪郭が崩れないかを表示で確認します。
2. スプライトシートを使って、2〜4フレームの歩行アニメをAnimatedSprite2Dで作ります。
3. TileSetを組み、1画面ぶんのマップをTileMapLayerで配置して、キャラ表示と背景表示を同じ基準で見比べます。