← すべての記事

iPhoneでつくるピクセルアートの世界——16ビットの巨匠たちが知っていたこと

Final Fantasy VIのパーティーメンバーは16×24ピクセル、戦闘中に使える色は12色、最大181タイルから組み上げた46のポーズを持ち、同じスプライトがフィールドもワールドマップもすべての戦闘も歩きます。1 Pokémon Emeraldは2層構造の16×16「メタタイル」から町のすべてを描き、マップ1セルは16ビット——タイルに10ビット、衝突判定に2ビット、高さに4ビットです。2 Celesteは世界全体を320×180で描画し、6倍に拡大します。3 この3つの数字に技法の核心が詰まっています。セルを決め、パレットを決め、キャンバスを決める。描くのはそのあとです。私たちのアプリKiradexにもRealityKitで描いたピクセルの広場がありますが、この基準に照らすとほとんどの項目で落第でした。28タイルのセットは場当たり的なベタ塗りでランプもなく、アウトラインの規則もなく、オクルージョンもなく、歩行は2フレーム。そこで本腰を入れて調べました。SNES時代に関する出典付きのレポート6本、逆コンパイル結果から読み解いたPokémonのタイルシステム、現代の名手たち、技法そのもの、Appleのレンダリング経路、そしてソーシャルな世界としてのコレクションゲーム。以下は、私自身が欲しかったガイドです。数字と、3倍解像度のiPhone画面およびiPhone Duoの両ディスプレイでドットを鮮明に保つ実測レシピ、そしてルールに従って世界を作り直した最初の成果をまとめました。

TL;DR

  • 巨匠たちは制約を起点に発想しました。 SNESが与えたのは、16色タイル用の背景パレット8本とスプライトパレット8本(各15色)、8×8タイル、走査線あたり32スプライト。Squareの答えは、16×24のセル1つ、ポーズのライブラリ、そしてタイルの共有でした。41 Game Boyが与えたのは4階調で、Pokémon Redのタイルセットは96タイル。Game Freakの答えは32×32のブロックと、追加の絵をいっさい描かずに草むらで足元を隠すプライオリティビットでした。56
  • ピクセルの世界が一つの場所として読めるかどうかは、3つの判断で決まります。 光の向きと影の色相を一つに統一すること(Seiken Densetsu 3のチームは黒ではなく深い青と紫で影を付けました)、すべてのスプライトに同じアウトライン規則を適用すること(FF VIのシルエットは輪郭の93パーセントがほぼ黒、Secret of Manaには黒が1ピクセルもありません)、そして明暗だけの色見本ではなく色相をずらしたカラーランプを使うことです。3389
  • 現代のライティングは、下の段なら手が届き、上の段なら身を滅ぼします。 Moonlighterはスプライトを重ねて光を偽装し、Celesteは2048ピクセルのアトラス1枚にライトをマスクとして描き、Eastwardは全アセットのバンプマップを手描きします。HD-2Dはプロデューサーの言葉を借りれば「思っている以上にコストがかかる」手法で、プレイヤーは被写界深度をオフにしてしまいます。10111213
  • Appleのプラットフォームでは、本物の3Dオブジェクトを1つだけ含む2Dの世界ならRealityKitにとどまり、ARのデフォルト設定を切ってください。 ピクセルアートに必要な機能にはすべてドキュメント化されたAPIがあります(nearestサンプラー、ミップマップなし、不透明度のしきい値、フレームごとのUV変換)。ただしRealityViewは既定でモーションブラーとHDRトーンマッピングを適用するため、本記事のレシピでは被写界深度、グレイン、アンチエイリアスとあわせてこれらをオフにします。141516 そうするまで、歩くキャラクターは足を踏み出すたびににじんでいました。
  • iPhoneでの整数倍スケーリングは、ポイントではなくピクセルで行う計算です。 3倍環境では1テクセル6ピクセルが2ポイントなので、16テクセルのタイルは32ポイント。iPhone 18 Pro Maxは1テクセル8ピクセルで10.3×22.4タイル、開いた状態のiPhone Duoは6ピクセルで29.7×20.9タイルを表示します。現行のiPhoneで高さが320で割り切れる機種は一つもないため、「縦ちょうど20タイル」は必ず帯が出ることを意味します。17
  • ルールで描いた自前のアートが、いちばん筋の通った道です。 米国著作権局の2025年1月の報告書は、著作権の成立には「プロンプトだけでは十分な制御を与えない」と述べています。作風は保護されませんが、個々のタイルやキャラクターは保護されます。そこで私たちは、58色のパレット1つと手で定めたルールからすべてのタイルを描く「フォージ(鍛冶場)」を作りました。最初のフィールドと作り直した広場は記事の末尾にあります。1819

1. 16ビットの巨匠たちが相手にしていたもの

Super Nintendoにはフレームバッファがありませんでした。画像処理プロセッサは186ナノ秒ごとに1ピクセルを出力しなければならないのに、ビデオメモリの応答は100ナノ秒。そのため8×8タイルのマップから8ピクセル先読みし、水平帰線期間中にスプライトをラインバッファへ組み上げていました。4 アーティストの仕事はすべて、ここから派生しています。16色タイルのために、256エントリのカラーメモリは背景パレット8本とスプライトパレット8本に分割され、各パレットは15色と透明インデックス1つ。背景はカラーメモリの前半を、スプライトは後半を使いました。21 スプライトのサイズは8、16、32、64ピクセルの正方形で、同時に有効にできるのは2サイズまで、オブジェクトメモリに置けるのは128個まで。1本の走査線に載るのは32スプライトまたは8ピクセル単位の断片34個までで、それを超えた分は表示されません。21 多くのRPGが使ったモード(Mode 1)の背景は16色レイヤー2枚と4色レイヤー1枚。Mode 7は256タイルからなる1,024×1,024ピクセルのタイルマップ1枚で22、走査線ごとにアフィン変換をかけることで地平線へと傾けられました。23 ビデオメモリは全部で64KBしかなく、タイルマップ、背景タイル、スプライトタイルがこれを分け合っていました。20

もう一つの壁がカートリッジの容量でした。Final Fantasy IVは8メガビット、Final Fantasy Vは16メガビット、Final Fantasy VIは24メガビットで出荷され、Chrono Triggerは終盤に24から拡張されて32メガビットになりました。Chrono Triggerのディレクター時田貴司はこの最初の数字をこう言い表しています。「このカートにはFFIVが4本入る」。追加された8メガビットについては、デザイナーのYasuhiko Kamataが「8メガのうち6メガほどはグラフィックに使われた」と述べています。2425 坂口博信はFF Vの最後の数か月を、スタッフが「互いに取れるだけの容量を奪い合っていた」と表現しました。26

動画:Graphics & Palettes, SNES Features Pt. 01, Retro Game Mechanics Explained

制約が強いたもの

制約 数値 アーティストの対応
タイルサイズ 8×8、16色 8ピクセルのセル単位で考え、パレットと反転を共有する16×16の「メタタイル」を組む20
タイルあたりのパレット 8本のうち1本、15色 メタタイルを1パレット内に収める。草、石、木には町をまたいで使い回せる中間色のパレットを割り当てる20
スプライトサイズ 8/16/32/64の正方形、16×32と32×64 16×24の主人公は16×16のオブジェクト1つと8×8を2つ、あるいは空行を含む16×32。Chrono Triggerの背の高いCronoは、フレームごとに配置された16×16ブロックの積み重ね2127
スプライトのタイル番号 9ビット、512タイル キャラクター1人のポーズ一式がタイル予算に収まる。FF VIのパーティーメンバーで181タイル1
走査線の上限 32スプライト、スプライト272ピクセル モンスターは背景レイヤーへ。幅16の主人公4人とエフェクトだけで、すでに限界が迫る214
反転 スプライトごとに水平・垂直 左右対称のポーズは1回だけ描く。Cronoの左足は右足の反転27
カラーマス 加算、減算、半分 水、幽霊、半透明のテキストボックスは50パーセント合成で。夜は減算で28

私が何度も立ち返るのはポーズの予算です。スプライトエディタはFF VIの各キャラクターについて17のアニメーションと13の静止ポーズ、計46の固有ポーズを列挙しており、反転を含めると約92。1ポーズあたり6タイルで、ポーズ間で大量に共有されています。歩行とその他の3ポーズアニメーションは1-2-1-3の順に再生されるため、表示上のサイクルは4フレームです。1 北瀬佳範はFF VIがFF Vの「倍以上のパターン」を持っていたと語っており、だからこそ1つのスプライトでフィールドと戦闘の両方をまかなえました。7 表現を生んだのはピクセルではなくフレーム数だったのです。

渋谷員子の手法

渋谷員子はFinal Fantasy IからVIまでのスプライトを描き、Pixel Remasterの描き直しを監修しました。彼女の証言は、記録に残るなかで最も明快な方法論の表明です。スプライトの描き始めについて。「基本的には、線よりも面から入ると言えます」。そして「まず大きな面をざっくり塗りつぶしてから、彫刻のように少しずつ削り込んでいきます」。8 見分けやすさについて。「プレイヤーがキャラクターを識別できなければならないので、デザインを見て、いちばん特徴的な要素だけを盛り込みます」。29 FF IVの16×16スプライトにアウトラインがなかった理由について。「1ピクセルが死活問題だったので、輪郭に使う余裕などありませんでした」。8 坂口博信はその帰結をアニメーションの面から補足しています。「腕をあまり高く上げられないので、喜びを表現する方法はくるりと回ることしかなかったのです」。8

動画:Kazuko Shibuya on 35 years of pixel art, Square Enix

イラストレーターとピクセルアーティストは別人で、両者をつないでいたのは一通のテキストでした。坂口博信いわく、「天野氏にイラストを発注するときは、文章による説明で行います」。8 Chrono Triggerでは鳥山明は「キャラクターのイラストとコンセプトアートだけ」を手がけ、後ろ姿は一度も描きませんでした。スプライトチームのUchiyamaはこう語っています。「推測するしかありませんでした」。30 野村哲也はFF VIのラスボスをスケッチブックに「画面単位で」描き、それをスキャンしてスプライトを起こしました。31 1994年の時点でパイプラインはすでにハイブリッドで、魔法エフェクトは別の3Dツールでモデリングしてから重ねていました。32

三つの「見え方」を測る

書き手はFF VI、Chrono Trigger、Secret of Manaをひとまとめに「SNESらしさ」と呼びます。しかし実際には3種類あり、違いの大半はアウトラインの方針にあります。私たちはアニメーション単位で切り出したファンアーカイブから各作品の主人公1体を取り、いずれも正確な2倍拡大であることを確認したうえで、立ちフレームの輪郭ピクセルをすべてほぼ黒(全チャンネルが255中40以下)、中間の暗色、明色に分類しました。9

作品とスプライト ほぼ黒の輪郭 中間の暗色 明色 読み取れること
Final Fantasy VI、Terra 93% 4% 3% 硬い黒のシルエット
Breath of Fire II、Ryu 59% 37% 4% 光の当たる側で黒い輪郭をやわらげている
Chrono Trigger、Crono 48% 51% 2% 半分が黒、半分が暗色
Seiken Densetsu 3、Duran 38% 54% 9% 選択的。接地部に黒を残す
Secret of Mana、Randi 0% 100% 0% 黒なし。輪郭は周囲より暗い固有色
EarthBound、Ness 0% 100% 0% 黒なし。濃い茶と紺の輪郭

やわらかい輪郭はManaシリーズでは明確な意図でした。石井浩一はSeiken Densetsu 3についてこう述べています。「影などには黒の濃淡ではなく深い青や紫を使い、やわらかさを出しています」。そしてスプライト担当と背景担当は、人物が場景のなかに収まるよう連携していました。「スプライトを作るときに背景を完全に無視してしまうと、場面の方向感覚がすっかり狂ってしまいます」。33 Chrono Triggerはその中間に、意図的に位置づけられています。開発では画面の明度をSecret of ManaとFinal Fantasyシリーズの「あいだ」に保つことが方針でした。34 一つのルールをゲーム内の全スプライトに適用すること。それが、登場人物たちを一つのキャストに見せるのです。

リマスターの教訓

