はじめに
プログラマと名前付けのルール、命名規則は話し合っていた方が良い。
ゲームのサウンドで、華やかさがないので
あまり語られていないのですが、
作業のほとんどが大量のリソースの管理になります。
大抵は、名前は後でどうとでもなると考えがちだったりなのですが、
そもそも膨大なアセットを管理するという状況が想像できない場合がよくあります。
命名規則が自由すぎるのもまた、困りものだったり。
といった、あるある話。
ゲームジャムで付けていた名前を例にあげてみます。
wavファイル名
音を扱う場合、大抵 wav形式のファイルを用意することになります。
用意の仕方は、DAWや波形編集ソフトなどでwav出力するのが主なやり方だと思います。
これは音一つに対して、ファイル名を付けて何らかのコンバータなり、ゲームエンジンなり、ミドルウェアなりに渡さなければいけません。
Unityを例に、置き場所を
Unityで音を鳴らす場合、UnityEditorに直接波形をドロップすると追加できます。
ドロップ先はプロジェクトのヒエラルキーならどこでも入れられる。
ちょっとまって、どこでも？
いやいや、ルートに波形を置いても良いけど、これは、NG。
とりあえず、SoundやAudioとかのフォルダを作った方が良い。
（英語圏だとAudioClipsとかSoundsもあるかな）
そこにひとまず入れておけば、他の人と変更がバッティングしなくてよい。
オーディオファイルは膨大
例えば、ゲームジャムの規模でもこれくらい最低でも必要かなと
タイトルのBGM （なくてもよい）
タイトルの選択音(あった方が良い）
ゲーム開始の音（あった方が良い、タイトルの選択音と一緒でも良い）
ゲーム中のBGM （あった方が普通）
成功、失敗などの状況説明的なSE（効果音）
リザルトのBGM(あった方が良い）
タイトルへ戻るSE(なくても良い）
これだけでも8音はある。
さらに、音にこだわりだすとどんどん増えていく。キリがないくらい。
音のカテゴリ分け
上の例で、
BGM系 （ループ素材）
SE系 （ワンショット素材）
と分けることができる。
まず、これらでフォルダを用意する。
BGMの名前の付け方例
- 大文字、小文字
TitleBgm,wav
GameStartBgm.wav
GameMainBgm.wav
GameClearBgm.wav
メリット：ルールがシンプル。
これ、大事。 大文字小文字を区別するC#などでは、あとあと、これが守られていないと
名前違いで見つからないとかあったりする。
例：titleBgm.wavとTitleBgm.wavは別のものとして解釈される。
デメリット：ちょっと詰まって見えるくらいなので、よくわからない時はこれで良いかも。
小文字のみ
個人的には、全部小文字も好き。だけど、単語が増えると区切り文字に難儀する。
title_bgm.wav
game_start_bgm.wav
とか、「_」アンダースコアを使うことがある。
あと、後ろのBGMは、フォルダ分けてたら必要ないかも。
title.wavとかすっきり。
デメリット：名前が長くなりがち。
ただ、これが
clear.wav とかだとあとあと、これがBGMなのかSEなのか、
はたまたその間のようなジングル（ワンショットの音楽的なフレーズありのもの）なのか区別できなくなる。
- 小文字はじまり、区切りのみ大文字
プログラマ的には、最初だけ小文字とかもある。
titleBgm.wav
これは、何だろう、C++とかの変数の命名規則とかに近いかな。
名前変更のコスト
で、できなくなった時にリネームすれば良いと考えがちですが、
大抵の場合、最初に決めた名前から変更するのに苦労する。
名前変更のコストとは・・・
他の名前と重複していないかどうか
すでにプログラムから古い名前で呼ばれていた場合に、再設定しないといけない。（ミスが起こりやすい）
SEの名前の付け方例
OK.wav
NG.wav
Clear.wav
ルールを厳格に守るならば、
Ok.wav
Ng.wav
だろう。
でも、これが、なんとなく気に入らないので、全部小文字も捨てがたい。
ok.wav
ng.wav
SEとかの命名ルールも簡単にしておく
（追記:20200731)
オブジェクト名+動作名とかのルールが良さそう。
名前ソートで集まるので、指定したり、探すときに迷いにくくなります。
ゲームの場合オブジェクトが多いので、例えば
DoorOpen
DoorClose
とか
英語的には先に動詞がきそうですが、検索性の高いものでまとめておく感じがよいかと。
あとで、分割するときとかにもオブジェクトでまとめて移動とかできるなど、メリットあり。
キャラ名＋動作とか。
名前にフォルダパスが含まれているようなイメージですね。
フォルダが使えるシステムなら個々にシンプルでも良さそうですが、大量になった時は、個別に名前がある方がありがたいことも
例えば、フォルダ無視して検索した時に、同じ名前が並んでいたりしていると、音を聞かないとわからない状態になり、大変手間が増えます。
後で波形エディタで編集するときや存在チェックなどのときも混乱しがちなので、名前に焼きこめる情報は入れてしまうのも手です。
オブジェクト+動作+修飾
（追記20210729）
ドアの開く音で
どこのドアか、どんなどか
とかいったバリエーションは、
- バリエーション番号
- バリエーションABC
などが考えられる
DoorOpen1
DoorOpen2
より具体的なものがつくなら番号の変わりに たとえばドアの接地場所や種類など
DoorOpenLabo
DoorOpenHome
ボイス（セリフ）の名前の付け方
これは、ゲームジャム的な経験からなのですが、
そのままセリフの内容をローマ字で書いてしまうのが一番間違いがなかった。
konichiwa.wav
hajimemasite.wav
arigato.wav
「はじめまして」の「し」がshiがsiなのか、
「ありがとう」の「う」がarigatoがarigatouなのか
など微妙な違いもありますが。
まぁ、ボーカロイドとか音声合成に入れる時のローマ字 くらいの気持ち。
なお、長いセリフの場合は出だしのフレーズだけで、どこかで切ってしまう。
実際問題
こんな感じで、頭では思っているのですが、
忙しいと適当な名前になりがちです。
例外を許すとどんどんルールがカオスになります。
某ゲームの実データ（整理されていない）を例として見てみましょう。
とあるゲームの
Soundsフォルダ以下にあったもの
ButtonPlaySound.prefab
damage(CriAtomSource).prefab
select(CriAtomSource).prefab
driveBgm(CriAtomSource).prefab
gameover(CriAtomSource).prefab
gameclear(CriAtomSource).prefab
hanautadoi(CriAtomSource).prefab
hanautagoto(CriAtomSource).prefab
kaifukuvoice(CriAtomSource).prefab
hanaurahidaka(CriAtomSource).prefab
hanautatanaka(CriAtomSource).prefab
hanautatakaki(CriAtomSource).prefab
hanautaisizaki(CriAtomSource).prefab
hanautanakamura(CriAtomSource).prefab
hanautakaifuku(CriAtomSource).prefab
ButtonPlaySound_Start.prefab
これは、拡張子が.prefabになっていて、とりあえずシーンに配置したり、インスタンス化したら鳴るようにスクリプト付きで共有していたのだろうと思われます。
hanautaの後に続く名前らしきもの。これは、「ハナウタ」を開発者メンバーが歌っていて、それらの素材を使っていた。
歌の内容で区別できないので、話者（歌手）の名前が割り当てられています。
あわてて、作ったので、これでも動作はしますが、
これは、
リネームして、音が鳴らなくなるリスク ＞＞＞＞＞ 管理上の美しさ
時間が無い時にはこうなります。
あと、チームで作るとバージョン管理（git,svn,peforce)というファイルを
時系列で差分を持ちながらみんなで共有して、管理するシステムがあるのですが、
名前変更が辛い
直接ファイル名で管理される ＝ チームで作るのでバージョン管理ツールを使う
バージョン管理ツールに慣れていないと、後からリネームがしずらい
もともとDAWなどで出力した名前と変わってしまうと、元の素材に戻れなくなる。
（戻るために別のエクセルシートを用意して、人力リソース管理の地獄になる）
という状況になります。
数が、これくらいなら、まだ見渡せるので良いのですが、
画面に入りきらないくらいの数になると、もう困ります。
正直、数が多すぎて、なんとかならなくなります。
（これが、数年続いたタイトルとかだともう・・・）
ちなみに、もっと酷い例をあげると、「全角が含まれるケース」とかもあります。
見た目でわからない。
「＿」と「_」の区別はつかない・・・
おわりに
「命名規則は、はじめにしっかり決めて、開発途中では変更しない」
ようにした方が良いです。
そして、バージョン管理にコミットする前に、改めて、命名が正しいかはチェックした方が良い。
人力で注意が難しいなら、
ルール通り正しいかツールを通してチェックする
くらい徹底必要があります。
（自作が難しければプログラマにお願いして作ってもらえば良い）
プログラマレイヤーでは、さまざまな工夫も可能ですが、
サウンド側の素材管理をしている時にも同じ問題が発生するので、
なるべくルールはシンプルに守れる範囲に留めた方が良いです。
例えば、セリフなら、
そのまま
こんにちわ.wav
初めまして.wav
ありがとう.wav
と日本語にしてしまうなんてことも今時はありかもしれません。
（文字コードで表現できない文字が使えない問題（絵文字がどこまでいけるかとか）、多言語開発などではまだ安心できないテクニックですが）
おそらく、とっさの時に、「様々な回避方法がある」ということを知っておくことも、ゲームサウンドならではのノウハウかもしれません。
こぼれ話
おそらく、「サウンドに名前をつける」という行為が過去のものになると、より幸せになれる。
ゲームのコンパイル時に
ファイルベースという考え方じゃなくて、サウンドそのものにアクセスできるような。
例えば、クラウド上にあるURL（名前ではなく、場所から自動生成された識別文字列）にwav（名前は何でも良い）を上げておくだけ。ゲームエンジンはそのリンクアドレスを使う。
（オープンな素材とか、更新される素材とか、後で無効化とかの管理も扱え、なんなら利用料に応じたビジネスもできる・・・soundCloudとか近いか）
wavとかの形式ではなく、psdファイルのように、レイヤーをもった画像といった一般化されたフォーマットがサウンドでもできれば、より複雑なインタラクティブミュージックや効果音なども扱えるようになる未来はあると思う。(ちょっとズレるけどAmbisonicsのBformatのような)