3月28日、ソニー・コンピュータエンタテインメント(SCEJ)にて、ソフトウェア開発者向けにPS Vita発売タイトルの開発事例を講演する「PlayStation Vita Game Conference 2012」が開催された。

　このカンファレンスでは、株式会社セガよりPS Vita「パワースマッシュ4」、株式会社ドワンゴよりPS Vita用アプリ「ニコニコ」、SCEJより「GRAVITY DAZE」、「みんなといっしょ」を制作した開発者が登壇し、PS Vita用タイトル制作時の開発事例について講演した。

　ユーザーサイドでは普段は想像するほかない“開発現場においての取り組み”や“PS Vitaソフト開発のポイント”が伺い知れる貴重な講演となっている。

　まずこのPart1では、「パワースマッシュ4」と「ニコニコ」の講演についてお伝えしていこう。

■ 「パワースマッシュ4」――フル解像度60FPSを実現すべく最適化の日々!
　 そこから見えてきたPS Vitaというハード

●講演名
　「フル解像度60FPSで動くPowerSmash4を作る」

●講演者
　株式会社セガ
　第二研究開発本部
　平山 尚氏
　鈴木 宏氏

◆ 製品発売1年前にPS3から移植状態で動作。しかしFPSは1桁……

　・PowerSmash4は、960×544フル、4xMSAA、60FPSを実現した
　　これをどのように達成したか

　・ただの移植ではない
　　1機種に集中。本チームが集中的に開発

セガ第二研究開発本部 平山 尚氏(写真内右)、鈴木 宏氏(写真内左)が登壇。平山氏はプラットフォームSDK抽象化ライブラリの面から、鈴木氏はレンダリング部(シェーダー)の面から、「パワースマッシュ4」での開発事例を解説した

「パワースマッシュ4」最大の特徴は、PS Vitaのフル解像度である「960×544」、「MSAA4x」、「60FPS(プレイ時)」を実現していること。据え置き機と比べても遜色がないほどのハイクオリティなグラフィックスとなっている

　「パワースマッシュ4」の講演には、セガ第二研究開発本部 平山 尚氏、鈴木 宏氏が登壇。平山氏はプラットフォームSDK抽象化ライブラリを、鈴木氏はレンダリング部(シェーダー)を手がけたており、双方の視点からPS Vita「パワースマッシュ4」のグラフィックス開発について解説した。

　「パワースマッシュ4」最大の特徴は、PS Vitaのフル解像度である「960×544」、「MSAA4x」、「60FPS(プレイ時)」を実現していることにある。ローンチタイトルの中でもグラフィックスクオリティがずば抜けて高く、注目を集めた。

　「パワースマッシュ4」は据え置き機種版が先行して発売されており、PS Vita版は基本的にはその移植となるが、これはもちろんただの移植ではない。据え置き機版の開発から引き続いて2010年から2011年末まで本チームが“PS Vitaで据え置き版のクオリティを実現”すべく、集中して開発したタイトルだ。最終的に据え置き機レベルのグラフィックスと処理を実現するために、たくさんの努力が重ねられている。

　まずは開発の経緯を追ってみよう。PS Vita版の開発では2010年5月にサンプルをビルド。6月にはライブラリ等が出そろい、開発インターフェイスが整った。これまでの開発経験からすれば、開発環境の構築はとてもスムーズで楽だったそうだ。

　6月20日にはレンダリング部をPS3版から移植。そこから1度、平行していた据え置き版の開発が入ったためPS Vita版の次の展開は10月になったが、その10月1日にはゲームが初めて動作するところまで進んだという。

　だが、2010年10月1日時点での状態はというと、起動に30秒以上かかり、素材もシェーダーも据え置き版のままなので、少し動かすとメモリが足りなくなって停止。フレームレートは1桁(5や6程度)だったという。この状況からどうやって製品のクオリティへ到達できたのか? CPUとGPUの最適化、ライブラリとシェーダーの両面から解説していくのがこの講演のポイントだ。

◆ 960×544フル、4xMSAA、60FPSを目指してCPU最適化の積み重ね

　・最初は困難の連続だった
　　性能は未知

　・おおよその方針
　　解像度は最大(960×544)。有機EL押し。MSAAは4x
　　フレームレートは可変。落ちたら描画スキップ

　・GPUよりもクリティカルなCPU側最適化

　・GPUの頂点シェーダに移動したスキニング

　・動くものを減らした布・髪シミュレーション

　・アーティスト側の作業が大きいDrawコール

　・UI描画システムの問題
　　社内のライブラリが遅かったため、様々な工夫

