3Dゲームファンのためのグラフィックス講座
西川善司の3Dゲームファンのための「Panta Rhei」講座（前編）
カプコンの次世代ゲームエンジンから見えてくる新世代ゲームグラフィックスの方向性とは?
（2013/7/31 00:00）
- 6月取材
- カプコン本社
PS3、Xbox 360世代のゲーム開発シーンでは、ゲームエンジンの重要性が強く説かれることとなった。開発効率の向上はもちろんのこと、グラフィックスからゲーム性に至るまでの多角的なゲームの品質の底上げ、マルチプラットフォーム展開のしやすさといったあらゆる方面から見てゲームエンジンの概念の導入は理に適っていた。しかし、その実践に先行して勤しんでいたのは欧米のゲームスタジオ達だった。
そんな状況のなか、日本のゲームスタジオの中で唯一、気を吐いていたのがカプコンで、「世界に追いつけ追い越せ」をスローガンに、ゲームエンジン「MTフレームワーク」開発プロジェクトを発足。そしてこのMTフレームワークベースの処女作「デッドライジング」、第2作「ロストプラネット」が立て続けにヒットを記録。日本のゲームスタジオが実績を伴う形で、ゲームエンジンの有効性を見せつけたことで、日本のゲーム開発シーンも一気に「そちら」の方向へ向かい始めることとなる。いわば、カプコンは、PS3、Xbox 360世代のゲーム開発シーンを牽引してきたと言っても言いすぎではない。
そんなカプコンが、2013年2月に行なわれたPS4発表会にて、新エンジンの存在を明らかにした。しかも、それは「MTフレームワーク」の新バージョンではなく、フルスクラッチビルドの新規エンジンだった。今回は、「「Panta Rhei」（仮称）」と呼ばれているこの新エンジンの潜在能力について迫ってみることにしたい。
【著者近影】
「ピクミン3」が面白い。「ピクミン3」のような細々としたグラフィックス描写は、やっぱりHDグラフィックスとの相性がいい。もっといえば4Kとも相性がいいかも。Wii Uが4K対応になればいいのにと「ピクミン3」をプレイしながら思う今日この頃。写真はカナダのCNタワーの約350m付近の手すり無し屋外回廊を歩く体験ができるEDGE WALKツアー時のもの。ブログはこちら。
新エンジン「Panta Rhei」の背景～「MTフレームワーク」との互換性を捨てる決断へ
「Panta Rhei」の開発検討が始まったのは2011年の夏。MTフレームワークの開発コアメンバーによって行なわれた次世代ゲームエンジンの開発検討ディスカッションにおいて、MTフレームワークにおける問題点の洗い出しが行なわれた。幾つかの問題点においては、開発効率の悪化にも繋がっており、ひいてはエンジンのポテンシャルを活かしきれない局面も起こっていると分析される。
問題の1つ目として挙げられたのは、ゲーム開発プロジェクト終盤で行なわれるシェーダーの回収作業がとても大変なものになっているという点。
MTフレームワーク2.0から、シェーダーをソースコードレベルで抽象化する「メタシェーダーシステム」(詳細は本連載「MTフレームワーク2.0編」を参照されたし)が搭載されたが、この機能において、シェーダーを構成するパーツソースコードを回収するプロセスは規定されていなかった。そのため、この工程はゲーム開発プロジェクト側の裁量に依存する格好となり、最初からきちんと管理して開発が進められていればいいが、各アーティストが各々の好みでシェーダーパーツを組み合わせて開発しているとシェーダー回収段階で「そのシーンに必要なシェーダーが全て集まっているのか」、「余計なものを集めていないか」という混乱が生じることとなったのだ。
次世代エンジン、すなわち「Panta Rhei」では、この問題に対してエンジンレベルで面倒を見る決断を下したのだ。DirectX 11世代のGPUではシェーダーパーツをサブルーチン化して動的リンクできる仕組みを持っているので、そうした機能を駆使してこの問題に対して取り組むことになると思われる。
MTフレームワークの問題点の2つ目は、「リソース管理がMTフレームワーク側のツールで実践できていない」という点。MTフレームワークでは3Dモデル、テクスチャ、モーションデータ、サウンドデータなどのアセットデータのコンバートから実機向けへの組み込みは、サポートツールを提供する形で実践されていたが、コンテンツパイプラインをスムーズに流せるような仕組みにはなっていなかった。PS4やXbox Oneなどの次世代機では、さらにアセット量が膨大になることが予測されるため、様々なコンテンツデータの依存関係を管理して、実機に落とし込む工程などでは、そうした依存関係に配慮したコンバートを高効率に実践していく必要がある。新エンジンでは、この問題もエンジンシステム側で管理するように設計方針を固めることとなった。
もうひとつ、3つ目は問題点の解決というよりは改善項目ともいうべきものだが、それはゲームロジックを開発するためのスクリプティングシステムについて。MTフレームワークではゲームロジック部をC++で開発していたが、開発メソッドとしてやや高度過ぎる傾向があり、リンク時間も長くなりがちとなった。
そこで「Panta Rhei」では独自のバーチャルマシンを持ち、C#とC++を透過できるシステムを構築した。プログラマ側が機能等をC++で書くとこれが関数として登録され、C#から利用できるような仕組みだ。つまり、ゲームロジックを開発する側は面倒なプロパティ設定などを記述せずとも、C#でのゲームロジックコーディングが行なえるのである。
伊集院氏：MTフレームワークは、実機の性能を最大限に引き出すことを開発思想にして取り組んできたマルチプラットフォーム対応型ゲームエンジンでした。ある意味、性能重視のエンジンだったと言ってもいいかもしれません。新エンジンでは、そうした要素の追求ももちろん行ないますが、合わせて「開発のしやすさを追求する」という点にも注力して、基礎設計をやり直すことにしました。
開発方針を確定させた次世代エンジン開発チームは、検討の結果、大胆な結論を導き出す。それは、「MTフレームワークとの互換性を捨てる」という結論だった。つまり、MTフレームワークで用いてきたコンテンツパイプラインやワークフローを捨てるということだ。
伊集院氏：伊集院氏：ええ、それはもちろん、開発の現場からは疑問の声が上がりました。しかし、問題の根本解決を行なうには、MTフレームワークのアーキテクチャを継承してしまっては、それに引きずられることは明白でした。次世代の開発体制を実現するには、バッサリと行くしかなかったんです。
念のためにいっておくと「互換性を切る」とはいっても一般ユーザーには全く無関係のことである。関係あるのはMTフレームワークを活用して各ゲームタイトルを開発してきた開発現場のスタッフ達だ。現場からすれば、使い慣れてきた道具が新調されるようなものなので、確かに戸惑いが起こるのも無理はない話である。しかし、エンジン開発チームは決めた方針をぶらすことなく「この判断は開発効率を確実に底上げするためには必要不可欠である」と開発現場を説得。かくして、MTフレームワークとは別系譜の新エンジン「Panta Rhei」開発プロジェクトは2011年晩秋より開始されたのだった。
伊集院氏：「Panta Rheiって一体なんなの?」と聞かれたときには「ゲームエンジンである」という説明ではなくて「総合的なゲーム開発環境である」と答えるようにしています。ユーザーの皆さんを引きつけるためにはビジュアル面のステップアップが必要であり、そこで手を抜くことは絶対にできませんので、グラフィックスエンジン部分にはとても力を入れています。ただ、今回、我々が特に力を入れているのは開発効率を向上させるための、全方位的な環境整備なんです。
今回の「Panta Rhei」では、海外製ゲームエンジンで見られるようなレベルデザインツールも含まれるという。ただ「ゲーム開発に必要な要素を何から何まで自社開発する」という方針をとっているわけではなく、ゲーム開発チーム側がやりたいことを実現するために社外ミドルウェアの使用を選択する場合もあるとのことだ。この辺りの臨機応変さはMTフレームワークの時から一貫したコンセプトではある。