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 が食い込んできた……という状況ではないかと感じています。

An ideal software design (1)

通常、私達は、チームがプログラムに手をつけ始める前に、ソフトウェア設計を決めようとする。それは、簡単なブロック図であったり、 UML であったりするかもしれない。多くのプログラマが迅速な開発のためにあなたのチームに集まり始める。あなたがしなければならないことは、ソフトウェア設計である。それのために、あなたは、ソフトウェアをモジュールに分割する。それは、プログラムのための分割設計である。

しかし、あなたの任務は、各プログラマがプログラミングの一部を担当可能な状態を作り上げることである。あなたの設計は、それを実現し得るか？

プログラムの機構上妥当な分割設計と、プログラマに仕事を分けるために妥当な分割設計の間には、ちょっとした違いがある。もしあなたが自分でソフトウェアを設計してそのプログラムを書く場合は、恐らくあなたはこの事実に気づかない。

プログラム上の妥当性のために多くのモジュールに分割された理想的なソフトウェア設計は、しばしば、専門性のプログラマの仕事を妨害する。それは、生産的な開発を始めることを不可能にする。

多くのプログラムの専門的な要素がある --- makefile、メモリ管理、リソース管理、入力装置、ハードウェア制御、コンテンツパイプライン、並列処理、シェーダ、エフェクト、パーティクル、アニメーション、グラフィック、オーディオ、立体音響、人工知能、物理学、幾何学、プロシージャル技術、スクリプト、ネットワーク、デバッグシステム、サードパーティミドルウェア等など……。

これらの専門的な要素を系統的に組み合わせることでソフトウェアを設計し得るか？　ひょっとすれば、それは可能である。しかし、プログラムのために設計した理想的なソフトウェア設計は、プロジェクトに集まるプログラマにとっては悪いニュースである。ゲームシステムは、彼らの知識と彼らのコードの合成物を初期から要求する。そのため、プロジェクトは難航することになるだろう。

Is an Object-Oriented Game Engine necessary? (3)

極限まで抽象化された概念であるところのゲームオブジェクトはおそらくもともとは画面への描画の最小単位として使われることで意義をもっていたのではなかろうか。要するに昔はオブジェクトがそれぞれ単純に自分自身を自分自身に基づいて描画するだけで画面が描画でき、単純明快な一部品として扱えていた。しかし、例えば最近のシャドウマッピングなどのマルチパスレンダリングが主流になってくると、自分自身を描画するときに自身や他のオブジェクトがすでに描かれたテクスチャがあることを前提としなくてはならない場合もある。描画するだけでも他のオブジェクトの描画結果に依存する必要がでてきてしまった。また、テクスチャを参照する必要がなかったり、透明度を無視してもよかったり、描画する内容も複数の描画指示のあいだで全く異なる。スーパークラスのポインタを渡してのんきに描画命令がとどくのを待つだけというわけにはいかない。描画処理の全体の流れの中のどこでなにを描画するか言及する必要がでてきてしまった。

描画処理の側面からみてももはやゲームオブジェクトはすべてが全く同じものだとはみなせない。

[描画でさえももはや構造化できない - 作業記録]

経緯としては指摘の通りなのですが、個人的にはゲームオブジェクト的なものと描画はかなり前の段階から切り離しが始まって、（今風に言うと）緩やかな結びつきで処理することがトレンドになってきているような気がします。それはつまりそれぞれ担当するプログラマが別人になったからとも言えるのですが、ゲーム上の処理は処理、描画系は描画系というノリが主流だと思います。
（といっても会社によって違うので何とも言えない）

昨日、「ゲーム・ビジネスロジック的ななにか」はタイトルに特化するので C++ の"再利用面"における有効活用はないんじゃないか、ということを書きました。しかし、僕は逆に描画系や３Ｄのシーン管理の部分は再利用性を生かして、なんとかミニライブラリに体系的にまとめられないものかと、ここ２〜３年くらい考え続けています。

