［AOGC2007＃17］ガンホーの堀氏，ついに「Project：“Rondo”」を語る

　昨年（2006年）のAOGCで「ソフトウェアプラットフォーム」として語られたガンホー・オンライン・エンターテイメント（以下，ガンホー）年来の開発案件，「Project：“Rondo”」（旧名　Codename：Rondo）の大枠が明かされた。本日（2月23日）行われた，AOGC 2007二日目第4講，ガンホー 取締役開発本部長 堀 誠一氏の講演「オンラインゲーム開発への道程」での話である。
　BBA側からコミュニティに絡めた講演を頼まれたという氏は，話のまくらとして，今年はマズローではなくテンニースの「ゲマインシャフトとゲゼルシャフト」を援用した。手っ取り早く言うと，ゲマインシャフトとは家族とか村とか，自然発生的な性格の強いコミュニティで，相互信頼と結束の固さを特徴とする。それに対してゲゼルシャフトは，明瞭な意志を持って作られ，契約関係などで支えられた団体を指す。
　この二つを対立軸の両端に据えて堀氏は，ファンの形成にはゲマインシャフト的なあり方が有用で，ゲームの進行やプレイ目標に依存したゲゼルシャフト的あり方は顧客単価を上昇させることに貢献する，といった分析を加えていった。

　ゲームの展開とコミュニティのあり方を筋道立てて考えるに当たって，このアナロジーは確かになかなか有用なものに思える。ただし，例えばゲゼルシャフト的あり方に対して，やや否定的な論調が強かったのは，ガンホーで氏が積み重ねてきたミッションに由来するものなのだろうかといった興味を，惹かないこともない。例えばFPSのクランなどを想定すれば，ゲゼルシャフト的あり方を強く持つことでしか，成り立ち得ないゲームコミュニティもあるのだから。




　さて，余談はどこまでも余談として。堀氏はオンラインゲーム開発の壁として，以下の三つを挙げる。

1.ゲームモデル（処理系）とUIの乖離
2.不特定発生事象の考慮の不足が致命的
3.アップデートの脅威

　1.は，オンラインゲームではスタンドアローンのゲームと異なり，重要なプログラムやデータがクライアントPCのメインメモリにすべて展開されることがないため，「重いメディア」を引きずっているのと同じことだ，というもの。この論点については講演で回収されていないため，本稿でも深くは掘り下げない。
　2.は，ゲーム開発に当たって細かい処理手順などが明確に決まらないまま，とりあえず作ってみて，問題が出たら都度切り抜けるといった方法が持つ限界を示したもの。処理が体系的に設計されていないため，あとでいかにもできそうな変更が，些細な理由でできなくなっていたりする，ということである。
　3.は，オンラインゲームにつきものの，要素追加についてだ。データを追加していくなら，グラフィックスをはじめとして，それにかかる労力を事前に見込んでおかないと，あとで苦労するよ，というお話である。



　上記2.と3.の問題に対処すべく，ゲーム開発のフレームワークとして，ガンホー内部で構築されつつあるのが，Project：“Rondo”ということになる。講演ではガンホー自身の歩みを追いつつ，Project：“Rondo”の概要と考え方が順に説明された。
　講演を聴いた限りでざっくり捉えるなら，フレームワークたるProject：“Rondo”は，開発ツールや，それで作ったデータ/ライブラリの引き継ぎ方法，あるいは人的配置や代替人員の養成までを含み込んだ，会社としての開発体制そのものを指すようだ。
　要するに，いままで職人芸の延長だったゲーム開発を，大規模プロジェクト化したオンラインゲーム開発の実態に合わせて，分業/協業できるようにしていくためのもの，であるらしい。
　作品単位でなく会社として取り組むということは，その体制でいくつもの異なったゲームを作れるよう，コードやデータの継承性/再利用性が重視される。ただし，それを完全に確保することはできないし，する必要もない（それでは，別のゲームにならないのだから当然だ）。むしろツールにいたっては，良い物が出てきたら随時入れ替えていくといった柔軟性を，はじめから前提しているという。



　そうしたProject：“Rondo”が目指すのは，以下の4項目である。

1.ノウハウの集中化
2.生産効率の向上
3.追加開発ラインの潤沢化
4.独自性の創出

　1.は例えば，ネットワークラグの問題に長期間取り組んでいるプログラマーなど，そのゲームが成り立つかどうかを左右する人の意見が早期から尊重され，かつ必要なときに必要な情報やノウハウを突き合わせて検討/開発が進むような体制を指す。
　2.は，先ほどの「オンラインゲーム開発の壁」の3.で問題にしたデータ作成を，専門的に効率化できるような体制のこと。つまり，どんなアイテムがゲームに有用かという個別個別の話ではなく，どのみち要素追加が必要になるなら，量産の利く体制を別途工夫できる仕組みが合理的，ということだ。
　3.は，例えば他社と協力して開発を進めるとき，提示すべき作業の進め方をはじめから明確にして，いつでも予定外の戦力を投入できる体制をとりましょうということだ。
　4.は，以上のような組織的/合理的体制によって，純然たるゲームデザインにより集中できるだろうという見通しのことである。



　では，作品単位で考えたとき，どのくらいの部分がフレームワーク側から供給され，どこが独自部分となるのか。それを示すのが「開発考慮要件例」の図で，ここに挙げられた12の要素のうち，タイトル個別に作るのは2要素「クライアントゲームモデル」と「サーバーゲームモデル」のみ。残りの要素，描画エンジンやらログイン管理やら，パッチモジュールやらは，全作品で共通化して，いちいち作品ごとに開発しなくて済むものと構想されているのだ。
　講演ではそうした，共通部分の仕様を示す図が示されたので，まとめて写真を添えておこう。写真だけでは分かりづらいポイントについて補足しておくと，トラフィック制御エンジン“Red-Stone”や，インスタントデータトランスエンジン“Trench”などの説明にあるスケーラビリティとは，要するに，確保したい能力分だけ稼働サーバーを増やせば，それがそのまま能力向上につながるということ。性能的な限界が来たらいちいち作り直す従来のやり方に比べて，これが合理的な構造であることはいうまでもないだろう。

　このProject：“Rondo”の最初の適用例は，ガンホー開発作品の3作目となる「グランディアオンライン」であり，それは年内に稼働が始まる見通しとのこと。
　オンラインゲームの開発に分業と長期計画，そして破綻しない拡張手段をもたらすProject：“Rondo”は，さしあたりFPSの開発に耐え得る仕様が予定されているという。長期的な経済性はもちろんのこと，堀氏の言うとおり，これによって各タイトルの開発を純然たるプレイアビリティの構築に集中できるなら，確かにオンラインゲーム開発において，時代を画する手法が確立されたことになるのだろう。（Guevarista）