RPGツクールプラグイン制作過程紹介 第2回

前回はプラグイン制作の下準備として、プラグインの構想やファイルの作成などを行いました。
第2回となる今回は、ツクールの標準機能を使用したプラグインの仕様検討というテーマで進めていきたいと思います。

ツクール標準機能による機能実装

本シリーズにおいて「標準機能」とは「ツクールのエディタ上から呼び出せるスクリプト以外の機能」と定義します。
プラグインを実際に作る前に、私は必ず標準機能のみを用いて構想している仕様の実装をテストしています。つまりデータベースやイベントコマンドといった機能のみで、目指す仕様を実装してみるわけですね。これには様々な理由があるのですが、具体的には後述します。

ところで本シリーズでは、プロジェクト作成時自動的に用意されるデータベースを利用していきます。特に断りがなければデフォルトデータベースの項目・値をそのまま使っているとお考えください。

ケース1: イベントに直接実装

まずはシンプルな実装方法を試してみます。以下のようなイベントを作成します。

実行してみると、選択肢に「はい」を選択するとたきぎに火が付きます。あれ、もうこれで良くない？と思うかもしれません。
実際、ちょっとしたイベントであればこれだけでも十分です。ただし、今回のゲームの構想からすると以下の点が気になるところです。

①誰が《ファイアⅠ》を使用したのかがわからない。
②実際に《ファイアⅠ》を使用しているわけではないので、MPを消費していない。
③MPが足りなかったり、沈黙や戦闘不能など《ファイアⅠ》が使えなくなるステートにかかっていたりしても使えてしまう。

①については、イベントの条件にアクターがパーティにいるかどうかを設定すれば解決できそうです。
②は①が解決すれば、そのアクターのMPを《ファイアⅠ》の消費MP分だけ減らせば問題なさそうです。
③も②と同様です。

これを踏まえて、イベントを以下のように編集してみます。

《ファイアⅠ》を使えるかどうかについて詳細に判定を追加し、いずれか一つでも条件を満たしていなければ火を付けるイベントが発動しないように設定できたと思います。

1ページ目はこのページのアクターを「アルベール」にしただけのものです。デフォルトでは《ファイアⅠ》を覚える職業は魔法使いだけであり、魔法使いのアクターは「アルベール」と「ケイシー」の二人だけです。
ですのでそれ以外にアクターを増やすつもりがないなら、これだけでも十分機能しそうです。

ただしこれでもまだ以下のような問題があります。

④「アルベール」と「ケイシー」の両方がパーティにいる場合、１ページ目であるアルベールが強制的に使うことになってしまいプレイヤーが使用者を選べない。

これを回避するにはさらに使用者を選択させる選択肢を追加する必要がありそうですね。ただしそれはパーティに二人ともいる場合の処理で、どちらか一方しかいない場合はこれまでと同様の処理をして…やってみるとわかりますが、これはかなり複雑な条件分岐が必要になります。

めんどくさっ！（このスクリーンショットも途中で投げています！！）

単に複雑なだけなら頑張れば実装できますが、これを乗り越えたとしてもまだ以下のような問題点が残っています。

⑤転職やイベント習得等により、ゲーム中に《ファイアⅠ》の使用者が増える可能性がある場合は？
⑥《ファイアⅠ》が使用不可になるステートを「戦闘不能」「沈黙」以外にも増やしたくなったら？
⑦そもそも《ファイアⅠ》を使うことをプレイヤーが選んだわけではないので、謎解き要素としては機能しない

たった一つのイベントを組むだけでも大変なのに、その分岐がさらに増加すると考えたら悪夢ですね。しかも《ファイアⅠ》だけでなく今回の構想では他のスキルにも同様のイベントを用意するわけですから、雪だるま式に労力が増すことは想像に難くありません。

ですのでもしこの方法による実装を選ぶ場合、例えば「《ファイアⅠ》の習得者をケイシーだけにする」とか「このようなイベントは炎系魔法限定にし、《アイス》や《ヒール》など他のスキル系統には用意しない」といった妥協が求められるのではないでしょうか。

どうもこの方法ではうまくいかないようです。他の方法を考えてみましょう。

ケース2: コモンイベントで実装

（あらかじめケース1のイベントは全て削除してあります。）

ツクールではスキルの「使用効果」にコモンイベントを指定できます。これを使った実装はどうでしょうか。

まず、《ファイアⅠ》の使用効果にコモンイベント1番を設定します。また、メニュー画面で使えるように使用可能時を「常時」にします。

上記に対応したコモンイベント1番を以下のように設定します。

そして以下のようなマップイベントを設置します。

上記を設定して実行してみると、うまくいったような感じがします。今回はメニュー画面から選択するので、使用者をプレイヤーが選択できます。また「MP不足や沈黙状態など、使用できない状態にある場合使用できない」ということが考慮されているところもいい感じです。
ただし以下のような問題点があります。

①マップのどこにいても使えてしまう（イベントが画面外だったとしても）。
②マップ上に複数のたきぎを設置した場合、区別できないので全てのたきぎが発火してしまう。

