[不思議のダンジョンプラグイン] 壺実装中 & アーキテクチャについて

壺

容量の表示と、壺の中に壺を入れられないようにしました。

⬜ 容量による最大数の実装
⬜ 容量の増減と、減った時のアイテム消滅
✅ 壁とかに投げ当てて割れた時の実装
✅ モンスターに投げ当てたら中身が全部衝突する
✅ 複数選択
✅ 壺に壺は入れられないようにする
⬜ 転んで落とした時に確率で割れるようにする
✅ アイテム名に容量を表示する
⬜ 🔺壺増大の巻物
⬜ 🔺壺縮小の巻物
⬜ 🔺壺割れずの巻物
⬜ 🔺すいだしの巻物

壺関係の巻物もまとめて作ってしまいます。ということでタスク４つ追加。

アーキテクチャのメモ

このプラグインはかなり複雑になってきています。もうちょっと上手く作れなかったかなぁと思ってここ最近見直せるところは無いか探っていました。
結果、ちょっと直すのは難しそうだったので、考えたことや調べたことをメモしておきます。

まず一番大きな制約は、 マニュアルに書いてあるこの仕組みです。

ツクールユーザーであればマップ内に存在する敵キャラやアイテム、ワナもイベントとして作成したり、イベント実行内容や移動ルートコマンドなどで制御できると考えると思います。

しかし、このプラグインではそれができません。なぜかというと上記リンク先の説明のように、ツクールの中に独立したゲームシステムを丸ごと抱えていて、この２つを無理やり同期しているからです。

このような仕組みにしている理由は、大きく分けて次のようになります。

• ツクール標準システムでは不思議のダンジョンの再現は困難
• 2つのゲームシステムを統合してしまうと、自動テストができなくなる

ツクール標準システムでは不思議のダンジョンの再現は困難

アイテム

例えば、マップ上に登場するあらゆるオブジェクトは「アイテム」となりえます。モンスターはある壺を投げ当てると捕まえることができますし、アイテムに化けられるモンスターは持ち物に入り込んできます。吹き飛ばし効果はモンスターだけではなく、アイテムも、罠も、階段でさえも効果を発揮します。

そんな細かいところまで再現するべきなのか、というのはありますが、これは個人的に不思議のダンジョンに欠かせない「カオス」的なモノを表現するのに大切な仕組みだと思っています。並行して開発中のタイトルでもこの仕組みは最大限活用していきたいので、何とか盛り込みたい。

でもツクールのコアスクリプトでは、アイテムのデータは単に「何個持っているか」しかなく、個性が表現できないです。アイテムの持ち方ルールを変えるプラグインもありますが、それらは表面的なルールの変更であり根本的な個性の実現はできません。

マップ

不思議のダンジョン用のマップではタイルやリージョンだけでは表現しきれない多くの情報を扱います。例えば、部屋の範囲、通路の接続情報、タイルの種類などです。

部屋や通路は、AIの行動や視界を決めたり、ワナやお店の設置のガイドとなる重要な要素です。タイルの種類は見た目だけではなく、床、壁、水路、中空などを表現できなければなりません。特に新しい不思議のダンジョンタイトルでは、動く床などもあります。

タイル１つの内部はシステム的にレイヤー分けされてて、ワナやアイテムが配置されるレイヤー、キャラクターが配置されるレイヤー、飛翔体が配置されるレイヤーに分かれます。

ツクールのマップデータはシンプルな数値の３次元配列です。これをタイル情報の配列に大改造しなければなりません。

自動テストができなくなる

上記よりもこちらの方が深刻です。このプラグインはゼロからゲームシステムを開発するのと同じような規模になっています。不具合修正などで何かプログラムを変更したら、当然その影響範囲を調べてテストするのですが、個人開発なので限界があります。また石橋を叩くのに時間を取られすぎてモチベを無くしてしまうのは大きなリスクのひとつです。

というところで代表的な機能から少しずつ自動テストを組んでいるのですが、ツクールのコアスクリプトは根っこからしてGUIを伴う環境 (ブラウザなど) を想定しているので、一般的なユニットテストフレームワークとは相性が悪いです。

フレームワークは Jest を使っていますが、この上では PIXI.js が使えません。rmmz_managers.js などがグローバルスコープで PIXI.js の機能を使っているので、ほとんどの .js をインポートできないことになります。

puppeteer などでテストにブラウザ環境を使うことができますが、これはスクリプトをブラウザ上で実行するというよりは別プロセスで稼働しているシステムのE2Eテスト用みたいなので、細かいテストに苦労します。

せめてもの対策として、冒頭で紹介したようにゲームシステムを独立させることで、この部分だけテストしやすいようにしています。

まとめ

最近はずっと「もっとシンプルに書く方法があったのでは？」「ツクールのシステムと自然に統合する設計にできなかったのか？」とぐるぐる考えてしまっています。

いっそ専用のゲームエンジンを作るべきな感じもしますが、それはそれで、ツクールのメリット（であるゲーム開発素材の豊富さとか）に乗ることもできなくなります。

SRPG Studio くらい需要が見込めそうならいいんだけどなぁ…。