［CEDEC 2010］社内のゲーム開発基盤を整えてさらなる効率化を――サイバーコネクトツーの標榜する「開発の効率化を目指したゲームシステム」とは

左から，サイバーコネクトツー 開発支援室 技術開発チーフ 宇佐見公介氏，同 リードプログラマー 相場武友氏，同 プログラマー 片桐誉裕氏

　2010年8月31日から9月2日までの3日間，神奈川県・横浜市のパシフィコ横浜でCEDEC 2010が開催されている。
　ここでは開催初日に行われた，サイバーコネクトツーのプログラマーによるセッション「開発の効率化を目指したゲームシステム：サイバーコネクトツー，15年目のポストモーテム」をレポートしよう。

　二部構成で行われた本セッションは，同社で開発を重ねてきたゲーム開発基盤システムを題材に，その変化の内容や問題点を分析/検証し，今後どのような効率化を図っていくべきかを検討するという内容だった。
　なお本セッションに登壇したのは，サイバーコネクトツー 開発支援室から，技術開発チーフ 宇佐見公介氏，リードプログラマー 相場武友氏，プログラマー 片桐誉裕氏の3名である。

サイバーコネクトツー 公式サイト

　第一部「15年目のポストモーテム」では，まずサイバーコネクトツーがこれまで採用してきたゲーム開発基盤システムの変遷が紹介された。変遷はそれぞれ，初代PlayStation，PlayStation 2，PlayStation 3というプラットフォームの世代の節目に対応している。

　会社設立の1996年から1999年までは第一世代に当たり，初代PS用にSCEが提供していたツールを使用。担当する作業の多さからプログラマーの負担が非常に大きくなっており，またデータ管理を手作業で行っていたため，人為的なミスも多かったという。
　片桐氏は，データ管理の不備修正に多くの時間を取られていたと，当時を振り返る。


　第二世代では，その反省を踏まえて，データドリブンで作業を行えるよう「CCS」と呼ばれる基盤システムを自社開発した。
　このシステムにより，アーティスト（デザイナー）が演出やアニメーションなどを担当することになり，プログラマーの負担を大幅に軽減。加えて補助ツールを開発することによって，さらなる効率化を図ることができたという。
　なおCCSは，タイトルごとにカスタマイズされており，必要な機能をマージしながら更新を重ねてきたそうだ。そのため，タイトルに特化したチューニングが可能という利点があったが，逆に一元管理をしてこなかったがために，作を重ねるほどマージが大変になり，問題が累積していくというデメリットも生じていった。

　そしてPS3の登場と同時に，新たな開発基盤が必要となった。ここで肥大化したCCSは一旦破棄して，第三世代の「NUCCライブラリ」を開発することとなったのである。
　このライブラリは，バンダイナムコゲームスの「NUライブラリ」をベースにしたもので，ツール群をPS3/Xbox 360に合わせて作り直したりしたものの，基本的なワークフローはCCSと大きく変わることはなかったという。


　相場氏は，サイバーコネクトツーの開発基盤は，第二世代で実装したシーンのストリーミング機能に拠るところが大きいと説明する。
　3dsMaxのシーンファイルをそのまま実機で再生できるため，ゲームの開発が進行していなくとも，アーティスト側が先行してイメージを制作することが可能となり，初期のプレゼンで多大な説得力を持たせることができたという。
　またシーンベースのアニメーション表示では，モデル素材とエフェクトをすべて合わせた状態での処理が可能となり，プログラマーとアーティスト双方の負担を軽減することができた。
　これは，当初プログラマーがアニメーションの制御を行うことを想定していたが，予想以上にシーンベースのアニメーション表示の使い勝手がよかった結果によるものだとのこと。
　レイヤー機能では，アーティストが描画の優先度を管理することも可能で，さらに，シェーダの描画パスの管理にも利用されている。


　そのほか，データフォーマットを作成するにあたり，素材ファイル一つにつき出力ファイルを一つにする，デバッグ時にエラーの発生箇所を特定しやすいよう，データソースのファイルパス情報を埋め込むなど，データ管理時にミスが起きにくくする工夫が加えられている。これらの機能は，第二世代でほぼ完成していたとのこと。


