開発前にしておくべき事前準備とは？基本機能とプラグインの使い分けについて【開発編】RPG Maker 制作インタビュー - Cthulhu Mythos ADV 闇に囁く狂気
こんにちは！Gotcha Gotcha Gamesです。
Gotcha Gotcha GamesパブリッシュのRPG Maker製ゲーム、「Cthulhu Mythos ADV 闇に囁く狂気」での実際の制作事例を基に、ゲーム制作の進め方や開発時のTipsをインタビュー形式でご紹介いたします！
当記事はその「開発編」です。
「企画編」はこちら
・「Cthulhu Mythos ADV 闇に囁く狂気」とは？
『闇に囁く狂気』は、「クトゥルフ神話」をモチーフとしたTRPGが疑似体験できる2Dアドベンチャーゲームです。
物語は、主人公は気がつくと見知らぬ廃病院にいて、そこからの脱出を目指すことになります。途中、仲間やクトゥルフ神話の生物なども登場し、宇宙的恐怖と相対するストーリーが描かれます。選択肢の成否がダイスで決まる要素があります。
ダイスの判定によってTRPGのように異なる体験ができる点が特徴です。
当記事ではゲーム開発時にありがちな課題、基本機能とプラグインの使い分けや事前準備等について紹介をしております。
ある程度ツクールでの制作に慣れてきた中級者以上の方に向けた内容となります。
ぜひ最後までお読みください！
Cthulhu Mythos ADV 闇に囁く狂気を開発いただいたINAZUMA GAMESの川口隼人さん(以下、川口)にインタビューさせていただきました！
【リンク】
INAZUMA GAMES：https://www.inazumagames.co.jp/
──まず初めに、開発の流れについて教えてください。
川口：主に下記の4つに分類されます。
・仕様の確認、決定
・プラグインの選定
・デモの作成
・本格的に開発開始
──仕様確認について、より具体的に教えてください。
川口：本ゲームでは企画の段階でやりたいことは明確でしたので、それをゲームに落とし込むために仕様の確認及び決定をしました。
まず初めに、ゲーム全体の企画内容を確認します。文字通り、オープニングからエンディングまで全ての仕様です。
それがRPG Makerの基本機能で可能なのか、あるいはプラグインで対応可能なのか、選定していきます。
次にその仕様の実装に作業工数がかかりそうか、計算していきます。
本作品で言うと、2Dアドベンチャーゲームということもあり仕様はそれほど多くありませんでした。
──仕様決定段階で工夫された点がありましたら教えてください。
1つを例に挙げると、多言語対応です。
仕様決定段階で、英語と簡体字に対応する方針は決定していたので、対応コストが最小限になるよう事前に設計していました。
その為に、くろうど様が公開している「KRD_MZ_Multilingual.js」を使用しました。
少し高度なお話になりますが、イベントエディタ内に文章を言語分全て登録している訳ではありません。
このプラグインを使用して文章をJSONデータで外部化しています。
より具体的にお伝えをすると、イベントエディタ内で文章を直接入力するのではなく、代わりにIDを入力。
そのIDに準じた文章を外部のJSONで入力する形です。
基本機能だけで多言語対応しようとすると、対応言語の数だけイベントエディタに文章を入力する必要があるため作業工数が増え管理も煩雑になるのですが、このプラグインを用いることでイベントエディタ上での設定数が少なくなり後から見返しやすいです。
また、翻訳担当者がRPG Makerの内部を操作せずに、JSON上の言語を変更するだけで多言語対応出来ます。
本作品はアドベンチャーゲームで文章量が多いので、開発開始時点で多言語対応を見据えた設計にしておかないと多言語対応により多くの時間を要すことになっていたと思います。
【リンク】
Github - KRD_MZ_Multilingual.js : https://github.com/kuroudo119/RPGMZ-Plugin/blob/master/KRD_MZ_Multilingual.js
くろうどさん Twitter：https://twitter.com/kuroudo119/
──他に導入されたプラグインがありましたら教えてください。
多言語対応以外に導入したプラグインの1つとして、トリアコンタンさんが公開している「ピクチャのボタン化プラグイン」があります。
本ゲームには探索要素がありまして、当プラグインを用いて画像の特定要素をボタン化し、そのボタンクリックをトリガーにイベントを発生させています。
【リンク】
ピクチャのボタン化プラグイン：https://triacontane.blogspot.com/2015/11/blog-post_23.html
トリアコンタンさん Twitter：https://twitter.com/triacontane
──ちなみに、基本機能とプラグインの使い分けはどのようにされていますか？
川口：基本機能を優先して使用するようにしています。
本作品はRPG Maker MZで制作しており、基本機能だけでゲーム制作に充分な機能を備えています。
本ゲームはRPGではなくアドベンチャーゲームですが、アドベンチャーゲームも基本機能だけで充分に作成できます。
基本機能の「文章の表示」「スイッチ操作」「変数操作」「条件分岐」等のコマンドを10個程覚えるだけでアドベンチャーゲームは作成できます。
また、それらの基本機能を中心に使いやすいよう設計されており、基本機能を優先して使用した方が「後からイベントエディタを見返しやすい」等のメリットがあります。
プラグインは確かに便利ですし拡張性は高いですが、その分、機能数の多いプラグインや導入数が増えると競合問題が発生しやすくなります。
つまり、プラグイン同士で干渉しあってしまい、思い通りの動作をしない可能性が高くなってしまいます。
競合問題を解決するには導入したプラグインに精通している必要があり、プログラミングの知識が無い方にはレベルの高い作業です。
また、プラグインを数多く導入していたり高度なプラグインを導入している場合には、競合問題がより根が深くなってしまい問題解決に時間を要してしまいます。
なので、「基本機能を優先、プラグインを導入する際はピンポイントで課題解決出来るものを選定」するように心がけていました。
──公式だけでなく有志の方により公開されているプラグインも数多く存在します。どのように導入するプラグインを調査し選定されたのでしょうか？
川口：プラグインは検索すれば発見できますので、基本は検索して見つけたまとめ記事等を見たり有名なプラグイン開発者さんのプラグイン開発リストから探していますね。
日本語で無く英語で公開されているものも数多く存在しますので、英語で検索もよく行います。
また、RPG Maker製のゲームをプレーする際にはシステムファイルを見るようにも心がけています。どのプラグインが使用されているか確認出来るからです。
選定基準は先ほども述べた通り「ピンポイントで課題解決出来るもの」ですね。
競合問題を避けるため、多機能よりもスモールでピンポイントで課題解決出来るプラグインを優先して選定しました。
ゲーム内で使用されたプラグインを一覧化出来ます。
──仕様の確認、大枠の設計方針決定が終わり、開発段階に進むと思います。開発時の流れや工夫を教えてください。
川口：結論から言うと、最終的に手戻りが発生しないかつ、後から開発状況を見返しても瞬時に理解できるよう開発環境を設計した上で本格的な開発をスタートしました。
本ゲームはDAY1からDAY7まであります。
その中でDAY1ではなく、DAY2から開発をスタートしました。
何故かと言うと、DAY2は他のDAYでも発生するイベント･設定がほぼ全て盛り込まれていたからです。
先にDAY2を開発しておくことで最終的な開発状況まで見通すことが出来ました。
後から手戻りが発生するのも大変ですからね。
DAY2開発以降、他のDAYも開発した訳ですが、最初にDAY2を開発したことで最後までスムーズに開発出来たと思います。
また、事前準備として画面や背景が切り替わるタイミングを単位でマップを分けるよう考え、その仕組みで開発を進めていきました。
つまり、「1シーン=1マップ」ということです。
なぜこのような仕組みにしたかと言うと、他の組込み方法として1つのマップに背景素材や条件分岐を詰め込むことも可能です。
しかし、それだと一覧性が悪くなってしまい、後から見返す時に「あれ？これって何のイベントだったっけ？」と混乱しやすくなってしまいます。
「1シーン=1マップ」とすることで一覧性が向上し、マップ一覧から一目で目的のイベントに辿りつけるようになりました。
どのマップでどのシーンを設定しているのか一目でわかる。
開発の初期段階で将来を予測して準備をしっかりしておく。
そうすることで、後は手戻り無く準備通りに残りの開発をするだけという理想的な開発環境を整えられます。
既に紹介したプラグインと基本機能の使い分けや、変数やスイッチの余白を空けておく等まで、事前にしっかり準備しておくことが、開発において最も重要だと感じます。
──お時間いただきありがとうございました！