戦国時代で最も早い建造物は豊臣秀吉の墨俣の一夜城。その速さの秘訣は、「上流でしっかりと印の規則を決めて素材を作り、下流でそのに印に従って短時間で組み上げた」ことにあります。
どうも、クリーク･アンド･リバー社 COYOTE 3DCG STUDIO テクニカルチーム 戦国大好き人間の中林です。
今回は重要なテーマなので、少し強めの表現が入っています。
そして、僕の苦い思い出と愚痴も含まれています。
命名規則を甘く見るな！！
「名前なんて何でもいい」——それは個人作業で終わる人の発想です。
チームで仕事をする以上、名前は「個人のメモ」ではなく、チーム全員のインターフェースになります。
1. ファイル名は『情報』そのもの
ファイル名は「中身を開かなくても中身がわかるラベル」です。
いい加減な名前をつけるというのは「他人に内容を隠して、無駄な時間を使わせる」のと同じことです。
悪い例
suzuki.ma
sato.ma
tanaka.ma
takahashi.ma
日本で多い名字を並べただけですが、情報が少ないです。
良い例
CHP01_Tana.ma
CHN01_Sato.ma
MOB01_Suzu.ma
MOM01_Taka.ma
ゲームに詳しい人なら、CHがキャラクター、MOがモンスターだとすぐに分かります。
悪い例では内容を想像できず、チーム全体の足を引っ張ります。
「そんな極端な例ないでしょ？」と思うかもしれませんが、
残念ながら「Tree01.mb」というファイルを何度も見たことがあります。本当に！
2. 命名規則が守られないと、検索が地獄になる
後から「あのファイルどこ？」となったとき、
統一された名前がついていれば一瞬で見つかります。
バラバラの命名だと、探すだけで数十分が飛びます。
つまり、命名の手抜き1分が、将来の検索10分を奪うことになります。
全員がそれをやると、1日で数時間のロス。
「仕事が遅いチーム」の典型パターンです。
3. 命名規則は“チーム文化”を表す
ファイル名が乱れているチームは、例外なく管理も乱れています。
命名規則を守る意識がないと、バージョン管理・納品・レビューすべてにミスが出ます。
ファイル名の乱れはプロ意識の乱れです。
ファイル名を雑に扱う人は、仕事も雑になります。
逆に、名前を丁寧につける人は、仕事の全体像も整理できている。
ファイル名を整えるのは「細かいこと」ではありません。
プロとしての最低限の礼儀です。
命名はいつ決めるの？
ここはどなたも一度は気になるところですよね。
決めるのデータを作る前の最初期です。
よくある言い訳
「まだ内容が決まっていないので名前が決められない」
——それ、完全に逆です。
名前を決めるために内容を詰めるのです。
名前が決まらないほど内容が煮詰まっていないなら、作り始めてはいけません。
決まらなければ、徹底的に企画を練りましょう！！
仮でも良いから付ける
試作や検証中など初期段階では、仮の名前でも構いません。
仮の名前でも統一されていれば、後から一括リネームができます。
ただし、「仮だから適当でいいや」と思った瞬間に、
「test_test01_testtest.mb」みたいな地獄ファイルが生まれます！
個人のテストならまだしも、共有するデータなら体裁を整えましょう。
決めなかった悪い例
僕が巻き込まれた、命名規則を決めなかったことで起きた悲劇を紹介します。
「ミカン入り段ボールを壊したときのデータ」で、事前に命名規則が定められていなかったため、後工程で大混乱が起こりました。
ミカン入り段ボールを壊したときのデータ例です。
1箱（小）3箱（中）6箱（大）とタイプが分かれていました。
ちなみに茶色の段ボールだけだと見栄えが悪いから、ノリで白い段ボールを足していました。
そして、そのファイル名はこんな感じでした。
| 内容 | モデル | エフェクト | SE |
|---|---|---|---|
| ミカン箱（小） | MikanBox01 | Orange01 | fruits03 |
| MikanBoxBreke01 | Dball01 | Danball03 | |
| ミカン箱（中） | MikanBox02 | Orange02 | fruits02 |
| MikanBoxBreke02 | Dball02 | Danball02 | |
| ミカン箱（大） | MikanBox03 | Orange03 | fruits01 |
| MikanBoxBreke03 | Dball03 | Danball01 | |
| ミカン箱白（小） | MikanWhiteBox01 | Orange01 | fruits03 |
| MikanWhiteBoxBreke01 | DballW01 | Danball03 | |
| ミカン箱白（中） | MikanWhiteBox02 | Orange02 | fruits02 |
| MikanWhiteBoxBreke02 | DballW02 | Danball02 | |
| ミカン箱白（大） | MikanWhiteBox03 | Orange03 | fruits01 |
| MikanWhiteBoxBreke03 | DballW03 | Danball01 |
モデルは壊れる前と壊れた後の2つもモデルがありました。
エフェクトは段ボールの中身はりんごの場合もあるし、スイカの場合もあるので果汁と段ボールを別データで作成をしました。
SEは果物によって果汁の音は変化しないのでfruitsで統一、段ボールの音も茶色も白もないので統一されていました。
ブログのSEのリストの番号が間違っている？ 残念ながら世間的に間違っていても、この時の企画的には間違っていません。
大中小・白茶などの命名規則を決めずに始めた結果、 命名がバラバラで管理不能な状態になりました。
当時エフェクトだった僕がリーダーに聞いたら『前のゲームの命名規則が大中小だった』と話していました。
ちなみにSEの担当者に聞いたら『前のゲームの命名規則が小中大これだった』と異口同音で話していました。
プログラマが丸投げ、企画が逃亡し、その結果、誰がやっても間違えるような構造になっていて、案の定ミスが大量発生。
企画の手抜き設計が原因でこの案件は炎上しました。
「なんで簡単な作業を時間をかけて間違うんだ」と企画に言われるたび、ヘイトが貯まっていきました。
——今でも恨んでます。その時の企画が手抜きしたせいで地獄を見たんだぞ！！
でも、そもそも論として
命名は誰が決めるの
意見が分かれるところですが、僕の中では明確に決まっています。 キーワードは「前工程」と「後工程」です。
| 前工程 | ⇒ | ⇒ | ⇒ | ⇒ | 後工程 |
| モデリング | モーション | エフェクト | SE | 企画（組込） | プログラム |
基本的なゲームデータの作成と組み込みの流れです。
前工程は絶対に決めてはいけない。
前工程ほど人数が多く『船頭多くして船山に上る』状態になりがちです。
勝手にミカン、オレンジ、フルーツ……とバラバラな命名が生まれます。
これを避けるために、前工程では決めないのが鉄則です。
後工程が決める
命名規則は、後工程のプログラマや企画が決めます。
理想は、企画がプログラマの意見を聞いて整えること。
ゲームはプログラムで動く以上、制御しやすい名前が大原則です。
また、後工程の人は最後まで残る可能性が高いため、データ管理が一貫しやすいという点でも適任です。
後工程の決める命名規則の弱点
後工程が決めた命名には、人間が間違えやすいという弱点があります。
たとえば、スカートの揺れ物のジョイント名。
スカートの揺れ物の名前を幾つか用意しました。
| Aパターン | Bパターン | Cパターン |
| Right_Skirt01_S01 | R_Skrt00_00_ast | Skrt01_01_R |
| Right_Skirt01_S02 | R_Skrt00_01_phy | Skrt01_02_R |
| Right_Skirt01_S03 | R_Skrt00_02_phy | Skrt01_03_R |
| Right_Skirt01_S04_End | R_Skrt00_02_phy_End | Skrt01_End_R |
数値が0から始まったりやEndの時に数値が増えなかったり、連番処理のズレなどで簡単にミスが起こります。
では、人が付ける間違いパターン例をあげます。
| Aパターン | Bパターン | Cパターン |
| Right_Skirt01_S01 | R_Skrt00_01_ast | Skrt01_01_R |
| Right_Skirt01_S02 | R_Skrt00_01_phy | Skrt01_02_R |
| Right_Skirt01_S03 | R_Skrt00_02_phy | Skrt01_03_R |
| Right_Skirt01_S04 _Endの付け忘れ |
R_Skrt00_03_phy_End | Skrt01_04_R _Endにしてない |
プログラマーは揺れ物に限らず、ジョイントの先端のエンドジョイントを分かるようにしたい人が多いです。
しかし、手動でするとEndを付け忘れたり、番号を間違えたりします。
でも、それは命名規則が悪いのではなく、手動でやるのが悪いです。
こんな時こそ、ツールで自動化するのが我々、テクニカルアーティスト（以下、TA）の出番です。
命名規則こそテクニカルアーティストの出番
命名規則が複雑でも、命名規則さえ統一されていればツール化できます。
ツール化できれば、数クリック・数秒で完璧な名前付けが可能になります。
ブログ用の戯れに上記の命名規則で自動に名前を変更するツールを作りました。
慣れているTAならこれくらい30分くらいで作れます。
キレイな命名規則は、想像以上の時間短縮を生みます。
単純な作業こそTAに頼んで自動化して楽をしましょう。
昔は命名規則の問題は無かった
どれくらい昔かは覚えていませんが、少なくとも僕がプレイステーションでゲームを作っていた頃には、今のような命名規則の混乱はほとんどありませんでした。
なぜなら——ファイル名が8文字しか使えなかったからです（爆）
つまり、「付けたくても複雑な名前を付けられなかった」んです。
制約があることで、逆にシンプルで一貫した命名になっていました。
当時はこんな感じでした。
「MPW01S01.tim」
MP=マップ
W =世界の種類、01=草原、02=雪原、03=砂漠……
S =細かいマップの区分、01～フィールドマップ、50～街マップ
1枚の画像にすべてのマップチップが入っていた時代です。
だから命名は短くても、中身の意味が全員に共有されていた。
名前だけで「ああ、あのデータね」とすぐ通じました。
一方で、今は自由に長い名前を付けられるようになり、「自由＝無秩序」に陥るケースが増えました。
「Map_Desert_Indoor01_Tance01」
「Map_Grass_Field01_Tree01」
「Map_Snow_Town01_Bonfire01」
など、一見わかりやすいようで、文字数がバラバラ、フォーマットも曖昧、検索も引っかかりにくい——
結果として、探しづらく、扱いづらいデータが増えています。
皮肉な話ですが、制限のあった昔の方が、 チーム全員が命名を大切にしていたのかもしれません。
「限られた文字数でどう伝えるか」という意識が、 自然と“命名の哲学”を生み出していたんです。
命名規則は人を幸せにするためのもの
命名規則が適当なプロジェクトで、予定通り完成した例を僕は知りません。
ほとんどの場合、後工程の人たちが徹夜して尻ぬぐいしています。
命名規則を決めるのに、30分もかかりません。
もし決まらない部分があるなら、それは企画が破綻している証拠です。
少し厳しいことを言うと、30分の手間を惜しんで命名規則を決めない企画は課題が残ります。
あなたの30分の怠慢が、他の人を地獄に突き落とします。
どうか30分だけでも時間を割き、周りの人を幸せにしてください。