たとえばシーンや、座標・座標と姿勢を持ち最終的にマトリクスに情報を出せる存在というものは３Ｄゲームなら必ず扱う概念です。ここに再利用性を持ち込む意図は、生産性のための再利用ではなく、フィーリング（あるいはモデルと言い換えてよい）の再利用です。ゲームの開発は「同じものを何度も書くのは馬鹿馬鹿しいからライブラリ化する」ほどスパンが短くありませんし、同じような物をタイトル毎に様子を見ながらコードをブッコ抜いて作る……という行為も高い効果を持つ一面があると思います。また、ハイエンドコンソールとそうでないコンソール、ポータブルマシンでは実装が変わってくることもありますから、どこかで手を動かす必要はあります。

ですから、あくまでフィーリングを揃えるための再利用というわけです。たとえば、 XML の DOM は C と C++ では使い方が全く異なりますが、フィーリングは一緒です。 C++ にも多くの種類の DOM がありますが、使い方が違うだけで根本にあるモデルは同じです。

少し極端な例えですが、そのような形で描画系やシーン管理、あるいはリソースマネジメントにはっきりと再利用のための C++ の活用を実践できないかと考えています。が、それも前述の方が書かれているように……どういう絵作りをするかでまったく手順が変わってくるので、やはりタイトル特化のアーキテクチャは避け難いですよね……これの単純な解法は、存在するんですが、パフォーマンスが……

そういう意味では（負け惜しみだけど）海外勢は似たようなものをよりゴージャスに作り替えていくことで次のタイトルを出す、という市場の形があるから、エンジン部分の再利用を促進できている部分があると思います。

たとえば、日本はＲＰＧでもタイトルごとに文法が違いますよね。ドラゴンクエストIIIを再利用してドラゴンクエストIVは作れそうですが、ファイナルファンタジーXIIを流用してドラゴンクエストVIIIを作るのは難しいでしょう。しかし、海外はＦＰＳといえばこうだ！という形がしっかりできあがっています。ここに一度作った物を広く再利用する市場があるんじゃないかと思います。

海外の方がゲームプログラムの設計が進歩的だから生産性が高いとよく言われますが、個人的には、ユーザーの厳密なジャンル認識の下、割りきりの基準ができつつあるのと、ＦＰＳのように明確な仕様のジャンルが大きな市場で存在しているため、日本よりそういったことがやりやすいからではないか……と考え初めています。

日本だろうと海外だろうと、タイトル or システムに対してその描画系は特化してしまう傾向。そして、抽象度を高めるとパフォーマンスが落ちてハイエンド部門の競争ではキツくなる……といったコンポーネント化へのジレンマは同じものを抱えているのではないかと考えています。

Is an Object-Oriented Game Engine necessary? (2)

では、理想的なオブジェクト指向言語における理想的なゲームオブジェクト設計とは何だろう？　私は、良いゲームオブジェクト設計は、前時代に完成されたと考える。ビデオゲームプログラミングは、当時からオブジェクト指向設計の要素を実装してきた。

当時のビデオゲームプログラマがオブジェクト指向のプログラミングを実現することを望まなかったことは、重要である。彼らは、生産的な開発とエキサイティングなゲームを追求してきた。そこに我々が学ぶべきである何かがある。

現在、私達は、十分な仕様のオブジェクト指向プログラミング言語を用いることができる。私は、前のエントリで、それが私達のゲームオブジェクト設計を狂わせる原因であると書いた。しかし、当時のビデオゲームプログラマは、 C++ (Cも!) を使えなかった。従って、彼らは、マシン語を用いた。私が最初に加わったプロジェクトは、アセンブリで書かれていた。そのような条件下で、プログラマは、オブジェクト指向の設計を追求することはできない。従って、その設計は、自然とゲームのために良いバランスになる。

見てみよう。私達が使った技術は、タスクシステムである。もちろん、ビデオゲームプログラマは、 C++ と共に今この手法を使っている。しかし、当時のプログラマは、アセンブリでタスクシステムを書いた。従って、現在の手法と当時の手法には違いがある。

