［CEDEC 2008＃12］Unreal Engineの生みの親Tim Sweeney氏が語る2012年から2020年にかけてのゲーム開発環境とは

　CEDEC 2008最終日に「GAME DEVELOPMENT 2012-2020」と題して，2012年から2020年にかけてのゲーム開発状況を大胆に概観してみせたのが，FPS「Unreal」およびUnreal Engineシリーズの主要開発者として知られるTim Sweeney氏だ。
　Tim Sweeney氏といえば，2006年にプリンストン大学で開催されたSymposium on Principles of Programming Languages 2006（POPL 2006）で次世代のプログラミング言語に関する講演を行って話題になっていた。今回の講演も，この講演での考察とかぶる部分がかなりあるので，未見の人はスライドをダウンロードして眺めてみるのもよいだろう。

Tim Sweeney氏が手がけた歴代Unreal Engineの概要

2008年現在のゲーム開発状況

　2012年から2020年にかけてのゲーム開発はどうなるだろうか？　というのが今回のテーマなのだが，まず現状のゲーム開発現場はどうなっているのかの確認が行われた。例として挙げられたのは，「Gears of War 2」の開発状況だ。
　Gears of War 2は，プログラマ15人，アーティスト45人，開発期間は2年で約13億円の予算で作られている。Unreal Engine 3を主体に，20種類ほどのミドルウェアが使われ，各機種用のプラットフォームライブラリが使用されている。コード量は，ゲーム本体でC++を中心に25万行程度，Unreal Engine 3部分だとC++で200万行程度になるという。最初は小さなチームで始めたものの，途中で人員がかなり増えたとのこと。
　ちなみに，プリンストンの講演ではUnreal Engine 3のコード量は25万行とされていたのだが，2年半で8倍に膨れ上がっている。
　それはともかく，現在の最先端レベルのゲームとしては，まだ人員も少なめなほうではないだろうか。これが，今後のゲーム開発環境ではどうなっていくか，それが問題となる

2012年から2020年にかけてのハードウェア

　では問題となる2012年から2020年にかけてのハードウェア状況を想像してみよう。Sweeney氏は，i80386あたりからのCPUの発展を追ってみせた。486でキャッシュが搭載，Pentium IIIで実数ベクトル演算器とSSE（インターネットストリーミングSIMD拡張命令）が追加され，マルチコア化，そしてメニーコア化の流れで現在に至る。プログラム実行は当然として，ベクトル演算の強化と高並列化が進化の方向となっている。
　GPUでは，3dfxのVoodooあたりから本格的なPC用3Dチップが展開していく，ピクセルシェーダの搭載，さらに高機能なシェーダとC言語サポート，そしてLarrabeeでのCPU複合型GPUへと至る。高並列化は当然として，ベクトル演算の強化とプログラマブル化が進化の方向となっている。
　要するに，CPUとGPUのアーキテクチャは収束しつつあるとSweeney氏は語る。2012年から2020年にかけて，CPUとGPUを統合したアーキテクチャが登場しうるとしている。

2012年から2020年にかけてのプログラミング事情

冒頭で掲げられた構造化プログラミングの提唱者ダイクストラの言葉。Tim Sweeney氏は，とにかく大事なのは，いかにヘマをしないようにするかだという

　以上のような前提を踏まえ，Sweeney氏は，2012年から2020年にかけてのゲーム開発の状況を，プログラミングとグラフィックスの両面での課題，そして対応法などを示し，さらに考察を加えていった。

　将来的には，コア数がたくさんになることが既定路線となっているのは周知のとおり。
　それとともに，プログラマの生産性を上げることが重要だと説く。Epic GamesのCEOでもあるので経営的な視点を含むのも当然ではあるが，作らなければならないものが2倍になっても開発費は倍になったりしないから，生産性を上げていくことが必須であるとする。ゲームの世代が進むごとに，作業量は指数関数的に増大するものの，投入できる人員や予算は，せいぜい線形にしか増えていかない。

