私事で恐縮ですが、昨年・一昨年とCEDECでユーザー・インターフェース（UI）に関するラウンドテーブルをモデレートし、多くの開発者にご参加いただきました。昨年度は主にメニュー周りの開発技法について議論しましたが、そこで得られた共通認識として「開発負荷の高いXbox360・PS3などのハイエンド機では、従来の開発フローに限界があり、FlashによるUI開発が望ましい」という点がありました。
それから１年後、今年のCEDEC最終日では、「Flashを用いてゲームUIを開発する」と題して、Xbox360の最新タイトルで講演が行われました。講演者はフロム・ソフトウェアの新作アクション「NINJA BLADE」開発チームで、プロデューサーの竹内将典氏、テクニカルディレクターの大前広樹氏、アートディレクターの小川啓一郎氏の3名です。開発中タイトルでの事後報告という、過去に例のない、非常にホットな内容となりました。なお、ここでいうUIとは、メニューと体力ゲージなどゲーム画面上の標示物を指しています。
まず「NINJA BLADE」について簡単に紹介しましょう。本作は東京を舞台に、忍者キャラクターが超高速ビル群をダイナミックに駆け回り、モンスターと戦っていくアクションゲームです。スタイリッシュな映画的演出と、ゲームプレイがシームレスに融合した「シネマチックアクション」を標榜しており、発売は来年初頭を予定しています。
本作のUIは、UI専用ミドルウェアの「Scaleform GFx」（GFx）を用いて制作されています。FlashでUIをオーサリングし、GPU依存でゲームへの表示が可能です。「Crysis」「Mass Effect」「Sid Meier's Civilization IV」など、海外では300本以上のタイトルで採用実績があり、2バイト言語にも対応。Xbox360、PS3、Wii、PS2、PSPの公認ミドルウェアにも認定されています。
本セッションは三部構成となり、まず竹内氏がUIの定義とGFxの概要について語り、その後で小川氏がデザイナーの立場から、最後に大前氏がプログラマーの立場からGFx導入におけるメリットとデメリットについて語りました。竹内氏は「優れたUIを作るには、作っては修正するしかない」とした上で、作り直しを前提とした開発環境の整備が必要だと指摘。その答えの一つが、GFxの導入だったと解説しました。なおGFxは「NINJA BLADE」開発の途中段階で導入されており、それだけ大きな課題だったことがわかります。
■デザイナー視点でのGFxとは？
 |  |
初めに小川氏は従来のUI開発フローが、GFxの導入でどのように変更したか紹介しました。従来はデザイナーがフォトショップで作成した画像データを、社内ツールに読み込んでレイアウトし、画像ごとに作成したアニメーションデータと合わせて、プログラマーが開発機材に組み込み、その上で流れを確認して、調整作業を行っていました。
しかしツール性能の問題で、メニュー全体の動きをツール上で再生できず、一連の処理がどういった挙動で動くのか確認できないため、データを想像で作成する必要がありました。フェードイン・アウトなど一部の表示機能がPC上でプレビューできず、データの確認に開発機材やプログラマーが必須で、ちょっとした修正にも待ち時間が発生し、開発効率も良くありませんでした。
これがGFxの導入後は、開発機材に組み込む必要がなく、FlashからSWFファイルをGFxプレイヤーに書き出し、PC上でメニュー全体の動きや、個別のアニメーションを確認したり、調整できるようになりました。このためデザイナー側でトライ＆エラーの時間が増え、見た目や演出のクオリティがより高められました。また社内ツールの整備が不要になったこと、さらにはベクターフォントに対応しており、フォントのサイズ調整がやりやすいメリットもありました。
ただし描画がGPUに依存するため、描画負荷が高いデータを読み込むと処理落ちすることと、1つのSWFファイルに多くの画像を格納すると、展開時にラグが発生する点には注意が必要でした。またツールの導入と学習コストが必要でしたが、Flashがメジャーなツールのため、参考書も多く、1〜2週間程度で基本操作は可能だったと述べました。ただし後述しますが、今回アクションスクリプトはプログラマーが組んでおり、この点も含めた作業のルール化が今後の課題だと指摘されました。
 |  |
