ゲーム UI 素材の命名規則：透明画像、ボタン、アイコン、キャラクタースプライト

あなたのプロジェクトフォルダに、こんなファイルがありませんか？btn_ok.png、button_confirm.png、按钮_确定.png？3つの命名スタイル、3つの理解方法、そしてチームコラボレーションにおける3つの災難の始まりです。

私もこの落とし穴にハマりました。最初のミニゲームプロジェクトが終わった時、アートフォルダには200枚以上の素材がありました。半分は英語の略語、もう半分は中国語の直訳、さらに 新建文件夹 (2).png なんて名前のものもありました。ファイルを探すのは海底針を探すようなもので、UIを変更するたびに半日かけてどれが対応する状態か確認していました。

この記事は1つの問題を解決します：どうやって命名フォーミュラ1つでUIリソースを一目瞺然にするか。 プレフィックス、カテゴリ、機能、状態——4つの要素を組み合わせるだけで、十分です。

第1章：命名混乱の実コスト — なぜ規則が重要なのか

まず、実話から始めましょう。

昨年、友人2人とカジュアルゲームを作りました。役割分担は私がコード、王さんがアート、李さんがプランニング。プロジェクト開始から2ヶ月目、王さんがボタン素材を一括送ってきました——12個のファイルで、名前は全部 按钮1.png から 按钮12.png。「どれが確認ボタンで、どれがキャンセルボタン？」と聞くと、「画像を見ればわかるよ」との答え。

その時、画面上の12枚の画像を凝視しました。どれも同じようなサイズの角丸長方形で、色が少し違うだけ。対応関係を整理するのに15分かかりました。その後、プロジェクトがリリースされ、王さんがボタンのカラースキームを変更し、新しい12枚の画像を送ってきました。今度は 新按钮1.png から 新按钮12.png。古い画像は削除されず、新しい画像と混ざって、フォルダには24個の「ボタン」が転がっていました。

騰訊WeChatゲームチームの統計によると：適切な命名でファイル検索時間を80%節約できます。 これは小さな数字ではありません。毎日10回素材を探し、各回3分とすると、1日で30分。規格化後は6分に。1ヶ月で12時間節約でき、新機能のプロトタイプを書き上げるのに十分な時間です。

さらに大きな問題は自動化スクリプトにあります。私はボタン素材を一括置換する小さなツールを書きました。ロジックは簡単：btn_ で始まるPNGファイルをすべて探して、新しいバージョンに置換。結果、スクリプトは半日実行しても1つもファイルを見つけられませんでした——王さんの命名には btn_ がなく、全部中国語だったからです。スクリプトは使い物にならず、手動で2時間かけて変更しました。

コードで素材名を参照する時、問題はより明確になります。この2行を見てください：

// 規則的な命名
this.confirmButton.spriteFrame = assets.get('btn_ok_pressed');

// 規則なしの命名
this.confirmButton.spriteFrame = assets.get('button2');

1行目は一目で「確認ボタンの押下状態」とわかります。2行目は？button2 って何？アートフォルダを開いて、button2.png を探して、開いて見て、やっとわかります。UIを変更するたびにこの作業が必要で、コードの可読性は崩壊します。

第2章：汎用命名フォーミュラ — 1つのフォーミュラですべてのシーンを解決

「規則」という言葉に怖がらないでください。コアフォーミュラは実はとてもシンプルです：

prefix_function_state.png

または、より完全に：

[email protected]

4つの要素、左から右へ段階的に構成。例：[email protected]。分解すると：メールモジュール、アイコンカテゴリ、検索機能、押下状態、2倍画像。各部分に明確な意味があります。

よく使うプレフィックス早見表

騰訊クラウドCocos Creator基礎チュートリアルと智聯招聘UIデザイン規範の総合的な提案に基づき、最も一般的な15個の略語をまとめました：