　・newの問題
　　通常はCPUに頼ってしまうため、削減する必要があった

　この初動作した時期に平山氏がPS Vitaに対した感じた事は、

「性能はまだ未知数だったが据え置き機と同じグラフィックスが実現できる」
　(同じシェーダーが動く)
「メモリの量は充分に多い」
「開発環境の構築等に違和感はなく非常に楽」

　というもの。先ほどゲームが初めて動作したところで「メモリが足りなくなって停止」とあったが、その時点ではテクスチャを圧縮していなかったからで、圧縮してメモリのアロケーションアレイも書き直したところ、すぐにメモリが余る状態になったそうだ。

　また、この時点で「性能が未知数」としているのは、時期として当然だが「CPUが未知数で掴めなかった」というのが1番の理由。CPU側でどれくらいまで速くできるのかが想像できなかったこともあり、本作の開発方針を可変フレームレートで進めることにしたそうだ。ただ、据え置き機版が固定60FPSを実現していたこともあり、スキップするのは描画のみ。ゲーム処理はスキップしないという方針だ。

　この状況から以下に解説しているような最適化を試みたところ、ゲームプレイ時30FPSを到達できたという。だが、演出シーン(キャラクターがアップになるシーンなど)ではFPSはまだ一桁。このままではダメだという思いと同時に、平山氏はノウハウが掴めてきたこともあって楽しくなってきたところもあったそうだ。「いけるいける、もっといける」という気持ちが沸き上がり、プレイ時60FPS達成に向けてさらに最適化を積み重ねていくことになる。

CPU最適化に目を向けてから徐々にパフォーマンスを引き出せるようになり、「楽しくなってきた」という平山氏。ノウハウが掴めてきた喜びもあって「もっといける! 」という気持ちが湧いてきて、60FPSを目指していったそうだ

移植元のデータである据え置き機版では固定60FPSだったのでスタジアムを分割していなかったが、PS Vita版ではこれを分割しカリング(片方の面を描画しない処理)

　解説された最適化について触れていこう。まずは「スキニング」。スキニングとは簡単に言うと「外観を変更する処理」のことだが、据え置き機ではスキニングをCPUで1回行なってGPUに送る方式を取っていた。だが、PS Vita版ではCPUにもっと余裕を持たせて高速化したいという目的があったので、GPUにスキニング処理を移動。そのぶんGPU側の頂点処理は重くなるが、頂点処理自体を削って対処した。

　次に「布と髪のシミュレーション」。布や髪に動きを付けるシミュレーションだが、これは前のフレームの結果に次のフレームの結果が次々と重ねていくという累積的な処理になるため、スキップさせられない。軽くするためには“動くものを減らして対処する”ことになる。PS Vita版では髪の毛のみに絞っているそうだ。

　「Drawコール数の削減」。Drawコール処理で重くなる場面も“数を減らす”か、または“中身を軽くする”ことになる。ここではアーティスト側に努力してもらいマテリアルをマージ(違う質感だったものを統一するなど)してバッチ数を削減。エンジン側も、特に影の処理において“ロードしてからマージする”という処理に変更。

　また、スタジアムを分割してカリング。据え置き機版は全オブジェクトが映っている時にも60FPSが維持されているため分割されていない。そこをPS Vita版では分割し「画面に映っている面だけを描画する」処理を施した。また、「Drawコールあたりの負荷削減」という全般的な最適化も行なっているそうで、ここではDirectX9合わせのインターフェイスがかなり障害になったという。

　「UI描画システムの問題」。社内で使用していたUIライブラリは据え置き機のCPU性能に合わせた作りだったため、STLの中に大量のnew演算子が走っていて、毎フレームごとに文字列操作を大量にしていたそうだ。それが最悪の時期には動作を2msほど遅くしていたという。そこで遅いものを削ってハードコーティングし、newしがちなSTLの文字列操作をID化した。平山氏はここについて「今から何かを作るなら軽量なシステムを別に作りたい」と語る。PS Vitaに移植作業をする時にはUIを新規設計したほうが結果的に早く済むと言っていいのかもしれない。

◆ 据え置き版ではシングルスレッド構成だったところをマルチスレッドに

　・マルチスレッド化
　　スレッドプールによる並列化

　・必死に最適化したテクスチャロード

　CPU処理の最適化では「マルチスレッド化」も行なわれている。「パワースマッシュ4」の据え置き機版はシングルスレッド構成だったが、PS Vitaではそれでは速くならない。PS VitaのCPUは4コアあるのでそれを活かすため、アプリ側を大改造してスレッドプールによる並列化を行なった。最終的には4コア中2コアをスレッドプール専用に確保したという。