タスクシステムは、ポピュラーなビデオゲーム開発方法のうちの 1 つである。それは、データ格納とジャンプアドレス群から成る原始的なメモリブロックである。振る舞いを変更するには、ジャンプアドレスを書き直す。コールバックされたコードは、オフセットアクセスによってメンバーデータにアクセスすることができる。既にポリモーフィズムは実現していた。そこには「型」がない。しかし、それは、 C/C++ のコンパイルされた結果と類似している。現在、私達は、 C++ でこれを書く。C++ は、 vtable という概念を持っている。従って、もっとうまくポリモーフィズムを実現することができる。

一方、私達のプロジェクトは、タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることを禁じた。つまり、私達は、ゲームオブジェクトの間のメッセージ通信を禁じた。

タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることは、安全ではない、なぜなら、 型がないからだ。C++ は、もう少しうまくそれを扱うことができる。なぜなら、私達は、 C++ でダウンキャストを比較的安全に書くことができるからだ。しかし、それは、同じくデバッグしにくい。私達がそれを禁じた別の理由は、私達はそのような方法からメリットを発見できなかったからである。

子供タスクは、自身のものをコントロールする。しかし、これらのタスクが他のタスクと仕事をする必要がある場合は、子供のマネージャ役である親タスクにまとめて仕事をさせた。私は、この方法が私達への最適解であるかどうかを知らない。しかし、それは、デバッグ、調整、調節に易く、そして、変更のために柔軟であった。

当時、私達の周りには「オブジェクト指向」という言葉がなかったので、私達は、それを追求しなかった。プログラマの自己満足が、ゲームオブジェクト設計の秩序を乱すこともなかった。

Is an Object-Oriented Game Engine necessary? (1)

なぜわざわざゲームオブジェクトクラスなんてつくって下方へ特殊化するクラスヒエラルキーをつくるんだろう。オブジェクト同士の連絡では、オブジェクトリストを持つ方は信号を伝達するだけで、ダウンキャストなりの特殊化はオブジェクト群のそれぞれの内側で行われるような運用をされる。か、もっと無茶をやる。

(snip)

ゲームルールはゲームオブジェクト同士の交互のやりとりを全体として眺めた状態を完全に規定する。プラグイン系のようなゆるい統合ではやっていけない。完全な記述が求められる。新たな種類のゲームオブジェクトが追加されるとしたら、全ての既存のゲームオブジェクトに対する反応が完全に新たにおこされてなくてはならない。ひとつのピースが残りの全部のピースとの接合部をもっている多次元ジグソーパズルだ。無機的な構造物と比べてここが全く異なっている。

[ゲームオブジェクトを一般化して管理しないことの妥当性について - 作業記録]

私は、彼の葛藤を理解する。なぜなら、私もここ数年、ミドルウェア、エンジン、シーングラフを研究することによって、系統的にゲームエンジンやグラフィックスを扱うことに挑戦してきたからだ。しかし、会社の実際の仕事で、私はそれを実践できていない。リアルタイムアプリケーションであるビデオゲームプログラミングは、常にパフォーマンスを要求し、そして、多くのプログラマがプロジェクトに参加する。そのため、パフォーマンスとプロジェクトの初期期間の両方を犠牲にする体系的アーキテクチャは、有益ではない。

C++ のような高級言語は、我々のプログラミングスタイルを変えるよう誘惑する。アマゾンや書店は、オブジェクト指向のプログラミングを書く方法を教える本を陳列している。我々は、これらの本を読み、そして、オブジェクト指向のプログラミングによってゲームオブジェクトクラスを扱えないか考え始める。大規模システム設計におけるオブジェクト指向アーキテクチャについての十分な議論があることは確かである。しかし、（特に日本において）、ビデオゲームアプリケーション設計のための議論は十分とは言えない。