略語	フルスペル	適用シーン
bg	background	画面背景、ポップアップ背景
nav	navbar	ナビゲーションバー要素
tab	tabbar	タブバーアイコン
btn	button	各種ボタン
icon	icon	機能アイコン、状態アイコン
img	image	汎用画像素材
txt	text	文字画像（タイトルなど）
pop	popup	ポップアップ関連
bar	bar	プログレスバー、ステータスバー
mask	mask	マスクレイヤー
sep	separator	セパレーター
del	delete	削除ボタン、アイコン
add	add	追加ボタン、アイコン
msg	message	通知情報、吹き出し
logo	logo	ロゴ画像

これらの略語には共通点があります：短い、覚えやすい、一目で何かわかる。button ではなく btn を、background ではなく bg を使いましょう。長ければ長いほどタイプミスが増え、文字数も増えます。

モジュール固有 vs 共通リソース

命名する時、まず考えるべきことがあります：この素材は1つのモジュールでしか使わないのか、それともプロジェクト全体で使えるのか？

共通リソース：モジュールプレフィックスを付けず、カテゴリで開始。例えばホーム画面の背景画像は、home_bg.png ではなく bg_home.png と命名。背景は他のモジュールでも再利用される可能性があり、カテゴリ別に分類すると見つけやすいからです。

モジュール固有リソース：モジュールプレフィックスを追加し、一括処理を容易に。例えばメールモジュールの検索アイコンは mail_icon_search.png と命名。メールUIを一新する時、mail_ プレフィックスを検索するだけで、関連するすべての素材を一緒に置換できます。

サイズ違いの命名

同じボタンに大きいバージョンと小さいバージョンがある場合があります。私のやり方は機能の後にサイズ記述を追加：

btn_ok_big_n.png      # 大きいサイズの確認ボタン（通常状態）
btn_ok_small_n.png    # 小さいサイズの確認ボタン（通常状態）

または具体的なサイズ数字を使用：

btn_ok_128_n.png      # 128px幅の確認ボタン
btn_ok_64_n.png       # 64px幅の確認ボタン

どちらでも構いません。重要なのはプロジェクト全体で統一すること。時には big/small、時には数字、また時には l/s と混ぜないでください。混乱の根源は命名ルールそのものではなく、ルールが統一されていないことにあります。

第3章：ボタンとアイコンの命名 — 状態を明確に一目瞭然

ボタンはUI素材の中で最も数が多く、状態が最も複雑なタイプです。1つのボタンには通常4つの状態があります：通常、押下、選択、無効。Douban UI命名規範の推奨は英語の単語または略語を統一して使用すること：

状態	フルスペル	略語	例
通常	normal	n / def	btn_ok_n.png
ホバー	hover	h	btn_ok_h.png
押下	pressed	p / pre	btn_ok_p.png
選択	selected	s / sel	btn_ok_s.png
無効	disabled	d / dis	btn_ok_d.png

私は1文字の略語を使います。理由は簡単：短いから。btn_ok_n.png は btn_ok_normal.png より5文字少なく、タイプが速く、見た目もスッキリしています。もちろん、チームがフルスペルを好むなら、統一してフルスペルを使いましょう。あるボタンは btn_ok_normal、別のボタンは btn_ok_n という混用は避けてください。検索時に面倒になります。

ボタン命名の実践

プロジェクトに「確認」ボタンが必要で、青い角丸スタイル、4つの状態すべて揃っているとします。命名案：

btn_ok_n.png          # 通常状態
btn_ok_p.png          # 押下状態
btn_ok_s.png          # 選択状態
btn_ok_d.png          # 無効状態

さらに赤と緑のバージョンもある場合：

btn_blue_ok_n.png     # 青い確認ボタン（通常）
btn_red_ok_n.png      # 赤い確認ボタン（通常）
btn_green_ok_n.png    # 緑の確認ボタン（通常）

順序は：カテゴリ（btn）+ 色（blue）+ 機能（ok）+ 状態（n）。この順序の利点は、ファイルをアルファベット順に並べた時、同じ色のボタンが集まり、一括置換しやすいことです。

