［GDC 2010］高品質なゲームはこうして作られる，Blizzardの「StarCraft II」の開発で使われているQA手法を見てみよう

Blizzard Entertainment Senior Graphics Engineer Dominic Filion氏

　GDC 2010が開幕したのは3月9日なのだが，実は前半2日間はサブイベントが多く，GDC本編の開幕といえるのが，本日（現地時間3月11日）からだ。
　その11日最初のセッション群のなかから，Blizzard EntertainmentのSenior Graphics EngineerであるDominic Filion氏が，「Designing for Performance, Scalability ＆ Reliability：StarCraft II's Approach」と題した講演を行ったので紹介してみたい。演題から分かるように，主にプログラムの質的向上をいかに計るか，というのが主旨となっている。


　講演を始めるにあたり，氏はBlizzardがゲーム開発で核と考える三つの要素について語った。それは，

• Game Play First
• Commit to Quality
• Think Globally

の3点だ。これらがゲームエンジン開発で，どのような意味を持つかについて，氏は「よくできた先端技術は魔法と区別がつかなくなる」というアーサー・C・クラーク氏（SF作家）の言葉を挙げて，魔法のように目に見えない技術で支えることがゲームエンジンの役目であるとした。
　クオリティを保証することは，単にQA担当者だけの問題ではなく，開発者全員がQAを担当する必要があり，さらに「20％の部分が残りの80％の部分のクオリティに大きな影響を与える」というパレートの法則を持ち出して，最初にゲームエンジンのパフォーマンスを上げておくことの重要性を説いた。
　またグローバル展開について，PCには非常に多くの種類があり，海外展開するには多くのPCで動き，かつスケーラブルに性能を発揮できるゲームが重要であるという。

　これらの課題に対するアプローチで，まず重要になるのは，パフォーマンス測定である。まあ，計れないものは改善できないというわけだ。
　パフォーマンス測定目的のツールというのもいろいろ存在するのだが，氏は，サードパーティ製のツールでは，厳密にはリアルタイムではなかったり，細かい情報を取っているとパフォーマンスが落ちたりなどの問題があるため，自社製のツールを作ることを勧めていた。
　実際にどのような情報をモニタリングするのかについては，

　　モデルデータのレンダリング時
　　パーティクルの演算時
　　表示されているユニット
　　その他

などがあるとしている。どのようなデータを取るかでは，

　　タイムスタンプ
　　イベントの型
　　ファンクションID

を可能な限り取るのが望ましいようだ。
　計測精度についての話では，PCの場合は，アセンブリ言語のrdtsc命令（実行クロック数を測定する専用命令）を使うのが正確だが，この命令自体が200〜300クロックを要するので注意が必要だとしている。

　そんなこんなで，例としてBlizzardで実際に使われているツールが紹介された。「StarCraft II」のゲーム画面にオーバーレイして，ゲーム内の情報を表示できるモニタリングツールだ

ゲームを起動して負荷をモニタリング中	急激な負荷がかかっているスパイク状の部分を重点的に改善していく
状態をグラフィカルに表示している	中央部の拡大図
右側の拡大図	さらに細かく調べていく

　負荷などのグラフが中央上に表示され，真ん中にはその処理の所要クロック数などが細かく表示されている。右側にあるのは負荷などを関数ごとに帯グラフにしたものと，関数リストである。左側には，誰が呼び出した処理かが並んでいる。
　あちこちをクリックすると，より詳細な情報に遷移していく感じで，負荷のかかっている部分を簡単に掘り出していけるインタフェースとなっている。急激に負荷がかかりグラフが棘のようになっている部分に注目して，そこを掘り下げて原因を究明するというのが基本的なアプローチとなるようだ。
　ボトルネックになる関数には，負荷の高い関数と使われすぎな関数の2パターンがあるとして，それぞれへの対策，急に負荷が高くなるケースおよび常時負荷が高いケースへの対策などの知見が披露された。

　実に良くできている。クオリティの高いソフトを作るには，こういった高機能なツールが必須となるのだろう。