　「マルチスレッドのプログラムを書くには，普通のプログラムの2倍のコストがかかる」というのは，Sweenwy氏がよく語っていることだが，PLAYSTATION 3のCellだと5倍，GPUだと10倍のコストがかかるとしている。つまり，マルチスレッドのプログラムをいかに簡単にするかが，今後のゲーム開発での重要な問題ということになる。先に挙げたPOPL 2006での講演もそのあたりの問題意識に根差したものといえるだろう。

●共有ステートによる手動並列化
　現在の一般的なマルチスレッドプログラムでは，データ書き換えにセマフォやMutexといった仕組みを使ってデータの一貫性を保つのだが，それらの多くは手動操作であり，誰かがちゃんとやらなかったらデッドロックする（当たり前）危険があるほか，ちゃんとやっているように見えても，2個のオブジェクトをA，Bの順にロックするプログラムと，B，Aの順にロックするプログラムが同時に走っているとデッドロックの危険があるなど，マルチスレッドでのプログラミングには目に見えない落とし穴も多いものだ。
　とはいえ，現状で多くのソフトウェアが，工夫をこらしつつマルチスレッドで作られているわけだが，Sweeney氏にとっては「難しすぎる」というのが結論のようだ。現状，そして今後のゲーム開発では数十人という規模でコードを書くことになり，全員に高度なスキルを期待することはできないという。「我々はコンピュータサイエンティストではない」という言葉には，もっと誰でも使える仕組みを求める氏の気持ちが表れている。

●タスクごとの並列化
　また，機能ごとに担当するスレッドを分けるというのは，簡単で分かりやすいマルチスレッドの使い方である。描画用のスレッドやAI用のスレッド，ゲーム管理用のスレッドなどに分けて処理を行う方式だ。あまり効率はよくなさそうだが，Unreal Engine 3でも使われているという。しかし，この方式は4コアならまだなんとかなるとしつつも，どうやって50コアのCPUに適したプログラムを書けばよいかが問題だという。50個の処理要素となると，仕事を探していくのも大変だ。
　
●トランザクション処理
　マルチスレッドでのデータ競合などを解決する方法として，20年前からデータベースなどで使われているトランザクションという手法がある。これは同時多発的なデータ処理でデータの不整合が発生しないことを保証するような仕組みを持っている。トランザクションでは，複数のオブジェクトを更新していても，そのうちの一つでエラーなどが起こると，すべてのオブジェクトでの更新をアンドゥするようになっているので，不完全なデータ更新は発生しない。
　これは仕組みとしては十分使えるものではあるが，C++ランタイムでのサポートが必要なことや，可逆性のある処理にしか適用できないこと，利用すると30％ほどパフォーマンスが落ちるのが問題だという。最近なにかと話題の言語Haskellで採用されているほか，IntelのC++コンパイラでもサポートが始まったそうだが，Intel以外のプラットフォームでIntel Compilerが使える可能性はまずないので，一般的なCでのサポートを待つしかないようだ。とはいえ，非常に有効な方法なので，今後のマルチスレッドプログラミングでは多く使われるようになるだろうと氏は語っていた。

●メッセージパッシング
　データの書き換えを複数で行わず，データ自体にやらせることで，データの整合性を保とうというのが，メッセージパッシングによるデータ書き換え手法だ。オブジェクト間のメッセージのやり取りで処理を進める，わりと綺麗な方式である。ただ，すべてをそれで動かそうとすると，数千のプロトコルを書かねばならず，データの整合性が完全に保証されるわけではないので，どこかでデータの同期を行わなければならないという問題は残ってしまう。
　

●純関数的プログラミング
　純関数的なプログラミングは，関数の戻り値を順につないでいくプログラミング手法だ。関数というのは，引数（複数でも可）をもとに返り値（一つの値）を返す仕組みで，複数のものを変更することがなく，結果を持った計算しかできない。衝突判定などでは，ベクトルデータやジオメトリなどをもとに，衝突したか否かだけを返す処理を行う。判定処理そのものではジオメトリなどを変更することもなく，ほかの部分にも影響しないので並列化も容易だ。純関数型処理は，こういったものには非常に有効である。しかし，ゲームプレイ自体のシミュレーションでは，刻々とオブジェクトの位置や状態など多くのものを書き換えながら進行していくので，純関数型プログラミングでは対応できない。ただ，前述のような副作用のない関数であれば，下位計算は並列化できるのでマルチスレッドに向いているとしており，将来的な展開次第では，純関数型プログラミングに期待を残しているように思われた。