Pixel Remaster(2021年から2022年)は16×24の基本寸法を保ちつつ、腕を伸ばしたりマントをなびかせたりできるよう上と左右に余白を与えました。FF VIでは、渋谷員子が1994年に願っていた1ピクセルがついに手に入ります。「当時は、上にもう1ピクセルだけ欲しいと切実に思っていました。このリマスターでその願いがかないました」。35 アートは「液晶画面に表示することを前提に」描き直されました。オリジナルはCRTのにじみを計算に入れて打たれていたからです。35 その後の論争はスプライトではなく書体をめぐるものでした。発売時のフォントは細身のモダン書体で、後から追加されたピクセルフォントは日本語約7,500文字分の制作を要しました。36 反面教師となるのが2014年のFF VIモバイル版で、滑らかに描き直されたグラフィックをKotakuは「うっかり洗濯機に放り込んでしまったかのよう」と評しました。37 出荷する画面に合わせて描くこと、そしてフォントもアートとして扱うことです。

2. Pokémonのタイルシステム、世代ごとに

Squareのアーティストには16色と24メガビットのカートリッジがありました。Game Freakのアーティストにあったのは4階調とGame Boyです。その制約に対処するために築かれた仕組みは、この分野で最も明快な教材です。というのも、いまやその全世代をpretの逆コンパイルで読めるからです。以下の数字はファンwikiではなく、ソースファイルから直接読み取りました。38

Game Boyは160×144の画面を2ビット4階調の8×8タイルで描き、ハードウェアオブジェクトは40個、1走査線あたり10個までです。39 Pokémon Redは最大96タイルのタイルセットを読み込み、4×4タイルからなる32×32の「ブロック」で世界を組み立て、町をブロック1つあたり1バイトで保存します。ゲーム中のどのブロックセットも128ブロックを超えません。マサラタウンは10×9ブロック、つまり320×288ピクセルで、ちょうど横2画面分・縦2画面分です。40 衝突判定は立つことのできる8×8タイルIDのリストで、エンジンが調べるのは1タイル、目の前のセルの左下だけです。41 水は1枚のタイルで、その16バイトを1ピクセルずつ右へ4回、左へ4回ビット回転させています。花は1枚のタイルを3つの保存フレームのあいだで1-1-2-3の順に差し替えるだけ。このアニメーション全体がおよそ20フレームごとに動きます。42 キャラクターは8×8のオブジェクト4つで、3方向それぞれに立ちポーズと歩きポーズの計6フレームとして描かれ、右向きは左向きの反転で作られます。上下方向の歩行サイクルは立ち、歩き、立ち、歩きの反転なので、描いた歩きフレーム1枚で両足分をまかなえます。43 私がいちばん好きな仕掛けはコストがゼロです。スプライトがタイルセットの草タイルの上に立つと、エンジンはその下側2オブジェクトに背景プライオリティビットを立て、草が脚の上に描かれるのです。6

動画:Sprite Analysis, Pokémon: Top-Down RPG Pixel Art, Brandon James Greer

Gold、Silver、Crystalはブロック形式を踏襲し、Game Boy Colorの新しいハードウェア性能を2点に投じました。タイルセットは2つのVRAMバンクにまたがって192タイルに拡張され、各タイルは名前付きの8パレット(GRAY、RED、GREEN、WATER、YELLOW、BROWN、ROOF、TEXT)のいずれかを取ります。これらのパレットは朝、昼、夜、暗所、屋内それぞれに別々に定義されているため、ジョウトの時間帯の変化は64バイトのパレット再読み込みであって、二組目のアートではありません。44 衝突判定は各ブロックの16×16の象限ごとに型付きの1バイト(FLOOR、WALL、TALL_GRASS、WATER、DOOR、LADDERなど)へ移りました。第2世代が32ピクセルのブロックを保存しながら16ピクセルのゲームとして遊べる本当の理由はここにあります。44 多様性はパレットから生まれました。5つの「人物」パレットは同じ肌色を共有し、違うのは1色だけ。つまり1枚のシートを5通りに塗り替えるだけで町の人口がまかなえます。45

Ruby、Sapphire、Emeraldは成熟したモデルであり、現代のエンジンが手本にすべき形です。タイルセットは地方全体で共有する512のプライマリタイルと、町ごとの512のセカンダリタイル、そして両者で13本の16色パレットから成ります。メタタイルは16バイト——GBAのスクリーンエントリ8個、2×2タイルの2レイヤー分で、各エントリがタイルID、反転2ビット、パレットを持ちます。属性ワードはさらに8ビットの挙動(長い草、段差、ドア、パソコン、全240種)とレイヤー型を加えます。Normalは上レイヤーがスプライトを覆い、Coveredは何も覆わず、Splitはプレイヤーが2つのレイヤーのあいだを歩きます。2 マップのセルは16ビットで、メタタイルに10ビット、衝突判定に2ビット、高さに4ビット。高さ15にすると橋の上も下も通れるようになります。46 フィールドはマップ用にハードウェア背景レイヤー3枚を一緒にスクロールさせ、4枚目を固定してテキストに使います。だから屋根や木陰がプレイヤーを隠すのは、何らかのソート処理ではなく、プライオリティの高いレイヤーに載っているからです。2 ミシロタウンは20×20メタタイル、トウカシティは30×30、カナズミシティは40×60、ミナモシティは80×40です。47

キャラクターは16×32の1ハードウェアスプライトになり、144×32のシートに9フレーム——3方向と各方向2歩分、東は西の反転です。歩行は歩き、立ち、歩き、立ちを各8ティックで再生します。誰もが覚えているあの上下動です。48 タイルアニメーションはフレームカウンタで駆動します。16ティックごとのティック0で花、ティック1で水、ティック2で砂の縁、ティック3で滝、ティック4で陸と水の境界。こうして5つのDMA書き込みが同じフレームに重ならないようにしています。49 水面への映り込みは、最低プライオリティに置いたスプライトの複製をアフィン行列で反転し、パレットを差し替え、スプライトの高さから2を引いた分だけずらしたものです。影はスプライトが宙に浮いているあいだ、つまり段差を飛び降りるときや自転車でジャンプするときにしか存在しません。長い草はいまやセル上に生成される5フレームのスプライトで、プレイヤーの下半身に重なります。50

第1世代(Game Boy) 第2世代(Game Boy Color) 第3世代(Game Boy Advance)
タイル 8×8、2bpp 8×8、2bpp、プラスでパレットのニブル 8×8、4bpp
歩行セル 16×16。衝突判定は8×8タイル1枚 16×16。象限ごとに型付き1バイト 16×16のメタタイル。セルごとに衝突判定と高さ
保存されるマップ単位 32×32のブロック、1バイト 同じ 16×16のメタタイル、16ビットセル内の10ビットID
タイルセット 96タイル、最大128ブロック 192タイル、屋外は128ブロック 512+512タイル、512+512メタタイル
パレット 1本、4階調 4色×8本、タイルごと 16色×13本、タイルごと
レイヤー 1枚、プラスでスプライトのプライオリティビット 1枚、プラスでタイルごとのプライオリティビット マップに3枚、テキストに1枚
キャラクター 16×16、6フレーム 16×16、6フレーム 16×32、9フレーム

表の出典は本節で引用したpretのリポジトリです。4044248

記録からもう2点。カードコレクターの世界に最も近い先祖であるGame Boy Colorのカードゲームは、カードのイラストをすべて64×48ピクセル、カードごとの4色パレットで描いています。パレットはタイルとともに埋め込まれ、表示時に1つのパレットスロットへ割り当てられます。だからCharizardにはクリーム、オレンジ、赤、ほぼ黒が与えられ、エネルギーカードには白、2段階のオリーブグレー、ほぼ黒が与えられます。51 ルールはサイズではありません。ルールは「カード1枚につき量子化されたパレット1本、固定されたフレーム1つ、ズーム倍率1つ」です。そしてこの規律について、机の上に貼っておくべき言葉は杉森建のものです。「ドット絵はとても奥が深い。スプライトのたった1ピクセルの位置を変えるだけで、まるで違う印象になるのです」。52 彼のスプライトは本人の言葉を借りれば、より複雑なデザインを「分かりやすく」した記号でした。画面が小さく、容量はもっと小さかったからです。53 RedとGreenはプログラマー約4人、アーティスト10人未満で出荷されました。54

3. 現代の名手たちと、「AAA級ピクセルアート」の値段

2010年以降、最良のピクセルアートゲームは1人から25人のチームが、制約のないハードウェア上で作ってきました。つまり彼らが守った制約はすべて選択です。その選択には共通点があります。

整数倍で拡大できるキャンバスを固定する。 Celesteの320×180は6倍で1080pになります。Pedro Medeirosいわく、「これが私の言うゲームキャンバスです」。3 Sea of Starsは640×360で描画し、その「Pixel Perfect」オプションについては、スタジオのSteam FAQスレッドでプレイヤーがこう説明しています。「表示の周囲に黒い縁を足すので、ピクセルがぼやけずにくっきり見えます」。55 Animal Wellは320×180で、ビューポートが小さすぎて走査線を正直に描けないときはスキャンラインフィルターを切ります。56 Hyper Light Drifterは480×270。Alx Prestonいわく、「うちのゲームは480pです。低解像度で、それもきわめて意図的にそうしています」。57 Shovel KnightはNESの可視走査線240本に合わせて400×240を選びました。Yacht Clubの言葉では、「Shovel Knightの1ピクセルは、1080pでは実質4.5×4.5ピクセルなのです」。58 Godotのドキュメントは現在、720p、1080p、1440p、4Kのいずれにも帯なしで収まることを理由に、640×360を基準として推奨しています。59

キャンバス 720p 1080p 4K 採用例
320×180 4倍 6倍 12倍 Celeste、Animal Well
400×240 3倍 4.5倍 9倍 Shovel Knight
480×270 2.67倍 4倍 8倍 Hyper Light Drifter
640×360 2倍 3倍 6倍 Sea of Stars、Godotの推奨

ピクセル密度を決して混ぜない。 Medeirosの拡大ルールはこうです。「これができるのは元画像の100パーセント刻みだけ」。そして2つの密度が避けられないときは、「100パーセントの要素と200パーセントの要素はあり得ても、150パーセントは絶対にない」。60 Celesteはさらに踏み込み、互いに決して混ざらない3つの「世界」を保っています。「Game、UI、Mapです。それぞれピクセルアート、高解像度、3Dにあたります」。3 UIは独自のレイヤーで独自の倍率を持ち、世界を拡大したあとで合成されます。初代SwitchのOctopath Travelerは携帯モードで世界を576pで描きつつUIを720pに保っており、道筋は違っても同じ分離です。61

ライティングの段を選び、その代金を払う。 いちばん下では、Moonlighterに動的ライティングは一切ありません。町の夜は「光の印象を与えるためのスプライトの重ね合わせ」です。10 一段上のCelesteは、すべてのライトを2,048ピクセルのテクスチャ1枚にマスクとして描きます。64スロットのグリッドでライト1つにつき1色チャンネルなので、1枚のテクスチャに256個のライトが収まり、シェーダーが色とマスクを乗算する前に遮蔽物がスポットライトから影を切り抜きます。11 その上のEastwardは「2Dの視点を持つ3Dゲーム」で、フラットなスプライトを実際のライトで陰影付けできるよう、チームが全アセットについて「バンプマップを1つずつ手で描き」ました。12 Animal WellのBilly Bassoは、滑らかなグラデーションがピクセルアートと衝突するという理由でエンジンのポイントライトを退け、自前のリムライトシェーダーを書き、煙と水のために全画面の流体シミュレーションを走らせています。62 Dead Cellsは3Dモデルを「ごく小さいサイズで、アンチエイリアスなしに」レンダリングしてトゥーンシェーダーで陰影を付けることで、ノーマルマップを無料で手に入れています。63 いちばん上では、Sea of Starsが最初の半年を「ピクセルアートと視覚的に一貫して見える」ライティングの構築に費やし、HD-2Dはライティングを施したUnrealのシーンにスプライトのビルボードを置いて被写界深度、ブルーム、カラーグレーディング、レンズフレア、ビネットをかけます。6465 HD-2D作品をプロデュースする浅野智也は、それが「思っている以上にコストがかかる」と語っています。13 そしてOctopath Traveler IIのプレイヤーは、「画面の端がぼやけて道が隠れてしまう」という理由で被写界深度とブルームをオフにします。13

動画:The Making of Sea of Stars, Escapist Documentary

