イベント
[CEDEC 2010]プログラマの立場から考える,HDゲーム開発に必要な事前準備と開発手順
このセッションでは,セガの第一CS研究開発部が制作するPlayStation 3版「龍が如く」シリーズを例に,大規模プロジェクトを迅速に遂行するために必要な事前準備や開発手順,デバッグの手法などが具体的に解説された。
受講スキルとして,PlayStation 3やXbox 360,PCなどのハイエンド環境でC++を使用してのゲーム開発経験が挙げられていることもあり,専門用語や開発に使われるソフト名などを用いた,プログラマ向けの実践的な内容のセッションとなった。
セッション第1部・開発環境編
大量のデータと格闘しなければならないHDゲーム開発には,とにかく膨大な時間が掛かる。そこで,時間をいかに削ることができるかという点を,開発環境の改善によって考えていくことが重要だと加来氏は述べた。
そのために必要なのが,リソース管理の高速化,ビルド時間の短縮,PCでの代替開発,コーディングしやすい環境づくり,という四つのポイントだ。
まず,リソース管理の高速化について。HDゲームにどれだけのデータが使われているかというと,「龍が如く4」では,製品版用の実機データ:21.4GB(約1万9000ファイル),中間データ(実機データにコンバートする前のデータ):398GB(約34万3000ファイル)。主にデザインリソースが占めるこれらのデータは,LANを通してのコピーが発生することとなる。これらはやむを得ないコストであるとし,その中でいかに高速化できるかを追求していくべきだと加来氏は語る。ちなみに,ソースコードは普通に,Subversionで管理しているそうだ。
リソース管理の高速化で最初に行うことは,高性能なサーバー/ネットワークの導入で,導入コストを惜しまず信頼性の高いものをチョイスしているという。良いものを選ぶことで,結果的に時間が短縮されてコストが減るという思想が根本にあるようだ。
しかし,いくら良いハードを導入しても限界はある。そこで,「龍が如く」開発チームは,独自のリソース管理ツール“TiVersion”を構築。この内製ツールは,最大5ノードとのP2P接続を使用し,サーバーの負荷を軽減することができる。さらに職種に応じた必要ファイルの選択が行え,ファイル転送量の根本的な削減に成功したという。ただし,このツールにはバージョン管理機能は必要最低限しか備わっておらず,バックアップ等はサーバーで行っているとのことだ。
ビルド時間の短縮については,分散ビルドによって解決し,ビルド時間は実に10分の1にまで軽減。リンク時間の短縮は,64bitOS(Window XP,Windows 7)を早期導入し,メモリの増設(4GB〜6GB),早いローカルストレージの導入といったPCの高性能化で対応したという。
なぜ,PS3開発機ではなくPCで代替開発を行うのか。実際のところPS3開発機を用いているプログラマも多いと思うが,理由はこの専用開発機にいくつかの問題点があるためとのこと。これらの問題点を解決するため,高性能なPCで開発環境を構築しているのだが,これにより素早い起動を実現し,PS3開発機では実現困難なさまざまなオプションを持つデバッグ機能も利用可能になったという。さらに機器のコスト安と大量のPCによる同時デバッグなどといったメリットがあることにも触れられていた。
また,プログラマに対してどんな会社でもコーディングルールというものは存在すると思うが,「龍が如く」チームでは緩いコーディングルールを敷いているという。一定の基準の中である程度の自由を与えることで,各自の能力を存分に発揮してもらい,さらにモチベーションの維持にも繋がっているそうだ。
また,内製のライブラリも使っており,PCとPS3で同じ動作を実現しているという。加えて,内製のライブラリを使うことは,ライブラリ開発者が近くにいることでもあり,質問がしやすく,修正も迅速に,そして理解しやすいといったメリットがあるのだ。
開発チームのコミュニケーションと育成に気を配ることでも,コーディングしやすい環境は作られるという。
「龍が如く」チームの場合,上は23年目から下は1年目の新人まで,最大で35名のプログラマが活躍している。そのうち若手のプログラマには,「龍が如く」でいうプレイスポット,ビリヤードやダーツといったミニゲームを,1人のプログラマに最後まで任せることで,育成の環境としているのだとか。
また,パーティションを立てずに雑談をしやすくし,質問や報告を気軽に行えるようにしてコミュニケーションの向上も図っている。
第2部・基礎技術(ライブラリ)編
PCでPS3と同様の開発を行う,マルチプラットフォームライブラリを自社開発すること。これは製品のリリースを目的としたものではなく,開発効率の向上を目的としたものを指す。このライブラリ制作には,PCとPS3上での共通なソース記述やメモリ使用量などの機能を考慮して開発を行っているという。
ここからは,同ライブラリで使っている共通のソース/メモリ使用量/挙動を内部記述を含めて解説していたので,そのスライドをまとめて掲載しておこう。
シェーダに関しては,プログラマがコーディングする形を取っているという。これは,どうしても増えてしまうシェーダの総数を抑制し,現実的ではない冗長なシェーダを事前に排除する目的もあるようだ。なお,シェーダのソースコードはPC/PS3に加えて,DCCツール用のシェーダも共通化しているのが特徴。環境の違いはシェーダ共通のヘッダ内のプリプロセッサで解決するという手法だ。
PS3の場合は,ここでフラグメントシェーダの静的分岐をエミュレートしている。シェーダのコンパイラに関しては,fcx.exe(PC),scs-cgc.exe(PS3)といったコマンドラインを呼び出すフロントエンドを用意し,それをVisual Studio上で行う形だ。ちなみに,シェーダの名前もルール化されており,名前からそのシェーダが何を実行しているのかを推測できるようにしている。
シェーダのアサインに関しては,キャラクターデザイナーや背景デザイナーがDCCツール(3ds MaxとSOFTIMAGE XSIに対応)上で,シェーダファイル名を指定して行っている。
シェーダのパラメータとして,マテリアルとテクスチャ,さらにUVアニメーションや個別パラメータも設定可能。そのプレビューはツール上で確認できる。基本的な質感は実機と同様だが,ポストエフェクト処理とダイナミックな光源には未対応で,除外されたものになっているという。
最終的には,モデルのマテリアル情報としてシェーダとパラメータをセットにしたものを出力する。その際は独自フォーマットのエクスポーターを使用するとのこと。
PS3というターゲットに対する最適化の指針は,PCとのマルチプラットフォーム環境,バイナリの互換と,同様の挙動は維持すること。ゲームアプリ開発者には出来るだけ負担をかけないよう,中間のライブラリ層で吸収させることを前提に考えること。意味のない最適化は自己満足にしかならないので,実シーンの解析を行って効果の大きい最適化を施すことの3点となる。
ここでは,「龍が如く」での実例でより深く説明が行われた。この実例でのSPU(Synergistic Processing Unit )の利用についてパネルで詳しく解説されていたので,こちらも併せて掲載しておこう。
第3部・デバッグ編
まずは,ランタイムデバッグ時に使う主な機能について,紹介しておこう。実機デモによるデバッグの実演も行われたので,そちらの画像も確認しながら読んでもらいたい。
●デバッグカメラ(free tracking view)
自由に視点を切り替えられるカメラ。ゲームカメラで目視しづらいバグの確認に用いる。
●デバッグストップ(pause)
実行フェイズを一時停止できる機能。デバッグカメラとの併用で細かい場所もチェックできる。
●デバッグウィンドウ(tweak window)
各種パラメータ類を調整可能なGUI風ウィンドウで,ゲーム進行からグラフィックの調整まで幅広く活用。
●シナリオセレクタ(scene selecter)
途中のシナリオから開始することが可能。
●どこでもセーブ・ロード(all-time save and load)
どこでもセーブとロードが可能。バグ報告に出来る限り添付してもらう。
●スクリーン・ムービーキャプチャ(scene capture)
ビットマップやAVIでキャプチャ可能。こちらもバグ報告に添付してもらう。
実機デモの後は,プロジェクト運用を支援する技術のポリシーが語られ,実際のプロジェクト運用支援技術に関して四つの具体例が紹介された。
その一つが,ゲームアプリケーションのデイリーリリース。これは1日に1回,最新のゲームアプリケーションをビルド,チェックしてリリースするというもの。このとき,アプリケーションの配布はTiVersionを用い,開発初期からデバッグ期間まで行われているようだ。ここで大事になってくるのは,データのエラーチェックを入念に行い,問題がプロジェクト全体に影響を及ぼすのを防ぐこと。また,デイリーリリースの時間割をきっちり決めておくことで,規則正しいスケジュールで人が動けることも利点となる。
二つめに説明されたのは自動ビルドチェックだ。これはデイリーリリースでも活用するSubversionの更新とビルドを繰り返し,ビルドエラーが発生したら自動でエラーメッセージを送信するというもの。メリットとしては,デイリーリリース環境で正常にビルドができる状態を維持できることと,何によって警告が出てしまうのかを学習できる点を挙げていた。
三つめは,プログラムの例外により異常終了したときに,デバッグに必要なファイルと共にメールを送信するエラーレポート機能だ。この機能で送られるファイルについてもここで紹介しておこう。エラーレポート機能のメリットは,バグ報告をする人員の手間を軽減できることと,早期にバグが検知できることだ。
最後の四つめは,AutoTest(動的テスト)で,その内容はゲームパッドの入力をランダムに発生させて,総当りでプログラムの異常個所を見つけることが目的に行われる。その流れは,まずはExcelで記述した設定ファイルをiniファイルに変換し,TiVersionでアップデート。その後テストを実行し,エラー発生時にはその旨が送信され,AutoTestの再起動が行われる。「龍が如く」シリーズ初期は,手順の初期段階を手動で行っていたが,人力ゆえのミスも多く,「龍が如く4」から,このAutoTestを運用を始めたのだという。
なお,AutoTestは約80台あるという開発用PCで実行している。実施されるのはデバッグ期間のみで,PCが空いている休日や深夜を有効に使っているのだそうだ。
「龍が如く4」の場合,AutoTest設定ファイルの記述は時枝氏と若手プログラマの2人で行っていたという。横軸にあるのが実際にテストを行う項目を表している |
Excelによる記述さえ行っておけば,開始ボタンを押すだけでAutoTestが自動で行われる |
プログラマとしての立場から,効率の良い作業を行うために行った創意工夫を惜しげもなく語ってくれたセガ第一CS研究開発部所属の講師3人。プログラマを本職とする人には,有意義なセッションとなったのではないだろうか。最後に,当セッションで話された内容をまとめておこう。
●事前準備で高速化を可能な限りやる
・予算の許す限り,高性能な機材を導入する
・ツールやデバッグ機能の作成に手を惜しまない
●メンバーが仕事をしやすい環境を整える
・PCでゲーム機と同様の動作をする環境を構築する
・メンバー間のコミュニケーションを密に行う
●プロジェクトを安定させる努力をする
・プロジェクトに潜んでいる余り時間を有効活用する
・人手のかかる容易な作業はツールで代替してミスを防ぐ
- 関連タイトル:
龍が如く4 伝説を継ぐもの
- 関連タイトル:
龍が如く OF THE END
- 関連タイトル:
龍が如く3
- 関連タイトル:
龍が如く 見参!
- この記事のURL:
キーワード
(C)SEGA
(C) SEGA
(C)SEGA
(C)SEGA