Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
DXRuby Advent Calendar 2014 ゲーム・プログラミングとサウンドについて

ゲーム・プログラミングとサウンドについて

 DXRuby Advent Calendar 2014も18日目となりました。
 前日の記事は、土井ヴぃさんの「遺伝的アルゴリズムを使ってゲームのAIを作る」です。
 記事中のAIに使われている遺伝的アルゴリズムというのは、それなりに歴史があるアルゴリズムです。ですが、一般的に使用されているアルゴリズムではないようです。もちろん、影ながら使われている場合は多いとは思います。
 採用例が少ない事情として、それなりにメモリーを使用すること、試行回数が必要なので時間がかかること、が考えられます。これらは現在のPCであれば、たいした問題ではないのですが、今までのゲーム専用機はメモリー量が小さいため遺伝的アルゴリズムを積極的に採用しなかったのでしょう。

 さて、今回の内容はサウンド、音声についてです。内容はDXRubyから離れた内容となりますが、DXRubyの主目的がゲーム作成という事もあり、ゲーム・サウンド・プログラミングの観点から記事にしました。

サウンド系ライブラリー

 DXRubyにも音を出すための仕組みがあります。標準ライブラリーであるSoundクラスやmirichさんが提供されているAyame、bass、voxのRubyバインディングなどです。
 個人的にこれらのRuby用ライブラリーに不満がありました。その理由は逐次ローディングや特定区間ループがない、などなど多数の問題からです。そのため一度はDXRuby掲示板でサウンド周りについて質問したこともあります。
 自分から探して見ることもしました。しかし、決定打といえるサウンド系ライブラリーはないようです。優れたサウンド系ライブラリーはライセンスが厳しかったり、有料だったりします。有料ライセンスの問題点は支払い発生の基準や支払った後の使用権の範囲が狭かったりすること、そしてRubyバインディングがないことです。
 サウンド系ライブラリーの選択肢が狭いのには理由があります。それは、このライブラリーの開発は複雑で難しく用件定義が広いことでしょう。「音を出す」という用件は様々な解釈ができます。音データーの読み込みひとつとっても、ファイル形式、コンテナー形式、コーデックの種類などあります。当然、「音を出す」という用件はまだまだ多種多様に定義されます。そして、ライブラリーはリリース後、秒単位で古い物になっていきます。PCの音環境は今、とても早く変化しています。
 サウンド系ライブラリーはこれからの分野なのかも知れません。もうすこし待つ必要があるのでしょう。

ゲーム・サウンドに求められること

 ここでは、ゲーム・サウンドに必要な機能について私なりに述べたいと思います。ただし、述べたことが実現可能かどうかについては考慮していません。

SEに求められること

定位

 SEが真ん中以外、右よりや左よりに発音する機能です。リアルタイムの定位指定が可能であればゲーム演出に幅を与えます。

細かいボリューム調整

 発音ボリュームをFloatで指定する事です。現在のCPUパワーであれば音声処理はFloatで可能でしょう。過去の慣例を引きずって整数計算する必要はないはずです。
 音声をFloatで処理することは音声ノイズの観点からも有利です。

エンベロープ調整

 SEの場合、元になる音声が同じであってもエンベロープを変えることで別のSEとして使用できます。ゲームの状況に応じたSEの変化などもエンベロープで行えますので演出の幅も広がります。
 SEの使い回しができればゲームリソースのコストも下がります。

ソース形式の自由

 SEならWAV形式、というのは過去の話だと思います。
 音声ファイルを無圧縮でゲームに収録した場合、音声データーがゲームデーターの大部分を占めることになります。そこで、既存の音声圧縮形式を使用したいのです。
 キャラクターの会話(肉声)であれば声専用の音声圧縮形式も存在します。音声の特性に合わせた圧縮形式を選択すればより圧縮できますし音質も維持できます。ファイルサイズが小さければメモリー上に読み込む速度も上がりますし、メモリー上に先読みやキャッシュする事もできるでしょう。
 圧縮形式の場合、展開計算コストが掛かりますが現在のCPUであれば負荷は掛かりません。

音響エフェクター

 イコライザーやリバーブ、フィルターといった音響エフェクトの使用です。エンベロープの項目と同じ効果が望めます。

BGMに求められること

ステレオ出力

 これはどのライブラリーでもできることですね。現在のゲームにおいてBGMのステレオ再生は必須です。

再生ポインターの指定

 再生を始める箇所、終了する箇所、そしてその間をループする機能です。
 ゲーム・ステージのプレイ時間は人によって違う場合があります。そのため、BGMを再生するだけだとゲーム・ステージをクリアーする前にBGMが終了してしまいます。この対策のため、ゲーム用BGMはイントロ部分を再生した後、イントロ部分を除いた区間を繰り返し再生できるように楽曲を構成しています。
 これに対応したサウンド・ライブラリーが必要です。