アイコン命名：機能優先

アイコンとボタンの違いは状態の数です。ほとんどのアイコンには2つの状態しかありません：通常と無効。命名パターン：

icon_search_n.png     # 検索アイコン（通常）
icon_search_d.png     # 検索アイコン（無効）

アイコンの命名で重要なのは、機能記述を正確にすること。icon1.png ではなく、icon_search.png や icon_delete.png と命名。ファイル名を見るだけで用途がわかり、画像を開いて確認する必要がありません。

よくある間違いの実例

こんな命名を見たことがあります：button_确认_正常.png。英語のプレフィックス、中国語の機能、中国語の状態が混在。一見直感的に見えますが、問題があります：

1. 並び順の混乱：中国語のファイルシステムでの並び順は不安定で、确认 が 取消 の前後に来る可能性があります
2. スクリプト互換性が低い：一括処理スクリプトは通常正規表現でマッチングし、中国語文字はマッチングロジックを複雑にします
3. チームコラボレーション困難：プロジェクトが後に国際化をサポートする場合、すべての中国語命名を変更する必要があります

最も安全な方法は、完全に英語、小文字、アンダースコア区切りを使用すること。btn_ok_n.png、簡潔で、並び替え可能で、正規表現可能で、国際化可能。

第4章：キャラクター素材の命名 — アクションフレームシーケンスを整理

キャラクター素材はUIボタンよりずっと複雑です。主人公1人で7〜8種類のアクション（待機、歩行、走行、攻撃、被弾、死亡、ジャンプ）があり、各アクションは複数の方向（上下左右または8方向）に分かれ、各方向に一連のアニメーションフレームがあります。

私が最も苦労したのはフレーム番号です。初めてキャラクターアニメーションを作った時、1桁の番号を使いました：

hero_run_left_1.png
hero_run_left_2.png
hero_run_left_3.png
...
hero_run_left_10.png

一見正常に見えます。問題はファイルの並び順にあります。フォルダを開くと、hero_run_left_10.png が hero_run_left_1.png と hero_run_left_2.png の間にあります。ファイルシステムが文字順で並べるため、10 の最初の文字は 1 で、2 の前に来るからです。

完全な災難です。

それ以来、私は2桁の番号を強制しています：

hero_run_left_00.png
hero_run_left_01.png
hero_run_left_02.png
...
hero_run_left_09.png
hero_run_left_10.png

00 から 09 はすべて 10 より小さく、並び順はついに正常になりました。アニメーションフレーム数が100を超える場合は、3桁を使用します（000 から 999）。

キャラクター命名フォーミュラ

完全なキャラクタースプライト画像の命名フォーミュラ：

characterName_action_direction_frameNumber.png

分解して例示：

• hero_idle_down_00.png — 主人公_待機_下向き_0フレーム目
• player_run_left_01.png — プレイヤー_走行_左向き_1フレーム目
• enemy_attack_right_02.png — 敵_攻撃_右向き_2フレーム目

アクション用語早見表

アクション	英語	略語（オプション）
待機	idle	—
歩行	walk	—
走行	run	—
攻撃	attack	atk
被弾	hurt	—
死亡	death	die
ジャンプ	jump	—
詠唱	cast	—

略語を使うかどうかは好み次第です。atk は attack より短いですが、新しいメンバーはわからないかもしれません。フルスペルの方が一般的で、略語の方が簡潔です。アニメーションフレーム数が20以下ならフルスペル、20を超えるなら略語を検討することをお勧めします——ファイル名が長すぎるとパス表示が切り詰められます。

方向識別

最もシンプルなのは4方向：up、down、left、right。

8方向は番号を使用可能：0 から 7、0 が上向き、1 が右上、という具合に。ただし、番号方式の問題は覚えられないことで、毎回表を確認する必要があります。私は方向名を直接使う方が好きです：