　一方で平山氏は「マルチスレッド化には罠もある」と警告した。他のスレッドを呼び出す時に止まってしまいがちで、同期のためのシステムコールは高くつく。そのため、ジョブの粒度には検討と実験が必要という。また、マルチスレッド化はバグの温床になりがちということもあわせて述べていた。

　続いて、「テクスチャのロード」の最適化。開発チームではデータ管理の手間などやコスト削減のために機種専用バイナリを作らないそうだが、開発用のPC版と同じデータをロードさせたところ、これが“泣くほど遅かった”ということで、テクスチャの並べ替えなど最適化を施した。機種専用バイナリを作らない方式はPS Vita版ではこうした手間があったものの、デバッグコストが下がって作業効率が上がるというメリットがある。

　そして「サウンドデコード」の処理。「パワースマッシュ4」ではいろいろと理由があってサウンドのデコード形式に独自のものを使っているいうことなのだが、これもだいぶ処理を重くしていたという。これについて平山氏は、「これから作るのなら豊富にあるメモリを活かし、短いサウンドはメモリを使って事前デコードにしたい」と語っていた。

◆ GPU側についてライブラリ側からの最適化

　・GPU側最適化
　　　GPU側についてライブラリ側の工夫を紹介

　・解像度のハードル
　　アーティストたちによるピクセルごとの気の遠くなるような最適化

　・MSAAx4の挑戦

　・CPU-GPU同期問題
　　リソースの書き換え同期に関してはよくよく設計を考える必要あり

　・定石をはずした最適化手順

フル解像度にとことんこだわったのは、有機ELディスプレイの美しさを活かすためであり、「パワースマッシュ」シリーズがもとから静止画の画質の良さを非常に重要と考えていたためだという。フル解像度に見慣れていたこともあり、落とす気にはならなかったそうだ

　CPU処理の最適化に続いて「GPU側最適化」について。平山氏は「960×544というフル解像度」が“悪魔”と表現するほどに厳しかったと話していた。これに対しては、ピクセルあたりのシェーダー処理を削る以外に手はなく、鈴木氏をはじめとしたレンダリング側による涙ぐましい最適化のおかげでフル解像度を実現できた。

　ではなぜ、最後まで妥協することなくフル解像度にこだわったのか? 平山氏によれば、今時の開発現場はどこでも「1ピクセルあたりの処理をリッチにして、解像度は下げたほうがキレイになる」という考え方が支配的とのことだが、「パワースマッシュ」シリーズではあえて解像度にこだわっているという。それは、ゲーム内容がテニスゲームであり画面があまり動かないので、静止画の画質の良さは非常に重要と考えているから。また、PS Vita版の開発ではCPUの最適化に取りかかっている間、ずっとフル解像度(GPU側は触っていなかった)でキレイな画面を見ていたので、解像度を落とす気が起きなくなったということだ。

　画質の面では「MSAA4xにもこだわっている。静止画質にこだわっているのだからMSAAも当然欲しい。どうせやるなら4x(4倍)がいい」と考えたということだが、普通のハードではMSAA4xをかければメモリ消費や帯域負荷などあらゆる面で4倍の処理コストがかかってしまう。だがPS Vitaではそのコストがかからずに済むという。また、メモリ確保なしにAPIのスイッチON/OFFひとつで切り替えられるので実装も楽だという。MSAA4xを使う事による負担がなく、ここにはあまり苦労がなかったようだ。

　「CPUとGPUの同期ポイント」について。CPUの処理とGPUの処理はいつか同期させなければいけないが、この同期をうまく行なわないとパフォーマンスが落ちてしまう。この設計は非常に重要と前置いた上で、PS Vita版ではフレームの開始関数において1フレーム前の頂点処理の終了を待つ方式にしたという。また、頂点バッファはダブルバッファとし、テクスチャのCPU書き換えは非対応にした(CPUでのテクスチャ書き換えを使うとGPUがその2フレーム前のピクセル処理が終わるまで待つことになってしまうため)。

　PS Vitaの「テクスチャフォーマット」にはGPUコアであるPowerVR専用形式のものがあるが、「パワースマッシュ4」ではこれは使っていないという。手を入れなかった理由として、絵素材のパイプラインをいじりたくなかったというのが大きかったそうだが、実際にPowerVR専用形式のダミーテクスチャに差し替えてみても性能はあまり変わらなかったということで、そこからテクスチャ形式がボトルネックになっているわけではないと判断。変えずにそのまま使ったということだ。