欧米では、開発者は、ゲームオブジェクト設計を議論する。しかし、彼らの大半は、 FPS 、及び、 RTS を開発する。これらのジャンルは、オブジェクト指向の設計と相性がよい。しかし、ゲーム全てが FPS/RTS であるわけではない。そのため、多くの日本の開発者は、ゲームオブジェクトクラス設計を議論しない。他のジャンルでは、ゲームコアが統括的にゲームをコントロールすることが必要である。そして、ビデオゲーム開発において最も重要なことは、調整と調節である。恐らく、我々の世界における理想的なアーキテクチャは、エンターテイメント制御装置を調整と調節が容易なように 1 つの場所に集めることだ。ビデオゲーム開発者は確定された仕様書より娯楽感覚を重要視しなければならない。

大規模システム設計を教える本にと一緒に我々がソースコードを書くならば、ゲームアプリケーションはプログラマの虚栄心を満たすだろう。しかし、そのアプリケーションは、ビデオゲームプログラムとして悪いものである。我々の理想的なプログラム設計は、大規模システムと異なるであろう。そして、ビデオゲームのオブジェクト指向設計は、大規模システムのオブジェクト指向設計と異なるだろう。従って、それらの本は、すべてのことを我々に教えてくれるわけではない。我々は、自分で答えを発見しなければならない。まだ日本もそして欧米もその答えを見つけてはいない。

PowerPC Personal Computer

全ての主要ゲームコンソールは、 PowerPC 系を採用しています。 PowerPC の性能を引き出すコードを書くために、多くの特別なテクニックが存在しています。私達は、休日でも、 Appe の PC でそれを試してみることができました。しかし、それはもはや過去の話になっています。 ApplePC が PowerPC からインテルに変更した今、自宅で PowerPC プログラミングを実践する妥当な PC はありません。どうすれば、自宅で PowerPC やマルチコアプログラミングを試みることができるでしょうか？

自宅には古い mac mini、最新の iMac そして PLAYSTATION3 があります。

私の古い mac mini は、マルチコアではありません。しかし、それは、私のために役に立ちます。なぜなら、 mac mini は、小さく、軽く、PowerPC プログラミングを楽しむには良いからです。

現在の私の PC、 iMac は、デュアルコアであり、そして、マルチ‐コアプログラミングを実践するには良い環境です。しかしながら、 intel core duo は、主要なゲームコンソールに採用されていません。従って、純粋なマルチコアプログラミングの実践に使うことはできますが、ただちに仕事に直結するわけではありません。

PLAYSTATION3 は、有益であるかもしれません。 Linux をインストールし、ヘテロジニアス（非対称）マルチコアプログラミングを実践することが可能です。もちろん、この重たい linux 環境は PS3 SDK よりプログラムは面倒ですが、通常の PC はヘテロジニアスマルチコアを搭載していませんから、そこに選択肢はありません。幸いにも、私達は、 SPURS のような特殊なライブラリを除けば、全てのツールチェーンを得ることができます。

今にして思えば、Power Mac G5 のような PowerPC マルチコアは、非常に価値があります。

マルチコアプログラミングを探求するには、労働時間だけでは不十分です。私は、研究開発段階でもっともっと研究しておくべきでした。今、私達のチームは、研究開発段階を終了し、製品の開発に入っています。それは、良いですが、私自身は、もっとトライ＆エラーのための時間を必要としています。自宅の PC はそういったことのために多少役に立つでしょう。

多くのエキスパート開発者は、ゲームにおけるマルチコア並列処理の道を見いだしています。しかし、私はまだ、そのような段階に至っていません。

Is little endian or big endian?

ターゲットマシンがリトルエンディアンか、ビッグエンディアンかを自動でチェックする面白いコードを見かけました。

bool isLittle()
{
 unsigned int val = 1;
 return *((unsigned char *)&val);
}

もしマシンがリトルエンディアンなら、 val はLSBから順にメモリに格納されます。そのアドレスの値を読み取る事でリトルエンディアンかどうかを判定するという方法で、仕事で使うには少し薄気味悪いですが、フリーのライブラリに含めておくにはぴったりのコードだと感じられました。というか実際にフリーのライブラリで見かけたんですが。 (^^;

導入者に設定を返させたり、定数をあれこれさせるよりすっきりしていると思います。