hero_attack_up.png
hero_attack_upright.png
hero_attack_right.png
hero_attack_downright.png
hero_attack_down.png
hero_attack_downleft.png
hero_attack_left.png
hero_attack_upleft.png

8方向の名前は少し長いですが、読んで推測する必要がありません。プロジェクトの方向がシンプル（4方向のみ、または左右のみ）なら、方向名を使うのが最も安全です。方向が複雑（8方向以上）なら、番号の方がコンパクトかもしれません。

第5章：Cocos Creator リソースディレクトリ構造 — 分類保存で効率向上

命名規則が解決するのは「ファイルを何と呼ぶか」の問題。ディレクトリ構造が解決するのは「ファイルをどこに置くか」の問題。両方しっかりやってこそ、素材探しが本当に速くなります。

騰訊クラウドCocos Creator基礎チュートリアルが推奨する構造：

assets/
├── textures/           # テクスチャ素材
│   ├── ui/             # UI要素（ボタン、プログレスバー）
│   ├── icons/          # 機能アイコン
│   ├── backgrounds/    # 背景画像
│   └── characters/     # キャラクタースプライト
├── audio/              # オーディオファイル
│   ├── effects/        # 効果音
│   └── music/          # BGM
├── animations/         # アニメーションクリップ
├── prefabs/            # プレハブ
└── scripts/            # TypeScript スクリプト

共通 vs モジュール固有：分けて保存

私がハマった落とし穴は、すべての素材を textures/ui/ に詰め込んで、300個のファイルが1つのフォルダに集まることでした。開くのに時間がかかり、スクロールに時間がかかり、ファイルを探すのにも時間がかかります。

より良い方法は「共通リソース」と「モジュール固有リソース」を区別すること：

共通リソースは textures/ の下のトップレベルサブディレクトリに配置。例えば textures/icons/ にすべてのモジュールで使えるアイコンを保存。

モジュール固有リソースはモジュール専用ディレクトリに配置：

assets/
├── modules/
│   ├── login/          # ログインモジュール
│   │   ├── textures/   # ログイン画面専用素材
│   │   ├── prefabs/    # ログイン画面プレハブ
│   │   └── scripts/    # ログインロジックスクリプト
│   ├── battle/         # バトルモジュール
│   │   ├── textures/   # バトル画面素材
│   │   ├── prefabs/    # バトルプレハブ
│   │   └── scripts/    # バトルスクリプト

こうすることで、モジュールを変更する時に assets ディレクトリ全体を探す必要がありません。バトル画面を変更するなら modules/battle だけを見ればいいし、ログイン画面を変更するなら modules/login だけを見ればいいです。

過度な細分化を避ける

細かすぎる分類は逆に面倒を招くことがあります。textures/ui/buttons/blue/rounded/ と5階層のディレクトリを作り、各ディレクトリに2〜3個しかファイルがない人を見たことがあります。素材を探す時にディレクトリツリーを一层一层クリックして進む必要があり、ファイル名を直接見るより遅いです。

私の推奨：トップレベルの分類で十分、あるカテゴリの素材が本当に大量（例えばキャラクター素材が50スプライトを超える）でない限り。textures/ui/ にボタン、プログレスバー、セパレーターを配置し、textures/icons/ にアイコンを、textures/backgrounds/ に背景を配置。3階層以内で、一目瞭然。

プレハブとスクリプトは近くに配置

プレハブ（prefabs）とスクリプト（scripts）は対応する素材と同じ階層に置くのがベスト。例えばログイン画面のボタンプレハブは modules/login/prefabs/ に、対応する素材は modules/login/textures/ に。2つのディレクトリが並列で、参照パスが短く、変更時にディレクトリをまたぐ必要がありません。

Cocos Creatorの公式ドキュメントもこの原則に言及しています：関連ファイルは近くに保存し、クロスディレクトリ参照を減らす。パスが短いほどプロジェクトが明確で、移行とリファクタリングも容易です。