◆ GPU側についてレンダリング部(シェーダー)からの最適化

「GPU側最適化」についてはレンダリング部(シェーダー)を手がけた鈴木氏から。ゲーム中60FPSを維持しつつ、自然な影の生成にたくさんの工夫を凝らしている

「パワースマッシュ4」には静的なもの動的なものにわかれる4種類の影が存在。この画像を見てもらうとわかると思うが、影の存在は非常に重要だ

　レンダリング部によるGPU最適化については鈴木氏から。最終的に「パワースマッシュ4」は可変フレームレートとなり、ゲーム中は60FPS、演出シーンは可変となったのだが、この2つのシーンでは処理を大きく変えているそうだ。

　まず60FPSを維持していない時のシーン構成(演出シーン)では、ポストエフェクトにブルーム+被写界深度を使用。シャドウマップをメインのレンダーターゲットに書き、そこから4つに分けてポストエフェクトをかけていく。ビューポートを切替える方式でパフォーマンスを上げている。UIはバックバッファに直接描画しているとのこと。

　一方で、60FPSを維持するシーンでは構成を大胆にカット。シャドウマップをバックバッファに直接描画するようにしている。このようにシーンごとに処理を大きく変え、個々の中身も最適化を重ねてゲーム中60FPSを実現しているというわけだ。

　次にPS Vita版における「影」の付け方。「パワースマッシュ4」では光源を固定し、4種類に分類しているとのこと。4種類の内訳は以下の表のようになる。

　これらの影はコート(地面)に落ちるものであれば影領域の中にサーフェス(コート)を描き、影同士が重なる場所では影が濃くなりすぎないようにブレンド用のマスクを用意していたりと、かなりの工夫がなされている。見栄えを徹底して工夫している上で、処理を高速化することも意識するという状況であり、まさに涙ぐましい努力となっている。

　最後に「UIの最適化」。平山氏からUIもかなり重かったという話があったが、UIは当初Drawコールが50回以上あったという。これをテクスチャをまとめ重ね描きをできる限り回避し、最終的に2回にしたという。さらにランタイムをハードコーディングし直して軽量化も行なった。

【背景が選手に落とす影】
まずは背景が選手に落とす影。選手の影は動的であり、背景の影は静的なもの。選手に落とす影を切り出した背景モデルを用意し、影を切り出した背景モデルを、シャドウマップのα成分に描き込んでいる
【選手が背景に落とす影】
影(濃さ)の描画結果で、右が合成結果
影領域のみ影の計算を行ない、中に暗いサーフェス(コート)を描いている。右が合成結果
静的に背景に描き込んである影とブレンドするため、ブレンド用のマスクを用意。左がカラーマップで、右がブレンド用のマスクとなっている
半影表現が必要なときは、丸影をボーンに沿って半透明で描画。こうした処理を経て、右の画像のような自然な影を実現している
【UIの最適】
テクスチャをまとめ、drawコールのバッチ数を50回以上あったところから2回に削減。重ね描きをできる限り回避し、ハードコーディングもし直して軽量化している

◆ これから作るなら……解析をもとにしたより効率的な設計と最適化をしたい
「これらなしでもここまで達成できるポテンシャルをもったハードウェアだった」

　・まとめ

　　正直どうしてここまで達成できたのかわからない。
　　今なら性能解析ツールが充実しているので、もう少し賢く最適化作業ができる。
　　シーンごと、シェーダごと、素材ごとの解析も。
　　機械の性質を踏まえた絵作りの設計ができる。
　　ライブラリ層のAPIを設計しなおせる。

　　逆に言えば、PS Vitaは、
　　「これらなしでもここまで達成できるポテンシャルをもったハードウェアだった」
　　ということである。

　こうして、ライブラリ側、シェーダー側のCPU・GPU最適化、アーティストによる頂点数の削減などの様々な努力を経て、PS Vitaでのフル解像度、プレイ時60FPSを実現した本作。

　こうした開発を終えて平山氏はPS VitaのGPUに対し「シェーダーの書き方やAPIの呼び出し方次第で大きな差が出るGPU」という印象を受けたそうだ。適当な書き方をしてもどうにもならず、いわゆるベタ移植のままでは厳しい。動くという点においてはベタ移植でも動いたことは動いたのでスムーズと言えるが、そこからのPS Vita用の最適化は必須になり、そこには特にCPUを高速化するための工夫が必要となる。

