【CEDEC 2010】開発基盤システムはどこへ向かう。サイバーコネクトツー、15年目のポストモーテム | GameBusiness.jp

【CEDEC 2010】開発基盤システムはどこへ向かう。サイバーコネクトツー、15年目のポストモーテム

その他 その他

ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
  • ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。
ゲーム開発を効率よく進めるために、開発基盤システムはどうあるべきか。創業15年目を迎えた株式会社サイバコネクトツーでのケースについて、同社の技術開発チーフ・宇佐見公介氏、相場武友氏、片桐誉裕氏が語りました。

セッションが行われた会場は開始前から超満員。同社の松山洋社長が自ら関係者席に聴講生を案内するほどで、その注目度の高さがうかがわれました。なお本セッションは、同社内で用いられている職種名を用い進められました。同社では北米で一般的な呼称に合わせているため、たとえば他のメーカーではプランナー、企画と呼ばれる職種が「ゲームデザイナー」に、デザイナーと呼ばれる職種が「アーティスト」になります。

左から宇佐見氏、相場氏、片桐氏


■15年間の道のり

同社の開発基盤システムには3つの世代があるとし、それぞれPSの時代、PS2の時代、PS3の時代と言い換えることができるといいます。

第1世代は基盤となるシステムがなかった時代。SCEから提供されるものを利用していました。当時はプログラマがエフェクト、パーティクルの表現、カットシーンの演出まで担当し、負担がとても大きかったとのこと。データ管理も手作業で、ヒューマンエラーが多かったのと片桐氏は振り返ります。

第2世代では開発基盤システムCCSを開発。これによりエフェクトやカットシーンの演出はアーティストの作業になりました。また補助ツールでデータ管理などを行うことにより、開発の効率化が進められたといいます。

CCSはのちに移植。さまざまなバージョンが派生。タイトルごとに独自カスタマイズを行っており、別タイトルで作った機能を取り入れていきます。こうしてタイトルに特化したチューニングを行えるようになりましたが、のちにマージ作業が他の作業を圧迫。問題が累積しても修正しづらい状況になっていたといいます。

CCSの派生図


ワークフロー。赤い部分が第2世代から変わったところ


そして第3世代へ。ここで肥大化した基盤システムをいったん捨て、新たにNUCCライブラリを開発します。これは株式会社バンダイナムコゲームスが開発したNUライブラリをベースに、CCSの機能を追加したものです。

この第3世代で開発基盤システムは大きな変貌を遂げたものの、開発ツールやワークフローは前世代からほとんど変わっていないといいます。また、このときの移行ではコストが少なくて済んだものの、いまだ見直しができていないという現状もあるとのことです。

こうして同社の開発基盤システムは、効率化がまったくされていなかった第1世代から、第2世代である程度の効率化。その思想を引き継いで第3世代に入ったわけです。

第2世代で効率化に成功した背景には、次のような機能があると片桐氏はいいます。

「ストリーミング・シーン再生」『3ds Max』上に表示されたシーンを実機上でも再生できるため、開発初期段階でのプレゼンなどに利用でき、ゲーム本体の開発が進んでいなくても先行してムービーを作成できたといいます。

「シーンベースのアニメーション表示」これは従来モデルにアニメーションを割り当て、エフェクトを重ねるという作業を行っていたものを、すべて組み合わせた状態で表示する機能です。キャラクター+エフェクトのシーンでもプログラマの作業が発生せず、負担が軽減されました。またアーティストも、モデルとエフェクトを組み合わせたまま開発できるようになったといいます。

レイヤー機能


「レイヤー機能」どこを優先して描画するかを管理するためレイヤーを用意。これをアーティストが管理し、どのオブジェクトをどのレイヤーに置くか決めます。第3世代の開発基盤システムでは複数のパスを使うシェーダーの管理にも利用されているといいます。必要に応じてレイヤーに機能を追加できるため、たとえばメニュー画面を追加したいときには、そのレイヤーを指定すれば済むとのことです。

その他、ミスを減らすため、1ソースファイルにつき出力するファイルはひとつとする。データ内にデータソースのファイルパスを埋め込む。メモリの確保サイズがわかるようにフォーマットを作る、といったデータ管理上の工夫がなされているといいます。

■超えるべき問題

しかし、第3世代の開発基盤は第2世代をもとにしたものであるため、内在していたデメリットまで引き継ぐ結果になったといいます。

問題点のまとめ


第3世代で顕著になったのは、データフォーマットの問題です。第2世代で固定のフォーマットを使っていたため柔軟性がなく、新しいデータを追加する際に手間がかかるといいます。またプロジェクトごとに拡張データが必要になりますが、結局は各担当者が独自フォーマットを作ったほうが早く、無駄な作業が多くなったといいます。

それに付随し、シェーダー対応の問題があります。シェーダーのプログラミング内容によって、入力されるデータが変わりますが、本来ならば汎用性のあるデータフォーマットがあるべきだといいます。しかし同社では、時間的な制約から実装が先送りにされ続け、結果「のちのちボディブローのように効いてきた」といいます。

