The reason why video games use Flash

前回 flash.ocx を直接ダイナミックリンクする形で FLASH データを OGRE3D で活用できるアドオン Hikari を紹介しましたが、ゲームだけでなく、モバイルの性能向上にあわせて最近ではデジカメや携帯電話のメニューにも FLASH が使われ始めているようです。ゲームにおける活用も進んでいて、来週開催の国内最大級のゲーム開発者カンファレンス CEDEC においても、FLASH を使ってゲーム UI を構築するというセッションが開催されます。

ゲームでは、 RPG 、格闘ゲーム、シューティングゲーム、アクションゲームなどのジャンルによらず、必ず何らかの形でメニューなどの UI を提供することになります。ゲームで提供するメニューでは、銀行の ATM の画面のような、ボタンの押下を待つだけの、ただのボタン表示の並び……のような画面はまず絶対に許されません。メニューは登場からして必ずアニメーションし、気持ちよく、かつ、ユニークに動き、背景もアニメーションし、カーソルが当たっているだけでもレスポンスしなければいけません。ゲーム開発ではあまりスポットの当たらない部分ですが、ユーザーの心証とゲームの操作性を左右する非常に重要な部分です。

RPG ならメニューがそれにあたるでしょう。 FPS なら武器選択を FLASH に。シューティングゲームですら、自分が乗り込む宇宙戦闘機を選択する画面をきっちり作らなくてはいけない時代です。そしてゲーム開発にかかわるビジュアルスタッフにはそういったメニューを作り込む能力があります。また、プログラマからしてみれば、オーサリングデータさえあればそれを動かすことは決して難しくはありません。

ツールとしての FLASH 製作環境

問題は UI を担当するビジュアルスタッフにどうやってオーサリングデータを作ってもらうかです。 UI ですからユーザーの入力に対するレスポンスを作る必要があり、単体のアニメーションの集合体というわけにもいかず、また作り込みプレビュー環境も必要でしょう。求められるのは、ツールとプレビューを（できればPC上でそのまま）シームレスに実行することができ、実機でも簡単に確認できるような製作環境です。内製ともなれば当然ツールにも再生エンジンにもバグが出るでしょう。そういったバグを速やかに修正できれば、よりいっそうクオリティの高い製作に打ち込むことができます。

ところが、現実的にはゲームプログラマの大半は、ゲームルールの実装や、ゲームの描画、演出、アクション、物理演算や群集制御、メモリやロード周りなどのゲームやライブラリに駆り出されているのが実情です。また、ゲームの実装のバグは比較的速攻で叩き潰しますが、ツールのバグ修正はそれに比べれば後手に回りがちです。ミドルウェア開発部門のある会社（ゲームの開発とツールの開発が分離している会社）でも、必ずしも理想的な対応ができるとは限りません。

解決策は二つあります。ひとつはあくまで内製を貫き、現代で求められるレベルにスタッフ（＝人件費）が一丸となって応えようという製作体制を敷くことです。これは、オーサリングを含む UI 関係の作業を 3D やサウンド、AIに並ぶプライオリティまで引き上げ、PS1→PS2→PS3→PS4などのマシンの進化にあわせてきちんと強化して保守していくことを意味します。もうひとつの解決策は、同様の主旨のツールが吐き出すデータを読めるようにしたり、 FLASH などのミドルウェアを導入して組み込むなどして、他のメーカーがコストをかけて開発し完成度を高めているツールを導入（流用）することです。

第５世代(PS1)までのゲーム開発では前者の選択肢しかありませんでした。第６世代(PS2)あたりから、そういう話が出るようになったのではないかと思います。

以下のビデオは FLASH 対応 UI 専用ミドルウェア ScaleForm GFx を使用してメニューを実装したゲームのメニューの様子です。

描画は独自

フリーソフトウェアの環境で使用できる例としての Hikari は未知数ですが、実際に製品レベルで使用できる ScaleForm GFx などの組込 FLASH の場合は、描画は独自に実装できるようです（というより、各ゲームには各ゲームのコアプログラムやレンダーシーケンスがありますから、勝手に描画されては困ります）。

たとえば、ベクターデータを描画するとなれば、精細な描画には限界がありますが、テクスチャを動かす場合などには、ゲーム用ハードウェアのビデオ能力を使いやすいので、半透明にするなり光らせるなりすることができます。また、 FLASH で動きをつけた動きの情報を取り出して、 3D 空間上のスポットライトにバインドするという活用方法もあります。メニューのバックグラウンドに抽象的な３D映像を用いている場合、この方法でメニュー操作とバックグラウンドを同一のオーサリングデータからコントロールさせることも考えられます。

今後は MS の Sliverlight なども選択肢に入ってくるかもしれませんし、 FLASH などの機能がバージョンアップしてくれば、他のことに使えるかもしれません。なんにせよ、ゲームの世界では「動かない一枚絵」を貼付けることはもはやあり得ないので、描画に載せればビジュアルスタッフの意図どおり適切にアニメして、最後まで調整が利くという点で FLASH は強力な選択肢として今後もゲーム開発に深く関わってくると思います。３Dのオーサリングデータなら作る方法はいくらでもあるけど、２Dに関しては決定打がなかったので、そこにここ数年で FLASH が食い込んできた……という状況ではないかと感じています。