ゲーム開発者向けツール&ミドルウェアの総合展示会“Game Tools & Middleware Forum 2013(以下、GTMF)”。2013年7月19日の大阪開催に続いて、2013年7月23日には秋葉原UDXにて東京でのイベントが開催された。
最後に行われたSCE提供によるふたつのゲストセッションの後半では、JET RAY LOGICの松田太郎氏により、PS Vita用ソフト『箱! -OPEN ME-』の開発の裏側が明かされた。
松田氏いわく、本作は「ミドルウェアなしでは到底不可能なプロジェクト」であったという。なんせチームは6名しかおらず、しかもその中でプログラマーは松下氏1名のみ。プログラマーの手をわずらわせないような効率化をどこかで行わなければいけないのだ。
最後に行われたSCE提供によるふたつのゲストセッションの後半では、JET RAY LOGICの松田太郎氏により、PS Vita用ソフト『箱! -OPEN ME-』の開発の裏側が明かされた。
松田氏いわく、本作は「ミドルウェアなしでは到底不可能なプロジェクト」であったという。なんせチームは6名しかおらず、しかもその中でプログラマーは松下氏1名のみ。プログラマーの手をわずらわせないような効率化をどこかで行わなければいけないのだ。
▲開発スタッフは6名の小規模チーム。しかもプログラマーは1名。ミドルウェアなどでどこかを効率化しないと無理ゲー。
|
例えば本作では最終的にコラボレーションも含めて全62箱(ステージ)が制作されるのだが、その1個1個が独自の仕掛けとなっている中、アイデアの実装にいちいちプログラマーの手を借りていたら、とても無駄が多い。
プロトタイプの開発中にそのことに気づいたことで、制作フローも変化。本制作では5人のゲームデザイナーがスクリプトを組んで自分たちで実装を行うようにし、プログラマーはシステムやネットワーク(本作には協力プレイがある)の構築に専念するようになっている。
プロトタイプの開発中にそのことに気づいたことで、制作フローも変化。本制作では5人のゲームデザイナーがスクリプトを組んで自分たちで実装を行うようにし、プログラマーはシステムやネットワーク(本作には協力プレイがある)の構築に専念するようになっている。
▲約8ヶ月、実質約6ヶ月の中で、全62ステージ……いや、全62箱を作る。一個一個にプログラマーが関わっていたら無駄が多い。というわけでステージはプログラマーの手を借りずにスクリプトで組むように制作フローを組む。
|
そしてミドルウェアの採用も実行し、開発工数を節約。最終的に、カメラを通して箱を呼び出すAR(拡張現実)部分にソニーのSmartAR、エフェクト部分にBISHAMON、サウンド部分にSCEのJapan Studioの内製ライブラリが使われている。
▲AR(拡張現実)部分や、エフェクト、サウンドなどでミドルウェアやツールを採用。
|
しかしSmartARの採用決定に至るまでは紆余曲折があったそうで、同じソニーグループ内のWAARやMagnetの採用も検討し、一長一短に悩む中、SmartARのバージョンが上がって認識に改善が見られたことで採用が決まったとのこと。
▲どのARライブラリを使うか? 日本のSmartAR、アメリカのWAAR、ロンドンのMagnetは、どれも不安定だったりリリースが不透明だったりして一長一短。
|
▲コラボレーションを実現するためにはオリジナルのマーカーが必要となる。
|
本作にはコラボレーションの関係でオリジナルマーカーを作らなければいけないという要件もあり、安定して高い精度で認識できるマーカーはどんなデザインが適しているかという試行錯誤も行われている。ちなみにMagnetはマーカーを使わないARライブラリであるため、この点でも採用に適さなかった模様。
最終的にSmartARの採用が確定したのは開発終盤となる5ヶ月目だったそうで、松田氏はこの点について、ミドルウェアを使うこと自体は簡単だが、最大限に利用するのは大変であると述べていた。
最終的にSmartARの採用が確定したのは開発終盤となる5ヶ月目だったそうで、松田氏はこの点について、ミドルウェアを使うこと自体は簡単だが、最大限に利用するのは大変であると述べていた。
▲どんなマーカーが適しているか模索。程よくランダム性があるタイポグラフィが優れているという結果に。
|
まとめとして最後に、松田氏が考えるミドルウェア採用のメリットとデメリットが挙げられた。プログラマーの工数を減らせること、トライ&エラーの回数を減らせること、ゲームデザイナーやプランナー側の対応で多くの問題が解決できることをメリットとして挙げていたが、これらはまさに本作に必要とされていたことだろう。
一方デメリットとしては、「本当に必要なのか」と問われがちで、きちんと資料を作るなどして説得すべきであると解説。また外部ツールなどではブラックボックスとなっている部分が往々にしてあること、往々にして補完するプログラムを書かなければいけないことなどを指摘。そして改善要求をした場合などに修正対応されるかどうかが不透明であるため、採用段階からの交渉や、開発側との関係構築をしっかり行なっておくべきであると語り、発表を締めくくった。
一方デメリットとしては、「本当に必要なのか」と問われがちで、きちんと資料を作るなどして説得すべきであると解説。また外部ツールなどではブラックボックスとなっている部分が往々にしてあること、往々にして補完するプログラムを書かなければいけないことなどを指摘。そして改善要求をした場合などに修正対応されるかどうかが不透明であるため、採用段階からの交渉や、開発側との関係構築をしっかり行なっておくべきであると語り、発表を締めくくった。
▲このプロジェクトにおいては、プログラマーの工数を減らし、デザイナー側の対応で大体解決できるというのが効いた形。一方でミドルウェアの開発側との関係構築や、採用にあたっての管理側の説得などが重要だという。
|
0 件のコメント:
コメントを投稿