①は遠距離呪文であるとか、設定の工夫で回避できるかもしれませんが、②は深刻な問題でしょう。ただしどちらも「プレイヤーの目の前にたきぎがある場合にのみ発火イベントが発生する」という処理にすれば解決できそうです。

以下の例では、たきぎがX:8、Y:5に設置してあるという前提です。

このイベントはプレイヤーが上を向いている、つまりたきぎの下からスキルを使用するという前提の分岐を定義しています。もちろんこれを全方向分設定してもいいのですが、マップ上にたきぎが複数ある場合なかなか面倒です。ここはズルしてイベントをこんな配置にしてしまいましょう！

（ちなみに右上は沈黙状態をテストするためにパーティ全員に沈黙をかけてくるイベント）

これなら下からスキルを使う場合の分岐だけ組めばいいので楽です。実際に組んでいただければわかりますが、このケースはかなり理想的に機能します。もうプラグインなくてもこれでいいのでは……？

ただしこのケースには問題が一つあります。

③プレイヤーが正しい座標に存在せず、《ファイアⅠ》が不発に終わったとしてもMPを消費してしまう。

ツクール標準では、コモンイベントが設定してあるスキルをメニューで使用した場合、コモンイベントの内容に関わらずMPを消費する仕様です。これはもう仕方ないので、不発に終わった場合《ファイアⅠ》の消費MP分だけMPを回復させればよさそうですね。MZで追加された変数のオペランド「直前に行動したアクターのID」を使用すれば誰がスキルを使ったのかがわかるので、そのアクターのMPを回復させればよさそうです。実は私も今回初めて知ったのですが、これは戦闘時だけでなくメニューのスキル使用者も取得できるのです。

あとは回復する値を《ファイアⅠ》の消費MPである15に設定すれば完成！…と言いたいところですが、そもそも《ファイアⅠ》の消費MPは常に15なのでしょうか？

「MP消費率」という特徴があります。これが付与されたアクターは、消費MPがその分だけ増減します。
例えばケイシーが《ファイアⅠ》を使ったとして、もし彼女が「マスターストーン」「マスターリング」「MPキーパー」の防具のいずれかを装備していた場合消費MPは15ではありません。ただ、「スキル使用者がマスターストーンを装備していた場合」、「マスターリングを装備していた場合」…といった具合で条件分岐させればとりあえず問題なさそうです。

ということで、このケース2は実装するにあたり特別に大きな問題点が見当たらない、かなり優秀な案であることがわかりました。強いていうなら以下の問題があるでしょうか。

②'マップ上に複数のたきぎが存在する場合、その数だけ条件分岐を用意する必要があるので面倒。
③'特徴のMP消費率が設定されたアクターや装備、ステートが複数存在する場合、条件分岐が面倒。
④スキル不発時、一瞬だがMPの減少が描画されてしまう。
⑤メニューを開く必要がある。開いている間、イベントの視認不可。

上記はいずれもそれほど深刻な問題ではありません。場合によっては妥協しても問題ないでしょう。ところで⑤に関してはメニュー画面を開くのではなく、マップ上にスキルリストウィンドウを表示できたら見栄えがいい上にイベントを見ながら選択できるので、良さそうな気がします。

②〜④を妥協したくないとか、⑤のマップ上ウィンドウを実装したいと言った場合、ツクール標準機能だけで解決することは非常に難しいと言えます。そこでプラグインの出番、というわけです。

標準機能によるプラグイン仕様検討の意味

というわけでかなり長くなってしまいましたが、ようやく本題に戻ります。そもそもプラグインはなぜ作る必要があるのでしょうか。主な理由を以下に挙げてみます。

1. 標準機能による実装では労力が大きい機能の、実装労力を軽減する。
2. 標準機能では難しい、もしくは不可能な機能を実装する。

これ以外にも場合によって様々な理由があるでしょうが、大まかにはこの２通りだと思っています。

逆に言えばそのいずれにも当てはまらない、つまり標準機能だけで、少ない労力で実装可能な機能に関してはわざわざプラグインを作る必要はないわけです。当たり前のようですが、これを事前検討することはとても大切なことだと考えています。検討した結果、プラグイン不要だと判明するならそれに越したことはないわけです。
プラグインを作るという結論に至ったのであれば、標準機能検証によって洗い出した問題点を全てクリアした仕様を検討しましょう。

こうした標準機能による実装の検証を経ることで、この後のプラグインの実制作において編集すべき関数の「アタリ」をつけることもできます。プラグイン制作においては標準機能の「模倣」がとても大切だと私は考えます。その際、どの部分を模倣すべきかの見当をつけておくと後の作業が楽になるのです。

まとめ

今回は、ツクール標準機能による検証を見てきました。今回はコードを書いていないので、コード掲載は割愛します。

次回はいよいよプラグインの実制作に突入します。何か気になる点などございましたらお気軽にコメントください。

それではまた次回お会いしましょう！