　また、「原因を特定し、それがわかってから修正し、さらにそれを検証しよう」というのが教科書的に言われている開発の正しい手法だが、高度に並列している場合は原因特定が困難であることを指摘。解析ツールで測定するのにも時間はかかるし、効率アーキテクチャがわかっていれば「原理的に高速化するはず」という修正は思いつくはずなので、ローンチ時のような状況ではとりあえずノリと勘で疑わしいものをどんどん直す方が効率的とコメント。

　ただ、こうした即実行な姿勢で果敢に制作したためか、「いつ60FPSになったのかはよくわからない」という。2010年12月時点の氏のメモには「1/4解像度で16fpsかよ!」と書かれていたそうだが……。

　これを踏まえて「今からやるなら」という最後のまとめでは、「性能解析ツールを使いもう少し賢く最適化作業をしたい」、「PS Vitaの性質を踏まえた絵作りの設計をする」、「ライブラリ層のAPIを設計しなおす」といった展望を挙げていた。そして、「これらなしでもここまで達成できるポテンシャルをもったハードウェアだった」と締めくくった。

■ 「ニコニコ」――UIコンポーネントから独自フォントキャッシュまでアプリを自社開発
　 将来の展望では、公式「ゲーム実況」機能についても紹介

●講演名
　PS Vita × ニコニコ動画

●講演者
　株式会社ドワンゴ
　　ニコニコ事業本部 CE事業部
　　齊藤 寛明

◆ 「マルチデバイス化」の一環から、親和性の高さも期待しPS Vita版アプリ制作を決定

　　・はじめに ～ ニコニコ動画とニコニコについて ～
　　　動画を中心に多彩なジャンルのUGCを扱うwebサービス
　　　　登録会員数2,500万人、1日当たり平均滞在時間101分

　　・PlayStation Networkとニコニコ動画の連携
　　　PCやガラケー、スマフォに留まらない、「ニコニコ動画のマルチデバイス化」の一環

講演したのは、株式会社ドワンゴ ニコニコ事業本部 コンシューマーエレクトロニクス事業部 齊藤 寛明氏。ローンチアプリ「ニコニコ」の開発事例を紹介した

　PS Vitaはゲームソフトウェアだけでなく、アプリケーションもリリースされているのが大きな特徴。中でもローンチリリースに「ニコニコ動画」が視聴できるアプリ「ニコニコ」が登場したのは話題となった。

　PlayStation Network内で外部Webサービスである「ニコニコ動画」に連携するこのアプリについて、株式会社ドワンゴ ニコニコ事業本部 コンシューマーエレクトロニクス事業部 齊藤 寛明氏が、参入の背景からアプリ開発の事例について講演した。

　まず参入の経緯についてだが、ニコニコ動画では「マルチデバイス化」を掲げており、その一環としてPS Vitaにも提供することを決めたそうだ。ニコニコ動画ではPS Vitaに高い親和性を感じたていて、その理由に、動画視聴に適した有機ELディスプレイ、3G回線を備えたインターネット接続の容易さ、タッチスクリーンによる直感的な操作を挙げていた。

　また将来的な可能性として、カメラやマイク、動画エンコード機能を使った「生放送」や「ゲーム実況」の配信も可能であると考えているという。こうした将来的な展望も含め、PS Vita用アプリ「ニコニコ」のローンチリリースを目指す事になった。

◆ PS Vitaに適したUIをデザイン。PSNから外部Webサービスへの接続には連携が必須

　　・ニコニコのUI構想
　　　ニコニコ動画を"PS Vita" のようにスタイリッシュに
　　　動画と生放送の統合をさらに強化
　　　シームレスに切り替えられる新しいUIに
　　　「今までとは違う新しいニコニコ動画を作ろう！」

PlayStation Networkのアカウントとニコニコ動画のアカウントの2つを連携してログインする形式。そのため、アカウント紐付けの設定等は、アプリ内だけでなくPC向けWebサービスからでもできるようにするのが理想的とのこと

　アプリケーション「ニコニコ」の開発は全てドワンゴによる内製ということで、開発期間は3カ月間（調査期間も含めると約半年）。だが、完成までには多くの難関があったそうだ。

　まず最初の関門は「PS Vitaアプリから独自サービスへのログインが可能なのか?」というそもそもの話。これについては、PSNを介さないWebサービスへのログインはNGとなっており、独自サービスへのログインをさせる場合は連携が必須となる。PS Vitaからニコニコ動画へログインする流れは以下の7手順となっている。