第6章：7つの命名黄金ルール — 騰訊ゲームチームの経験

騰訊WeChatゲームチームがまとめた命名黄金ルールを、私の実践経験と合わせて解説します。

1. 簡潔明瞭：十分な詳細を含み、過度に煩雑にしない

ファイル名は重要な情報を伝える必要がありますが、長すぎてはいけません。

良い例：btn_ok_n.png — 一目でボタン、確認機能、通常状態とわかる。

悪い例：button_confirm_normal_state_blue_rounded_large.png — 情報が密集しすぎて、読むのが大変で、タイプするのも大変。

私のやり方：ファイル名を3〜5個の単語断片に制御。5個を超えたら副次的な情報を削除することを検討（例えば「rounded」のような詳細はコードのコメントに補足）。

2. 階層的ネスト：概括から具体へ段階的に命名

命名順序は認知ロジックに従う：大きなカテゴリから、小さな機能へ、最後に詳細。

environment_forest_tree_01.png

解読：環境素材 → 森林シーン → 木木 → 最初のバリエーション。

この順序の利点は、同じカテゴリのファイルが自動的に集まること。environment_forest を検索すれば、すべての森林素材が表示されます。

3. 合理的な並び順：アルファベット順で見つけやすく

プレフィックスの選択は並び順効果に影響します。最も重要なカテゴリを一番前に置く。

例えばキャラクター素材：hero_ で始める方が character_hero_ で始めるより良いです。なぜなら、すべての主人公素材が h エリアに集中し、c エリアで探す必要がないからです。

4. 形式の一貫性：snake_case または camelCase を統一

プロジェクトで1つの形式を選び、最後まで統一します。

私は snake_case（小文字 + アンダースコア区切り）を使います。理由：

• ファイルシステム互換性が高い（大文字小文字の問題が発生しない）
• 可読性が高い（単語の境界が明確）
• 正規表現マッチングが簡単（_ で直接区切る）

チームが camelCase（キャメルケース）を好むなら、統一してキャメルケースを使いましょう。混用は避けてください。混用するとスクリプト処理で問題が発生します。

5. 統一番号付け：01/02 または 001/002、1桁を避ける

この点は第4章で詳しく説明しました。1桁の番号は並び順の混乱を招き、ゼロ埋めが必要です。

2つのルール：

• フレーム数が99以下なら、2桁を使用（00 から 99）
• フレーム数が99を超えるなら、3桁を使用（000 から 999）

6. 文法の一貫性：動詞形を統一

あるアクションには2つの書き方があります：spin と spinning、attack と attacking。

1つを選び、最後まで統一します。

間違い例：

cha_sonic_spin_01.png
cha_sonic_spinning_02.png

これら2つのファイルは同じアクションですが、命名が一貫していません。スクリプト検索時に片方が漏れます。

正しい例：

cha_sonic_spin_01.png
cha_sonic_spin_02.png

7. 語形の一貫性：スペル基準を統一

イギリス式スペルとアメリカ式スペルは時に異なります：ambience（イギリス式）vs ambiance（アメリカ式）、colour（イギリス式）vs color（アメリカ式）。

1つの基準を選び（通常アメリカ式スペルを推奨、より一般的）、プロジェクト全体で統一。ある時は bg_ambience.png、別の時は bg_ambiance.png と混用しないでください。スクリプト処理で問題が発生します。

第7章：透明画像と特殊素材の命名テクニック

一部のUI素材は比較的特殊で、命名には追加の考慮が必要です。

透明PNGの命名

透明背景のPNG素材はゲームUIでよくあります：ボタン、アイコン、オーバーレイ効果。命名時に _trans または _overlay サフィックスで識別：

btn_trans_round.png        # 透明角丸ボタン（枠なし）
icon_overlay_star.png      # スターオーバーレイアイコン（バッジ用）

透明素材の特徴は、ファイル名を見ただけでは透明度が判断できないため、サフィックスで注意を促します。素材使用時にこのファイルの背景が透明だと一目でわかり、開いて確認する必要がありません。

