遅れましたが3日目。まずは1コマ目から。
え、基調講演？
ネット上で記事を見かけた人いますか？つまりそういうことなんです。
1コマ目はEpicのTim Sweeneyによる未来の技術についてです。これからの10年とか言ってましたが、2012年から2020年くらいの予想の話です。
Timは初代Unrealエンジンの製作者です。彼はUE3は2012年まで使用され、それからはUE4になると予測しているようです。
GoW2の開発人員としては、PGが15人。VAが46人。2年1200万ドルをかけており、C++コードは25万行とのこと。ただ、エンジン開発者も人員として数えているかどうかは不明です（多分数えていない）。
ハードウェアのこれからの10年ではCPUとGPUが統合されると考えています。IntelのLarrabeeとNVIDIAのGeforce8のアーキテクチャは似通ってきており、これはいずれ統一されるだろうとのこと。
コアの数はどんどんと増えていき、扱えるベクトルの幅も増えていく。多少のグラフィック機能は固定で残るものの、ほとんどはプログラマが書くようになるだろう。
現在でも7コアのプログラムを書くのに必死になっているが、10年後には50コアのプログラムを書く必要が出てくるかもしれない。マルチコアプログラムを簡単にしなければ貴重なプログラマの時間は減っていくばかりだ。
UE3ではタスクの並列化にマルチスレッドを使用している。しかし、同期は手動で行っており、正確性をコンパイル時に検証することは不可能です。コードは数十人で書く。
とにかく大量のコアに対応しなければならない。そのためには同期をとる手法を考える必要があります。
手動同期はオブジェクトを使う前に必ずロックすることから始めます。ただし、デッドロックやデータ競合の問題があり、デバッグが大変です。
メッセージパッシングの場合、オブジェクトは自分自身しか更新できず、他のオブジェクトへは変更メッセージを送ることしか出来ません。
各オブジェクトはかなり多くの（千以上）のメッセージプロトコルを書く必要がありますし、ある程度の手動同期を必要とします。
ソフトウェアトランザクショナルメモリはUNDOのような手法です。
スレッドはトランザクションブロックで動作し、処理としてはローカルメモリのみ変更可能です。
同じデータを変更しようとするような複数スレッドからのアクセスがあった場合はロールバックし、そうでなければグローバルを更新します。
コードに副作用があってはいけない、速度の30％が犠牲になる、C++ランタイムのサポートが必要になるなどの問題点があります。
で、このマルチスレッドプログラムを簡単にするには純関数型言語を使うのがいいとのこと。あんまり聞いたことのないものですが、どうやら定数と関数で処理する言語のようです。つまり変数がなく、代入もない。
たとえば a=b+c という代入文はよく見かけると思いますが、b, c, +という関数の3つがわかっているならわざわざaに代入する必要もないだろうということ、らしい。
純関数型言語の関数は副作用がなく、任意の順序で実行することが可能です。それゆえ、マルチスレッドに向いている、というわけ…らしい。
また、変数や処理のベクトル化も必要になります。C++コンパイラはスカラコードを生成しますが、GPUシェーダコンパイラはベクタコードを生成します。
ループや関数呼び出しをベクトル化できれば性能向上の可能性が広がります。
話は変わってグラフィックですが、現在のシェーダプログラムにはいくつかの制限があります。
ランダムなメモリ書き込みは出来ませんし、データのトラバースも出来ません。
結果としてすべてのゲームが同じようなグラフィックに見え、小手先の工夫で違いを出さなければいけない状態です。
次は100％ソフトウェアレンダリングとなる、と予想されていました。CPUとGPUの統合もそれを後押しするでしょう。
つまり、ハード側に設定されているレンダリングパスとは別のパスを作り出すことが可能になる、ということなのかと思います。DirectXなどがいきなりなくなるってわけではないでしょうけど。
将来のグラフィック技術としてはいくつかの候補があります。
レイトレーシングは昔からいつかは来るんじゃないかと言われていた代物ですが、次には来る可能性もあります。メニィコアとの相性はいいものの、全体的な効率は決してよくないものです。
ピクサーが使っているREYESレンダリングモデルも候補の1つで、モデルを微小三角形で形成する手法です。つまり、三角形1つが1ピクセルに対応するように分割するというわけ。
この利点としては、ディスプレースメントが簡単に実現できる、テクスチャが不要、400万ポリゴンのモデルが法線マップを使用せずに描画できるようにもなります。
ただし、高度なLODが必要となります。
ボリュームレンダリングも候補の1つ。ボクセルレンダリングを直接行うことが出来るようになる…かも。
あとはソフトウェアタイルレンダリングとかいくつかの複合レンダリングとか指摘されています。
しかし、これによりゲームごとに違う映像が作られるのかどうかというと…そんなこともないんじゃないかと私は思うんですけどね。
では、これらの技術をどのように勉強していけばいいのでしょうか？
とにかく生産性を上げればいいのですが、そんなにうまくいかないのも現実です。
ハードの性能が20倍になって開発難度がそれくらいに上がったとしても、予算はせいぜい2倍がいいところです。それすら無理かもしれません。
生産性を上げるには性能を犠牲にする、ハイレベルなプログラミング（C++はすでにローレベルだと）、簡単に使えるハード、凄いツールが重要になります。
とにかく、現在のハードウェアは難しすぎる。あんたが言うなとツッコミたい気持ちもありましたが、コストを低下させるには、ということなのでしょう。それでも困りものですが。
今までの環境と比べると、マルチスレッドのコストが2倍、PS3のコストが5倍、GPGPUとなると10倍かそれ以上となるだろうとのこと。2倍以上は大半の会社にとっては大きすぎるリスクです。
UE3は3年で開発しましたが、次は5年はかかるだろうと見積もっていました。今からやっても2013年出荷。今からやらなければ遅いのです。
とにかく、今後も大きな変革があるとのこと。今の仕事を考え直さなければ10年は生き残れない。…きついな、おい。
質問はいくつか興味深いものを書いておきます。
まず、開発環境とかは誰に期待すればいいのかという質問ですが、ハードウェアベンダー、ツールベンダーはEpicも含めて色々あるのでその辺に期待するのがいいのでは、とのこと。期待できるのかな？
フレームレートや解像度は2012年の段階では変わらないんじゃないかとのこと。
メインメモリはPS3みたいな歪な構成はこれからは無理。すべてのコアからすべてのメモリが同時にアクセスできるような状態じゃなきゃダメ。
C++はすでに限界が近い。マルチスレッドには向いていない。でも、言語が成熟するのに5年くらいはかかる。そして、現在C++に取って代わりそうな有力な言語もない。まだまだC++でやらなきゃダメだろうな、とのこと。
2コマ目は『ソニックワールドアドベンチャー』のグローバルイルミネーション（GI）の話です。
海外では『Sonic Unleashed』という名前になっていますので、そちらで覚えている人も多いかもしれません。まだ発売してませんが、年末か年始くらいには発売予定かな？
このゲームではGIが静的オブジェクトと動的オブジェクトに適用されています。
静的オブジェクトに対してはライトマップに近いやり方で実装されています。つまり、GIテクスチャを用意してそれと合成するというだけです。GIテクスチャは事前計算を行います。
当初、サンプルとして作成した500m*500mのマップでは100MBのテクスチャが必要となり、計算に2日かかっていたそうです。
ソニックは秒速100mで走るらしいので、実際のマップは1ステージ15kmくらい。テクスチャは1GB程度になるものも出てきそうだし、計算時間にいたっては数ヶ月かかる計算。
当然現実的ではないため、分散コンピューティングを利用して全員の作業用マシンを少しずつ使って計算するようにしたそうです。これにより、時間は数10?100分の1程度にまで低減したそうです。
とはいえテクスチャサイズはどうしようもないので、これはストリーミングで。BGMのストリーミングは出来ないので、こっちをオンメモリにしたそうです。
この際の問題としては、360で実際のテクスチャ容量より大きなサイズのメモリが取られている問題が1つ。これは360の仕様で、1枚のテクスチャはどんなに小さなサイズでも12kB使われるためでした。小さなテクスチャをやめて大き目のテクスチャに固めてもらうことにして回避。
ファイル数もそのサイズも大きすぎてサブバージョンでの管理が無理になった問題は社内ツールで対処。
PCと360とPS3の数を増やしたらブレーカーが落ちたらしい。会社でブレーカーが落ちるなんてうちではないですね。
一番のリスクはデータサイズが大きいため、組み込みに時間がかかること。この部分に関しては改善できていないようです。
かなりしんどい作業ながら、確実にいい絵になるためVAの士気が高いのが利点だそうです。
動的オブジェクトへのGIは簡単なもので、ゲームフィールド上にグリッドを置いて、その交差点に色をつける方法を取っています。
この時、色は6方向を持っておき、キャラクタの位置と交差点の位置の関係から方向を見るようにしているようです。6方向ということは、TF2のシェーダでもやっていたキューブライティングっぽいやり方だと思います。
当然、より詳細な方向を持つためにSHとかを使うことも出来ますが、そこまでやらなくても十分な品質は出せるようです。とはいえ、出来ればやりたいって感じではありました。
GIの計算はレイを数千?数万本飛ばして計算しているようです。衝突回数は1回だけっぽいです。ここはレンダリングをするという方法もありますが（放射照度環境マップを参照）、反射を考慮する場合はレイトレースした方がいいと思います。
360とPS3の特徴と問題点についても少々語られています。
360はとにかくDVD容量が小さいこととHDD標準じゃないのが痛いとのこと。マルチスレッドもうまく活用できていない様子。ただし、メモリが自由に使えるのは良い点であるようです。
PS3は逆にHDD標準搭載、BDの大容量がありがたいようです。また、PlayStation Edgeを1.5人月で組み込んだそうです。かなり速くなるのでお勧めらしい。SPUはまだまだうまく使えるようになるんじゃないかと考えているようです。
今後の課題としては背景も動的なGIを導入したいのと、方向を持たせたいのがあるようです。
ちなみに、サンプルを360開発機（だと思う）で動かしていたのですが、1度フリーズしてました。もうすぐマスターらしいのですが大丈夫でしょうか？
3コマ目は射影を用いた関節角度制限方法についてです。後半はトポロジーに関する雑学ですが、理解できなかったので割愛。
この技術は『鉄拳6』のゆれもの（マフラーとか鎖などのアクセサリー）に使われているそうです。これらは物理シミュレーションで動くものですが、普通のキャラクタのIKにも十分使用可能です。
通常、関節の角度制限は親ボーンのローカル軸に対しての角度で制限します。この方法はわかりやすいのですが、回転順番によっては角度の制限範囲が限定されてしまいます。
例えばヒジは90°以上曲げられますが、回転順番次第では曲げられなくなる可能性があります。
まず、子ボーンの根元（親ボーンの先端）に球があると考えてみてください。子ボーンが動くとこの球と子ボーンの交差点が動くわけですが、角度を制限する場合、この球に矩形等を貼り付けてその範囲内を点が移動するように見えるはずです。
で、90°以上曲がらないということはこの範囲が球の前方にしか存在しないということです。
この範囲を特異点を1つとした範囲に広げることが可能です。それが平面への射影になります。
射影平面λを s,t で表した場合、s=-z/(x+1), t=y/(x+1) となります。これだと特異点は x=-1 の時となり、これは親ボーンと子ボーンが重なった時の状態となります。
角度の範囲を球面上の点の範囲に変更し、これを平面上の範囲に変換できれば問題ないというわけです。
あと、色々と説明していただいたのですが、図や実例が多く使われたためにメモをきちんと取れていません。
スライド資料を見ればたいていの人はわかると思うので、そっちを参照してもらった方が早いんじゃないかと思ったり思わなかったり。
あと、質問で、クオータニオンの係数を制限する方法について聞かれていました。この方法だと球の裏面がおかしな形状になりやすいみたいです。
クオータニオンの係数を制限する方法は私もよくわからないので、今度調べてみようと思います。
4コマ目。最後はフロムソフトウェアの『NINJA BLADE』チームによるFlashを使ったゲームUIのお話。
ここで言うゲームUIはHUDやメニューの事を指します。
良いUIを作るには、とにかくトライ＆エラーが大事。そのためには作りやすい環境が重要です。っていうか、それはUIに限った話ではないんですがね。
フロムでは元々自社開発ツールを使っていたようです。しかしこれだとレイアウトやアニメーションは作れても、アニメーションの遷移（ボタンを押された時にどうなるかとか）ができない、全体の動きを確認できない、フェードイン・アウトが出来ない、新規データはPGの手を介する必要があるなどの問題がありました。
そこでこのプロジェクトでは、途中からScaleformGFxというツールを使用したそうです。
このツールはFlashで作成したデータをゲーム機上、およびPC上で確認でき、ベクタフォントなんかも使えるスグレモノ。アクションスクリプトにも対応していて、MGS4で使ってた自社コンバータを凌駕する機能を有しているようです。
このツールを導入したことで、全体の確認をプログラマを介さずに確認できるようになり、デザイナとしてはかなり助かったようです。
デメリットはFlashの導入コスト、および学習コストです。ソフトは買わなければいけないし、学習も必要となります。
ただ、購入についてはどうしようもないものの、学習については本もWEBもたくさんあるのでそれほど困らないでしょう。ただし、Flashの一部の機能は対応していないので、その辺の学習も必要です。
ベクタフォントは解像度が変わっても綺麗に表示されるため、非常に便利です。問題はデータサイズ、描画コストですが、どちらもそれほど大きな影響を与えないようです。
ただ、他でGPUを圧迫しているとScaleformGFxの描画が重くなることもありますし、半透明の数、全体的な描画枚数なども注意が必要なようです。
全体のファイルサイズはSWFファイル（Flashのファイル）にすべてのデータ（画像データとか）を入れると重くなるので、汎用的に使われるものについては別途読み込む処理が必要になります。が、PCビューワは指定位置からのファイル読み込みにも対応しているため、ビューイングのコストは変わらないようです。
プログラマからしても利点はあります。トライ＆エラーを自分たちを介さずに行えるので勝手にやらせることが出来ますし、それによってプログラマの責任が低下します。
Flashの使用方法としては、公開されているSWFフォーマットを調べて自前のコンバータを作成する、SWF ToolsなどのSWFファイルからデータを引っ張ってくるツールを使う、ScaleformGFxのような実機上で動かせるツールを使うという3つが考えられます。
フロムでは時間と確実性の観点からScaleformGFxを選んだようです。このツール、それなりに実績があったりします。
GFxでは現在、ムービーとサウンドの再生が出来ないようです。ただ、2009年春のアップデートで対応予定だそうです。
このツールの問題点として、メモリの使用量が確定しない（メモリの確保・解放が頻繁に行われる）、動作速度が不透明などがあります。
制限もあって、Flashからゲーム、ゲームからFlashの通信には制限があり、高コストの処理もあります（メッセージ交換とか）。
また、忘れてはいけないことですが、GFxはワークフローを決定するツールではありません。役割分担はきちんとチームで行う必要があります。
で、今回のプログラムの役割の中にはメニューの振る舞いに関するいくつかが担当されていたりします。結局、このボタンを押したらどうなる？とかはプログラマの手を介する必要が出てきてしまうというわけ。
課題としてはまず、Flashとゲームの同期を保障しなければなりません。
例えば、体力を表示するバーがあったとします。このバーとキャラの体力は同期していなければなりません。
この場合の最も簡単な解決方法は、ゲームシステムがFlashに常に体力の現在値を渡すか、Flashが常に体力の現在値を要求します。
しかしFlash-ゲームシステム間の通信には制限があります。しかも前者の場合は体力バーが表示されるメニューかどうかをゲームシステムが知っている必要があります。
そこで使われたのが Observerパターン。知らない人はググってね。
つまり、体力などのゲームシステムからデータをリアルタイムで引っ張ってくる必要があるデータはすべて Observer を介して処理されます。ゲームシステムも決められた Observer にデータを送ればよいのですから混乱することはなくなるでしょう。
他には Mediatorパターンも使われています。これは、ゲームシステム上で色々やってる処理をPCビューワ用に書き直したものです。
例えば体力を取得しようとしても、PCビューワではそれが出来ません。ゲームシステムがPC上に存在しないんだから当たり前でしょう。
そこでPCビューワ用にダミーを作成し、Mediatorパターンを用いて実機とPCでの処理を振り分けるわけです。この辺の話は実装に絡む部分だけに参考にしやすいです。
ローカライズは今までとあんまり変わらないみたいです。フォントデータは別に読み込んで、文字列データの管理はEXCELを使って行います。個人的にもその方がいいと思う。
フロムの皆さんのアドバイスとしては、導入理由の共有、ワークフローの決定は確実にやっておくこと。夢を見るのはやめようなどとも言われていました。
あと、あまり関係ないですが、講演の手際が極めて悪かったですね。あの辺は何とかしてほしいです。
最後に全体的な感想。
講演自体は有意義なものが多く、非常に良かったと思います。
ただ、講演を予約なしにしたのはやはり問題があったのではないかと思います。
会場が十分に大きければ問題ないのですが、立ち見ですら教室に入れないような状況では予約はあったほうがいいのではないかと思います。
1つの講演が終了したら並ばなければならず、後で質問ということが難しい状況でした。
某氏と話をした時にそんなことを言ってみたのですが、やはりこれだけの規模の会場を見つけるのが難しいらしいです。
もっと金を積めば何とかなるんでしょうけど、さすがに難しいですからねぇ…。
ただ、定員なしの予約制ならライブシアターの設置とか事前に色々準備できるんではないかとも思います。
でも、楽しかったです。ほんとに。