思っているより少ないフレーム数でアニメーションさせ、代わりに色を動かす。 Dead Cellsのキャラクターは高さ50ピクセルで、Motion Twinの3Dアニメーションのワークフローは、Dead Cells以前の試作ScarKrowの時点ですでに秒間30フレームに達していました。ピクセル化の工程が加わったのはDead Cellsからです。63 サブピクセルアニメーションはこの技法の静かな武器です。小さなスプライトをわずかに動かすには、「スプライトを動かすな」とチュートリアルは言います。「その色を動かせ」。50ピクセルのキャラクターでは、淡い6色があれば呼吸を読み取らせるのに十分でした。66 OctopathはPhotoshopのパペットワープで動きを量産し、そのあとピクセルを手で修正しました。65 Animal Wellは生き物をプロシージャルにアニメーションさせ、四肢それぞれが独自の軌道を描きます。Bassoはスクワッシュ&ストレッチと画面揺れを意図的に避けています。67

パレットを固定し、共有する。 Raymond Schlitterの手法は、1段ごとに色相を20度ずらした9色のランプを作り、ランプ間は45度離すというもの。明るい側で彩度を落とすのは、そうしないと「目を焼くような強烈な色になってしまう」からです。68 Cassette Beastsは「およそ20色の同じプールを共有することで」120体のモンスターに統一感を持たせています。プラスチックの種類が決まっているアクションフィギュアのシリーズのようなものです。69 Shovel KnightはNESが3色しか許さなかったところを、スプライトあたり4〜5色プラス透明としています。58 コミュニティの固定パレット(Resurrect 64、Apollo、Endesga 32)が存在するのは、この規律が機能するからです。70

アートの規模をチームに合わせる。 Stardew Valleyは1人と16×16タイルです。Eric Baroneは次回作についてこう述べています。「16×16のタイルサイズを続けることで、これだけ大きな構想のゲームでもアートの量を扱える範囲に保てます」。71 Sabotage StudioはThe Messengerの7人からSea of Starsの約25人へと成長しました。72 Animal Wellは1人、7年、自作のC++エンジン、33メガバイト、そして部屋IDが1バイトであるためにちょうど256部屋の世界です。73 Eastwardのスタジオは創業者3人から常勤約12人へ拡大し、200体を超えるキャラクターをAsepriteでアニメーションさせています。74 Switch 2は従来の携帯機の妥協を取り払いました。1080pの携帯画面と1080pまたは4KのTV出力により、320×180と640×360のキャンバスはどちらのモードでも整数倍にできます。ただし4K出力は60フレーム上限です。75

4. 技法を、数字つきのルールとして

以下は、見下ろし型の3クォータービューの町をつくるための文法を、実践者たちの言葉どおりにまとめたものです。実践を私たちの用途向けに数値へ落とし込んだ箇所は、その旨を明記します。

  1. この視点は平行投影の傾きであって、透視図法ではありません。 LPCのスタイルガイドはカメラを「およそ60度」に置き、パースは付けないとしています。Schlitterは同じ視点を、家を45度上から見て「屋根と正面の両方が4分の3ほど見える」状態と説明し、支配的な一文を添えます。「統一感はリアリティに優先する」。7677 垂直線は垂直のまま、正面は圧縮され、屋根は回転させず、すべての物体が同じルールに従います。
  2. グリッドは16、制作のリズムは32です。 Schlitterいわく、「16×16ピクセルがおそらく最も一般的なサイズで、ドットを活かすには確実です」。78 StardewとGBA作品もこれに一致します。Pokémonのゲームボーイ版ブロックとLPCのグリッドは32です。タイルの制作と衝突判定は16で行い、家や大きな木は2タイル単位で設計しましょう。
  3. 背の高いタイルの問題はレイヤーで解きます。 Stardewのマップレイヤーは奥から手前へ、Back(地形)、Buildings(衝突判定)、Paths、Front(「プレイヤーがそれより北にいれば上に、南にいれば下に描かれる」)、AlwaysFrontです。79 PokémonのNormal、Covered、Splitというメタタイル型も同じ発想で、並び替えをハードウェアのプライオリティに任せています。2
  4. 地形のつなぎ目は47タイルです。 blobセットとは「2辺2角のWangタイルセットの47タイル部分集合」のこと。ビットの重みは北が1、北東が2、東が4、南東が8、南が16、南西が32、西が64、北西が128で、角は両隣の辺が立っているときにのみ数えます。この規則により256通りのマスクが47のシルエットへ畳み込まれます。8081 柵と生け垣は16タイルの辺セットです。Tiledのterrain setsもLDtkのルールグループも、これらを直接実装しています。8283
  5. 木は幹の上に葉の束を載せ、影はその真下に置きます。 Schlitterは「2×2ピクセルの小さな正方形」を基本単位とする束から樹冠を組み立て、「束あたり4〜5色」を使い、木々を「互い違いに重なる列に配置して密な森のパターンを作る」としています。影については、まず実用重視です。「ゲームデザイン上は、影を木の真下に置くのが最も実用的」。もっとも本人は「より動きのある見た目のために片側へずらす」のが好みだとも述べています。影は「控えめに、特定の方向へ長く伸ばさない」こと。そして壁の落とす影については、「1タイルの長さを超えてはならない」とのことです。84
  6. 色は見本ではなくランプです。 ランプが明るくなる方向へは暖色側に、暗くなる方向へは寒色側に、1段あたり最大20度の色相シフトをかけます。彩度はランプの中ほどで最大になります。68 LPCのルールは三語で言えば「純色は使うな!」。影は「いちばん近い紫のほうへ」、ハイライトは「いちばん近い黄のほうへ」。76 スプライト1体あたり、Schlitterは陰影に自信が持てるまで「せいぜい5色ほど」を勧めています。そしてCureの法則が効いてきます。「4色でいいスプライトが作れないなら、40色使っても助けにはならない」。8586
  7. アウトラインのルールは一つ、どこにでも適用します。 LPCはこう定めます。背景のアウトラインは「現在の色をより暗くしたもの、あるいは一般に暗い色であって、黒ではない」。キャラクターのアウトラインは「黒またはほぼ黒で、選択的アウトラインは使わない」。76 第1節のSNESの表は、スタジオごとに選択が違うとどうなるかを示しています。肝心なのは、一度選ぶことです。
  8. 三つの失敗に名前を付け、見つけ出せるようにします。 ジャギーは線のリズムから外れた1ピクセル。バンディングは「隣り合うピクセルが下地のグリッド上で同じx座標またはy座標で終わってしまう」こと。ピローシェーディングは光を無視した同心円状の帯です。86 アンチエイリアスは長くゆるやかな段差にだけかけ、45度や直線には決してかけないこと。そしてぼかしはスプライト自身の色のなかに収め、背後にあるものに対してかけないこと。背景を決めるのはゲームの側だからです。8687 16ピクセルの世界でのディザリングは、ほぼ出番がありません。Pixel Parmesanの言葉を借りれば、一部のスプライトは「含みうるディテールの量に対して、ディザをかけるには小さすぎる」のです。88
  9. キャラクターは、描く方向は3つ、歩行は4ステップ、アイドルも動かします。 Stardewの農夫は16×32で、決まった順序(体、ズボン、シャツ、アクセサリー、髪、帽子、腕)で描かれ、帽子は20×20のセルに収まります。歩行は3枚の固有フレームによる4ステップです。8990 Pokémon Emeraldは歩き、立ち、歩き、立ち。48 Schlitterいわく、頭は「スプライト全体の3分の1から半分を占める」。上、下、横を描いて横を反転させること。そしてアイドルについては、「筋が通っている必要すらない。とにかく動かせ」。9192
  10. 文字はアートです。 ビットマップフォントは整数倍でしか描画しません。Daniel Linssenのm5x7のページには「フォントサイズは16、32、48などを使うこと」とあります。93 Pokémon Emeraldのテキストウィンドウ枠は24×24の画像、つまりハードウェアタイル3×3で、これはナインスライスです。Asepriteのスライスはナインパッチの中心をエクスポートJSONへ持ち越してくれます。9495
  11. 穏やかな世界におけるジュースは、天候です。 画面揺れとヒットストップの定番の講演は、シューティングとブロック崩しを題材に組み立てられたものでした。コレクターの町に必要なのは、Stardewの天候の語彙(晴れ、雨、嵐、花粉や落ち葉を伴う風、雪)と、新しい絵ではなくタイルのプロパティから鳴る足音です。969798
  12. パイプラインはビルド工程です。 Asepriteのコマンドラインは、パックしたシートをJSONとともに書き出します(--sheet-type packed --shape-padding 2 --extrude --format json-array --list-tags --list-slices)。2ピクセルのパディングと押し出しが、各フレームの縁を隣のフレームからのにじみから守ります。99100

動画:Pixel Art Class, Top Down Style Analysis & Tutorial, AdamCYounis

5. Apple流——三つのアーキテクチャ、一つのレシピ、そして算数

私たちの課題は、互いに引っ張り合う二つの半分でできています。世界のほうは、整数倍に拡大され、nearestでサンプリングされ、ライティングされないテクセルがピクセル境界にぴたりと乗ることを求めます。そのなかで唯一「本物」であるもの、つまりコレクターのお気に入りのカードは、陰影のついた3Dオブジェクトとして平らな世界から立ち上がり、載っている棚に隠れてほしい。つまりタイルと同じ深度バッファのなかに存在しなければなりません。カードを第2のレイヤーとして合成する設計は、この遮蔽を失い、その瞬間を偽物にします。両方の半分を抱えられるAppleのアーキテクチャは3つあり、それぞれコストが違います。

SpriteKit 2DエンジンとしてのRealityKit Metal、低解像度で描いてから整数倍に拡大
ピクセルのサンプリング すべてのテクスチャにSKTexture.filteringMode = .nearest、ミップマップはオフ101 マテリアルに完全なMTLSamplerDescriptorを指定し、.nearestと.notMipmapped。テクスチャにはMipmapsMode.none14 自前のサンプラー。すべてのフィルターを自分で握る111
タイルマップ SKTileMapNode。チャンク分割され、全タイルが1つのアトラスを共有していれば可視チャンクごとに1ドローコール、隣接ルールあり102 マップ全体で1つのMeshDescriptor、1ドローコール。iOS 26から小物にGPUインスタンシング109 自前の頂点バッファ
スプライトのフレーム アトラステクスチャとSKAction.animate クアッドごとのtextureCoordinateTransformのオフセットとスケール(iOS 18)15 インスタンスごとのUV矩形
3Dのカード SK3DNodeがSceneKitをホストするが、AppleはWWDC25でこれを非推奨としメンテナンスモードへ移行103 同じシーン・同じ深度バッファ内のふつうのエンティティ。ライティングされない世界が無視するライトで照らす 自分で書く3つ目のパス
レンダラーの既定値 ドット絵にはそのままで問題なし モーションブラーとHDRトーンマッピングが既定でオン。被写界深度、カメラグレイン、アンチエイリアスは明示的にオフへ16 なし
フレームレート ProMotionのペーシングは自動113 Appleのパフォーマンス記事は60fpsの上限に言及114 CADisplayLinkとCADisableMinimumFrameDurationOnPhoneキーで120Hz113
パネル厳密なピクセル ビューのスケールフィルターを制御できない RealityViewにcontentScaleFactorがない QA1909に従いdrawableSize = bounds × nativeScale112
既知の落とし穴 ラベルにはnearestフィルターをかけられない。iOS 9の退行で.nearestが無視されたことがある カメラのscaleは説明が1行だけで単位の記載がない。平行投影カメラでの射影が誤った値を返すというフォーラム報告がある104105 アトラスパッカー、テキスト、入力、シーングラフを自分で書くことになる

純粋な2Dゲームであれば、いまもSpriteKitが最短経路であり、非推奨ではなく保守され続けています。本物の3Dオブジェクトを1つ必要とする世界には、RealityKitが正しいエンジンであり、ピクセルアートの要件にはすべてドキュメント化されたAPIがあります。Metalは、RealityKitが約束できない2つのもの、すなわち120Hzとパネル厳密なスケーリングのための避難口です。文書化されている手段はRealityRendererで、同じエンティティを自前のテクスチャへ描画し、自分で提示するnearest拡大パスに回せます。110

レシピ

// One texel is k device pixels, with k a whole number. Pixels, not points.
let pixelsTall = Float(size.height * displayScale)
let k = max(1, (pixelsTall / (20 * 16)).rounded(.down))   // aim for about 20 tiles tall
let worldTall = pixelsTall / k                            // world units are texels
var camera = OrthographicCameraComponent()
camera.scale = worldTall / 2                        // measured: scale is half the view's height
cameraEntity.components.set(camera)