　以上，これらのアプローチすべてが十分でないというのが氏の結論のようだ。単にダメというわけではなく，得意分野があるので，それを生かして使うのが重要だという。
　会場からの質問で，C++に代わる言語はあるかといった問いがなされたが，現状のところ，C++に代わるものはないというのが結論だ。新しい言語が主流になるには時間がかかり，現状でまだそういった動きが見えないことから，なにかが取って代わるとしてもかなり先のことになるという見通しのようだ。
　氏は，C++でマルチスレッド処理を書くのは，アセンブラでプログラムを作るようなものだとしつつも，次世代ゲームの開発とはいっても，開発には時間がかかるので，現状で使えないものは選択肢にならないと語っていた。

●ベクトル化の流れ
　多くの演算を一発で行うベクトル演算について，Sweeney氏は非常に効率的だと語った。とくに，GPUでのベクトル処理については，演算を一括で行うことよりも，ベクトルでメモリアクセスできる，しかも16個の違ったアドレスから一気にデータを取ってこれるということを高く評価していた。かなり以前から，CPUにもSSEのようなベクトル処理は組み込まれていたのだが，データをバラバラに取ってくることができなかった。しかし，次世代のベクトル処理では，CPUでもそういったデータアクセスが可能になること，さらにループ処理を簡単にベクトル処理に置き換え可能なことなどで，Larrabeeを絶賛していたのが印象に残った。

　
　以上をまとめ，それぞれの並列化手法の長所短所などから，ハードウェアアクセスは並列化せず順次処理で，ゲームワールドの状態管理はトランザクションで，シェーダなどは純関数型プログラムで，物理演算や衝突判定などはベクトル化でと，ゲームのレイヤーごとに適した手法で対応することで，最大1024倍の高速化が可能になる場合もあると話をまとめていた。
　

2012年から2020年にかけてのグラフィックス

　これから先のグラフィックスについて語る前に，2008年現在の状況を氏は簡単にまとめた。曰く，

　　大きなフレームバッファ
　　複雑なパイプライン
　　ほとんど固定機能

といったあたりがご不満のようだ。
　シェーダは，もともとグラフィックス処理を連続的に行うことを目的として作られており，ランダムアクセスを苦手としている。汎用的なプログラムを書くには，これが障害となっているようだ。
　また，GPUがプログラマブルであるのは確かだが，それをあえて「固定機能」的と呼んでいた。シェーダ自体はともかく，パイプラインがきっちり決まっているので固定機能のようなことしかできず，結果としてどのゲームを見ても同じようにしか見えないという。また，こういった固定機能だと，仮にシェーダが20倍の性能になったとしても，見た目的には2倍も綺麗になったりはしないものだと氏は語る。まあ，同じようなゲームに見えるのはゲームエンジンの責任って気はしなくもないのだが。
　さらに，MSAAの品質にも不満があるようだ。実際，SSAAと比べると，アンチエイリアスされてない部分が明らかに残るので，手抜き処理ではやはり限界はあるということか。


　こうしたことを踏まえて，将来的には，ソフトウェアレンダリングのほうがよいのではないかというのが，氏の意見である。もともとUnreal 1はソフトウェアレンダラで書かれており，かなり高品質な描画を実現していた。当時は，1ピクセルあたり16命令しか実行できなかったが，近い将来の4TFLOPS GPUでは1ピクセルあたり1万6000命令を利用できる計算になる。これくらいあれば，レイトレーシングやPIXERで使われているREYESといった手法も使えるのではないかと，氏は見積もっているようだ。ここでいう4TFLOPSが積和演算で水増しされていることを割り引いても，だいたい1万命令（命令というか操作）は可能だろうと見込めるので，プログラムの作りやすいGPUで，全部ソフトウェア処理で，という意見は，そう的外れなものではない。
　ただ，DirectXもOpenGLもバイパスして直接描画したいといった言葉も出ており，ちょっとそれは互換性面で問題がありすぎではないかとは思われた。まあ，Epic Gamesは今後PCハードウェアへの対応に消極的な姿勢を見せているので，仕様の固定されたコンシューマ機以外は作るつもりがないという意思表明にとれないこともないか（？）。