・アプリケーション上でニコニコ動画へのログイン情報を入力、処理を開始
↓
・アプリケーションからPSNサーバーへ「NPチケット」というPSNアカウント情報を要求
↓
・受領したNPチケットとニコニコ動画のログイン情報をニコニコ動画のサーバーへと送信
↓
・サーバー側の専用モジュールでログイン情報を解釈
↓
・PSN IDとニコニコ動画のアカウントを紐付けし、セッションを作成
↓
・作成されたセッションをサーバーからアプリケーションへと戻す
↓
・ログイン完了!

　このPSN連携について齊藤氏は、PSNと独自サービスという2つのアカウント情報に対して「ユーザーが混乱しないような配慮が必要」とコメント。「アカウントの紐付け、解除、確認手段をアプリケーション内に用意することは当然として、PS Vitaが手元にない場合でも行なえるようPC向けWebサービスでもフォローしたほうがいい」と語った。アプリケーション側、Webサービス側の双方から対応できるようにしておくことで、不測の事態にも対応しやすく、かつわかりやすくなるというわけだ。

PSNを介さないWebサービスへのログインはNG。実際にPS Vitaアプリの「ニコニコ」からニコニコ動画へログインする際には、PSNサーバーからアカウント情報を取得し、専用モジュールで解釈した後にニコニコ動画へのログイン処理を行なっている

PS Vita用に0からアプリをデザインするということで、PS Vitaのイメージに合うよう、ロゴデザインから刷新。全てのUIをタッチ操作で扱えることをコンセプトとした

　続いてはPS Vita「ニコニコ」アプリのUIについて。これまでケータイ向け等にUIを制作してきた同社だが、実はPS Vitaのような横画面のデザインをしたのは初めてだったそうだ(スマートフォン向けなどは全て縦画面のUIが基本だった)。そのため他UIからの流用をせず、0から構築したという。

　まずUIデザインのコンセプトとして、末永く利用してもらえるよう「PS Vita標準搭載アプリとデザインを合わせる」こと、「ニコニコ動画とニコニコ生放送を違和感なく切り替えられるようにする(Webサービス側では動画と生放送は若干連携しづらい設計になっているそうだ)」ことなど、PS Vita向けに最適化することが掲げられた。

　さらに操作面では「タッチ操作で全ての操作を完結できること」を重要視。具体的には、左側にナビゲーションバーという主要機能を配置、その隣に単一ペインアコーディオンリストを配置し、ニコニコ動画の階層を1画面で辿れるようにしている。また、動画と生放送の切替もデザインを統一し、違和感なく切り替えられるようなっている。

　動画再生時は、PS Vitaの大きな画面による視聴をスムーズに楽しめるよう、フルスクリーン再生をデフォルトに設定。このほかにもコメント入力機能でのコマンド入力用キーボードを、PS Vitaが標準搭載しているソフトウェアキーボードのデザインに揃えて一体感を高めていたり、動画の詳細表示画面ではWebサービスだと動画のサムネイルが表示されていたところをリッチなプレビュー表示にしていたりなど、たくさんのこだわりが入れられている。

ニコニコ動画は階層の深い構造になっているので、タッチ操作でそれを快適に辿れるよう、ナビゲーションバーやアコーディオンリストというUIを設計。さらに動画と生放送も違和感なく切り替えられるようになっている。また動画視聴画面は有機ELディスプレイの大画面を手間無く楽しめるよう標準でフルスクリーンに。コマンド入力UIはPS Vita標準搭載のソフトキーボードとデザインを揃え、詳細情報画面では従来サムネイルだった動画表示をプレビューにするなど、様々な工夫を行なっている

◆ PS Vitaアプリを自社でスクラッチ開発。今後を見据え「UIコンポーネント」も作成

　　　コンシューマゲームのノウハウも資産もない！
　　　UIコンポーネントをイチから開発
　　　作るからには高い拡張性と汎用性も意識
　　　ネットワークからデータを取得し、動的に構築できるUI構成に対応
　　　微フリーズを排除し、快適なUXの実現
　　　MT化によるWebAPIの応答待ち＆データ解析によるメインスレッドのブロッキングを排除
　　　ネットワーク経由のデータを遅延取得し、ユーザ操作を優先

完成したUIは全ての部品をViewで実現。「ジェスチャ」のUIコンポーネントではViewが重なっている複雑なシーンでも矛盾しない操作性を実現した

　こうしたPS Vita向けのUIをデザインしたわけだが、同社にはそもそも“これを実現する手段がなかった”そうだ。というのも、携帯電話やWebアプリケーションではブラウザからUI機能を持ってきて構築していたのだが、ゲームSDKにはそういったものはない。また、ゲーム機向けのアプリケーション開発は初めてで開発ノウハウもない。