■プログラマーが語るGFx
続いて大前氏が壇上に上がり、プログラマー視点でGFx導入について語りました。大前氏によると、これまではプログラマーが画像データの組み込みを行っていたため、表現の一部の責任をプログラマーが負うことになり、デザイナーのトライ＆エラーに巻き込まれる問題があったそうです。
たとえばフェードイン・アウトの処理だけでも、デザイナーはイメージを語るだけで、タイミングを設定するのはプログラマーの仕事です。開発機材へのビルドにも、ハイエンド機ではかなり時間がかかります。しかも最終決定権はデザイナーにあるため、実装後にデザイナーに確認を仰がなければ、仕事が終わりません。
また表現の制御コードとゲームの制御コードが混じる問題もありました。そのためフローが複雑になり、新人プログラマーが対応すると、ステート管理できずにコードが破綻する恐れもありました。そのためバグが発生しやすく、プロジェクトの終盤で優秀なプログラマーが何人もUIデザインに張り付いた、などの状況が起きたともいいます。
これがFlashを使うと、デザイナーとプログラマーの作業分担がしやすく、ビルドの必要がないのでトライ＆エラーも容易になり、コードがシンプルになってバグも減ります。このうち本作では、一番早くて確実な手段としてミドルウェアの採用を決定したこと。さらにはゲーム向けで必要充分な機能があり、採用例も多く、マルチプラットフォーム対応という理由からGFxの採用が決められました。
このように、一見すると良いことずくめですが、そこには幾つか課題も存在します。ツールやミドルウェアの特性に起因するものと、汎用的に見られるものです。
まずツール特有の制限として、GFxではムービーやサウンドの再生ができず、ゲームシステム側でサポートする必要がありました。SEのないUIはありえませんが、通常SEは開発終盤で組み込まれるため、大きな問題ではないとしました。もっとも将来のバージョン（2009年春）では、これらもサポートされるとのことです。
またGFxの問題点として、メモリの使用量が確定しないことと、動作速度やメモリ使用量が不透明で、どのような作り方をすると効率的なのか、良くわからない点を上げました。またシステム設計上で特有のコツがあること。さらにFlashとゲームシステムで、各要素の状態が同期していること、などが上げられました。その上で同期処理には、Observerパターンを使うと効果的だとの解説がありました。このほか実行速度の改善や標示物での注意、PCプレビュー環境における注意点と対処法などの解説がなされました。
■ワークフローの整備がポイント
一方でFlashを用いたUIデザインには、アクションスクリプトと呼ばれるFlashの制御コードを、誰が書くかという問題があります。これをデザイナーが書くと、両者の作業分担がより明確になりますが、総じて敷居が高いのも事実で、新しいバグの温床になることもあります。この点はメーカーやプロジェクトによってまちまちで、プログラマー以外にプランナーが書く例もあり、昨年度のラウンドテーブルで議論になったテーマの一つでもありました。
ちなみに本プロジェクトではプログラマーが書いています。デザイナーは従来通り、表示要素の作成とアニメーション、レイアウトのみで、プログラマーが行うのは、メニュー構造の作成など、それ以外の全てというわけです。この理由として役割分担がわかりやすく、デザイナーがスクリプトを書く必要もない、従来の作業フローに近いので混乱も少ない、などと説明されました。
もっとも、これによってプログラマーとデザイナーの相互依存性は、依然として残されたままとなります。またGFxの特性上、強い構造化を行うため、一般のFlashに見られるような、エッジの利いたUIが作りにくいデメリットも上げられました。もっとも大前氏は、それでもGFxの導入で大きな成果が上がったのは間違いない、と強調します。特に「GFxでは、FlashをFlashのまま使える点が大きかった」と大前氏は語りました。
最後に大前氏は今後の課題について解説しました。「?PCプレビュー上でのサウンド再生の対応」「?より優れたUIを実現するためのワークフローの整備」「?GFxで可能な処理の限界の見極め」です。その上で導入のアドバイスとして「?導入理由をチーム内で共有する」「?ワークフローを決める」「?GFxの特性を知る」「?過度な期待を抱かずに、まずは無難に使ってみる」という4点を上げました。
UIはゲーム機とプレイヤーを繋ぐインターフェースで、おもしろいゲームの開発には、直感的なUIが欠かせません。しかもUIはコントローラーとも不可分の存在で、WiiやDSでは新しい操作デバイスに対応した、新しいUIデザイン、ひいては新しいゲームアイディアも求められています。それだけに効率的なUI設計が必要で、Flashの活用が業界内で模索されています。
本セッションは、こうした現状に即した、非常にタイムリーなセッションとなりました。さらに開発中タイトルを題材とした技術講演という意味で、過去に例のない試みだったのではないでしょうか。