// Nearest sampling, no mipmaps, alpha test instead of blending.
let sampler = MTLSamplerDescriptor()
sampler.minFilter = .nearest
sampler.magFilter = .nearest
sampler.mipFilter = .notMipmapped
let texture = try TextureResource(image: sheet, options: .init(semantic: .color, mipmapsMode: .none))
var material = UnlitMaterial()
material.color = .init(tint: .white, texture: .init(texture, sampler: .init(sampler)))
material.opacityThreshold = 0.5
material.textureCoordinateTransform = .init(
    offset: [Float(col) / Float(cols), 1 - Float(row + 1) / Float(rows)],
    scale: [1 / Float(cols), 1 / Float(rows)], rotation: 0)

// Switch the AR defaults off.
content.renderingEffects.motionBlur = .disabled
content.renderingEffects.depthOfField = .disabled
content.renderingEffects.cameraGrain = .disabled
content.renderingEffects.antialiasing = .none
content.renderingEffects.dynamicRange = .standard

このコードについて3点。AppleがOrthographicCameraComponent.scaleについて記しているのは「カメラがエンティティを拡大縮小するために使う浮動小数点値」だけで、画面高さの半分という関係は私たちがシミュレータ上で実測したものです(3倍環境・1テクセル7ピクセルで、320ワールド単位が746.67ポイントに相当しました。320×7÷3の値です)。104 opacityThresholdはピクセルアートが求める切り抜きの経路です。「RealityKitはopacityThresholdより小さい不透明度のピクセルを破棄し」、残りを完全な不透明として描画するため、縁のブレンドもソート順の問題も起こりません。15 そして、どのサンプラーよりも効いてくるのが既定値です。RealityViewは明示的にオフにしない限り、「仮想オブジェクトにモーションブラーを導入するエフェクトを適用」し、さらに「ハイダイナミックレンジのエフェクトとトーンマッピング」を適用します。16 そうするまで、歩くキャラクターは足を踏み出すたびににじんでいました。各スプライトのxとy、そしてカメラは、イージングのあと毎フレーム整数のワールド単位へ丸めています。これでテクセルがピクセルの境目に挟まることはなくなり、一方で奥行きと3Dカードの動きは連続したままです。また、フォーラムで報告されている射影の不具合があるため、タップのワールド座標はRealityKitに尋ねるのではなく、カメラ位置、k、ディスプレイスケールから自分で計算しています。105107

シミュレータ上で、開いたiPhone Duoの内側ディスプレイいっぱいに表示されたKiradexの広場。1テクセル6デバイスピクセルで描かれた芝生と小道、セーフエリア内に収まったHUD。

スケーリングの算数

3倍というスケールファクターは、16ピクセルのグリッドと何の関係もありません。効いてくるのはピクセル数です。16テクセルのタイルで縦およそ20タイルを狙うなら、k = floor(pixelsTall ÷ 320)。余りの扱いから2つの戦略が導かれます。収まるだけタイルを収める(横長の画面ほど世界が広く見え、帯は出ない)か、縦ちょうど20タイルを保って残りを帯に回すかです。以下の各行はAppleの仕様ページとXcode 27のシミュレータプロファイルから計算しました。17118

機種と向き ポイント ピクセル k 見えるタイル数(横×縦) 縦ちょうど20タイルにした場合の帯
iPhone 18 Pro Max、縦 440 × 956 1320 × 2868 8 10.3 × 22.4 308 px
iPhone 18 Pro、縦 402 × 874 1206 × 2622 8 9.4 × 20.5 62 px
iPhone Duo 外側、縦 466 × 678 1398 × 2034 6 14.6 × 21.2 114 px
iPhone Duo 内側、開いた状態(横) 951 × 669 2853 × 2007 6 29.7 × 20.9 87 px
iPhone Duo 内側、縦 669 × 951 2007 × 2853 8 15.7 × 22.3 293 px
iPad Pro 13インチ、横 1376 × 1032 2752 × 2064 6 28.7 × 21.5 144 px
Apple TV 4K 1920 × 1080(2倍) 3840 × 2160 6 40.0 × 22.5 240 px

これらの高さはどれも320で割り切れません。つまり現行デバイスでは「縦ちょうど20タイル」は必ず帯を意味します。18 Pro Maxの2868 ÷ 320 = 8.96が、きれいな9にいちばん近い値です。HIGはゲームに対して「さまざまなアスペクト比で見栄えよく、ふるまいも良いこと」と「全画面での体験を前提に設計すること」を求めており、これは帯を出すより世界を広く見せるべきだという議論につながります。広場ではそのとおりにし、全体を見せる部屋のほうは中央寄せにしています。115 3倍ディスプレイでk = 8のとき5テクセルのフォントは13.3ポイント、k = 6では10ポイントとなり、HIGの最小11ポイントを下回ります。そのため会話テキストはワールド内ではなくSwiftUI側のUIスケールに置いています。115 そのSwiftUIのクローム内にあるピクセルアートのアイコンやナインスライスの枠には、Image.interpolation(.none)が鮮明さを保ってくれます。116

iPhone Duoの内側ディスプレイは、唯一この算数が決着していない場所です。Appleの仕様表はパネルを1878×2670ピクセルとしていますが、シミュレータのプロファイルは論理フレームバッファを2007×2853、スケール3.0としています。つまりUIKitは669×951ポイントを3倍で描画し、コンポジタがそれを約0.936倍にダウンサンプリングしてガラス面に合わせているわけで、これはAppleのTechnical Q&A QA1909がPlus系の機種について説明しているふるまいそのものです。したがってUIScreen.nativeScaleはおよそ2.807となり、1テクセル6論理ピクセルは実際のパネル上では約5.6ピクセルになります。17112120 論理フレームバッファを表示するシミュレータでは広場は正しく見えますが、実機ではごくわずかに甘くなるはずです。これを避けられるのはnativeBoundsでMetalが所有するドローアブルだけであり、最初の一歩は実機でnativeScaleをログに出すことです。外側ディスプレイはきれいに割り切れます(1398 ÷ 466 = 3.0)。

見つかった2つのバグと、1つのキャプチャ上の異常

カードビューアは、シーンが1回目とフレーム単位で同一であるにもかかわらず、2回目と3回目に開いたときに真っ黒になりました。原因は、RealityViewのMetalレイヤーを含むSwiftUIビューにかけた不透明度アニメーションです。この境界をまたいで.opacityをアニメーションさせると、レイヤーが描画されないまま残ってしまいます。修正は、ビューのアニメーションをやめ、代わりに黒いベールのオーバーレイをフェードアウトさせることでした。負荷のかかったシミュレータでは最初の描画が最大12秒ほど遅れて届くため、私たちのUIウォークスルーは一連のタイマー付き輝度サンプルのうち、最初ではなく最後のものを読むようにしています。

2つ目はレンダラーではなく、私たちのツール側にありました。ホストからDuoシミュレータの内側ディスプレイをキャプチャすると(xcrun simctl io <udid> screenshot --display=primary-1)、画像が更新されるのはCore Animationが再合成したときだけです。RealityKitのフレームだけでは再合成が起きないため、画面上では動いている歩行プレイヤーがキャプチャでは止まって見えます。テストバンドル内からXCUIScreen.screens[1]でキャプチャすると、ありのままが写ります。どちらも1日ずつを費やしたうえ、私が見つけられたどの文書にも載っていませんでした。ここに書いているのはそのためです。

iPhone 18 Pro Max上で、平らな広場からせり上がるコレクターのお気に入りのカード。ライティングのないピクセルの世界で唯一、光を受けて陰影のついたオブジェクト。

6. ケーススタディ——自分たちの広場を裁き、ルールで作り直す

TestFlightのビルド18として出荷された時点のKiradex Worldを、第1節から第4節に照らして正直に監査した結果がこれです。地面はテキストのグリッドに打ち込んだ場当たり的な色による28タイルのセットで、ランプもなければ光の取り決めもないベタ塗り。コレクターは48×96のシートで、歩行は2フレーム、アイドルなし、影なし、アウトラインの方針はスプライトごとにばらばら。頭上レイヤーがないので、木陰の下や屋根の下を通り抜けることもできません。オートタイルもないので、芝生から小道へのつなぎ目はどれも定規で引いた直線。高さの概念もなし。下まわりのエンジンは健全でした(マップはメッシュ1枚、nearestサンプリング、整数倍スケール、カードは同じ深度バッファ)。しかしその上に載っていたアートは、Game Boyに顔向けできない代物でした。

8倍に拡大しグリッドを重ねた、旧Kiradexのタイルセットとコレクターのシート。ベタ塗り、テキストグリッド由来のタイル、2フレームの歩行。

仕様書

以下の仕様は私たち自身のもので、上に挙げた出典のある実践から導いたものです。事実ではなく推奨にすぎない数値については、推奨であると明記します。

  • 投影とグリッド。 平行投影の3クォータービュー、光は左上から1方向、垂直線は垂直のまま。タイルは16×16。家と大きな木は32ピクセルのリズムで。部屋は10×8から12×9タイル。町の規模はトウカシティの30×30とカナズミシティの40×60のあいだ。
  • レイヤー、描画順に。 地面(オートタイルの芝生、小道、広場の石畳、水)、ディテール(バリエーション、花、焼き込んだ影)、オブジェクト(接地点でy方向にソート。人、ベンチ、街灯、幹、建物の正面、衝突判定あり)、頭上(屋根、木陰、手すり。常に人より上)、ライト(加算合成の街灯スプライト、夕暮れで差し替え)、天候、そして独自スケールのUI。Stardewの5レイヤーに、PokémonのNormal(上レイヤーがプレイヤーを覆う)を頭上として加えた構成です。
  • オートタイル。 芝生から小道、芝生から水、芝生から崖、広場から小道の4つに47タイルのblobセット。柵と生け垣に16タイルの辺セット。芝生のバリエーションは3種で、繰り返しが目立たないように重みを付けます。水は250ミリ秒で4フレーム(Emeraldの16ティック×8段がリズムの参照元)。花は2フレーム。街灯は2状態に夜のちらつきを追加。
  • パレット。 マスターパレットは1本、色相をずらした6〜8本のランプで48〜64色、彩度はランプの中ほどで最大、純色は使わず、屋内は寒色側の半分から取ります。スプライト1体あたり最大8色、タイル1枚あたり6色まで。夕暮れと夜は世界全体への乗算ティント1枚に、街灯、窓、売店の看板用の手描き発光バリエーションを加えて表現します。
  • キャラクター。 16×32のセルに幅16・高さ24の人物、頭は9〜10ピクセル、目は1ピクセル、口なし、足は最下段のタイルに接地させてy方向のソートが接地点を使えるようにし、帽子とカードを掲げる動作のために頭上8ピクセルを空けます。描く方向は3つと反転した4つ目。ただしカードを掲げる動作だけは、持ったカードが左右非対称なので右向きを別途描き起こします。歩行は125ミリ秒で4フレーム、アイドルは1ピクセル上下する2フレーム、カード掲げは3フレーム(予備動作、掲げ、保持)。ペーパードール方式のレイヤーはStardewの順序に従い、それぞれ体のグリッドに載る完全なシートとし、帽子は方向ごとにアンカーを設定します。すべての人と木の下に12×4の楕円影を置きます。
  • アウトライン。 キャラクターはほぼ黒、世界側は周囲より暗い固有色、タイルの内部には決して引きません。
  • テキスト。 m5x7を整数倍で、24×24のナインスライスの枠に2行、タイプライター表示、送りの矢印は2フレーム。ピクセル密度に対する唯一の意図的な例外が、コレクターの本物のカードです。エンジンがすでにプレイヤーの頭上へ掲げている、陰影のついた3Dカードで、高さ3タイル、同じシーンのなかにあります。掲げた手のなかの小さなカードは所持レイヤー上のスプライトであり、両者が同じ物体のふりをすることはありません。

フォージ