　続いて，スケーラブルなエンジンを作るための基本的な考え方などが示された。まず，ハードウェアの進歩は非常に速いペースで進んでいるので，スケーラビリティのあるエンジンが求められていること，しかし，その一方で古いマシンは厳然として存在しており，高速CPU用にマルチスレッド対応などを進めるとともに，無駄のない高速なコードを書くことは，現在でも最重要な事項になっているという。
　メモリ使用量についても注意が必要で，とくにメインメモリ搭載量の少ないPCでも問題なく動くようにするには，テクスチャの圧縮などが求められているとしている。MIPMAPを落とすだけでテクスチャを75％にできるほか，とくにUV情報の密度を最適化することが効果的なようだ。
　Blizzard製のメモリの状況を示すツールでは，どの関数がどれくらいのメモリを使っているかが，グラフとなって図示される。メモリ空間のフラグメントの状態も確認できる。

オブジェクトをたくさん出して負荷をかけているところ

　信頼性を高めるための方策としては，モニタリングなどのノウハウが示された。まず，どういう状況で不具合が起こるかを特定するため，ある種チートツールのような，様々な状況を自由に作り出せるものを用意し，障害の再現性を高めることが必要になる。ゲーム側でログを残し，どのような状況で障害が起こるかのデータを蓄積していくことも重要になる。

　関連したツールの例では，StarCraft IIの広いマップ上で，どこに負荷が集中しているかなども図示され，レベル設計などに活用できるようになっている。
　実例としては，パフォーマンス比較をしたグラフが示された。グラフは，縦軸がfpsで，StarCraft IIのビルドの違いごとに，様々な状況に対してのデータが表示されている。明るめの水色が，最新ビルドだそうだ。

　PCには非常に多くの種類があり，構成や性能もそれぞれ違ってくる。「うちの会社の，このPCでだけは素晴らしく良く動く」では意味がない。ハードウェアの性能に合わせて，ゲーム側で処理を変えることは，スケーラビリティという意味でも重要な処理となる。ということで，Blizzardでは，80種類以上のグラフィックスカードのプロファイルが用意されており，それぞれのクラスに合わせた処理を行うようにしているという。

　講演内容とはあまり関係ないのだが，途中に出てきた1枚のスライドが興味深かったので，ちょっと寄り道してみよう。

　これはBlizzardが実際のゲームで，GPUごとのデータを取って調べたものであり，実際のゲームでのパフォーマンスの指標としては興味深いデータである。まあ，こういったものは新製品，上位製品ほど性能が高いのは当たり前だが，どのあたりまでが実用上問題がないのか，他社製GPUとの比較ではどうかなどが，ごくざっくりとではあるが把握できる。
　見ると「Ultra」とされているのは，GeForce 9系の上位，200系，Radeonでは4000系の上位，「High」だとGeForce 8系の上位からGeForce 9系の下位，Radeon X3000系上位から4000系の下位，「Medium」だとGeForce 7系の上位からGeForce 8系の下位，そしてGeForce8M/9Mのモバイル系もMediumとなっている。Radeon系では，X1000の上位からX3000の下位まで。GeForce 7の下位，Radeon X2000シリーズの上位（Ultraを除く），Intel GMAシリーズは「Low」となっている。
　具体的に，どのあたりが「上位」「下位」なのかについては，いちばん左のリストで製品ごとに示されているのだが，データの一部しか表示されていない。ぜひ全リストを見てみたいところだ。

　思えば，StarCraft IIにしても「Diablo 3」にしても，十分動く状態で公開されてから，かなり時間が経つわけだが，このような手法によってブラッシュアップが進んでいるものと思われる。単に面白いゲームを作るだけではなく，それをいかにより多くの環境で快適に動作させることができるかに重点を置いた開発姿勢は，高く評価されるべきだろう。
　そして，その過程で生まれた最適化が，さらにゲームの可能性を引き上げ，＋αの処理を行う余地を生み出す。QAと最適化関連の比較的地味めな話題ではあるが，Blizzardが実践している開発手法の公開とあって，会場は非常に多くの人で埋め尽くされていたのが印象的だった。

ログモニタリングの結果をHTML出力している例