ミニゲーム 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 個の「ボタン」が混在。

Tencent WeChat ゲームチームの統計では、適切な命名でファイル検索時間を 80% 節約できるとされています。小さな数字ではありません。1 日 10 回、1 回 3 分探すと 30 分。規則化後は 6 分。1 か月で 12 時間の節約——新機能のプロトタイプが 1 本作れる時間です。

自動化スクリプトではさらに厄介です。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 倍解像度。各部分に明確な意味があります。

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

Tencent Cloud 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 つ考えてください：この素材は 1 モジュール専用か、プロジェクト全体で使うか？

共通リソース：モジュールプレフィックスなし、カテゴリから始める。ホーム背景は bg_home.png（home_bg.png ではない）。背景は他モジュールでも再利用されるため、カテゴリ分類の方が探しやすい。

モジュール固有リソース：モジュールプレフィックス付きで一括処理しやすくする。メールモジュールの検索アイコンは mail_icon_search.png。メール UI を差し替えるとき、mail_ プレフィックスで関連素材を一括検索できる。

サイズ差のある命名

同じボタンに大小 2 バージョンがある場合、機能名の後にサイズを付けます：

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 素材の中で数が最多、状態も最も複雑です。通常 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 ボタンより複雑です。主人公に 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）。

キャラクター命名公式

完全なスプライト命名公式：

character_action_direction_frame.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 は短いが新メンバーには不明。全称は汎用的、略語は簡潔。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 リソースディレクトリ構造 — 分類保存で効率 UP

命名規則は「ファイル名」の問題。ディレクトリ構造は「置き場所」の問題。両方整えて初めて素材探しが本当に速くなります。

Tencent Cloud Cocos Creator 基礎チュートリアルの推奨構造：

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

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

すべての素材を textures/ui/ に詰め込んだことがあります。300 ファイルが 1 フォルダに。開くのに時間、スクロールに時間、探すのに時間。

「共通リソース」と「モジュール固有リソース」を分ける方が良い：

共通リソースは textures/ 直下の 1 階層サブディレクトリ。例：textures/icons/ に全モジュール共通アイコン。

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

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

モジュール変更時に assets 全体を探す必要がない。バトル UI は modules/battle、ログイン UI は modules/login だけ見ればよい。

過度な細分化は避ける

細かすぎる分類も逆効果。textures/ui/buttons/blue/rounded/ の 5 階層、各フォルダに 2〜3 ファイルだけ。ディレクトリツリーを辿る方がファイル名を見るより遅い。

1 階層分類で十分——特定カテゴリが 50 スプライト超の場合のみ例外。textures/ui/ にボタン・プログレスバー・区切り線、textures/icons/ にアイコン、textures/backgrounds/ に背景。3 階層以内で一目瞭然。

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

プレハブ（prefabs）とスクリプト（scripts）は対応素材と同階層に。ログインボタンプレハブは modules/login/prefabs/、素材は modules/login/textures/。2 ディレクトリが並び、参照パスが短く、変更時にディレクトリをまたがない。

Cocos Creator 公式ドキュメントも同じ原則を述べています：関連ファイルは近くに置き、クロスディレクトリ参照を減らす。パスが短いほどプロジェクトは明確、移行・リファクタも楽。

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

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

1. 簡潔に：十分な情報、過度な冗長さなし

ファイル名はキー情報を伝えつつ、長すぎない。

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

悪い例：button_confirm_normal_state_blue_rounded_large.png — 情報過多、読みにくく、タイプも大変。

私のやり方：3〜5 単語セグメントに収める。5 超なら二次情報（「rounded」など）を削除。詳細はコードコメントで補足。

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

命名順序は認知ロジックに合わせる：大カテゴリ → 小機能 → 詳細。

environment_forest_tree_01.png

環境素材 → 森シーン → 木 → 1 番目のバリエーション。

同カテゴリファイルが自動的にまとまる。environment_forest で検索すれば森素材がすべて出る。

3. 合理的ソート：アルファベット順検索を容易に

プレフィックス選択がソート効果に影響。最重要カテゴリを先頭に。

キャラ素材：hero_ 始まりは character_hero_ より良い。主人公素材が h エリアに集中し、c エリアを探す必要がない。

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

プロジェクトで 1 形式を選び、徹底。

私は snake_case（小文字＋アンダースコア）を好みます：

• ファイルシステム互換性（大文字小文字問題なし）
• 可読性（単語境界が明確）
• 正規表現マッチが簡単（_ で分割）

チームが camelCase なら camelCase で統一。混在はスクリプト処理の障害に。

5. 番号統一：01/02 または 001/002、1 桁禁止

第 4 章で詳述。1 桁番号はソート混乱の原因。ゼロパディング必須。

2 ルール：

• 99 フレーム以下 → 2 桁（00〜99）
• 99 超 → 3 桁（000〜999）

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

spin と spinning、attack と attacking のように 2 書き方がある動詞。

1 つを選び、徹底。

誤り：

cha_sonic_spin_01.png
cha_sonic_spinning_02.png

同じアクションなのに命名不一致。スクリプト検索で片方が漏れる。

正しい：

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 — キャラ + アクション + 方向 + フレーム。この公式をマスターすれば 90% の UI 素材命名をカバーできます。

残り 10% は細部ルール：2 桁番号でソート混乱防止、英語徹底でクロスプラットフォーム問題回避、略語統一でスクリプト失效防止。命名自体より、実務での効率を左右する部分です。

次の 3 つから始めましょう：

1. 既存プロジェクトを確認：アートフォルダを開き、命名不適切なファイルを本文の公式でリネーム
2. 略語語彙表を作成：チームで略語標準（bg/btn/icon/nav）を合意し、掲示
3. ディレクトリ構造を整理：共通リソースとモジュール固有を分離。1 フォルダに詰め込まない

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