　こうした状況ではあるがデザインはもう完成しているので作るしかない。というわけで初めてのゲーム機向け開発に挑んだ同社。苦労はたくさんあったということだが、これを完成させ、さらに「せっかく作るなら……」と、今後の拡張や汎用性に耐えられるよう「UIコンポーネント」も作成した。

　こうして制作された独自のUIコンポーネントには多くの機能が詰まっているという。その中で特徴的な2つが紹介されたが、まずアプリの全ての部品はViewとして表示しているという。全てというのはプレーヤーやその上にオーバーレイされているコメントも含めて全て。これによりクリッピング処理も容易になっていて、今後の拡張にも役に立つという。

　もうひとつは操作の独自UIコンポーネント「ジェスチャ」。タッチ操作でコントロールする時にViewが重なる複雑なシーンでも“矛盾しない操作”を実現している。例えば動画のサムネイルをタップすれば動画が再生されるのは当然として、サムネイルを触りつつ縦方向にフリックすればリストスクロールに、横方向にフリックすれば動画と生放送というコンテンツの切替に反応してくれる。一覧性の良い1画面内でたくさんの操作ができるよう工夫されている。

　さらに開発においてはユーザーの体験を快適なものにすることを重視。微妙なフリーズやブロッキングを徹底的に排除し、通信状況やトラフィックによってデータが取得できない状況も考えられるので、まずユーザーの操作の処理を優先させ、データを遅延して取得するという機構も盛り込んでいるという。初めてのゲームSDKでの開発にもかかわらず、細部に至るまで配慮しているところに感心させられるばかりだ。

◆ コメント描画が課題に。独自フォントキャッシュを作成しクリア!

　　・「コメントを描画する」ことの難しさ
　　・膨大な文字列との格闘
　　　文字列描画に試行錯誤の日々
　　　ニコニコの独自フォントキャッシュ機構を開発

コメントをオーバーレイするための文字列のラスタライズで大量にメモリを消費してしまいボトルネックに。そこで独自のフォントキャッシュ機構を作成し、共通する文字を1つのキャッシュとして処理してラスタライズの時間とメモリを大幅に節約した

　こうして独自アプリの開発は進んでいったが、その先にはさらに大きな問題が待ち受けていた。それは、ニコニコ動画の最大の特徴といえる「コメント表示」のための文字列描画だ。ニコニコ動画では動画中にあらゆる文字が大量にオーバーレイされる可能性があり、それが滑らかに描画されなければならない。だが、文字のラスタライズが大きなボトルネックとなり再生が止まってしまったという。試しにひとつの板ポリゴンにラスタライズと描画するというストレートな方法をしてみたところ、300MBほどメモリを消費したという。

　これを解決するために同社は“独自のフォントキャッシュ”を作成して対処。「指定メモリ内で自由なサイズのフォントをキャッシュ化できる」というもので、サイズを無段階に格納できるツリー構造を実現したことで大量の文字を処理できるという。また、複数のコメント内にある同じ文字を1文字分のキャッシュとして処理できるようになったので、ラスタライズ時間とメモリを大幅に削減。例えば「w」という文字がキャッシュされていれば、複数コメント内に「w」の文字が大量にあっても、全て1つのフォントキャッシュで処理できる。それ以前は1文字ずつ個別に処理していたわけだから、大幅な最適化となる。

　このフォントキャッシュ機能だが、メインメモリとVRAMの両方に2重にキャッシュしているという。これは文字列表示にドロップシャドウの装飾をしているためで、同じコメントを2回描画しているため。描画の際にレンダラーから文字の指定が来て、まずVRAM内のキャッシュを参照。無ければメインメモリを参照し、そこにも無ければラスタライズする、という段階的なラスタライズ工程になっており、かなりの効率化が果たせたということだ。文字列処理の一例として、かなり独特な工夫がされたものになっている。

◆ ユーザー作成の動画はフォーマットが千差万別。独自の工夫で対応を重ねる

　　・PS Vita における動画の再生について
　　　～ニコニコ生放送をPS Vitaで実現する方法
　　　PS Vita と相性の悪い動画が多数存在→それらすべてに対応

PS Vitaの動画再生機能は専用のハードウェアデコードと高速な色変換機能を搭載していて、充分なスペック。動画データをメインメモリへプログレッシブダウンロード(PDL)する方式で実装している

