2006/7/27

音声ギミックフレームワークの素描  VRMスクリプト禅問答
テーマ的に万人の理解を求めると破綻しそうなので、投げっ放し的な書き方になります。展開を求める質問等はコメント欄に。要度に応じて即答したり別エントリを立てたりします。

*     *     *

形式番号を含むがゆえに、原則として車両毎にユニークであるべき画像リソースに対し、音声リソースは同車種間で共有が可能です。従って、
走行音だけカスタマイズしたい人や、一方で走行音は据え置き、ブレーキ緩解音とかノッチ投入音だけ使いたい人もいる(中略)リソースIDの1〜5を欠番にして、6〜9に音声リソースを設定するという何とも面倒な手間を課せられるわけです。

45-50s氏が指摘しているこの問題を回避し、効率的かつ現実的な音声リソースの割り当てを実現することが第一のテーマです。

最初に、氏の指摘を展開して、何が問題であるのかをより明確にしておくことにしましょう。
欠番が生じる理由は、ポータブル編成の「号車番号とパターン番号からリソースIDを算出する手法」に倣おうとした場合、この方法で算出されるリソースIDを空にする以外にデフォルトの音声リソースを使う手段がないからです。
一方で、車両毎にスクリプトウィザードでリソースIDを尋ねるベタな方法を使うと、現時点で車両に設定可能な音声は10種ありますから、たとえば8両編成にこれを設定するとなると、ユーザーは10種×8両で80回の番号入力を強いられることとなり、これまた不都合です。

以上が45-50氏が指摘している問題の本質です(不足していたら補足してください>氏)。では、この問題の解決法の素描に進むことにしましょう。


基本的な着想は「音声素材の“意味”を示す編成プロパティ(グローバル変数)に音声リソースIDを格納しておく」です。
たとえば、低速走行時の音声リソースを設定するのはSetWaveLow命令です。これにちなんで、そのリソースIDを収める変数名に“WaveLow”を含むことにします。加えて、大雑把に考えると走行音は動力車と付随車で異なるはずですから、これを区別すべく“Mcar”“Tcar”といった識別子を加えます。このルールを適用していくと・・・

動力車低速走行音記録変数:McarWaveLow
動力車高速走行音記録変数:McarWaveHigh
付随車低速走行音記録変数:TcarWaveLow
付随車高速走行音記録変数:TcarWaveHigh
     ・
     ・
     ・

のような「名前空間」を得ることが出来ます。
具体的な実装としては、まずはこうして出来る一連の変数(何が必要で何が不要かには議論の余地があると思います)に対し、具体的なリソースIDをユーザーが登録するためのスクロールを作ります。これは編成の種類(電車編成と気動車編成は管理ポリシーが異なりそうですから)によって何種かに分化するかも知れません。
幸いにしてSetWave〜系命令は、パラメータに0を与えられると「IDに0を指定すると部品に組み込まれているサウンドを使用」という仕様があるので、ユーザーはSCRIPTウィザードからオリジナル素材のみ任意のリソースIDを入力し、それを用意していない音素材については0を入力すれば良いことになります。これで、とりあえず「リソースIDの欠番問題」は回避できます。

次に、こうして独自の名前空間を通して「仮想化」したリソースIDを各車両に割り当てるスクロールが必要です。これは、現行のSCRIPTウィザードには個々の車両が動力車か付随車かを見分ける機能がないので(今後も実装はされないでしょう)車両毎に1つずつスクロールを組み込むしかないとは思いますが、大雑把に考えるとスクロールは動力車用と付随車用の二種類で済みます(もちろん、必要に応じて種類は増やせばよい)。
具体的には、これらのスクロールには名前が同じの音声初期化用メソッドが含まれます。そして、それぞれSetWave〜系命令が連記されているのですが、パラメータとして与える変数がMcar系かTcar系かに分かれます。つまり、ユーザーは個々の車両に対し、スクロールを使い分けることで車両が動力車か付随車か・・・厳密に言えば動力車っぽい音をだすか付随車っぽい音を出すかを選んでいくことになります。

さらにこの考え方を拡張し、以下のように応用を広げることが出来ます。

・車両に組み込むSetWave〜系命令を含むスクロールと、それを実際に実行するCallCar命令およびそのトリガイベントを含むスクロールを独立させ、組み合わせのバリエーションを生み出すとか。
・レイアウト側リソースに別系統の名前空間を用意し、それを参照する方法も可能。たとえば、トラックプランに依存する音声ギミック(鉄橋通過音だとか)はこの方法で対応するとか。

まぁ、いきなり大風呂敷を広げすぎると頓挫するので、まずは初期化の定石を固めることからいきたいな、とは思いますが。

*     *     *

以上が「基本的な着想」です。
あくまでも「着想」ですので実装に際してはもっと考えなければならないことが多々あります。が、一気に書いても意味不明になるだけなので、今日はこのへんにしておきましょう。
なお、このアイデアは、音声リソースを編成とレイアウトのいずれに組み込んだ場合も適用可能です。ポータブル編成のようにポータビリティにこだわるのであれば編成にリソースを組み込む方針になりますが、45-50s氏がこちらの作例で示しているようなケースは、むしろ編成ではなくレイアウトに所属する属性にも思えるので、より細かな要件の整理と絞込みが必要かと思われます。

※ 製品スクリプトマニュアル−制約の頁にはオブジェクト/メソッドあたりのグローバル/ローカル変数の数について「実用上多くても16個程度に」との記述がある。上記戦略は明らかにこれに抵触するが、拙作スクロールの稼動実績から鑑みて実害はないと判断している。ただし、これはマシンパワーに依存している可能性があるので、この点に疑義を抱いておられる方にはその旨のレポートをお願いしたい。

0

コメントを書く

この記事にはコメントを投稿できません




teacup.ブログ “AutoPage”
AutoPage最新お知らせ