このアートを画像編集ソフトで描くつもりはありませんし、プロンプトから生成するつもりもありません。米国著作権局の2025年1月の報告書は、著作者性について「プロンプトだけでは十分な制御を与えない」と結論しています。作者のいないタイルセットとは、アプリから誰でも持ち去ってよいタイルセットのことです。同じ報告書は「出力に対する創造的な改変」と、AIが人間の代わりではなく補助として働いた成果物を保護します。18 Circular 33はアイデア、手順、システム、操作方法を著作権の外に置いています。投影方法、タイルサイズ、レイヤー構成はまさにそこに属します。一方で個々のタイルやスプライトは保護される表現であり、名称が保護されるとすれば商標としてです。つまり筋の通った道は、すべてのピクセルの来歴を自分のものにすることです。19 私たちのフォージはscripts/forge/以下の小さなPythonプログラムで、1本のマスターパレットに対し、手で定めたルールからすべてのタイルとスプライトを描きます。パレットモジュールは色相をずらした14本のランプで58色を構築し、確認用にGIMPのパレットファイルを書き出します。ラスターはインデックスカラーです。スプライトは色名のグリッドであり、1ピクセルが取りうる値はパレットのエントリか、アプリがコレクターごとに塗り替える9つのマーカー色のいずれかだけ。地形モジュールは芝生、踏み固めた土、敷石、水を描き、そのうえで内側の地形の上に外側の地形を、揺らいだ境界線に沿って、外角を丸めて縁色を添えながら塗り重ねることで、47通りのblob遷移をすべて生成します。ランダムな選択はすべて位置から決まる固定ハッシュなので、作り直せばバイト単位で同一の結果になります。そしてすべてのルールは、人間が書き、弁明できる1行のコードです。

Kiradexのマスターパレット。色相をずらした14本のランプに58色。影は紫へ、ハイライトは黄へ寄っていく。

芝生のなかの小道のための47タイルのblobセット、ルールによる生成。cr31のビットマスクで索引付けされた辺と角に、揺らいだ境界線と暗い草の縁。

芝生と小道のセットを敷いた検証用フィールド。縁は定規を当てたようにまっすぐではなく揺らぎ、芝生のバリエーションが繰り返しを崩し、丸められた角が踏み減らされた地面に見える。

最初のフィールドは、この手法がそもそも成立することの証明でした。翌朝には、同じプログラムでキャラクターとエンジンが名前を持つ28タイルが続きます。16×32のセルに入る16×24の人物は、体、髪、帽子、所持カードのレイヤーとして描かれ、アプリがコレクターごとの見た目に差し替えるマーカー色を保持します。アイドルは2フレーム、歩行は4フレーム、カード掲げは3フレーム。木は幹の上の葉の束で、影はその下に。壁の漆喰には幅木を付けません。同じタイルが部屋の外の壁面も埋めるため、幅木があると画面全体に縞が走ってしまうからです。水は4フレームで、地面が1秒に4回それをめくっていきます。下のキャプチャは、これらとともに合格したシミュレータでの歩行確認です。広場はまだエンジンが名前を持つ28タイルを敷いているので、JSONのマップがblobセットを運んでくるまで、側面の縁はまっすぐなままです。

フォージ導入後、iPhone 18 Pro Max上のKiradexの広場。ルールで描かれた芝生、小道、敷石のタイル、下に影を持つ木々、柵と池、帽子をかぶった者もいるコレクターたちはそれぞれ楕円の影を持ち、2軒の家の正面が並ぶ。

部屋、ホール、小物、そしてより大きな町も、同じプログラムで続きます。出口にはAseprite互換のシートとJSONが並ぶので、アートが変わってもSwift側のローダーは一切変わりません。

この世界が果たすこと

アートのプログラムはメカニクスのためにあり、コレクションゲームの調査は作業の順序を変えました。主役はカードです。世界はつや消しのまま保ち、本物のカードだけが陰影を持つ唯一のオブジェクトになります。というのも、1億回以上ダウンロードされたゲームであるPokémon TCG Pocketでは、1枚を飾るディスプレイボードと30枚のアルバムで見せ場として十分だったからです。129 部屋の家具は16個が上限——Secret Baseと同じ数です。上限こそが棚を構図に変えるからです。訪問は読み取り専用、いいねは1日1回、部屋の累計は決して減りません。これはClub Penguinがイグルーに課したルールです。122124 訪問者は部屋ごとに旗を獲得し、30、100、500でランクが上がります。見知らぬ人の秘密基地に入ることを主要な動詞に変えた、ORASのランク設計です。125 毎週日曜には部屋を採点するレポートが届き、得点の内訳が示されます。ハッピーホームアカデミーのリズムです。123 週替わりのホールが借りてくるのはPokémonのコンテストではなくStardewの品評会です。9つの台座、基礎点、年代とセットにまたがる多様性ボーナス、スキャン記録由来のアイテム点、3段階のしきい値、そして見知らぬ人でも一目で分かる審査基準。121 チャットはプリセット文のツリー(あいさつ、返答、コレクションの話題、リアクション)にとどめ、語彙は遊ぶことで解放されます。Emeraldの「流行の人」が、記録交換で現れるたびに流行語を1つ解放してくれたのと同じやり方です。自由入力は絶対に用いません。Club Penguinの単語フィルターは「mom」を弾いたうえ、自社のヘルプページ自身が認めるとおり、一部の不適切なメッセージは通してしまっていました。133124 さらにFTCの2022年の命令は、Epicに対して子どもと10代のユーザーでは音声チャットとテキストチャットを既定でオフにするよう求めています。126124131 1日1人につき小さな贈り物を1つ、友好度のランクは1日、7日、30日、90日。これはPokémon GOの階段です。127 支援者向けの装飾はネームプレートと部屋のスキンにとどめ、台座の枠や審査のボーナスには決して触れません。コージーゲームの論文が警告する「豪華さはしばしば社会的比較のプレッシャーを生みうる」が限界線です。128 ランダム性のあるものは一切販売しません。

アートに続くエンジン側の作業は次のとおりです。ハードコードされた行の代わりにJSONから読み込むレイヤー化タイルマップ、共通のリズムで動くアニメーションタイル、y方向のソートによる遮蔽を持つ頭上レイヤー、フレームごとに合成されるペーパードールのスプライト、そしてサーバー側のマップ、NPC、パリティの各テーブルの更新です。

重要なポイント

アートを描く人へ

  • 最初の1タイルを描く前に、セル、パレット、光を固定すること。16×16のタイル、16×32のセルに入る16×24の人物、色相をずらしたランプで48〜64色、光は左上から。このガイドに登場した巨匠はひとり残らず、制約を起点に発想していました。
  • アウトラインのルールは一つ選び、キャスト全体に適用すること。FF VIの93パーセントの黒い輪郭も、Secret of Manaのゼロパーセントも、どちらも一貫しています。両者を混ぜたキャストは一貫しません。9
  • フレームは表現に、色は動きに使うこと。FF VIの46ポーズ、Emeraldの歩き・立ち・歩き・立ち、そしてスプライトではなく色を動かすサブピクセルアニメーションです。14866
  • つなぎ目は47タイル、柵は16タイル、木は葉の束で影は真下に。ルールは一度だけ描き、あとはエディタに配置させましょう。8084

Appleのプラットフォームで作る人へ

  • 平らな世界のなかで1つだけ本物の3Dでなければならないものがあるなら、RealityKitにとどまること。深度バッファを共有でき、ピクセルアートの要件にはすべてドキュメント化されたAPIがあります。純粋な2Dゲームを作るならSpriteKitを選び、120Hzとパネル厳密なピクセルのためのMetalの避難口としてRealityRendererを控えに置いておきましょう。14110
  • ARの既定値は初日に切ること。モーションブラーとHDRトーンマッピングは無効化しない限りオンであり、本記事のレシピは被写界深度、カメラグレイン、アンチエイリアスもオフにします。いずれもテクセルをにじませるからです。16
  • 計算はピクセルで行うこと。k = floor(pixelsTall ÷ 320)、各スプライトのxとyおよびカメラは整数のワールド単位へ丸め、シミュレータを信じる前に実機でUIScreen.nativeScaleを読むこと。とりわけiPhone Duoではそうしてください。112118
  • 私たちのRealityViewでは、それを含むビューの不透明度をアニメーションさせると画面が黒くなりました。代わりにベールをかぶせてフェードさせましょう。Duoの内側ディスプレイのキャプチャは、ホストからではなくテストバンドル内から行うこと。そしてLSSupportsGameModeを追加しましょう。Game Modeは「バックグラウンドの処理を抑えて、より滑らかなゲームプレイとより安定したフレームレートを実現」します。117

スタジオを経営する人へ

  • アートの規模をチームに合わせること。Eric Baroneは1人でStardewほどの広さの世界を描けるよう16×16のタイルを守り続けており、SabotageはSea of Starsの制作中に7人から約25人へ成長しました。7172
  • エンジン開発に半年を割けるのでなければ、MoonlighterからCelesteまでの段のライティングを選ぶこと。HD-2Dの段は「思っている以上にコストがかかる」うえ、ほかならぬそのプレイヤーたちがエフェクトをオフにしています。101113
  • すべてのピクセルの来歴を自分のものにすること。純粋にプロンプトで生成されたアートは、著作権局自身の結論によれば保護されず、混在する場合は個別に判断されます。手で描いたアート、そして人が書いたルールによって描かれたアートは、人間の著作者としての来歴を保ちます。18
  • コレクターのための世界では、集めたものだけを唯一つやのあるオブジェクトにし、部屋に上限を設け、日曜に採点し、いいねは増える一方にし、そして文字入力は決してさせないこと。Daniel Cookの「チャットをなくせば、ポジティブな社会的行動の95パーセントもなくなる」は事実です。だからこそ、子どもが入力したくなる答えをプリセット文のほうが担わなければならないのです。130

よくある質問

見下ろし型のピクセルアートゲームには、どのタイルサイズを使うべきですか

16×16です。Game Boyの16ピクセルの歩行マス以来Pokémonが使い続けてきたセルであり、Stardew Valleyが土台とするセルであり、Raymond Schlitterが「作業するうえで最もバランスの取れたサイズ」と呼ぶセルでもあります。4079132 キャラクターは16×32のセルに収め、体の高さはおよそ24ピクセル。家と大きな木は2タイル単位で設計します。

iOSのピクセルアートにはSpriteKitとRealityKitのどちらがよいですか

3Dオブジェクトを含まないゲームならSpriteKitです。隣接ルール付きのタイルマップ、ノーマルマップによるライト、そしてfilteringMode = .nearest。必要な対処はこれだけです。101102 シーンのなかの一つだけがタイルと同じ深度バッファで陰影のついた3Dでなければならないなら、RealityKitです。平行投影カメラ、明示的なブレンドモードまたは不透明度しきい値を備えたUnlitMaterial、nearestサンプラー、ミップマップなし——いずれもドキュメント化されており、iOS 26ではインスタンシングとポストプロセスのフックも追加されました。104106108109 SpriteKit唯一の3Dの橋であるSK3DNodeはSceneKitに依存しており、AppleはWWDC25でSceneKitをメンテナンスモードに移しました。103

iPhoneの画面で整数倍スケーリングを実現するには

ピクセルで考えることです。ビューのポイント数にdisplayScaleを掛け、高さを320(16ピクセルのタイル20枚分)で割り、小数点以下を切り捨てる。それが1テクセルあたりのデバイスピクセル数です。iPhone 18 Pro Maxでは8、開いたiPhone Duo、13インチiPad Pro、4K Apple TVでは6になります。17119 カメラと各スプライトのxとyは、毎フレーム整数のワールド単位へ丸めてください。余りを「より広い世界」に回すか、レターボックスの帯に回すかを決めましょう。現行のiPhoneで高さが320で割り切れる機種はありません。iPhone Duoの内側ディスプレイでは、実機でUIScreen.nativeScaleを確認してください。パネルの1878×2670ピクセルは、シミュレータが示す2007×2853のフレームバッファと一致しないからです。112

ゲームのピクセルアートをAIに生成させてもよいですか

画像を生成することはできますが、プロンプトだけでは生成物に対する著作権は得られません。米国著作権局の2025年の報告書は、純粋にAIが生成した素材は保護されず、「プロンプトだけでは十分な制御を与えない」と結論する一方で、出力に対する人間の創造的な改変と、AIが人間の創造性の「代わりではなく補助として」使われた場合は保護されるとしています。18 出荷するゲームにとっての実際上の帰結はこうです。プロンプトから丸ごと生成され、人間の表現が何も加えられていないタイルセットには、行使できる著作権が存在せず、その学習データの来歴も知りようがありません。人が表現を加えた場合には、著作権局はその寄与を個別に判断します。自分で描くか、描くためのルールを自分で書くか。そしてどちらなのかを記録しておきましょう。

「Pokémonに着想を得た」世界の、法的な線引きはどこですか