単一ファイル化

 再生ポインターの指定ができれば、これもできるようになります。使用する楽曲をひとつに繋げる事です。
 楽曲ごとにファイル分けするのが基本ですので、ゲーム・パッケージングにおける選択肢の一つとして提供されるでしょう。

シーケンサーおよびシンセサイズ

 楽曲を楽譜の形で収録できればBGMデーターのサイズは劇的に小さくなるでしょう。さらに、音そのものを実行時に生成できればデーターのサイズはメインプログラムより小さくなると思われます。
 一応、MOD形式を鳴らせれば目的は達成できたといえます。ただ、MOD形式は元になる音そのものを生成する能力はありません。

コンピューターが音を出すということ

 今あるPCには標準で音声出力の機能があります。ですからコンピューターは音を出せるモノと思っている人もいるでしょう。
 本来コンピューターは音を出す装置ではありません。音楽や音声は数学的側面があるため数値計算を得意とするコンピューターを音を出すことに応用した歴史があるだけです。現在の音楽成作においてコンピューターは必ず必要なものとなっています。そういった点から、この応用方法は成功したようです。
 一方、コンピューターの一形態であるPCにおいて音を出すことはどうでしょうか? 確かに音声の出力は問題なく行えています。しかしながら音楽的評価の点からは合格とは言えない状態にあると私は見ています。

 この理由を説明していきましょう。

コンピューターが音を出すまでの構成

 コンピューター、つまり電気回路が音声を出力するためには専用のハードウェアーが必要となります。そのハードウェアーは大別して以下の3要素で構成されている必要があります。

データー音声変換

 波形データーを音声電気信号に変換するハードウェアーです。ここでは電気回路におけるDAC(デジタル・アナログ・コンバーター)と呼ばれている部品に限定せず、より広義の意味で考えます。
 一般的なPCに搭載されているサウンド・システムがこれに該当します。プログラムからはOSを経由して限定的に利用することができます。

サウンド・ジェネレーター

 音を計算する専用の計算機が必要です。DSPやサウンド・チップがこれにあたります。
 PC用サウンド・カードには搭載されているものもあるようです。しかし、これをプログラムから直接操作する方法は提供されていません。

プログラマブル・シーケンサー

 音の出力タイミングを図るメイン・コンピューターから独立したCPUです。つまり、音専用のコンピューターです。
 音に関するデーターやプログラムはメイン・コンピューターから貰い受けます。受け取ったプログラムはサウンド・システム制御やメイン・コンピューターとの通信を受け持つOSやサウンド・システムをサウンド・データーに応じて制御するためのアプリケーションが含まれます。
 一般的なPCには搭載されていません。

PCにおける実装と問題

 家庭用ゲーム機では基本的にこの3つを搭載しています。そして、ゲーム専用機のプログラムはこの3要素を直接コントロールします。それゆえゲーム専用機は優れたゲーム・サウンドを出力します。
 一方、PCはビジネス用として売り出され発展してきた経緯があります。例外として、ホビー用途を主眼に設計されたPCもありますが、絶滅してしまいました。つまり、ゲーム・サウンドに必要な3要素のうち幾つかがありません。搭載されていたとしてもプログラムから操作することはできません。
 最近のPCに搭載されているCPUは超高速なので音出力以外はメインCPUだけでことが足りる と思われがちです。たしかに、DTM(デスクトップミュージック)アプリケーションはこれらを行っています。

 ここで考慮すべきことがあります。それは、音、音楽には決定的な条件があるということです。それはレイテンシー(遅延時間)です。音は出力を決定した時点から音が出始めなければなりません。PCでの処理には時間が掛かります。もちろんこれはミリセコンド単位の遅れです。しかし、人間の耳はこの遅れを認識します。
 また、音の発生タイミングは正確でなくてはなりません。音を出すタイミングを知るためには、正確で細かい時間を測ることのできる時計が必要です。コンピューターにはクロックがありますが、プログラムからこれを利用することはできません。大抵はOSにトラップされており、タイマー割り込みAPIを利用しても望んだタイミングでプログラム側に割り込みが通知されることはありません。
 こういった問題も音楽専用コンピューターを搭載してしまえば解決できますし、その方法も簡単になります。なぜなら音楽に関すること意外の雑事を行わず、すべての計算リソースを音楽に集中できるからです。

 ここではプログラム的側面について述べませんでした。プログラム、ライブラリー、OSといったコードは実行環境であるハードウェアー構成を前提としいます。つまり、ハードウェアー側の準備ができていなければコード側で対応するのはとても難しい事です。そして、対応できたところで不完全なものとなるでしょう。

おわりに

 以上、私がゲーム・プログラミングとサウンドについて考えていたことを文章の形にしてみました。

 私信ですがDXRuby Advent Calendar 2014、5日目の記事でmirichiさんが私の質問状に答えてくださいました。私の疑問点は解決しました。記事の中でいくつかmirichiさんから問われた事柄がありましたが、これへの返答は別の形で伝えたいと思います。(延長日の記事??)

 明日はkairikaff14さんの「DXRubyWS入門」です。お楽しみに!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment