「鉄拳タッグトーナメント2」を60fpsで動作させるために開発者が知恵を絞ったポイント

本日2011年9月6日(火)より9月8日(木)までパシフィコ横浜にて開催されている、日本最大のゲーム開発者向けカンファレンス「コンピュータエンターテインメントデベロッパーズカンファレンス2011(CEDEC2011)」の一環として「2体から4体！？ ～鉄拳タッグトーナメント2における描画システムと負荷削減について～」という、2011年9月14日から全国で稼働を開始する人気格闘ゲーム最新作「鉄拳タッグトーナメント2」において使用されている描画システムと負荷削減(主に描画)について、描画プログラムのリーダーを務めたバンダイナムコゲームスの堂前嘉樹さんが講演を行ったので聴講してきました。以下に掲載する講演の全内容とスライドを読めば、現地で聴講した気分をかなりリアルに味わえるはずです。

プログラミング | CEDEC 2011 | Computer Entertaintment Developers Conference

◆はじめに

堂前嘉樹さんの講演「2体から4体！？ ～鉄拳タッグトーナメント2における描画システムと負荷削減について～」がスタート。

皆さんおはようございます。朝一のセッションで、しかも同じ時間帯に稲船さんのセッションがあると聞いてどれだけの人が来てくれるのかと結構心配していたんですけれども、こんなに来てくれるとはちょっと思っていなかったので非常にうれしく思います。ご紹介が遅れましたが、私、バンダイナムコゲームスの「鉄拳プロジェクト」でプログラマーを務める堂前と申します。よろしくお願いします。

本日は「鉄拳タッグトーナメント2」における描画負荷や描画システムについてお話をさせていただきます。時間があれば質疑応答とか、描画の手法の話とかもちょっとできればなと思っています。まず、「鉄拳シリーズ」について簡単にお話しさせてください。「鉄拳シリーズ」は、家庭用で全世界4000万本をリリースしているフランチャイズでして、格闘ゲームとしては世界シェアナンバー1のソフトになっております。近年もシリーズごとに400～600万本販売しており、コアなファンの方も結構いらっしゃいまして、開発する際にはとてもプレッシャーの高いゲームになっております。今回は、こちらの1番下の「鉄拳タッグトーナメント2」についてお話しさせていただくわけですけれども、こちらは来週の9月14日に全国のゲームセンターで稼働いたします。それに関連する話としまして重要なシリーズがいくつかあり、「鉄拳6シリーズ」の「鉄拳6 BLOODLINE REBELLION」という業務用のものにも関わり、その後は「鉄拳6」の家庭用をやっておりました。

で、「タッグ2」ということですので「タッグ1」があるんですけれど、「1」の方は1999年にリリースされております。ですので、12年ぶりのタッグ制のゲームっていうことになります。で、大事なことを言い忘れていた上に宣伝にもなってしまうんですけれど、先日から「鉄拳 ブラッド・ベンジェンス」っていう映画が上映されていますので、ぜひ足をお運びください。以上宣伝です。「鉄拳タッグトーナメント2」がどんなものかっていう動画をこれから流していきます。ご覧ください。

TEKKEN TAG 2 - Combo Exhibition - YouTube(会場で流れたムービーとは別の物です)


はい、こんな感じのゲームになっております。そこで、「鉄拳タッグトーナメント2」の技術的なセールスポイントをいくつか紹介させていただきますと、PS3の互換基板であるSYSTEM369というものを採用しております。前作の「鉄拳6 BLOODLINE REBELLION」の方ではSYSTEM357というものを使っておりまして、そのパワーアップバージョンの基板です。そういうこともあり、グラフィック系も前作より向上を図っています。「タッグ1から12年ぶりの続編」と先ほど申し上げましたが、タッグ制のシステムとなっているところが今回の1番大きなポイントですね。前作みたいな1対1の戦いではなく、2対2で戦うと。

ここで前作の「鉄拳6 BLOODLINE REBELLION」のスクリーンショットをご覧いただきます。もちろん1対1ですのでこういった感じの構図になります。

今回の「タッグ2」ですと2対2ですので、1人に対して2人で攻撃を与えているシチュエーションがあり得るわけです。

◆「鉄拳タッグトーナメント2」のプロジェクトが始動

ここで、「『鉄拳タッグトーナメント2』を作るぞ」という話が来た時の話をさせていただこうと思います。

時期的には、先ほど年表をご覧いただいてた「鉄拳6」の家庭用が終わった2010年の頭くらいなんですけれど、上の方から「次は『鉄拳トーナメント』の続編をやるぞ」という話が来ました。その時に描画システムを自分が担当することになっておりましたので、自分の感想としましては「4体も表示すんの！？」っていうすごくネガティブな印象を持っていました。まあ、正直ちょっとやりたくない仕事だなあと思いました。

これは自分の最初のイメージなんですけれど、タッグなので4人を表示しまして、しかもこの状態で処理落ちしない状態にしなければいけないという。これにはちょっと頭を抱えることになりました。

ここで「タッグトーナメント2」の話が来た経緯を説明しますと、簡単に言ってしまえば「鉄拳プロジェクト」リーダーの原田の命令というか指示なんです。前作の「タッグ1」が非常に好評でしたので「やるぞ」という話になりまして。簡単に言ってくれたんですが、正直、開発期間中はずっと悩むことになりました。

具体的に何が心配かといいますと、まず1つ目としては「メモリ」のことです。先ほどちょっと触れたようにSYSTEM369というものを採用しており、前作からのパワーアップとは申し上げましたが、メモリ自体は「鉄拳6 BR」のSYSTEM357と同じなので、さらにキャラクター2体分のメモリを確保する必要があるということで悩みました。メモリというものはオーバーしてしまうと製品化できないので、ここら辺は非常に不安です。

続いての心配ごととして「描画負荷」というものがあります。単純に考えて2体多く描画する必要があると。キャラクターなので描画負荷は重くなりますから、それを2体追加ということで悩みました。当然、格闘ゲームというものは60fpsで動作させることが求められているソフトですので、そこら辺を考慮しつつ描画負荷を気にしなければいけない。

「タッグ1」の方はどんな感じで処理していたのかなと、前作を見てみることにしました。

こちらは下のキャラクターが上のキャラクターを持ち上げて発動するコンビ技で、カメラが切り替わってから相方が突っ込んできます。この時点で、下の持ち上げていたキャラはもう見えなくなっているわけです。そのまま相方が突っ込んできてキャラクターが完全に入れ替わり、2体分表示してるってことになります。

自分は当時のプロジェクトに参加していなかったので、先輩方にどんな感じでやっていたのかと改めて聞いてみました。すると、先ほどご覧いただいたように、タッグ技の最中もカメラアングルを切り替えたりして巧みに2体分のみを表示するようにして対処していたと。

それを聞いて、今回も同じ対処でいいだろうと思ってとても安心しました。そのときは安心していたんですが、やっぱりちょっと甘い考えだなあってところに至ります。

実際にプランナーが今作で考えていたイメージはですね、先ほどと同じような感じで3体を表示していたり。これなどは1、2、3、4と4体分も表示すると。状況によってはこういうシチュエーションもあり得るぞということを言われました。

さらに、アーティストの方からもキャラクターのライティングの面とか、「Screen Space Ambient Occlusion(SSAO) 」を導入してくれだとか、そういった要望が自分の方に来ていましたので、絶対に何らかの対策は立てなければいけないなと考えました。

ここまでをまとめます。結局、何が不安だったのかと言いますと、まず「メモリが収まるかどうか」ということと「処理落ちせずに済むかどうか」という話になります。これから話すことは割と基本的なことが中心になってしまいますが、ぜひ最後までおつきあいください。

◆第1の不安「メモリ」

まずは不安の一つである「メモリ」についてお話をさせていただこうと思います。ビジュアル的なリソース、つまりキャラクターのテクスチャーやモデルデータとかを格納するローカルメモリ、俗称「VRAM」についての説明です。前作の「鉄拳6 BR」ではVRAMを割と余り気味に運営していたんですが、ちょっと不安な面もありました。

ここでは「鉄拳6 BR」の運営の流れについて説明していきます。ちょっと簡易的な絵ですけれど、こちらの左側がVRAMの領域になっていて、右側がキャラクターや背景とかのリソース、テクスチャーなどを大雑把に示したものになります。画面に描画するためにはそれらのリソースをVRAMに移す必要がありますので、どんどん移していきます。

まずキャラクターを移しまして、今度は背景を移します。

続いて、キャラクター2が必要になります。で、キャラクター2をこのように格納します。領域が一つなので順に頭から格納する形になり、これでひとまずゲームが進んでいくわけです。例えばキャラクター1が不要になりました、というような時はもちろんこのように開放して消してやり、別のキャラクター3が必要になった時はまたVRAMに移します。先ほどのこの場所だとサイズ的にちょっと入らないので2の後に置かれます。

つまりですね、ここの赤い部分が無駄になってしまうわけです。プログラマーの方ならご存じの状況ですが、こういうのは「メモリの断片化」が起きてしまうので、非常に無駄なメモリの使い方になってしまいます。

このように「鉄拳6 BR」の時代は「メモリの断片化」がおこりやすい設計になっていたので、キャラクターを読み込む順番やキャラクター自体のテクスチャーのサイズなどが重要になり、不具合も特定しづらくなっていました。例えば、コンティニュー画面では自分のキャラや背景はロードする必要がなさそうに思えますが、実際には自分のキャラや背景の読み直しが発生しており、読み込み時間の面で酷評を受けておりました。それでも「鉄拳6 BR」の頃はメモリが余り気味だったので乗り切れたのですが、今回はタッグということですので、VRAMがよりシビアになると想像できます。

対策を立てる必要があるので設計しました。仕組みとしては単純なんですけれど、VRAMを1つの領域としてではなく、ある程度大雑把な単位に分けてしまおうと。キャラクターの領域や背景の領域など、各領域ごとにロードするという形にしています。後で実際のサイズをお見せしますが、カテゴリのサイズ自体は前作の「鉄拳6 BR」の数値がとても参考になりました。

先ほどと同じ状況のこれを、このようにそれぞれの領域に分けてやり、またリソースを移します。

まずはキャラクター1をキャラ領域3に移し、背景は背景専用領域に入れ、今度はキャラクター3をキャラ領域1に入れたりと、そういった感じでどんどん格納してやります。

同じくキャラクター2をキャラ領域2に入れます。

先ほど断片化が起きた時と同じように、ゲーム中で必要になったから背景を別のものに差し替えたいという時は、背景領域から先ほどの背景を開放してやりまして、このように入れると。さっきとは違い、他の領域を汚さず安全に管理できるということがお分かりいただけるかと思います。

ここまでをまとめると、仕組み自体は単純とはいえカテゴリ分けをして良かったなと。キャラや背景などで、個々にサイズを気にする必要があったことが大きかったと思います。前作の場合はVRAMが足りなくなる問題が発生した時にも各担当が「どうせ他の要因で圧迫されているからでしょ？」と考えてしまって問題意識が薄くなることがあり、非常に危ないなと思っていました。今回も、テスト的にフルカラーのテクスチャーが使いづらいという難点はありますが、カテゴリ分けすることで問題意識の点などを解消できたので、分けておいてよかったなあと思います。

次に、メモリの各種状況からキャラクターと背景のみを抜粋してお見せしていきます。ここで注目していただきたいのがキャラクターの領域のサイズです。前作の時は19.5MB使えたのですが、今回は1体につき19MBとほぼ変わらない状況になってます。

今回も従来の「鉄拳シリーズ」と同様にキャラクターのカスタマイズがとても充実しており、こういった感じです。カスタマイズの一環として、キャラクターの服の色を変えたりする要素があります。

前作との比較で話を進めていきますが、これはアンナというキャラクターのデフォルトコスチュームの赤いドレスです。

これには8種類の色替えが存在しています。

「鉄拳6 BR」の色替え描画フローをご覧いただくと、左側がHDDに入っているリソースで、描画するためにはVRAMに移す必要があります。normalとmaskテクスチャーに関してはそれぞれ1個で済みますが、decalは色違いのものを8種類持つというちょっと強引なことをやっている状態です。ですから、実際にVRAMへ移す時にはnormalとmaskテクスチャーはそのまま移せますが、decalはHDDに入っているものの中から適当に1種類選んでVRAMに格納してやります。今回は白っぽいdecalを選択しました。結果、この3枚でドレスを描画してあります。今回は白いdecalを選択しましたので、色の方ももちろん白。

まとめますと、「鉄拳6 BR」ではこのような感じで描画しており、PS3ですとDXTが主体なのでこんな仕組みになるわけです。PS2とかPSP世代ですとdecalを複数持っていてもパレットがあるので良かったのですが。とはいえ、decalを複数持つことで生まれるデメリットも多くあります。例えばHDDの容量を圧迫するだとか、決まった色にしか変更できないとか。デバッグする時に大変だったりするので、結果としてデメリットの方が多く目立つ結果になったと思います。

今回は、それらを踏まえた上で色替え用のmaskテクスチャーを追加し、ある程度自由に色を変えられるようにしたいと当初から計画していました。

右側のエディというキャラのパンツ部分だけを切り取ったものですが、decalとnormalと、さっきのmaskですね。specular mask自体は先ほどと変わらなく、それについた形で右下のcolor maskが追加されていて、それと同時に、色情報として緑と黄色を数値で持っています。そして、これらの情報からパンツが描画されると。

色情報をご覧いただくと、このように赤と青に切り替えてやれば当然赤と青主体の色に変更されます。

この方法は一見万能そうに見えますが、先ほどのcolor mask用のテクスチャーが新規で必要になります。VRAMの要領で組めたんですが、キャラクターに関しても「鉄拳6 BR」とさほど変わらない程度なので1枚増えるとキャラ作成という意味合いでは大きなデメリットになってしまいます。で、どうしようか考えました。そして「実機上で先ほどの色替え済みのdecalテクスチャーを作ってしまおう」と。これが一つの大きなポイントになります。

ここからが今回の正式な手法です。先ほどと同じ準拠で、VRAMに4枚のテクスチャーを常に配置してあります。

この状態で一時バッファを作ってdecalとcolor maskと色情報から色替え済みのdecalを作ってやり、この時はいったんフルカラーで描画します。

この時点でcolor maskのテクスチャーは不要になるので開放します。

すると若干すっきりしますが、この時点から一時バッファを元のdecalのあった領域に上書きしてコピーします。この時、decalの方がDXT1とか5だった場合には、こちらはフルカラーなので圧縮しながらこっちに上書きするという形をとると。

そうしますと一時バッファも不要になり、結果としてこちらの3枚が残って結構すっきりした形になるわけです。こうやってエディのパンツを描画してやるという手法になります。

こちらが焼き付けた一時バッファです。それに上書きする形で左下の柄を重ねてやりますと、緑の部分にdecalも作れます。この手法を用いて描画すると、こういった感じで柄も自由に乗せられるという大きなメリットがありました。

今は1種類でお話ししましたが、柄は2種類、3種類とドンドン上書きしていくことも可能になっています。今回はこういう風にしてカスタマイズを実現しました。今の手法ですとcolor maskがいらなくなるので1体あたりのVRAM容量が抑えられ、前作と大体同程度になると。シェーダの処理も単純になるので描画負荷の方も軽くなったり、柄も重ねられるなどメリットの方が非常に大きかったわけですが、decalに描き戻す時にDXT圧縮をしているので若干ブロックノイズが目立つなど、品質の面で問題があるので今後の研究課題なのかなと思います。ひとまずメモリに関してはこれらの手法で少しクリアになりました。

◆第2の不安「描画負荷」

続いての心配ごと「描画負荷」についてお話をさせていただきます。先ほどから何回か申し上げていますが、単純にキャラクターが2体増えているので、その分だけ描画の負荷もプラスして考える必要があります。とはいえ、メモリとはちょっと違ってまだ調整が利きやすい分野かなと。極端な話、解像度を極端に落とせば描画落ちという面では解消されますので。そういうこともあり、調整が利きやすい設計にしておこうと念頭に置いて開発を進めることにしました。

ここで「鉄拳タッグトーナメント2」のゲーム中における各種状況をご覧いただきたいんですけれども、基本的に「タッグの片割れ同士が戦う2人表示」が状況としては1番多いです。

時折、相方がサポートしてくれる時がありまして、この時は合計で3人表示されている形になります。

シチュエーションとしてはあまり無いのですが、「タッグ投げ」をしているときに投げ抜けをするとこのように4人表示されることもまれにございます。

ここまでを考察すると、基本としては1対1、つまり2人表示の状況が1番多くてたまに3人とか4人という状況がおこることになります。描画負荷を抑えるには描画解像度をちょっと小さくしてやるのが1番制御しやすいので、初期は状況に応じて解像度を動的に切り替えてしまう設計にしました。

具体的な数字を列挙します。1番多い2人表示の時、こちらの描画解像度は1024×720です。3人の時は900×720、4人表示の時は極端に低くして800×720で描いてます。これらを動的に切り替えて処理すると。

今回、このように人数を軸として解像度を下げる処理を盛り込みました。先ほどの解像度でも無理そうな時は、さらにそこから下げるという処理を入れています。この処理を入れても結局3人、4人の時にはちょっと厳しそうなんで、そういう時はSSAOをカットしたりもしています。

ここまでが負荷を抑えるための基本的な話です。ここからはいくつか特殊な例をご紹介させていただきます。今回、カスタマイズが豊富であったり、ステージも種類がたくさんあったりしますので、場合によっては簡素なカスタマイズで描画負荷が軽くなったり、もともと軽い背景もあります。そういった時は、やっぱり高い解像度で見ていただきたいなと思いますので、2人表示の時はなるべく高い解像度でいけるような処理を導入しました。

こちらがその基本フローです。ラウンド開始時は2人の時の上限解像度を1280×720で描画してやります。そこから描画落ちしそうになった場合には先ほどの1024×720にし、それ以降はちょっと軽そうな状況であっても、念のためラウンド終了までそのままにしておきます。

感単に図で説明させていただくと、ラウンド開始時には既に1280×720で描画してまして、カスタマイズなどで重い時はこの瞬間にもう1024×720にしています。まあ、ラウンド開始時なので処理落ちしてもいいだろうという感じでやっているわけです。

実際に戦いが進んでちょっと重そうなエフェクトが出たりして描画落ちしそうになった時、この瞬間に1024×720へ落として描画します。

それ以降は、結構軽そうな状況もありますが、もう諦めて1024×720でラウンド終了まで描画し続けると。

2つ目の特殊な例です。特殊な技とかで、ご覧いただいている画像みたいにカメラがキャラクターに寄ることがあります。この図ですと、ポールというキャラが崩拳という技を放っていて、結構カメラが寄っています。それによってキャラの描画面積が増えると負荷も増えますので、どう対策したかといいますと、ゲーム側でカメラが寄ったと分かった時に解像度を最低レベルまで下げて、徐々に戻す処理を入れています。

通常の状態が1024×720で、特殊な技を使ったり壁が壊れたりすると一気に低い720×720にしてやり、徐々に戻していきます。一瞬ですので、こんなに低くしてもあまり目立たない感じです。

続いて最後の特殊例。キャラクターの登場演出があるのですが、背景がLEDみたいになっていて軽めなので1280×720で描き、余裕があれば2x MSAAをかけたりします。他にもランキング画面でキャラが表示されていなくて背景だけで済む場合は、終始2x MSAAをかけて描画してやるわけです。

描画負荷をまとめますと、今回は表示されている人数を軸にして変更する仕組みにしました。格闘ゲームですので1番多い状況、つまり2人でいることが多いので、そこを軸として考えてみたわけです。ここら辺の仕組みは開発初期に作りました。そうすることで最後の特殊例みたいな「実はここの負荷は軽いから」という時にも調整が効きやすいような仕組みにしています。

◆「勝利演出」での描画負荷

描画負荷の話でもう一つ心配事がありました。「勝利演出」という特殊例を掘り下げてお話しさせていただこうと思います。

勝利演出はその名の通り、バトルに勝った時の特殊な演出になります。「演出」なので全てにクオリティの高いものが求められるシチュエーションです。背景表示はもちろんしますし、タッグでもたまに表示されることがある上、ポストフィルタが必要だったりとか、そういうものです。その反面、カメラがキャラクターに寄ることが多いのでとても負荷的に厳しいと。

実機のイメージをご覧いただいておりますけれど、ものすごくカメラが寄り、シェーダもすごそうなのを使ってポストフィルタもかかっています。

2人を表示してアップになってますし、とにかくクオリティが高いものという感じです。

「鉄拳6」の家庭用に独自モードでシナリオキャンペーンというものがありますが、そちらのデモではフレームスキップを採用していました。で、今回もそれを使えるかなと許可も一応取っていたのですけれど……

開発の中盤頃になって偉い人がこんな感じで言ってきまして。こんな格好で言われたら僕もちょっと「いえ、できません」とは言えないので、がんばって作ることにしました。

それで対策を考えていきましたが、先ほどと同じ手法で描画面積を抑えようとしても、演出なので見栄えを良くしなければいけません。画面がさみしくなったり、ちょっと汚くなったりして商品価値が下がってしまうということも懸念されました。カメラを引いて対策することも考えましたけれど、カスタマイズ状況によってはそれでも不完全なことがありますのでダメです。

負荷を押さえるためには面積を小さくすることが1番なので、どうしようかなと考えたときに「インターレース」というアプローチが応用できないかなと思いつきました。インターレースについて簡単に説明させていただきます。

1フレームごとにその絵の奇数ラインと偶数ラインを交互に変えて合成する手法となっていまして、言い換えますと2フレームかけて1枚の絵を描画するイメージになってます。

ここでは1つの四角が1ピクセルを表しています。これが横8、縦8の最終画像です。

分かりやすくするために赤色のラインを奇数ライン、黒色のラインを偶数ラインとして考えていきます。

ここから奇数ラインの塊と偶数ラインの塊について考えていくと、赤いのだけ集めると奇数ラインになり、黒いのだけ集めると偶数ラインの塊ができあがります。ピクセル数にすると横8、縦4の塊が2つできると。

実際にインターレースの描画では、まず1フレーム目の描画面の方に奇数ラインの塊を描画してやり、実際に画面に表示するフレームバッファの方には奇数ラインごとにいったんコピーしてやります。

次のフレームではフレームバッファをそのままにし、その状態で描画面に偶数ラインの塊を描いてやります。これもフレームバッファの偶数ラインのところにのみコピーすると。

そうすることで、最終画像と同じものができあがるのが分かるかなと思います。これがまあ、インターレースの手法と言うことになります。

これを用いまして実際に「タッグトーナメント2」で適応したのがこちらのフローです。上と下の塊がそれぞれ奇数ラインの塊、偶数ラインの塊。それぞれ1ラインずらしたものを考慮したレンダリングになっていて、それをシェーダで合成し、最終的な1280×720の1枚絵になっています。まあ、割と見られる状態になったのかなあと。

負荷の話に戻ると、描画面積という意味合いでは1280×360という極端に小さい解像度で済むことになりました。それで負荷も結構減ったんですが、大きな問題が発生します。

演出で動いてライン交互で合成した時に、とても汚い絵になっていると。分かりにくいので一部を拡大しますと、横縞が入っているのが分かっていただけるはずです。ライン交互ですので、このような感じで横縞が発生して非常に見苦しいものになってしまいました。

原因は単純で、2フレームかけて1枚の絵を描画していますから、情報としては半分が1フレーム前なので、それが縞になって表示されてしまうと。このことがとても汚い感じになってしまう原因です。これを解消するために先ほどの奇数ラインの塊と偶数ラインの塊を引き延ばしてアルファブレンドするという手法を試してみました。

こちらがそのイメージ。アルファブレンド合成で引き延ばしてアルファ50で構成する手法ですけれど、それでできあがった絵がこちらになります。

拡大するとこんな感じです。情報としては2フレーム分あるんですが、さっきみたいな縞ではないので見られるようにはなりました。

これでもちょっと不完全です。演出が終わりかかった時、実機で見ると全体的にボケボケになってしまうと。

結局のところ、あまり動いてないところはライン交互の合成がよく、動いている時はアルファブレンド合成がいいのかなと思い、前作と同じモーションブラーを採用しました。モーションブラーに利用しているベロシティマップですと、そのキャラクターのピクセルごとの移動量が分かりますので活用し、ピクセルごとに大きく動いている、動いていないの判断をして合成をするのがいいのかなと。

それについて掘り下げてお話しします。このキャラクターが右足を振り下ろしているシーンです。

これはモーションブラーのベロシティマップになります。ニュアンスで捉えていただきたいんですけれども、上半身はあまり動いていない状況です。下半身の右足が、まさしく大きく動かしている部分になっています。そういうのがピクセルごとに格納されていると。

先ほどの、合成方法はどうするのかという話に戻りますが、ベロシティマップを参照し、上半身はあまり動いていないのでインターレースを使ったライン交互の合成をします。そして右足の方はアルファブレンド合成で処理する、という風にシェーダで合成することにしました。

最終フローがこちらになります。先ほどは2枚の奇数偶数の塊のみだったのですが、モーションブラーのベロシティを参照し、その3枚を使って最終的な1280×720のものを描画してあります。結局これで商品をリリースすることになりました。

補足になりますが、今回のモーションブラーも前作と変わらずにキャラクターだけなので、背景の方はどうするんだと思うかもしれません。背景はカメラ全体の移動量、例えば大きくカメラを振ったり、カメラ自体が動いたりということから全体をどうするか判断しまして、その上で演出として被写界深度を強くかけてごまかしてます。結局この方法でやると合成のコストはかかりますが、描画面積という意味では激減して逆に余るので、被写界深度もリッチなものを入れたりできました。描画負荷に関しては以上になります。

◆デバッグ

ここまでで「メモリ」と「負荷」という面は結構クリアになったと思いますので、これからはちょっとデバッグの話をして、その負荷が大丈夫なのかどうかという測定の話をさせていただきます。

CPU負荷もですけれど、描画負荷のチェックは処理落ちするかどうかを確認する必要があります。カスタマイズの種類やステージの種類など組み合わせが非常に多いので手動では絶対限界がありますから、「自動の計測」というものが必然的に求められることになりました。

それでアトラクトルームという単純なものを作りました。放置していると(キャラクター同士で)勝手に戦ったりするものです。それを延々と回しまして、処理落ちしたときには画面をキャプチャする仕組みを作りました。キャラクターはランダムだったり、ステージは順番に回したりだとか、いろんな状況に対応したシステムを作って回したわけです。

これらが実際に撮れた画像なんですけれども、印象としては攻撃しているところが多くて、いかにも処理が落ちそうだなという瞬間です。

こちらが処理落ちしているところです。下にあるビットマップのファイル名で各種状況が分かるようになっています。この数字の羅列が実際に撮れた日時ですね。ステージの種類、そしてプレイヤーの表示状況や種類だったりします。CPUと書いてあるのがCPU負荷でして、GPUと書いてあるところが描画負荷の数値になります。CPUが82でGPUが105ってことは描画落ちしてるな、とファイル名を見て分かるわけです。

このファイル名を基にして各種状況の判断ができます。Perlとかで判断し、csvに出力して統計表を作りました。例えばキャラクターごとに、落ちやすいキャラは誰とか、落ちやすい背景はどれかとか、そういったことが状況として把握できるようになります。

これらのシステムを実装した当初にカスタマイズ無しの状況で回してみたら、5時間で354枚も撮れてしまったんですよ。1時間で70枚くらいですので、結構落ちると。商品としてはちょっとやばいレベル。ですから、プログラマー以外にもアーティストとかプランナーを集めて緊急会議を開くことになりました。

キャプチャ画像をみんなで見ていって、落ちやすいシチュエーションを簡単に絞り込むことができました。例えば、攻撃して床にたたき付けているときには床にひびが出る状況があります。これが出ている時にはよくキャプチャが取れると。ちょっと調べたら、このひびに使っているシェーダがリッチなものになっていたので軽めのものに差し替えてもらいました。

続いて多いシチュエーションにタッグアサルトというコンビ技があります。白い輪郭があるのがお分かりいただけるかと思うんですけれど、これが出ている時には割と落ちやすいと。で、これも描画の時に無駄な処理が多かったので、がんばって最適化することで対処しました。

こちらは相方を助けに行くシーン。対策しようかなと思ってプランナーに聞いてみたら、既にシーンがカットされていたので特に対処することはなかったです。

他にも各種対処を施し、その上で再度同じシステムで回してみたところ、ひとまず「24時間回しても検出なし」という結果まで至りました。

自動負荷計測のまとめとしては、キャプチャしたので視覚的に把握しやすかったのが良かったと思います。そうすることでアーティストやプランナー相手にとても話がしやすかったです。画像で容量を食うというのはありますが、全体としては良かったかなと。

◆録画デバッグについて

デバッグの一環としてもう一つ、「録画デバッグ」というものについてお話をさせていただきます。

自動計測よりもちょっと前になりますが、画面を録画したいというニーズが開発の際にあるわけです。HDの画像を録画する時ってPCにキャプチャボードが必要だったり、場合によっては専門のPCを手配したりだとか、非常に手間と時間がかかります。それで考えた末にSDKにある録画機能を利用できないかなと思って試してみました。

それを使って実際に実機で録画したものがこちらです。こんな感じで20秒くらいの18MB。解像度は粗めですが、こういったことができるようになりました。

先ほど、「録画デバッグは負荷計測で使いたい」と申し上げましたが、結局録画自体に処理がかかってしまうということもあり、本来の目的で使うことはなかったです。けれども、たまに不具合として遭遇する、1フレームだけモーションが崩れたり、1フレームだけ描画負荷が高いといったシチュエーションを絞り込むのに非常に有用だったと思います。特別な機材を必要としなくても個々で録画できるのが1番大きかったのかなと。

◆描画手法

今回、「タッグ2」で新規導入した話を一つだけさせていただきます。

アーティストからの要望やプログラマーの提案などで描画手法をパワーアップさせています。例えば、シャドーがソフトになっていたり、Screen Space Ambient Occlusion (SSAO)を導入していたり、水面表現もリッチになっていますし、キャラクターのライティングも変えてみました。

時間の関係で一つだけになってしまいますが、「キャラクターの汚れ表現」についてお話しさせていただきます。プランナーから、戦いの臨場感を出すために転倒した際などに「土ぼこり」や「ぬれ表現」を試してくれと言われました。それで研究を進めて、こんな感じで土ぼこりがついているものを作ってみました。

「汚れの基本原理」についてお話ししますと、仕組みとしては単純で、頂点から頂点ごとで処理して乗せているだけです。本当はテクスチャーを貼りたかったんですが、時間の関係で諦めることになりました。ここからが独特だと思いますが、頂点ごとにどれだけ汚れているかという「汚れ度合い」パラメータと、特有の「ムラ情報」というのを保持して処理を行ってます。

1番大きい情報が「ムラ情報」。均一に汚れると面白くないので、頂点ごとに適度なムラを与えることにしました。これはキャラクターのモデルロードの時、ランダムに0から1で与えています。「汚れ度合い」の時、スキニング結果(ワールド座標)が汚れ範囲に入ったときに汚れ度合いをどんどん増加させる感じです。これら2つのパラメータからステージごとに決まった特定のカラーをシェーダ内で乗せるように処理しています。

これはキングというキャラでやってますけれど、この赤いブロックが実際の汚れ範囲で、分かりやすいように極端な緑で汚すようにしています。入った範囲だけこんな感じに汚れるわけです。

次はムラについて。このキャラを汚してみると、均一ではなく、このようにムラを与えてリアルな感じで描画されると。これを頂点ごとに追いかけると、「汚れ具合」という意味合いでは下の方から5、3、2、0.5、0っていう感じで、下の方から汚れているパラメータになります。また、ムラ情報というものが個別にありまして、これは頂点ごとにまちまちな数値です。

これらを用いて「ムラ」を表現しています。他にも、汚れ範囲に入っていない時には徐々に乾く処理も入れています。

◆まとめ

駆け足気味で申し訳ないんですが、本日のセッションのまとめに入らせていただこうかなと思います。

今回は、「タッグ形式」ということでメモリと負荷に苦労したという話がメインになりました。「メモリ」に関しては、単純な仕組みではありますが、最初の段階で「キャラクターは19MB」という制限を設けてからアーティストなどへ依頼して作ってもらうようにすることが重要だと思います。容量を指定すれば、アーティストの方もプロですので、その容量できっちりしたものを作ってくれます。今回はそういった意味でアーティストとかスタッフにとても恵まれたのかなと思います。「負荷」の方は、メモリと違って若干設計がしづらい分野なのかなと。実際に表示してみないと分からなかったりもしますから。そういうこともありますので、後から調整が利かせられるような仕組みを作っておくのが非常に重要だと思います。

「負荷測定」のまとめとしては、測定結果を分かりやすくすることが非常に重要だと思っています。今回は画面のキャプチャを行いましたけれども、そのキャプチャを見ていただくことでアーティストやプランナーに提案とか相談が非常にしやすかったです。密な連携を取るためにもそういった工夫は絶対必須になってくるのかなと。最後に、1番重要だと思っていることとして「あまりに考えすぎ、プレッシャーを感じて体を壊さない」ということ。ぶっちゃけた話ですね、メモリや負荷も、本当にピンチの時はアーティストさんにお願いしてデータを削ってもらったり、解像度を下げたりする処置を最終的には取ってしまってもいいと思います。その分、ネットとかで「クオリティが低い」みたいなことを言われるかもしれませんが、そこまでの責任を自分1人で抱え込む必要は絶対に無いと思います。せっかくゲーム開発という夢のある職業に就いていますので、長く楽しく仕事をしていくのが1番なのかなと。以上で全て、終了になります。

◆質疑応答

時間がありそうなので質疑応答に入ろうかなと思いますけれど、何か質問とかありましたら挙手願います。いなさそうですかね？あ、お願いします。

任天堂の中谷：
「解像度を動的に変更する」ということですが、解像度を1番低い状況に1度して、そこから徐々に上げていくということをされていました。解像度が変わってしまう場面で変になったりしそうですが、そこで何か対策はされていたんでしょうか？

堂前嘉樹：
対策は特にしていません。アーティストとかプランナーたちが一堂に会した際に見てもらった時でも、変わっていても気付いてもらえない場面がありましたから。1点、工夫したところがあるとするならば、解像度を下げてからすぐまた戻して、という連続だとガビガビしてしまうので、1度戻したら数フレーム戻さない、そういう工夫はちょいちょい入れている記憶があります。

質問者A：
「解像度を下げる」ということですが、あらかじめさまざまな解像度を作ってやっているのでしょうか？

堂前嘉樹：
そうですね、あらかじめいろいろな解像度を作っておきます。今回は1ピクセル単位で小さくするとかはできなくて、あらかじめ決まった解像度のものを持っておいて、それで下げたりしています。

質問者A：
ありがとうございます。あともう一つ、CPUの負荷に関しての問題は発生しなかったのでしょうか？

堂前嘉樹：
CPUは描画以外にもゲーム処理などいろいろな要因がありまして……。まあ、CPUも苦労しましたが、そこはマルチスレッドで物理を別のスレッドに回したりとか、そういったことを泥臭くやって対処しました。

質問者A：
ありがとうございました。

堂前嘉樹：
本日は、本セッションにお集まりいただいてまことにありがとうございました。これでセッションを終了させていただきます。ありがとうございます。