作風、手法、システムは保護されず、具体的な表現が保護されます。Circular 33は「あらゆるアイデア、手順、プロセス、システム、操作方法、概念、原理、発見」を著作権から除外しています。19 16ピクセルのタイルによる3クォータービューの町、2層のメタタイル、歩き・立ちの歩行、47タイルの海岸線——これらは手法です。マサラタウンのタイル、あの生き物たち、モンスターボール、タイプのシンボルは表現であり、名称は商標です。Kiradexはすべてのタイルとスプライトを、自前のパレットのなかで自前のルールから描いており、アプリ内のどこを探してもPokémonの図像はユーザーがスキャンした本物のカードだけです。

地形のつなぎ目に、なぜちょうど47タイルが必要なのですか

タイルの見た目が8つの隣接マス(4辺と4つの角)に依存し、組み合わせが256通りあるからです。ただし角が意味を持つのは、その両隣の辺もそろっているときだけ。このルールのもとで256のマスクを畳み込むと、47の異なるシルエットが残ります。Tiledのドキュメントが混成セットの標準的な縮約形として「47タイルのBlobタイルセット」を名指ししているのは、このためです。808182


このガイドの作り方について。 背景となる6本の調査ドシエは2026年10月2日にClaudeのエージェントでまとめ、本文中のすべての数値は、注に挙げた一次情報源から改めて読み直しました。pretの逆コンパイル、Appleのドキュメント(JSONエンドポイント経由)、開発者自身の講演や投稿、そしてShmuplations、Nova Crystallis、Lava Cut Contentにある翻訳インタビューです。スプライトの計測、スケーリングの算数、RealityKitのカメラの実測、そしてKiradexのフォージは私自身の仕事であり、その旨を明示しています。ある主張が単一の情報源に依拠している場合は、注にそう書いてあります。

当サイトの関連記事。iPhone Duoを開発者の視点ででは、上のスケーリング表が立脚する内側ディスプレイのポイント寸法と1.42という比率を導いています。iPhone Duoに向けてアプリを準備するは、折りたたみ、予約領域、そして広場がいま従っているHUDのルールを実例で示したものです。Xcode 27.1ベータ——iPhone Duoシミュレータで自分のアプリを動かすは、シミュレータと、本記事のキャプチャの元になったDevice Hubのポーズを扱っています。RealityKitと空間のメンタルモデルは第5節のRealityKitの土台です。Metal 4の要点は、例の避難口を作るとしたら使うAPIを扱っています。そしてブラウザでMacPaintを再現するは、私が一次資料からピクセルレンダラーを作り直した前回の記録です。

出典


  1. FF6hacking Wiki「Sprites (FF3us tutorial)」2026年10月2日閲覧、https://www.ff6hacking.com/wiki/doku.php?id=ff3%3Aff3us%3Atutorial%3Asprites。 ↩↩↩↩↩

  2. pret、pokeemerald/include/global.fieldmap.h(メタタイルとマップセルのレイアウト、レイヤー型)、pokeemerald/include/fieldmap.h(NUM_TILES_IN_PRIMARY 512、NUM_TILES_TOTAL 1024、NUM_PALS_TOTAL 13、NUM_TILES_PER_METATILE 8)、pokeemerald/include/constants/metatile_behaviors.h(240種の挙動)、2026年10月2日閲覧、https://github.com/pret/pokeemerald/blob/master/include/global.fieldmap.h、https://github.com/pret/pokeemerald/blob/master/include/fieldmap.h、https://github.com/pret/pokeemerald/blob/master/include/constants/metatile_behaviors.h。 ↩↩↩↩↩

  3. Pedro Medeiros「Consistency」Saint11、2026年10月2日閲覧、https://saint11.art/blog/consistency/。 ↩↩↩

  4. Fabien Sanglard「Why Did the SNES Have Two PPUs?」2026年10月2日閲覧、https://fabiensanglard.net/snes_ppus_why/。 ↩↩↩

  5. gbdev「Tile Data」Pan Docs、2026年10月2日閲覧、https://gbdev.io/pandocs/Tile_Data.html。pret、pokered/gfx/tilesets(96タイルのセット)、https://github.com/pret/pokered/tree/master/gfx/tilesets。 ↩

  6. pret、pokered/engine/gfx/sprite_oam.asm(UNDER_GRASSのプライオリティビット)、2026年10月2日閲覧、https://github.com/pret/pokered/blob/master/engine/gfx/sprite_oam.asm。 ↩↩

  7. 「Final Fantasy VI Developer Roundtable (1994)」Shmuplations訳、2026年10月2日閲覧、https://shmuplations.com/ff6rt/。 ↩

  8. 「Final Fantasy 35th Anniversary Special Interview, Part 2」書き起こし、Nova Crystallis、2023年7月、2026年10月2日閲覧、https://novacrystallis.com/2023/07/final-fantasy-35th-anniversary-special-interview-part-2-of-2-transcription/。 ↩↩↩↩↩

  9. 著者による計測、2026年10月2日。videogamesprites.netのアニメーション単位の切り出し素材から、各作品の主人公1体の立ちフレームを対象とした(いずれも正確な2倍ニアレストネイバー拡大であることを確認済み)。輪郭ピクセルとは、4近傍のいずれかが透明である不透明ピクセルを指す。「ほぼ黒」は全チャンネルが255中40以下であることを意味する。アーカイブ:http://www.videogamesprites.net/。 ↩↩↩

  10. 「Moonlighter: Building Pixel Art & Preparing for Switch」80.lv、2026年10月2日閲覧、https://80.lv/articles/moonlighter-building-pixel-art-preparing-for-switch。 ↩↩↩

  11. Noel Berry「Remaking Celeste’s Lighting」2026年10月2日閲覧、https://noelberry.ca/posts/celeste_lighting/。 ↩↩↩

  12. 「Eastward’s Creators Share Insights on Making Pixel Art Adventures」Game Developer、2026年10月2日閲覧、https://www.gamedeveloper.com/art/eastward-s-creators-share-insights-on-making-pixel-art-adventures。 ↩↩

  13. 「Triangle Strategy Producers Talk HD-2D and Why Other Devs Haven’t Used It」Nintendo Life、2022年5月、2026年10月2日閲覧、https://www.nintendolife.com/news/2022/05/triangle-strategy-producers-talk-hd-2d-and-why-other-devs-havent-used-it。Octopath Traveler IIのプレイヤーによる回避策スレッド、Steam Community、https://steamcommunity.com/app/1971650/discussions/0/3777994452130450169/。 ↩↩↩↩

  14. Apple Developer Documentation「MaterialParameters.Texture.Sampler.init(:)」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/materialparameters/texture/sampler-swift.struct/init(:)。「TextureResource.MipmapsMode」https://developer.apple.com/documentation/realitykit/textureresource/mipmapsmode。 ↩↩↩

  15. Apple Developer Documentation「UnlitMaterial.opacityThreshold」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/unlitmaterial/opacitythreshold。「UnlitMaterial.textureCoordinateTransform」https://developer.apple.com/documentation/realitykit/unlitmaterial/texturecoordinatetransform-swift.property。 ↩↩↩

  16. Apple Developer Documentation「RealityViewRenderingEffects」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/realityviewrenderingeffects。 ↩↩↩↩

  17. Appleが公表しているパネル寸法(iPhone Duo:https://www.apple.com/iphone-duo/specs/、iPhone 18 Pro:https://www.apple.com/iphone-18-pro/specs/)とXcode 27のシミュレータデバイスプロファイルに基づく著者の計算、2026年10月2日。完全な表は第5節に掲載。 ↩↩↩↩

  18. U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability(2025年1月)、2026年10月2日閲覧、https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf。 ↩↩↩↩

  19. U.S. Copyright Office, Circular 33: Works Not Protected by Copyright、2026年10月2日閲覧、https://www.copyright.gov/circs/circ33.pdf。 ↩↩↩

  20. SNESdev Wiki「SNES PPU for NES developers」2026年10月2日閲覧、https://snes.nesdev.org/wiki/SNES_PPU_for_NES_developers。 ↩↩↩

  21. SNESdev Wiki「Sprites」2026年10月2日閲覧、https://snes.nesdev.org/wiki/Sprites。 ↩↩↩↩

  22. SNESdev Wiki「Backgrounds」2026年10月2日閲覧、https://snes.nesdev.org/wiki/Backgrounds。 ↩

  23. Wikipedia「Mode 7」2026年10月2日閲覧、https://en.wikipedia.org/wiki/Mode_7。 ↩

  24. SuperFamicom.orgのカートリッジデータベースにおけるFinal Fantasy IV、V、VIおよびChrono Triggerの項目、2026年10月2日閲覧、https://superfamicom.org/info/final-fantasy-4、https://superfamicom.org/info/final-fantasy-5、https://superfamicom.org/info/final-fantasy-6、https://superfamicom.org/info/chrono-trigger。FF Vの16メガビットについては、注26のFF VインタビューにおけるKokuboの発言(「今回は16Mbです」)にもある。 ↩

  25. 「Chrono Trigger Developer Interview (1995)」Shmuplations訳、2026年10月2日閲覧、https://shmuplations.com/chronotrigger/(時田:「このカートにはFFIVが4本入る」。Kamata:「8メガのうち6メガほどはグラフィックに使われたと思う」)。 ↩

  26. 「Final Fantasy V Developer Interview (1992)」Shmuplations訳、2026年10月2日閲覧、https://shmuplations.com/ffv/。 ↩

  27. Chrono Compendiumフォーラム「Sprite assembly data」トピック2872、2026年10月2日閲覧、https://www.chronocompendium.com/Forums/index.php?topic=2872.0。 ↩↩

  28. SNESdev Wiki「Color math」2026年10月2日閲覧、https://snes.nesdev.org/wiki/Color_math。 ↩

  29. 「Kazuko Shibuya」UT Magazine、ユニクロ、2026年10月2日閲覧、https://www.uniqlo.com/jp/en/contents/feature/ut-magazine/s134/。 ↩

  30. 「Chrono Trigger Developer Interviews (1995), Part 2」Shmuplations訳、2026年10月2日閲覧、https://shmuplations.com/chronotrigger2/。 ↩

  31. 「Tetsuya Nomura on Final Fantasy VI」Final Fantasy Portal Site、2026年10月2日閲覧、https://na.finalfantasy.com/topics/528。 ↩

  32. 「Final Fantasy VI Developer Interviews (1994)」Shmuplations訳、2026年10月2日閲覧、https://shmuplations.com/ff6/。 ↩

  33. 「Seiken Densetsu 3 Developer Interview (1995)」Shmuplations訳、2026年10月2日閲覧、https://shmuplations.com/seikendensetsu3/。 ↩↩

  34. Wikipedia「Chrono Trigger」(開発の節、Yasuhiko Kamataを引用)、2026年10月2日閲覧、https://en.wikipedia.org/wiki/Chrono_Trigger。 ↩

  35. 「Interview: Discussing Final Fantasy Pixel Remaster Sprites and Designs」Siliconera、2026年10月2日閲覧、https://www.siliconera.com/interview-discussing-final-fantasy-pixel-remaster-sprites-and-designs/。 ↩↩

  36. 「Square Enix Details the Considerable Amount of Work That Went into the Fonts of Final Fantasy Pixel Remaster」GoNintendo、2026年10月2日閲覧、https://gonintendo.com/contents/21170-square-enix-details-the-considerable-amount-of-work-that-went-into-the-fonts-of。 ↩

  37. Jason Schreier「Oh No, Square Enix, What Have You Done to Final Fantasy」Kotaku、2026年10月2日閲覧、https://kotaku.com/oh-no-square-enix-what-have-you-done-to-final-fantasy-1502268040。 ↩

  38. pretの逆コンパイルプロジェクト(pokered、pokecrystal、pokeemerald、pokefirered、poketcg)、2026年10月2日時点のGitHub master、https://github.com/pret。タイル数は、以降の注に挙げるファイルのPNG寸法とバイトサイズから読み取った。 ↩

  39. gbdev「Graphics」および「Object Attribute Memory (OAM)」Pan Docs、2026年10月2日閲覧、https://gbdev.io/pandocs/Graphics.html、https://gbdev.io/pandocs/OAM.html。 ↩

  40. pret、pokered/data/tilesets/tileset_headers.asm、pokered/gfx/blocksets/、pokered/constants/map_constants.asm、2026年10月2日閲覧、https://github.com/pret/pokered/blob/master/data/tilesets/tileset_headers.asm、https://github.com/pret/pokered/tree/master/gfx/blocksets、https://github.com/pret/pokered/blob/master/constants/map_constants.asm。 ↩↩↩

  41. pret、pokered/data/tilesets/collision_tile_ids.asmおよびpokered/home/overworld.asm、2026年10月2日閲覧、https://github.com/pret/pokered/blob/master/data/tilesets/collision_tile_ids.asm、https://github.com/pret/pokered/blob/master/home/overworld.asm。 ↩

  42. pret、pokered/home/vcopy.asm(UpdateMovingBgTiles)、2026年10月2日閲覧、https://github.com/pret/pokered/blob/master/home/vcopy.asm。 ↩

  43. pret、pokered/data/sprites/facings.asmおよびpokered/gfx/sprites/、2026年10月2日閲覧、https://github.com/pret/pokered/blob/master/data/sprites/facings.asm、https://github.com/pret/pokered/tree/master/gfx/sprites。 ↩

  44. pret、pokecrystal/home/map.asm(LoadTilesetGFX)、pokecrystal/gfx/tilesets/johto_palette_map.asm、pokecrystal/gfx/tilesets/bg_tiles.pal、pokecrystal/constants/collision_constants.asm、2026年10月2日閲覧、https://github.com/pret/pokecrystal/blob/master/home/map.asm、https://github.com/pret/pokecrystal/blob/master/gfx/tilesets/johto_palette_map.asm、https://github.com/pret/pokecrystal/blob/master/gfx/tilesets/bg_tiles.pal、https://github.com/pret/pokecrystal/blob/master/constants/collision_constants.asm。 ↩↩↩

  45. pret、pokecrystal/gfx/overworld/npc_sprites.pal、2026年10月2日閲覧、https://github.com/pret/pokecrystal/blob/master/gfx/overworld/npc_sprites.pal。 ↩

  46. pret、pokeemerald/include/global.fieldmap.h。Porymapマニュアル「Editing Map Collisions」2026年10月2日閲覧、https://huderlem.github.io/porymap/manual/editing-map-collisions.html。 ↩

  47. pret、pokeemerald/data/layouts/layouts.json、2026年10月2日閲覧、https://github.com/pret/pokeemerald/blob/master/data/layouts/layouts.json。 ↩

  48. pret、pokeemerald/src/data/object_events/object_event_anims.hおよびpokeemerald/graphics/object_events/pics/people/、2026年10月2日閲覧、https://github.com/pret/pokeemerald/blob/master/src/data/object_events/object_event_anims.h、https://github.com/pret/pokeemerald/tree/master/graphics/object_events/pics/people。 ↩↩↩↩

  49. pret、pokeemerald/src/tileset_anims.c、2026年10月2日閲覧、https://github.com/pret/pokeemerald/blob/master/src/tileset_anims.c。 ↩

  50. pret、pokeemerald/src/field_effect_helpers.c(映り込み、影、草エフェクトの配置)およびpokeemerald/src/data/field_effects/field_effect_objects.h(5フレームの長い草スプライト)、2026年10月2日閲覧、https://github.com/pret/pokeemerald/blob/master/src/field_effect_helpers.c、https://github.com/pret/pokeemerald/blob/master/src/data/field_effects/field_effect_objects.h。 ↩

  51. pret、poketcg/Makefile(rgbgfx --colors embedded --auto-paletteのルール)およびpoketcg/src/gfx/cards/、2026年10月2日閲覧、https://github.com/pret/poketcg/blob/master/Makefile、https://github.com/pret/poketcg/tree/master/src/gfx/cards。パレット値はcharizard.pngとdoublecolorlessenergy.pngから読み取った。 ↩

  52. 「Pokémon: 2000 Developer Interview with Ken Sugimori and Shigeru Miyamoto」Shmuplations訳、2026年10月2日閲覧、https://shmuplations.com/pokemon/。 ↩

  53. 「Sugimori & Masuda Developer Interview (Nintendo Online Magazine, July 2000)」Anthony Madry訳、Lava Cut Content、2026年10月2日閲覧、https://lavacutcontent.com/sugimori-masuda-developer-interview/。 ↩

  54. 任天堂「社長が訊く『ポケットモンスター ハートゴールド・ソウルシルバー』」第3回、2026年10月2日閲覧、https://www.nintendo.com/en-gb/Iwata-Asks/Iwata-Asks-Pokemon-HeartGold-Version-SoulSilver-Version/Iwata-Asks-Pokemon-HeartGold-Version-SoulSilver-Version/3-Just-Being-President-Was-A-Waste-/3-Just-Being-President-Was-A-Waste–225951.html。アーティストの人数についての杉森の発言(「10人弱くらい」)は「社長が訊く『ポケットモンスター ブラック・ホワイト』」、書き起こしはhttps://pocketmonsters.net/content/Iwata_Asks_BW。 ↩

  55. Soleil(HylianAngel)、Sabotage StudioのSaboMathが立てたSteam Communityスレッド「Sea of Stars: Frequently Asked Questions」へのコメント、2026年10月3日閲覧、https://steamcommunity.com/app/1244090/discussions/0/5913784177847747164/。640×360という数値と「Pixel Perfect」の説明はこのコメント投稿者の言葉であり、スタジオの公式見解ではない。 ↩

  56. Billy Basso、内部解像度と走査線についての返信、Animal Well Steam Community、2026年10月2日閲覧、https://steamcommunity.com/app/813230/discussions/0/4361250264577867864/。 ↩

  57. 「Resolution Doesn’t Matter With 2D Games, Says Hyper Light Drifter Developer」Nintendo Life、2014年11月、2026年10月2日閲覧、https://www.nintendolife.com/news/2014/11/resolution_doesnt_matter_with_2d_games_says_hyper_light_drifter_developer。480×270という数値はPrestonの発言で、「Road to the IGF: Heart Machine’s Hyper Light Drifter」Game Developer、https://www.gamedeveloper.com/design/road-to-the-igf-heart-machine-s-i-hyper-light-drifter-i-による。 ↩

  58. Yacht Club Games「Breaking the NES for Shovel Knight」2026年10月2日閲覧、https://www.yachtclubgames.com/blog/breaking-the-nes/。 ↩↩

  59. Godot Engineドキュメント「Multiple resolutions」2026年10月2日閲覧、https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html。 ↩

  60. Pedro Medeiros「Scaling」Saint11、2026年10月2日閲覧、https://saint11.art/blog/scaling/。 ↩

  61. 「Video: Octopath Traveler Earns Digital Foundry’s Respect for Blending Old With New」Nintendo Life、2018年7月、2026年10月2日閲覧、https://www.nintendolife.com/news/2018/07/video_octopath_traveler_earns_digital_foundryrs_respect_for_blending_old_with_new。 ↩

  62. 「Why Animal Well’s Home-Brewed Engine Was Key to Its Success」Game Developer、2026年10月2日閲覧、https://www.gamedeveloper.com/design/why-animal-well-s-home-brewed-engine-was-key-to-its-success。 ↩

  63. Thomas Vasseur「Art Design Deep Dive: Using a 3D Pipeline for 2D Animation in Dead Cells」Game Developer、2026年10月2日閲覧、https://www.gamedeveloper.com/production/art-design-deep-dive-using-a-3d-pipeline-for-2d-animation-in-i-dead-cells-i-。 ↩↩

  64. Wikipedia「Sea of Stars (video game)」開発の節、The Escapist『The Making of Sea of Stars』15:00を引用、2026年10月2日閲覧、https://en.wikipedia.org/wiki/Sea_of_Stars、https://www.youtube.com/watch?v=NvsDBAcKFDw。 ↩

  65. アクワイア「Octopath Traveler」プレゼンテーション、UNREAL FEST EAST 2018(Epic Games Japanのスライド)、2026年10月2日閲覧、https://www.docswell.com/s/EpicGamesJapan/KXPWY5-UE4_UFE2018_ACQUIRE_OCTOPATHTRAVELER。Wikipedia「HD-2D」https://en.wikipedia.org/wiki/HD-2D。 ↩↩

  66. 「Give Your Sprites Depth with Sub-Pixel Animation」2D Will Never Die、2026年10月2日閲覧、https://2dwillneverdie.com/tutorial/give-your-sprites-depth-with-sub-pixel-animation/。 ↩↩

  67. 「Creature Feature: The Surreal Pixel Art and Animation of Animal Well」Game Developer、2026年10月2日閲覧、https://www.gamedeveloper.com/art/creature-feature-the-surreal-pixel-art-and-animation-of-animal-well。 ↩

  68. Raymond Schlitter「Pixelblog 1: Color Palettes」Slynyrd、2018年1月、2026年10月2日閲覧、https://www.slynyrd.com/blog/2018/1/10/pixelblog-1-color-palettes。 ↩↩

  69. 「Cassette Beasts Interview」Pocket Tactics、2026年10月2日閲覧、https://www.pockettactics.com/cassette-beasts/interview。 ↩

  70. LospecのパレットページResurrect 64、Apollo、Endesga 32、2026年10月2日閲覧、https://lospec.com/palette-list/resurrect-64、https://lospec.com/palette-list/apollo、https://lospec.com/palette-list/endesga-32。 ↩

  71. 「Getting Started with Pixel Art: An Interview with Eric Barone」Mental Nerd、2026年10月2日閲覧、https://mentalnerd.com/blog/getting-started-pixel-art-interview/。Wikipedia「Stardew Valley」https://en.wikipedia.org/wiki/Stardew_Valley。 ↩↩

  72. 「Sea of Stars: Sabotage Director Thierry Boulanger Interview」MobileSyrup、2023年9月、2026年10月2日閲覧、https://mobilesyrup.com/2023/09/07/sea-of-stars-sabotage-director-thierry-boulanger-interview/。 ↩↩

  73. 「The Scratch Coding and Discipline at the Heart of Animal Well」Game Developer、2026年10月2日閲覧、https://www.gamedeveloper.com/programming/the-scratch-coding-and-discipline-at-the-heart-of-animal-well。Wikipedia「Animal Well」https://en.wikipedia.org/wiki/Animal_Well。 ↩

  74. 「Road to the IGF: Pixpil’s Eastward」Game Developer、2026年10月2日閲覧、https://www.gamedeveloper.com/business/road-to-the-igf-pixpil-s-i-eastward-i-。Wikipedia「Eastward (video game)」https://en.wikipedia.org/wiki/Eastward_(video_game)。 ↩

  75. 任天堂「Nintendo Switch 2: More details about features」2026年10月2日閲覧、https://www.nintendo.com/en-gb/Hardware/Nintendo-Switch-2/Nintendo-Switch-2-More-details-about-features-2790188.html。 ↩

  76. Liberated Pixel Cup「LPC Style Guide」2026年10月2日閲覧、https://lpc.opengameart.org/static/LPC-Style-Guide/build/styleguide.html。 ↩↩↩

  77. Raymond Schlitter「Pixelblog 3: Graphical Projections, Part 1」Slynyrd、2018年3月、2026年10月2日閲覧、https://www.slynyrd.com/blog/2018/3/14/pixelblog-3-graphical-projections-1。 ↩

  78. Raymond Schlitter「Pixelblog 20: Top Down Tiles」Slynyrd、2019年8月、2026年10月2日閲覧、https://www.slynyrd.com/blog/2019/8/27/pixelblog-20-top-down-tiles。 ↩

  79. Stardew Valley Wiki「Modding:Maps」2026年10月2日閲覧、https://stardewvalleywiki.com/Modding:Maps。 ↩↩

  80. cr31(Boris the Braveによるミラー)「The Blob Tileset」2026年10月2日閲覧、http://www.boristhebrave.com/permanent/24/06/cr31/stagecast/wang/blob.html。 ↩↩↩

  81. Boris the Brave「Classification of Tilesets」2021年11月、2026年10月2日閲覧、https://www.boristhebrave.com/2021/11/14/classification-of-tilesets/。 ↩↩

  82. Tiledドキュメント「Using Terrains」2026年10月2日閲覧、https://doc.mapeditor.org/en/stable/manual/terrain/。 ↩↩

  83. LDtkドキュメント「Auto-layers」2026年10月2日閲覧、https://ldtk.io/docs/general/auto-layers/。 ↩

  84. Raymond Schlitter「Pixelblog 44: Top Down Trees」「Pixelblog 21: Top Down Objects」「Pixelblog 43: Top Down Tiles, Part 2」Slynyrd、2026年10月2日閲覧、https://www.slynyrd.com/blog/2023/5/22/pixelblog-44-top-down-trees、https://www.slynyrd.com/blog/2019/9/18/pixelblog-21-top-down-objects、https://www.slynyrd.com/blog/2023/3/26/pixelblog-43-top-down-tiles-part-2。 ↩↩

  85. Raymond Schlitter「Pixelblog 7: Developing Style」Slynyrd、2018年7月、2026年10月2日閲覧、https://www.slynyrd.com/blog/2018/7/14/pixelblog-7-developing-style。 ↩

  86. Cure「The Pixel Art Tutorial」PixelJointフォーラム、2026年10月2日閲覧、https://pixeljoint.com/forum/forum_posts.asp?TID=11299。 ↩↩↩

  87. Pedro Medeiros「Anti-Alias and Banding」Saint11、2026年10月2日閲覧、https://saint11.art/pixel_art_articles/article5/。 ↩

  88. 「Dithering for Pixel Artists」Pixel Parmesan、2026年10月2日閲覧、https://pixelparmesan.com/blog/dithering-for-pixel-artists。 ↩

  89. Stardew Valley Wiki「Modding:Farmer sprite」2026年10月2日閲覧、https://stardewvalleywiki.com/Modding:Farmer_sprite。 ↩

  90. Stardew Valley Wiki「Modding:Hats」2026年10月2日閲覧、https://stardewvalleywiki.com/Modding:Hats。 ↩

  91. Raymond Schlitter「Pixelblog 22: Top Down Character Sprites」Slynyrd、2019年10月、2026年10月2日閲覧、https://www.slynyrd.com/blog/2019/10/21/pixelblog-22-top-down-character-sprites。 ↩

  92. Raymond Schlitter「Pixelblog 8: Intro to Animation」Slynyrd、2018年8月、2026年10月2日閲覧、https://www.slynyrd.com/blog/2018/8/19/pixelblog-8-intro-to-animation。 ↩

  93. Daniel Linssen「m5x7」itch.io、2026年10月2日閲覧、https://managore.itch.io/m5x7。 ↩

  94. pret、pokeemerald/graphics/text_window/(枠1.png、24×24ピクセル)、2026年10月2日閲覧、https://github.com/pret/pokeemerald/tree/master/graphics/text_window。 ↩

  95. Asepriteドキュメント「Slices」2026年10月2日閲覧、https://www.aseprite.org/docs/slices/。 ↩

  96. Jan Willem Nijman(Vlambeer)「The Art of Screenshake」INDIGO Classes 2013、2026年10月2日閲覧、https://www.youtube.com/watch?v=AJdEqssNZ-U。 ↩

  97. Martin JonassonおよびPetri Purho「Juice It or Lose It」GDC Europe 2012、2026年10月2日閲覧、https://www.youtube.com/watch?v=Fy0aCDmgnxg。 ↩

  98. Stardew Valley Wiki「Weather」および「Modding:Maps」内のTypeタイルプロパティ、2026年10月2日閲覧、https://stardewvalleywiki.com/Weather、https://stardewvalleywiki.com/Modding:Maps。 ↩

  99. Asepriteドキュメント「Command Line Interface」2026年10月2日閲覧、https://www.aseprite.org/docs/cli/。 ↩

  100. CodeAndWeb「TexturePacker: Texture Settings」2026年10月2日閲覧、https://www.codeandweb.com/texturepacker/documentation/texture-settings。 ↩

  101. Apple Developer Documentation「SKTexture.filteringMode」および「SKTextureFilteringMode」2026年10月2日閲覧、https://developer.apple.com/documentation/spritekit/sktexture/filteringmode、https://developer.apple.com/documentation/spritekit/sktexturefilteringmode。 ↩↩

  102. Apple Developer Documentation「SKTileMapNode」2026年10月2日閲覧、https://developer.apple.com/documentation/spritekit/sktilemapnode。Apple「What’s New in SpriteKit」WWDC16セッション610(書き起こしミラー)、https://nonstrict.eu/wwdcindex/wwdc2016/610/。 ↩↩

  103. Apple「Bring your SceneKit project to RealityKit」WWDC25セッション288、2026年10月2日閲覧、https://developer.apple.com/videos/play/wwdc2025/288/。 ↩↩

  104. Apple Developer Documentation「OrthographicCameraComponent」および「OrthographicCameraComponent.scale」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/orthographiccameracomponent、https://developer.apple.com/documentation/realitykit/orthographiccameracomponent/scale。画面高さの半分という関係は、2026年10月にKiradexのレンダラー上で著者が計測したもの。 ↩↩↩

  105. Apple Developer Forums、スレッド768467(平行投影カメラの追加時にRealityViewがクラッシュする報告。macOS 15.0で報告され、Appleのエンジニアは.2系のリリースで修正されるはずだと回答。2025年2月のフォローアップでは射影が誤った値を返すと報告されている)、2026年10月2日閲覧、https://developer.apple.com/forums/thread/768467。 ↩↩

  106. Apple Developer Documentation「UnlitMaterial」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/unlitmaterial。 ↩

  107. Apple Developer Documentation「RealityView」および「SceneEvents.Update」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/realityview、https://developer.apple.com/documentation/realitykit/sceneevents/update。 ↩

  108. Apple Developer Documentation「PostProcessEffect」および「PostProcessEffectContext」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/postprocesseffect、https://developer.apple.com/documentation/realitykit/postprocesseffectcontext。 ↩

  109. Apple Developer Documentation「MeshInstancesComponent」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/meshinstancescomponent。Apple「What’s new in RealityKit」WWDC25セッション287、https://developer.apple.com/videos/play/wwdc2025/287/。Apple Developer Forums、スレッド694561(iOS 26以前にインスタンシングは存在しない)、https://developer.apple.com/forums/thread/694561。 ↩↩

  110. Apple Developer Documentation「RealityRenderer」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/realityrenderer。 ↩↩

  111. Apple Developer Documentation「MTLSamplerMinMagFilter」およびサンプル「Customizing render pass setup」2026年10月2日閲覧、https://developer.apple.com/documentation/metal/mtlsamplerminmagfilter、https://developer.apple.com/documentation/metal/customizing-render-pass-setup。 ↩

  112. Apple, Technical Q&A QA1909「Supporting native screen scale in your graphics application」およびMetal Best Practices Guide「Native Screen Scale」2026年10月2日閲覧、https://developer.apple.com/library/archive/qa/qa1909/_index.html、https://developer.apple.com/library/archive/documentation/3DDrawing/Conceptual/MTLBestPracticesGuide/NativeScreenScale.html。 ↩↩↩↩

  113. Apple Developer Documentation「Optimizing iPhone and iPad apps to support ProMotion displays」2026年10月2日閲覧、https://developer.apple.com/documentation/quartzcore/optimizing-iphone-and-ipad-apps-to-support-promotion-displays。 ↩↩

  114. Apple Developer Documentation「Improving the Performance of a RealityKit App」2026年10月2日閲覧、https://developer.apple.com/documentation/realitykit/improving-the-performance-of-a-realitykit-app。 ↩

  115. Apple Human Interface Guidelines「Designing for games」2025年6月9日更新、2026年10月2日閲覧、https://developer.apple.com/design/human-interface-guidelines/designing-for-games。 ↩↩

  116. Apple Developer Documentation「Image.interpolation(:)」2026年10月2日閲覧、https://developer.apple.com/documentation/swiftui/image/interpolation(:)。 ↩

  117. Apple Developer Documentation「LSSupportsGameMode」2026年10月2日閲覧、https://developer.apple.com/documentation/bundleresources/information-property-list/lssupportsgamemode。 ↩

  118. Xcode 27のシミュレータデバイスプロファイル(/Library/Developer/CoreSimulator/Profiles/DeviceTypes/以下のcapabilities.plist)、著者が2026年10月2日に読み取り。iPhone Duoのディスプレイは1398 × 2034および2007 × 2853でスケール3.0、iPhone 18 Pro Maxは1320 × 2868でスケール3.0、iPad Pro 13インチ(M5)は2064 × 2752でスケール2.0。 ↩↩

  119. Apple「iPad Pro: Tech Specs」2026年10月2日閲覧、https://www.apple.com/ipad-pro/specs/。 ↩

  120. Blake Crosley「iPhone Duo for Developers」blakecrosley.com、2026年9月、https://blakecrosley.com/blog/iphone-duo-for-developers。 ↩

  121. Stardew Valley Wiki「Stardew Valley Fair」(品評会の採点)、2026年10月2日閲覧、https://stardewvalleywiki.com/Stardew_Valley_Fair。 ↩

  122. Serebii「Pokémon Ruby & Sapphire: Secret Bases」2026年10月2日閲覧、https://www.serebii.net/rubysapphire/secretbase.shtml。 ↩

  123. Nookipedia「Happy Home Academy」2026年10月2日閲覧、https://nookipedia.com/wiki/Happy_Home_Academy。 ↩

  124. That Penguin Game「Your Igloo」および「Chat Modes」(Club Penguinヘルプのアーカイブ)、2026年10月2日閲覧、https://thatpenguingame.com/club-penguin-help/game-help/your-igloo/、https://thatpenguingame.com/club-penguin-help/safety/chat-modes/。 ↩↩↩

  125. Serebii「Pokémon Omega Ruby & Alpha Sapphire: Super-Secret Bases」2026年10月2日閲覧、https://www.serebii.net/omegarubyalphasapphire/supersecretbases.shtml。 ↩

  126. pret、pokeemerald/src/data/easy_chat/easy_chat_groups.hおよびグループの語彙リスト、2026年10月2日閲覧、https://github.com/pret/pokeemerald/blob/master/src/data/easy_chat/easy_chat_groups.h。流行語の解放ルール(記録交換で「流行の人」が現れるたびに1語)はpokeemerald/src/easy_chat.cにある、https://github.com/pret/pokeemerald/blob/master/src/easy_chat.c。 ↩

  127. Serebii「Pokémon GO: Friends」2026年10月2日閲覧、https://www.serebii.net/pokemongo/friends.shtml。 ↩

  128. Project Horseshoe「Cozy Games」(2017年)、Lost Gardenに再掲、2026年10月2日閲覧、http://lostgarden.com/2018/01/24/cozy-games/。 ↩

  129. 「Pokémon TCG Pocket: Binder and Card Showcase Guide」Game Rant、2026年10月2日閲覧、https://gamerant.com/pokemon-tcg-pocket-binder-card-showcase-album-guide/。Wikipedia「Pokémon Trading Card Game Pocket」https://en.wikipedia.org/wiki/Pok%C3%A9mon_Trading_Card_Game_Pocket。 ↩

  130. Daniel Cook「Game design patterns for building friendships」Lost Garden、2017年1月、2026年10月2日閲覧、https://lostgarden.com/2017/01/27/game-design-patterns-for-building-friendships/。および「Kind Games: Designing for Prosocial Multiplayer」2023年7月、https://lostgarden.com/2023/07/08/kind-games-designing-for-prosocial-multiplayer/。 ↩

  131. U.S. Federal Trade Commission「Fortnite Video Game Maker Epic Games to Pay More Than Half a Billion Dollars over FTC Allegations」2022年12月、2026年10月2日閲覧、https://www.ftc.gov/news-events/news/press-releases/2022/12/fortnite-video-game-maker-epic-games-pay-more-half-billion-dollars-over-ftc-allegations。 ↩

  132. Raymond Schlitter「Pixelblog 35: Top Down Interiors」Slynyrd、2021年11月、2026年10月3日閲覧、https://www.slynyrd.com/blog/2021/11/30/pixelblog-35-top-down-interiors。 ↩

  133. Wikipedia「Lane Merrifield」(Club Penguinのフィルターが「『mom』のような一見無害な語まで弾き、電話番号とメールアドレスの双方をブロックしていた」こと)、2026年10月3日閲覧、https://en.wikipedia.org/wiki/Lane_Merrifield。 ↩

関連記事

iPhone Duoへのアプリ対応:実例でたどる準備と提出

iPhone Duo向けにアプリを準備して提出する方法。レイアウトを切り替えるSDKスタンプ、実アプリで全ポーズを歩いた結果、スクリーンショット、App Storeのルールまで。

46 分で読める

Xcode 27.1 beta:iPhone Duoシミュレータでアプリを動かす

Xcode 27.1 betaは最初のiOS 27.1 SDKとiPhone Duoシミュレータを載せてきました。SDKに何が加わり、デバイスプロファイルが何を語り、プローブがポーズごとに何を報告したのか。

27 分で読める

iPhone Duo のデザイン:動くもの、分かれるもの、留まるもの

Apple の iPhone Duo デザインガイドと3本の Tech Talk をルールとして読み解く。ポーズごとではなく2つのサイズクラス、折り目での変位、arrangement、そしてサイドバー。

21 分で読める