【CEDEC 2012】開発環境共通化の意義とメリット ― カプコン「MT FRAMEWORK」の場合 | GameBusiness.jp

【CEDEC 2012】開発環境共通化の意義とメリット ― カプコン「MT FRAMEWORK」の場合

その他 その他

スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
  • スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。
スクウェア・エニックスの「共通DCCツール環境」に続いて、内製ツールを発表したのはカプコン技術研究部の大井勇樹氏です。カプコンの内製ツール「MT FRAMEWORK(MTF)」について、先ほどのセッションとは違った切り口で環境共通化についてのセッションが行われました。

「MTF」は、今や知る人ぞ知るゲーム開発フレームワークです。どのような経緯で誕生し、現在のように同社を代表するエンジンになったのでしょうか。

2004年頃、次世代機開発対応の一環として開発がスタートしました。2006年に発売されたXbox360ソフトの『デッドライジング』『ロストプラネット』が初のMTF採用タイトルになります。その後は社内でもより広く認知され、PS3版『ロストプラネット』やPS3/XBOX360ソフト『デビルメイクライ4』などで、プラットフォームを越えた共通化が達成されました。そして、2011年の『ULTIMATE MARVEL VS. CAPCOM 3』ではプラットフォームだけでなく、会社も超えて共通化が可能になりました。

ですが、MTFが社内で地位を築くまでには紆余曲折があったそうです。例えば、周囲からはこんなことを言われたとのこと。

1、「共通のエンジンを使っていては、一番大事なゲームの個性が失われる」(タイトル側)
2、「プラットフォームで共通化したら、プラットフォームごとの強みが生かせない」(プログラマ)
3、「各タイトルにあわせて一番慣れた方法で開発するのが一番低コストなんじゃないのか」(エラい人)

大井氏によれば、タイトル側(ゲーム制作側)とエンジン側(MTF制作側)が求めているものや、考え方が対立してしまっていた(エンジン側は全体に最適なモノを制作しなければならないが、タイトル側は自分の作っているタイトルが良ければ問題ないというような考え方の相違など)ということです。それを乗り越えるためには、

・否定的意見に安心感を与える
・問題(バグなど)が起きれば即座に対応し、軽減もしくは回避する方法を探す(≒サービスを提供する)
・回避できないいデメリットがあるなら、それを上回るメリットを増やす

最終的に「使った方がいい」と判断してもらえれば良いだろうという結論にたどり着いたということです。まず先ほどの周囲からの否定意見に対しては、

1、「エンジン部分を開発する手間を、個性を出す方向に割けば十分に出せる」
2、「移植の手間が軽減すれば、プラットフォームの個別対応に時間をさける」
3、「1回覚えれば、2回目からはほぼノーコストになるから、長い期間で考えたらコストは安い」
このようにして、安心感を与えていきながら、「開発環境共通化はサービス」という大井氏は様々な施策を打ち出しました。まずは、タイトルから出た意見や要望を共有する場を週単位で提供しました。担当者同士のやりとりだけでなく、問題も要望も、社内で共有し、開発環境への習熟度を高めたということです。次にとった施策は、タイトル側とエンジン側の橋渡しになる「指南役」を設置しました。今ではテクニカルディレクターという職種で定着しているとのことです。そして、最後にタイトル側にも様々な技術提案を行い、最先端の技術トレンドも常に吸収していくようにしていったとのことです。

このような施策をとりながら、コミュニケーションをとることで、今日では多くの作品で使われるようになりました。大井氏はこのなかで学んだという3つの教訓ですが、一つ目は「担当領域の線引きが大事」ということです。互いの領域を侵さずに、責任の所在は明らかにしておくべきだということです。次に、「地道な継続が肝心」だということです。前述の「サービス」という言葉の通り、要望対応や不具合修正などをコツコツ重ねることで、利用者の拡大につながったそうです。そして、最後には「双方の協力体制が不可欠」とし、意見が違うながらも、お互いを認め合っていかなければならないとしました。

では、実際に「MTF」を導入してどのようなメリットがあったのかを職種ごとに説明していました。プログラマの場合は、コーティングスタイル・設計思想を共有できるので、ソースコードの可読性が向上するそう。また、アーティストの場合は、タイトルが変わってもやりたい作業がすぐにできる環境があるということです。そしてマネージャーは、同じ環境で開発するので、純粋な適性と能力だけでプロジェクトにアサインできるということです。

最後に、大井氏は「開発環境共通化はサービスだ」と再びまとめ、だからこそ、作る側と使う側がしっかりと意思疎通をしなければならないし、「リスクとデメリットに対抗できるサービスとメリットを用意しましょう」と言いました。そして最後は「柔軟な意思と、明確な方針をもって取り組もう」と締めくくり、セッションは終了しました。
《宮崎紘輔》

特集

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