　続いて「動画のデコード」について。プレーヤーには「SCE AV PLAYER」を使用。「ニコニコ」アプリは動画データをメインメモリへプログレッシブダウンロード(PDL)を取得して再生しており、動画データ用に100MBのメモリを確保しているとのこと。パフォーマンス的にもアップロードされている動画の最大サイズ的にも問題のない作りになっているそうだ。

　だが、ここにも新たな問題が発生する。ニコニコ動画には様々な形式の動画があり、中には上手くエンコードされていないものもあり、それをそのまま「SCE AV PLAYER」に渡してしまうと動作がおかしくなってしまう。そこでニコニコ動画側で、アップロードされている動画を再度エンコードし、そのデータを優先的に取得するよう処理をしているという。また、PS Vitaが対応していないFLV形式の動画についても、今後同様の再変換する方式で対応していくとのことだ。

　「SCE AV PLAYER」と相性の悪い動画もあるという。「SCE AV PLAYER」のシーク機能(動画のジャンプ機能)はIDRフレームという動画内の情報を参照する方式だが、ニコニコ動画にアップされている動画の中にはIDR情報がないものもあるという。そこで再生前に動画を解析して、iフレームをIDRフレームに変換するという方法で対応させたそうだ。

◆ 生放送＝ライブストリーミング映像は? 映像データの変換を重ねて実現

　　・ニコニコ × 生放送再生
　　　PlayStation Vitaではそのままでは実現できない。PC/Android、iOS向け配信を応用

　　　　→MPEG-2 TSをHLSで受信し、MPEG-2 TS ⇒ AVC/AACに変換し、
　　　　　AVC/AAC をSDKでデコードする

ストリーミングライブ映像のニコニコ生放送。こちらは映像データの変換を間に挟んでPS Vitaでも実現しており、形式としてはiOS向けの方式に近いとのこと

　次は「ニコニコ生放送の再生」について。PS Vitaアプリでの“リアルタイム配信されているストリーミング映像の再生”だ。生放送ではユーザーがエンコードした映像を配信サーバーに渡すまでにいくつもの工程を経て、各プラットフォーム向けのプロトコルを使って視聴側に渡しているが、PS Vitaでは「http Live Streaming(HLS)」プロトコルを使用。配信者からの映像データをMPEG-2TSに変換し、そこからPS Vita向けにMPEG-2TSをAVC/AAC形式に変換。PS Vita側はHLSで受信しAVC/AACをデコードして視聴するという流れにしている。これも新たにPS Vita向けに構築したものだ。

◆ 実現なるか? 専用SDKを組み込んでのPS Vita上での「公式ゲーム実況」機能

　　・ニコニコの今後
　　　生放送タイムシフト、UI改良、生放送配信機能の追加など

　　＋αとして…
　　　ドワンゴより提供するSDKを各ゲームタイトルに組み込んでいくことで、
　　　公式「ゲーム実況」を実現させる予定

専用SDKをゲーム側に組み込んでの、公式「ゲーム実況」機能についても紹介。配信はもとより、ゲーム画面側に放送へのコメントを表示するなども考えているということだ

　最後は展望編として、今後の「ニコニコ」アプリについて紹介。まず現実的なものでは、生放送のタイムシフト対応、UIの改良、PS Vitaでの生放送配信に順次対応していくとのことだ。

　また、さらに大きな展望としてゲームメーカー公式の「ゲーム実況」機能実現についても紹介された。こちらはまだまだ提案段階のものだが、例えば「プレイ中のゲームを生放送配信」したり、「視聴者さんとプレーヤーがやり取りできる機能」、「ニコニコ動画のように生放送へのコメントをゲーム画面に表示」といったことを考えているという。

　これはゲームタイトル側にドワンゴから提供されるSDKを組み込む方式にして、「公式」として実装していきたいということで、「興味を持たれたメーカーはぜひお声かけ頂きたい」とまとめた。

　PS Vitaのローンチで、PSN経由の外部Webサービス連携するアプリをリリースし、その内部には独自UIコンポーネントやフォントキャッシュ、対応形式の変換など、様々な工夫を盛り込んだ「ニコニコ」。講演の中身からもわかるとおり、未経験でありながら問題に直面しても果敢に打破して実現していったという背景があり、最後に紹介されたゲーム実況SDKによる公式ゲーム実況という未知の試みも期待できるかもしれない。ゲームソフトウェア開発とはまた異なる観点を持った講演となった。

【パワースマッシュ4】
(C)SEGA All trademarks used herein are under license from their respective owners.
【ニコニコ】
(C)niwango,Inc All Rights Reserved.