　第二世代の完成度を引き継いだ第三世代だったが，数々の問題点もそのまま引き継いでしまったと，宇佐見氏は述べる。
　一つはデータフォーマットの問題である。第二世代はバイナリフォーマットだったために，拡張フォーマットが必要な場合，追加に多くの手間がかかってしまうそうだ。
　また，プロジェクトで拡張データが必要になると，担当者がそれぞれ独自のフォーマットを作ってしまい，ツールの扱いに統一性がなくなってしまうという問題も発生した。
　第三世代は，それらの問題をそのまま引きずっているという。

　そして統一性のないデータフォーマットに関連して，シェーダの汎用性の問題も発生した。本来なら第三世代開発の時点で統一フォーマットを実装すべきだったのだが，時間的な問題で見送りになってしまったとのこと。それがボディブローのようにジワジワと効いてきてしまっているそうだ。
　ツールの実装は開発者任せのため，開発者ごとに操作や完成度にバラつきがある，プロジェクトスケジュールが最優先のためメンテナンスが後回しになる，といった問題につながった。
　結果として，ツールの完成度を上げることができず，たとえば，使い勝手が悪いと担当者が入れ替わった時点でツールを作り直すといった，非効率な状況が発生してしまったのだ。

　そのほか，GUI Toolkitが実機に依存しているために使い勝手が悪く，フォーマット間の移行が難しいといった問題も存在している。
　こうした数々の問題点を踏まえて，宇佐見氏は拡張性ツールの重要性を訴え，問題点を以下のように掲げた。

・ゲームプロジェクトへの依存
　サイバーコネクトツーでは，ゲーム開発のスケジュールに沿って開発基盤の構築が行われてきたために，時間的/人的制約が課せられ，完成度よりも実装が優先されてしまった。
　また外的な要因として，プラットフォームの世代交代も挙げられた。

・ゲームの複雑化
　ゲームの進化に伴って，ツールが増大。さらにプロジェクトごとに機能を追加することによってシステムが肥大化し，メンテナンスの不行き届きや，処理速度低下といった事態を招いた。


　第二部「新しい開発環境に向けて」では，第一部で指摘された開発基盤の問題点をクリアするための試みが紹介された。
　プロジェクト依存に関しては，社内体質から改善し，独立した「開発支援室」を設立した。その中でも開発基盤の管理をするのが，「技術開発」部門である。
　しかし，独立したとはいえ，人的リソースの問題で，結局はプロジェクトに左右されるケースが多いという。そこで宇佐見氏は，明確に目標を設定し，社内におけるヒアリングなどを通じて部門の意思表明をしていくことが重要だと述べる。
　いきなり大きな目標を立てても，リスクやコスト，そして時間の関係で達成は難しいため，小さな内容から導入していく。ゆくゆくはフレームワーク，ゲームエンジンへと目標を高くしていく予定だ。

　ゲームの複雑化に関しては，市場の要求からすると，簡略化すればいいというものではない。そこで下位の問題をクリアすることになるわけだが，システムは拡張性を持たせてモジュール化し，また使う側の操作を共通化していくこととなる。


　しかしライブラリを揃えただけでは，実際に使ってもらえないという問題が生じる可能性がある。そこで宇佐見氏が進めているのが「ゲームデータ・エディタ」の導入だ。これはゲームエンジンに組み込まれている，オブジェクトのプロパティを変更する仕組みに近いものとのこと。
　また，このエディタの導入により，最適化されたデータのみをゲームアプリ本編に落し込むような仕様を考えているという。さらに具体的な利用方法としてExcelシートのデータをGUIで調整したり，開発機ではなくWindows上のGUIエディタを利用したりといったアイデアが披露された。


　そのほか将来的な展望として，「レンダリングパイプラインエディタ」「ゲームフローエディタ」が紹介された。
　こうした要素の導入により，サイバーコネクトツーの開発体制は，これまでのアーティスト主導から，ゲームデザイナー主導になる見込みであると，宇佐見氏は述べる。それはすなわち，早い段階からゲームの全体像を確定させることに繋がり，その結果，ゲーム開発本来の姿が実現できるというわけだ。

　宇佐見氏は最後に，社内の開発基盤を整えることが重要と述べ，そのためのポイントを「体制の見直し」「ポイントの絞り込み」「小さいことから始める」とまとめ，さらなる開発の効率化の可能性を示して締め括った。