　ちなみに，REYESというのは，オブジェクトをサブピクセル単位まで細かい三角形ポリゴンに分割して扱う描画方法だそうで，三角形パッチにはフラットシェーディング（単色塗りつぶし）だけが行われるのだという。「シェーダ」とかいう概念とは対極にあるアルゴリズムだ。テクスチャマップなどといった，マッピングという概念も存在しない。テクスチャはパッチの色を変えればよいだけだし，バンプなどは，その形に沿ってパッチを作っていけば必要なくなる。ものすごく単純な処理をものすごく大量に行い，出力は自動的に，完全にアンチエイリアスされたものとなる。並列ハードウェアには適しているので，確かに面白い考え方である。
　
　氏が1998年に作ったUnreal 1では，ソフトウェアベースのタイルレンダラが実装されていたのだそうだ。
　タイリング方式は，画面の一部ずつを効率的にレンダリングしていく手法で，ハードウェア実装のものでは小容量の高速キャッシュを駆使して，小規模のハードと少量かつ低速メモリでも効率のよいレンダリングが実現できることで知られていた。以前はPowerVRなどの製品で実用化されたものの，高速メモリを大量搭載かつ力業のバス高速化など，コスト度外視のGPU進化の潮流によって表舞台からは消えていった方式である。AMDなどは携帯用GPUで利用している。
　Sweeney氏のアイデアは，タイルベースの処理を超並列で行うというものだ。確かに処理単位はシンプルなので高並列も簡単そうで，最初から分割実行が前提なので，そのままスケーラブルに拡張できそうだ。タイル方式自体は分割して画面を描くので，単一方式より効率が悪くなることがあったとしても，並列度で簡単に取り戻せる。氏のアイデアは，これをソフトウェアで実装するというもののようだが，現状のハードウェアトレンドに合致するのみならず，結構簡単にできそうなので，どっちかというとハードベースでどこかに本気で取り組んでみてほしいアイデアである。


　いろいろ試してみた結論として，氏は，とにかく生産性が第一だと語る。そのためには，ミドルウェアやゲームエンジンが有効だと語る。ゲームエンジンメーカーのCEOなので，そのあたりを強調するのも当然といえば当然ではあるが，Epic Games自身，ミドルウェアメーカーであると同時に，20種類以上のミドルウェアを利用するヘビーユーザーでもあるという。前述のGears of War 2のプログラマ数が15人程度というのは，あの規模のゲームとしてはかなり少ないほうではないかと思われるのだが，これも適切なミドルウェアを活用することで高い生産性を挙げているのだという。
　また，真に必要なのは，とにかく簡単に使えて高速なハードウェアで，現在のシェーダやCell，GPGPUプログラミングなどは複雑すぎて採算があわないという。ハード業界にいいたいことは山ほどあるようだったが，ゲームエンジンム開発者としては，ハードウェアの潮流を見きわめて，動くことが重要だと説いた。
　確かにUnreal Engine 3が発表された頃は，あまりにハイスペックな仕様に驚いたものだが（当時はXbox 360もPLAYSTATION 3も発表されてなかった），当時の「次世代機」での需要に見事にマッチし，150本以上で採用されるという成功を収めた。エンジン開発には5年くらいはかかるので，やるならいますぐ始めなさいと講演をまとめていた。


　CPUとGPUの境界が曖昧になり，さらなる汎用化と高並列化を遂げようとしている。氏が，Larrabeeにご執心なのは，講演の流れを見てもだいたい察せられるところ。Unreal Engine 3の開発時には，途中でインテルがマルチコア路線の展開を打ち出したり，各プラットフォームともマルチコア路線のため，マルチスレッド対応にはとことん泣かせられていたようだが，メニーコアは大歓迎のようだ。はたしてソフトウェアレンダリングへの回帰は起こるのか？　少なくとも今後の10年間でもゲームの進化はまだまだ止まりそうにない。