開発ツールについても担当者ごとに完成度のバラつきがあるうえ、プロジェクトが優先されてメンテナンスがおろそかになる問題があるといいます。結果、担当者が変わると同じようなツールの作り直しが発生しているとのことです。

たとえば同社ではデバッグのためのリソースエディタをゲームアプリケーション側に作っています。これは有効に機能したものの、パッド操作がしにくい、他のコンソールへの移行が難しいといった弱点があるといいます。

こうした問題のほとんどがツール関連のものばかりで、プロジェクトが大規模になるに従い、ツールの必要性と拡張性が求められてくるとのことです。

ライブラリを整備するだけでは・・・


こうした問題の原因は、プロジェクトへの依存が強まったことと、ゲームが複雑化していることにあります。プロジェクト依存とは、開発基盤システムの完成度がプロジェクトの動向に影響されることで、実装優先のためにマニュアルが整備されないという問題などが起こります。また、ゲームが複雑化・肥大化することにより、内製ツールの数自体が増え、そのメンテナンスに追われることになるというのです。

こうした悪循環を断ち切るためには――。

■小さな一歩から

ここからは問題に対し、どう対処していくかについて話が進められます。

独立した部署を


ひとつはプロジェクト依存からの脱却。会社の体制を見直し、プロジェクトから独立した部門の設立が必要だと宇佐見氏は考えました。ゲームの複雑化については、市場の要求に応えたものである以上「ではゲーム内容を簡単に」というわけにはいきません。ならば、そこに付随する問題に対処していこうという話になったといいます。

同社では2年前に開発支援室を設立。プロジェクトからの独立した形でゲーム開発のための基盤整理を行っています。設立当初は人手不足からプロジェクトのヘルプに入ることが多くあったものの、明確な目標を立て社内にアピール。上司を説得することで部署の存在意義を訴えたといいます。

開発支援室の最終的な目標は内製のゲームエンジンを作ることにあるといいます。そのためにまず小さな実装から導入し、それがうまくいけばフレームワークの開発へ、そしてエンジンの開発に着手するという段階的な目標を設定したといいます。

さしあたって内製ツールの開発環境を整備する必要があります。ツール作成の手順を共通化したり、インターフェイスを共通化したりすることで、ツールの増大に対処したいとのことです。また、『Excel』との相互機能を充実させ、いったん出力したデータを書き戻せるようするなどしたいといいます。

共通データフォーマットについては、第3世代で実装したGUI Toolkitをコンソール側でなくWindows側に持ってきたいとのこと。ビジュアルプログラミングについては、今後アーティストがツールを使う機会が増えることが予想されるため、制御フローを視覚化。さらに、こうしたライブラリを活用してもらうため、ゲーム本体から切り離してゲームデータ・エディタを用意し、汎用性を高めたいといいます。

同社のゲームデータ・エディタは次のような構成になる予定です。

ゲームフローエディタ


まず「ゲーム構造エディタ」これはクラス設計をするツールで、データの構造を規定します。そして「データエディタ」でデータの編集を行い、「データ最適化」を盛り込むことで、デバッグ時の情報を削除します。

データ編集する仕組みについては、ゲームから独立させるとリアルタイムでの編集がしづらくなり、かといって内包するとゲームが重くなるという問題があります。

そこでゲームデータ・エディタはゲームから独立し、なおかつ同期の取れる通信同期型を採りたいといいます。それによってコンソール依存を軽減し、ターゲットが変わっても開発を続けられるようにしたいとのことです。

その先の展望として、「レンダリングパイプラインエディタを作りたい」と宇佐見氏。他のハードに移植するとき、レンダリングパイプラインをカスタマイズできるほうが便利だといいます。これには先ほど述べられた、レイヤー機能を応用するとのことです。

また、氏はゲームフローエディタの用意も考えています。

同社ではゲームデザイナが少ないという事情があり、ゲームの全体像が見えてくるのが遅く、「実装してみたら仕様が足りない」ということがあるといいます。これを解決するため、あらかじめゲームフローを視覚化するというのです。

それにより「これまでイメージから入るアーティストドリブンだったゲーム開発を、ゲームをデザインする側から製作するデザイナードリブンへの移行をしたい」といいます。

「中小ディベロッパーではミドルウェアを使った方がよいと思われるかもしれない」と宇佐見氏。「それも選択肢のひとつだが、プロジェクトやジャンルによって合わないものもある。いずれにせよ会社独自のものが必要になる」といいます。

まずは会社の体制を見直し、問題点を洗い出す。小さなことから始めていけば、中小ディベロッパーでも開発の効率化はできるはずと、同じような悩みを抱える同業者たちを励ましました。
《土井大輔》

関連ニュース

特集

人気ニュースランキングや特集をお届け…メルマガ会員はこちら