マスクレイヤーの命名

マスク（mask）は画像の切り抜き、角丸効果の実装に使用。命名フォーマット：

mask_rounded.png           # 角丸マスク
mask_circle.png            # 円形マスク
mask_gradient.png          # グラデーションマスク

マスクファイルは通常数が少なく、textures/ui/masks/ ディレクトリに置くか、直接 textures/ui/ に置くかは自由です。

多言語リソースの命名

国際化プロジェクトには複数の言語のテキスト画像が必要。命名フォーマット：

title_zh.png               # 中国語タイトル
title_en.png               # 英語タイトル
title_ja.png               # 日本語タイトル

またはISO言語コードを使用：

btn_start_zh-CN.png        # 簡体字中国語
btn_start_zh-TW.png        # 繁体字中国語
btn_start_en-US.png        # アメリカ英語
btn_start_ja-JP.png        # 日本語

完全なISOコードの方が正確ですが、ファイル名が長くなります。プロジェクトの言語版が5つ以下なら、略語（zh/en/ja）で十分です。

高解像度対応の命名

モバイルゲームは異なる画面密度に対応が必要：通常画面、高解像度画面、超高解像度画面。Cocos Creatorは @1x、@2x、@3x サフィックスを推奨：

[email protected]            # 通常密度（1倍）
[email protected]            # 高密度（2倍）
[email protected]            # 超高密度（3倍）

このサフィックスセットはiOS/Androidの基準と一致し、素材ツール（TexturePackerなど）も自動認識できます。

注意：倍率サフィックスは状態の後に置き、ファイル名の最後には置かない。[email protected] は btn_ok@2x_n.png より明確——まず何の素材か（確認ボタンの通常状態）を確認し、次に何の倍率かを確認。

特殊文字の処理

時々ファイル名に特殊文字が含まれることがあります。例えばスペース、括弧、中国語。私の推奨はすべて回避すること。

スペース：アンダースコアに置換。btn ok.png → btn_ok.png。

括弧：削除または数字に変更。btn_ok(1).png → btn_ok_01.png。

中国語：統一して英語に変換。按钮_确定.png → btn_ok.png。

特殊文字はクロスプラットフォームで問題を引き起こします。Windowsは中国語ファイル名を許可しますが、一部のLinuxサーバーはサポートしません。FTP転送時に中国語が文字化けする可能性があります。CI/CDビルド時にパス解決が失敗する可能性があります。最も安全な方法は完全に英語、小文字、特殊文字なし。

まとめ

命名規則のコアフォーミュラは、実は4つの要素の組み合わせ：プレフィックス、機能、状態、詳細。

btn_ok_n.png — カテゴリ（ボタン）+ 機能（確認）+ 状態（通常）。hero_run_left_00.png — キャラクター + アクション + 方向 + フレーム番号。このフォーミュラをマスターすれば、UI素材命名の90%は解決します。

残りの10%は、いくつかの詳細ルールです：2桁番号で並び順の混乱を回避、完全に英語でクロスプラットフォーム問題を回避、統一した略語でスクリプト無効を回避。これらの詳細は命名そのものには影響しませんが、実際の作業での効率を決定します。

この3つのことから始められます：

1. 既存プロジェクトを確認：アートフォルダを開き、命名が不適切なファイルがないか探し、この記事のフォーミュラで名前を変更
2. 略語一覧表を作成：チームと略語基準（bg/btn/icon/nav）を決め、書き留め、目立つ場所に貼る
3. ディレクトリ構造を整理：共通リソースとモジュール固有リソースを区別し、すべてのファイルを同じフォルダに詰め込まない

命名規則は一度きりの作業ではなく、継続的な習慣です。btn_ok_n.png の書き方に慣れ、2桁番号に慣れ、完全に英語に慣れると、プロジェクトのファイルはどんどん明確になり、素材探しがどんどん速くなります。