神無月サスケの波瀾万丈な日常

神無月サスケのツイッター(@ktakaki00)を補完する長文を書きます。

MZの可能性。MZサンプル「ルイーゼと秘密の地下室」を主に技術的側面からご紹介

この記事は、ツクールアドベントカレンダー2020の12月9日の記事になります。
12月3日にもツクールMZの紹介のような記事を執筆しておりますので、よろしければそちらもどうぞ。

最初に:ルイーゼと秘密の地下室とは


ツクールMZのサンプルゲームであり、シナリオもシステムも高く評価してくれた皆さんに感謝します。

  • シナリオについては、僕がプロットを書き、ふうきゅう氏がシナリオを書いてくれてます。今作は、僕が今まで封印していた「社会風刺」を5章に取り入れています。これはスタッフの皆さんが「入れるべき」と力説してくれたお礼です。
  • プラグイン関係はほぼ僕、サスケが書きました。どちらかというと理系の僕と、文系的な感性のあるふうきゅう氏、そして作曲のセンスのある氷石彩亜。三者三様ゆえに生み出されたクオリティだと、若干の自負はしています。
  • ゲーム作成の際にMVサンプル(エミールの小さな冒険)と同様、3人でケストナーの児童小説を参考にした部分があります。具体的には「ふたりのロッテ」「点子ちゃんとアントン」を一番重視しました。いずれもルイーゼという名前の登場人物がいたため、今回のサンプルでも、主人公はルイーゼなのです。

「ルイーゼと秘密の地下室」はSteamでも無料でプレイすることが可能です。

もう一本の柱は、氷石彩亜君原案のものだった

偶数章ではフェナック村でのライル達の活躍が見られます。ここで出てくる登場人物(ファリア、タルガなど)は旧アクツクで作成した「フェナックむら ものがたり」(2008年公開)の設定を強く意識していました。このシナリオは、音楽だけでなく、シナリオも書ける氷石彩亜君の仕事でしょう。それらを導入し、さらにシナリオのふうきゅう氏の目にもとまり、彼は積極的に氷石彩亜君のサポートをしていました。僕には音感のセンスが悪いのだけれど、それゆえに作曲方針は氷石君に決めてもらっていました。僕が注文したのは「町のフィールド曲」とか「お店の中の曲」とか「戦闘」といった漠然な要求をしていましたが、氷石君が僕の意図を読んでくれたのは大きいです。

氷石君のサイトの看板娘、クレミナも登場していますが、氷石君はそれ専用のエピソードのシナリオを書きました。特にクリア後の余章のシナリオなどは全て彼の要求に従いました。彼女専用の武器として氷石君は、クレミナには魔法剣、というこだわりがあり、僕も設定を実現するために奮闘しました。、FF5などと異なり、魔法剣呪文を唱えたそのターン敵1体をランダムで攻撃できます(これはステート付加とともに、コモンイベントを呼びだすことで実現しました)。僕、サスケは、魔法剣を導入したことがなかったため、いろんな試行錯誤をしました。
その甲斐あって、ひとまず彼の要望に応えられました。
魔法剣は、使い方によっては、バランスブレイカー的な強さ持ちますが、プレイヤーがそこに辿りつく前に試行錯誤してみてください。

ルイーゼの売り(技術関連)1:比較的賢いオートバトル

今回、タイムプログレッシブ戦闘というのがあり、FFシリーズと同様、リアルタイムで戦闘を行う設定が可能になりました。「新機能を使わないなんてありえない」という理由で、僕もTPBアクティブ、つまりコマンド入力中も敵が襲ってくる、油断ならない仕様になっていますが、今回MZサンプルが6本ありますが(僕も含む)、このうち3人がTPBアクティブを選択したようです。

自動戦闘をどう賢くしたか

今回、NPCが戦闘に参加したり、一般のコマンド入力でも、一番上に「おまかせ」があるなど、戦闘AIの登場が多いので、戦闘AIを賢くすることにも努力をしました。具体的には、ロンチプラグインにもした「SmartAutoBattle.js」がそれです。javascriptに詳しい方は、プラグインの内容を解析してみれば分かると思います。一応「ルイーゼと秘密の地下室」用にカスタマイズしていますが、何度もいろんな形で戦闘を行い、かなり最適化されていると思います。特筆すべきは以下です。

  • コアスクリプトでは勘案されなかった蘇生魔法や使用回数制限なしのアイテムを候補に入れるようにした
  • コアスクリプトでは補助魔法は一切考慮されなかったが、場合に応じてこれらを使うようにした
  • 行動前に入力されたコマンドをチェックし、無効な行動と判断されたらその場でもう一度行動選択を行う。
    • 具体例として、HP回復魔法を選択したが、行動前に別のアクターが回復をしてしまったため、既に選択したコマンドを行っても無意味……などの場合、行動直前に再度計算を行い、行動を変更するようにした。この結果、アクターは詠唱待機(魔法スキルを使う準備)のアニメだったが実際に行動したのは敵への通常攻撃だったりすることがあるが、これが原因である。
    • これを読んで「だったら全て行動直前に行動を決め、入力時には決定しなくてもよいのでは」とお考えになる方もおられるでしょうが、コアスクリプトでは入力後に行動を決めておかないとエラーが出る箇所があるため、このような方針を取っています。
    • メモの設定によって「高優先度で使わせたいスキル」を設定可能にした。前述のとおり、通常のアルゴリズムでは補助魔法をほとんど使わないが、それらの頻度を上げさせることも可能。

以上のおかげで「いいタイミングでキャラが回復や蘇生を行ってくれる」など好評をいただいていますが、個人的には、純粋なAIの視点からすると、若干邪道なことをしていると思っています。それは、「○○だったら評価値を○増やす」みたいな「行動によって直接的な数値で評価値を変更する」ことが中心になっているため、数値の増減があまりにも場当たり的なんです。経験則で決めた数値なのですが、真に本格的なAIを作りたいなら、こういう「場当たり的に決めた数値」ではなく、もっときちんとしたアルゴリズムで行動の評価値を決めているでしょう。なのでこのプラグインは、あまりよいお手本ではないことをあらかじめお断りしておきます。

ルイーゼの売り(技術関連)2:太陽や月などの魔石がメニューで合成可能

合成システム自体は、旧作MVにもありましたが、一旦町に戻り、魔法屋でしてもらう形式でした。だったら今回は、メニュー画面からいつでも合成可能にしよう、と考えてやりました。
アイテム合成シーンは、僕によるものですが、これは僕が、ツクールMZでの新機能でのシーンクラス作成に慣れるために作った、と言う側面をあります。シーンをメニューから呼び出せるので、作者である僕自身も、テストプレイの時はかなり入念にデバッグしていました。

このプラグインは、需要があるかも、と思い、ロンチプラグインにも採用しました。ItemCombineScene.js というのがそれですが、合成というより、装備やアイテムを魔石などで強化、といった方がいいと思います。しかし、もっと汎用性の高いアイテム合成プラグインはすぐ出てくるのが容易に予想できていましたので、そちらを使った方がいいかもしれません。

メニューシーンはMVより高機能なのに作成難易度はほぼ同じ

今回、メニューの全てのシーンの右上に「戻る」アイコンが付いています。しかし、これについては一切意識せずにこのシーンを作ることが出来ました。どうやら「戻る」ボタンは、現在アクティブなウィンドウのキャンセルハンドラを呼び出すようになっているのでしょう。つくづく、ユーザーフレンドリーさは失われていないと思いました。

ルイーゼの売り(技術関連)3:シンボルエンカウント

僕はもともとはランダムエンカウント派でしたが、現在ではシンボルエンカウント派になりました。これは、僕が一番ゲーム作りの参考にしているドラクエシリーズがそれを採用するようになったからです。特に7と8は3DSに移植される際に、元がランダムエンカウントだったものをシンボルエンカウントに作り直すという気合の入れよう。「今のトレンドはもはやシンボルエンカウントだ」と思い、前作、ツクールMVの「エミールの小さな冒険」から、シンボルエンカウントです。

シンボルエンカウントプラグインで実現

シンボルエンカウントは、当然ですが、イベントコマンドで実現することも可能です。しかし、ちょっと凝ったことをしたいため、それ専用のプラグインを作りました。ロンチプラグインではない、ルイーゼと秘密の地下室のプラグインフォルダにしか入っていないのですが、SymbolEncountLibMZ.js というのがそれにあたります。MZとついているように、ツクールMVでも同様なプラグインを作っており、基本的にはマイナーチェンジです。

プラグインだといろんなことが出来る

僕が敢えてプラグインを作成した理由に「普段は低位置にいるが、プレイヤーが近づくと音や視界の関係で気づかれて追跡され始める」そして「プレイヤーが一定距離以上離れると諦めて持ち場に戻る」ということがしたかったからです。前者の際には敵シンボルが「!」の吹き出しアイコンを、後者の際には(画面上のことが多いのであまり見た人はいないでしょうが)「くしゃくしゃ」のアイコンを表示し、持ち場に戻っていくことです。

こちらが強くなると敵が逃げ出すようになる

そしてこのプラグインの売りは、強くなってから序盤のダンジョンにいくなど、敵がプレイヤーが強すぎると判断した時、プレイヤーから離れていく、つまり逃げる動作を取るようになることです。そこで問題になるのが「いかにプレイヤーと敵の強さを比較するか」ですが、僕は素早さ(敏捷性)にスポットを当てました。僕のゲームでは、素早さはどのキャラでも一律レベルに比例して上がっていくため、敵グループとプレイヤーそれぞれ素早さの平均を取り、プレイヤーが8以上素早いと逃げ出す、というアルゴリズムになっています。

自分用に作ったが意外と利用者が多かったのに驚いた

さて、このプラグインは前述の通り、最初はMV用に作りましたが、「こんな設定が複雑な物、誰も使うまい」と思っていたのですが、意外にも採用している事例を見ました。MZ版に関しても興味がある人がいるらしく、「ヘルプを読んでも設定方法が分からない」という意見をムノクラ様(ツクプラMZなどの運営管理者)などからご報告いただいたこともあります。特に、0x01など、16進数リテラルをどう設定するのか、という点が多かったです。これについては、2進数に直して、合計の値を取ることで設定できるのはプログラマのほぼ常識の為、「どうせ使う人いないから」と説明を怠った部分です。「16進数 2進数 変換」などのキーワードで検索すれば出てきます。例:検索すると16進数から2進数の変換方法が出てきました。

このプラグインの機能ではなくランダム移動する敵も作った

MVの「エミールの小さな冒険」では、宝箱の近くに敵を配置し、全てアルゴリズムで制御していましたが、実況を見ると、戦闘を全て避けて初期レベルのまま第1ダンジョンをクリアしたものがありました。実は第2ダンジョンの入り口すぐに中ボスがいるのですが、初期レベルでは到底倒せません。その方の実況がそこで止まっていたのは、ここで挫折したからだと思います。この反省を生かし、今回はランダム移動(プレイヤーに近づく)し、強制的にエンカウントしやすい敵も作りました。僕はゲームバランスを取る時、「全敵シンボルと1回ずつ戦った」状態を想定して作っていたので、エンカウントを避けていた人は、後半苦労したんじゃないかな、とは思っています。

ルイーゼの売り(技術関連)4:数々のダンジョンギミック

僕は長年ゲームを作ってきましたが、ツクールMVのころから「自分のゲームにはダンジョンギミックが足りない」と思い、様々なダンジョンギミックや謎解きを追加するようになりました。これは、ドラクエシリーズが毎回悩ませてくれるギミックを毎回ダンジョンに盛り込んでいたからです。サガシリーズのように、成長システムで悩ませるゲームにはあまりギミックは必要ないと思われますが、シナリオ重視なら入れないと、と気づかせてくれました。

今回のMZサンプル「ルイーゼと秘密の地下室」ではMVサンプル(エミールの小さな冒険)で使用したギミックは原則入れていません。マンネリを避けたかったからです。

全ては紹介しきれないので、特筆性があるものなどを中心にいきます。

一筆書きが可能な絵が掲げられている部屋のみ有効

恐らくこれが、皆さんが最初に経験するパズルだと思います。いろんな図形が書かれていて、それが一筆書き出来るかどうか……。間違った部屋に入ると敵がうじゃうじゃいる地下に落とされますが、あまり悪い反響は聞かなかったところを見ると、皆苦労はしなかったんじゃないかな、と思います。

なお、「一筆書きが可能かどうか」については、実は必要十分条件があり「オイラーグラフか半オイラーグラフであれば可能、それ以外は不可能」となってます。これを知っている方なら楽勝だったでしょう。オイラーグラフの説明については、検索するとこのサイトを見つけました。オイラーグラフについて

左右のリージョンにあるタイルの数値の合計を同じにする


※画面は開発中のものです。
最初のダンジョンで、2、3、6、7の数値が書かれたタイルがあり、二つのリージョンに合計が同じ数になるようにせよ、というものがあり、その後、難易度が増したものも登場しましたね。算数が苦手な方は戸惑ったかもしれません。
これらの数値タイルは、基本的に動かせる岩と同じ仕組みを使っているので、何も難しいことはありません。MVの初心者講座の記事と全く同じことをしています。

「同じ数値になったか判定」については、これはプラグインを使っています。各イベントコマンドのメモに、など、数値を書き、「valueタグを持つ全てのイベントがいずれかのリージョンにある」「それぞれのリージョンのイベントのvalueの数値の合計が同じである」という判定を行っています。これはルイーゼのプロジェクトのプラグインフォルダにあるNumberPuzzle.jsで行っているので、興味のある方はご参考にどうぞ。

なお、そういう計算方法をしているため、恐らく複数の答えがあることもあると思います。制作者側が意図しない組み合わせで正解になる可能性もあると思います。

桂馬飛びパズル


第2章のボス直前に出てくるパズル。桂馬飛びするイベントを動かして、4つのスイッチを全部押すとクリア、というものですが、こちらも割と好評でした。これはルイーゼのプロジェクトの中のKnightMoveEvent.jsで実現しています。キーボードのみでも、マウスやスマホのタッチでも、両対応しています。

プラグイン中級者なら、大体作れそうな難易度のギミックなので、細かくは説明しませんが、このパズルが作られた経緯は、ふうきゅう氏が書いたシナリオに「桂馬飛びを使ったパズルを」とあったので、直感で作ったものです。桂馬(チェスのナイト)は移動先が8か所しかないため、移動先を表現するスプライトを表示するのはあまり難しくありませんでした。

滑る床

第4章でパーティーが二手に分かれた際、アントンのパートで出てきます。あとクリア後の余章でも出てきますね。僕はプラグインをわざわざ作って実現したのですが、ゆわかさんがイベントコマンドだけでやる方法をアドベントカレンダーの6日に載せており、明らかにこっちの方が作りやすく、ああ、僕はイベントコマンドはまだまだ上級者を名乗れない、と思った次第です。

なお、僕が作った滑る床パズルは、難易度が高かった、という声も聞かれました。でも、僕としてはドラクエ5の妖精の城のパズルでもあったため、若干難しくてもいいだろう、みたいな感じで強行しました。

二度乗ると崩れて下の階に落とされるタイルのパズル

これもドラクエ5か何かで見たことがあるものをそのまま採用したもので、ゲームでは第5章のラスボス前の最後のギミックでしたね。

※画面は開発中の物です。

これもプラグインでないと実現できないと思われます。ルイーゼのプラグインのフォルダにあるBrittleFloor.jsで実現していますが、実現には、イベントではなく、マップデータの該当箇所のタイルIDを直接書き換える、という、かなりトリッキーなことをしています。これはあまり推奨される使い方ではないと思うのですが、実際にきちんと動いたのできっと今後のバージョンでも動いてくれると思います。

なお、第2章にある、「特定の色のスイッチに触れると、同じ色のタイルが全て消える」も、マップデータを直接書き換えることで実現していますが、それもうまく作用しています。

ところで、実際にゲームで採用されているパズル、結構難易度高めに作ったつもりですが、プレイ実況を見ていると、あまり悩まずにすんなり解けていた人が多かったのが意外でした。

三原色のパズル


※画面は開発中の物です。
これはプラグインなしで、スイッチの判定だけで実現しています。

このパズルは3章のボスキャラの前で採用されましたが、最初にα版を編集部に納品した際、「テストプレイヤーが誰一人解けなかった」というご意見をいただき、急遽、ヒントをくれる存在を追加しました。最初から全部話すのはよくない、ということで、3段階でヒントを提供し、最後のヒントは答えそのものを言わせたつもりですが、それでも難しい、という意見も拝受しております。

実際、RPGアツマール版でのコメントを見ていても、このパズルのマップで「難しい」という意見がかなり多く、ちょっと難しくしすぎたかな、と反省しています。

ルイーゼの売り(文系関連):シナリオテキストの改善

イベント打ち込みは、主にふうきゅう氏と僕の二人で手分けしました。些細なミスこそあれど、大きな問題が起きなかった奇跡に感謝。
そして一通りβ1版が仕上がった頃、ふうきゅう氏は僕の台詞にも色添えを添えてくれました。ルイーゼのシナリオで悪い評価を寡聞にして聞いたことがありませんが、やはりそれも、ふうきゅうマジックと言っていいでしょう。いいスタッフに目覚めて僕は幸せ者です。

ルイーゼの売り(音楽関係):氷石彩亜君のこだわり

MVサンプル「エミールの小さな冒険」では「汎用的に使えるように敢えてテーマを設定しませんでした。しかし今回の「ルイーゼと秘密の地下室」では、氷石イズム、すなわち、多くの曲でメインメロディがベースになって、一通りの曲を作りたいと話したので、即OKしました。

僕としては、これが氷石君がやりたいことなんだと思い、BGMやMEの選定は熟慮して決めました。どんな感じなのかは、実際にプレイしていただけると分かると思います。

終わりに

他にも探せばいろいろ出てきそうですが、特に印象に残っている物をピックアップしました。この記事を読まれた中で、JavaScriptに詳しい、ゲームが作りたい、という方は、ツクールMZのサンプルゲームのプラグインを解析してくれれば、参考になるでしょう。

ツクールMZサンプルに込めた、MZの可能性とアピールポイント

この記事は、ツクールフォーラム・アドベントカレンダーの12月3日の記事になります。

今年、2020(令和2)年は、RPGツクールの新作、MZが発売されたことで、ツクール界隈は盛り上がりを見せています。僕、神無月サスケは、ロンチプラグインの制作とサンプルゲーム「ルイーゼと秘密の地下室」の作成に関わりました。おかげさまで、いずれも好評をいただけているようです。皆さまに感謝いたします。

ロンチプラグインについて

まず最初に。今回、MZの公式プラグインは、トリアコンタン様が、かなり多くの物を作っておられます。今回、この「公式プラグイン」は、MVの公式プラグインと異なり「MITライセンスではない」「他ツールへの流用不可など、かなり厳しい制限がある」ことにご留意ください。

僕が担当したのは、主に「MV公式プラグインのうち、MZのデータベースに採用されなかった機能を持つプラグインをMZに移植」という点でした。また、僕が制作したMVプラグインのうち、特に需要の高かったものも自主的に移植しています。これらにつきましては、以下のツイッターのモーメントにまとめてあります。

神無月サスケ謹製 RPGツクールMZ プラグイン集

上記を読めば、僕が作成したロンチプラグインの範囲が分かると思います。具体的には……

  • WeaponSkill.js, KeyItemNumber.js など、MZではデータベースで設定可能になったプラグインは見送り
  • ExtraEquipType.js (装備可能武器の動的追加)などは、SimplePassiveSkillMZ.js(装備の特徴や設定を元にした、簡易的なパッシブスキル作成)としてより汎用的、包括的なものに置き換え
  • EventEffects.js のように、MV、MZ両対応のプラグインでも、パラメータの指定方法を分かりやすくするなど、些細な改良を追加
  • TinyGetInfoWndMZ.js のように、同名同機能のMVプラグインがあり、MZ専用のものにはプラグイン名末尾にMZを追加

といったものです。

公開後、いくつか不具合の報告があったため、MZのVer1.1.0では、修正されたものも多数あります。ご利用される方は、ぜひ最新版をお試しください。

ロンチプラグインに見る、プラグインの進化

今回、MZ用のプラグインは、MV用と区別するために、ヘルプのアノテーションに対して「@target MZ」といった記法が導入されました。両対応のプラグインでも、「@target MV MZ」と記述することが勧められています。まだMV側では「@target」アノテーションに対応していませんが、将来、導入される可能性があるため、MV対応の是非もこのアノテーションで記述するのが望ましいです。

このように、プラグイン利用者がパラメータの設定を容易にするために、様々なアノテーションが新規導入されました。詳しくは、公式サイトのプラグイン講座でのアノテーション解説をご覧ください。これらの一部は、RPGツクールMVの後期バージョンで採用されていましたが、今回新設されたものもあります。プラグイン作者様方には、ぜひ有効活用してもらいたいものです。ロンチプラグインでも、これらの記述が加わり、MV版よりも使いやすくなっている物が多いです。

最大の変更は、プラグインコマンドでしょう。MVでは1行のコマンド入力でしたが、MZでは、GUIに変更されており、「新たなイベントコマンドを作成する」ような感覚で、プラグインを作成することが可能になりました。

以前より、海外のツクールフォーラムを中心に「新たなイベントコマンドをユーザー側で作成可能にしたい」という意見が多かったようですが、今回、このような形で、答えを出してくれたわけです。

これらの結果、プラグインが、より設定のしやすい、利便性の増したものになったことは特筆すべきだと思います。

コアスクリプトの進化とプラグインのMV/MZ互換性

プラグインを作るうえで、ベースにするのがコアスクリプト。MVからMZになって、大きく変わった点もありますが、MVのプラグインの中で、あまり手を加えずに使えるものも、意外と少なくないことに気づきます。

そのまま動く可能性が多いもの

  • マップ関連のもの。8方向移動やタイルの特徴を利用したプラグインは、これらに大きな変更がないので動く。
    • ただし今回、マップには任意のレイヤに任意のタイルが置けるようになったため、MVの「特定のレイヤにはその層特定のタイルしか置かれない」と仮定しているプラグインは正常動作しない。
  • アクターや敵のパラメータに関するプラグイン。パラメータには大きな変更がないため、例えば「Buff/Debuffを2段階から4段階以上などに変更する」といったプラグインは、変更なしで動く公算が大きい。

多少の改修が必要な物

  • メニュー画面系。今回、常に「戻る」ボタン(フィールドでは「メニュー」ボタン)が画面に表示されている。よって、ウィンドウの配置も、この領域に何も置かないようなレイアウトに変更することを余儀なくされている。
  • 新たにウィンドウを作成する際、座標をRectangleで指定する必要が出てきたこと。これによって、新しくウィンドウを作成する部分はMVから書き換えなければならない。

大きく書き直す必要があるもの

  • メッセージウィンドウ関連。今回、アラビア語のような「右から左へ流れる言語」にも対応したため、既存の関数名も大きく変わり、処理は完全に別物になったと言っていい。--ロンチプラグインでも、MVのNovelMessage.jsは、僕ではなくほぼ尾島氏の添削によるものだが、MVとMZのコードの違いに対処しきれず、尾島氏に下駄をあずける形となっている。
    • メッセージウィンドウで文字ごとにSEを演奏するロンチプラグイン「PlayMsgWndCharSeMZ.js」。処理がMVから完全に変わったことから、このプラグインも、MV版と別物になっている。
  • バトルシーケンス関連。今回、タイムプログレッシブ戦闘という、ATBによく似たシステムが導入され、ターン制、アクティブ、ウェイトから選べるようになったが、驚くべきは、これらが全て共通のルーチンで処理されていること。通常のプログラマなら、それぞれ用のプログラムを書き、別々のルーチンを準備するだろう。これを共通で出来るというのは、相当熟練したプログラマであることが伺える。
    • このため、MVにあった、バトルコマンドウィンドウ(戦う/逃げる)に、「オート」や「リピート」を入れるのが現実的でなくなった。これらはターン制以外まともに機能しない。ロンチプログラムは、苦肉の策として、アクター毎にオートにするかどうかを選択可能にするもの(AddAutoToActorCommand.js)を導入した。

全体的に言えること

公式のアナウンスは「MVとMZのプラグインレベルでの互換性はない」である。しかし、あまり変更の少ない部分を扱うプラグインは両対応出来る物もあるし、微細な修正で対処できるものもある。MVのプラグインはMZで「動いたらラッキー」程度に考えるべきである。

コアスクリプトJavaScriptは、ES5からES6へ。しかし……

これはJavaScriptを知っている人向けの話題だが、コアスクリプトプラグインで利用している言語であるJavaScriptが、MV発売の時は最新はES5だったのに対し、MZの時にはES6という新記法を採用した。厳密にはツクールMVでも、Ver1.6.0以降は、ES6に対応、という報告も聞くが、一貫性を考えると、MVでのES6使用はおすすめできない。一方、ツクールMZは、ES6を前提にコードが組まれている。ただし……

MZでも依然と残るprototypeやfunctionなどのES5記法

コアスクリプトというのは、原則「プラグインで書き替えてもらうこと」を前提に作られています。このため、わざと、class などのES6構文を使わず、意図的にES5時点のfunctionとprototype構文で書かれています。なぜなら、そちらの方が、書き換えが容易だからです。このことは「コアスクリプトが十分にES6を活用していない」と、早くから話題になり、議論が起きていましたが、僕にとっては、「考慮に考慮が重ねられた結果だ」と受け止めています。

結論:プラグインでは自由

上記の理由によって皆さんがプラグインを作る際は、ES6記法は自由に使ってよいと考えられます。

ツクールMZでの制作。エディタ周りについて

スクリプトの話はここまでにして、今度は実際にサンプルゲームを作っていて便利だと感じたものをいくつか書いていきます。大抵のことは、よそが書いているので、独自の視点で。

64bitソフトになったことで、64bitOSで軽量化された

RPGツクールMVは、32bitソフトであり、32bit/64bitの双方で動くプログラムでしたが、この時点で大半のユーザーは64bitOSを使っていたものと思われます。実は、64bitOSが32bitOSを実行する場合、OSレベルでは、若干手間のかかることを行います。32bitで受け取った値を、一旦CPUでの計算用に64bitに変換し、計算結果をまた32bitに戻す……といった具合のことをしています。Windowsなら、この処理をWOW64が承っています。普通なら速度への影響は、ほぼ問題のない些細なレベルです。しかし、ちりも積もれば山となる。64bitOSでは、同じ内容の32bitソフトより、64bitソフトの方が、若干軽くなります。

  • 先日公式がツイッターで「ツクールMZのエディタはツクールMVより軽快なこともある」と書きましたが、これは大げさな話ではなく事実であり、これによるものなのです。
  • なお、32bitの弊害として「4GBの壁」がありますが、これが問題になるような状態はツクールはあまりありませんでしたね。

オーディオにm4aが必要なくなり、oggだけでよくなった

僕のサンプルゲームは、作曲担当がいます。氷石彩亜君というのですが、彼にとってもこれは歓迎すべきことだったのではないでしょうか。そもそもMVの熟成期に、OggOnly.js という「ツクールMVでoggだけで十分」という、革命的なプラグインドワンゴ側の開発班からもたらされ、いくつかの改良を経た結果、実用性十分と言うことで、今回MZに晴れて採用の運びとなりました。今のところ、大きなトラブルの話も聞かず、まさにこれは革命的進化と言ってもいいでしょう。言うまでもなく、プロジェクトのサイズ削減にも大きく貢献する進化です。

大きく見栄えは変わらないが、細かい所に気が利く

これは実際に使ったことのある人なら、いちいち細かい所に気づくのではないでしょうか。僕が今リストアップするだけでも……

  • マップツリーで、ツリーのマップを別の層に移動する際、末尾のみならず真ん中に挟み込めるようになった。
  • メッセージウィンドウの設定。右クリックで色番号やアイコン番号を挿入可能になったので、\C[17]とか\I[360]といった外字が楽に入力可能になった。
  • 「変数の操作」の「代入→ゲームデータ」で、「アクター」の「TP」がこっそり取得可能になっています。僕はTP持ち越しではないため、この機能は未使用ですが、助かった人は多いのではないでしょうか。

マップエディタで、従来とは異なるレイヤにタイルを置けるようになった

もっと厳密にいえば、レイヤごとの編集が可能になった、ということです。前述の通り、これに影響を受けるMVプラグインもありますが、タイルの重ね合わせの自由度が劇的に高まったことは、もろ手を挙げて歓迎しました。本当に、マップの痒いところに手が届くためです。今回「ルイーゼと秘密の地下室」のマップの多くは僕自身が書きましたが、何度、助けられたか分かりません。重ね合わせ万歳。

マップエディタで、通行判定★が正常にエディタに反映されるようになった

これは、ツクールMVユーザーを一番悩ませた要素かもしれません。通行判定★のタイルの上に通常タイルを置き、エディタとゲームでの見かけが異なることがありました。MVの際は、講座などで、こういうことをしないように注意していましたが、やはり、ユーザーが気を遣わずに済むようになったのが一番でしょう。

その他、サンプルゲーム作成の役に立った点

キャラクター生成機能の向上

キャラクター生成はMVからありましたが、今回はさらに様々な点がバージョンアップしているようです。僕は今回触っていませんが、開発メンバーのふうきゅう氏が、イメージに合うキャラを作成するために使い、使い心地の良さを報告してくれています。

「コアスクリプトの更新」の自動化

以前は、コアスクリプトのバージョンアップの際には、「plugins.jsを除いてファイルを置き換え」など、若干ややこしい作業を求められていましたが、今回、コマンドひとつで可能になりました。これで、まちがってplugins.jsを上書きするなどの事故がなくなりそうですね。

  • ただ、ひとつ懸念があるのは、MVのVer1.2→1.3、1.5→1.6の時のように、エンジン部分(Nw.jsやPIXI.jsなど)が大きく変化するケース。これはコアスクリプトの書き換えだけじゃどうにもならないため、若干大きな作業が必要になる可能性もあります。

結論:ツクールMZは買いだ

ツクールMVを使っていて、プラグインに詳しい人は勿論、皆のプラグインを使う立場の人、それでゲームを作っている人は、皆、移行の価値があります。僕が一番評価しているのは、スマホ対応の強化なんですが、そこにこだわる方はもう僕と同様選択肢はひとつです。一方で未だにツクールVXAceで作っている人もいますが、彼らはWindows対応で満足しているのかもしれません。Macスマホにも進出した世界で作品を公表したい人は、例外なくMVやMZこそが選択肢であり、そして、MZは非常に高機能化、ユーザーフレンドリー化しています。買わない手はありません。

結論2:この記事で他にメインで書く予定だったこと

もっと、サンプルゲーム「ルイーゼと秘密の地下室」の隠しギミックなんかを解説しようかな、って思っていたんですが、それなしでも、ずいぶんな分量になってしまいました。そこで、まだアドベントカレンダーが埋まっていないのを見て、「そのことでもうひとつ記事を書いたら?」という気持ちになりました。その時の為に取っておきます。

僕が「いふび」という荒らしの濡れ衣を着せられ続けている件

概要

最近困っていることがある。エゴサーチして分かったのだが、僕は濡れ衣を着せられている。
「いふび(痛フb)」という以前ツイッター上でツクラー周辺に荒らしをしていた正体が僕だという根拠のない情報が流れ、悪評を流されているのを見た。真犯人(いふびで検索すると出る)が名乗り出たにも拘わらず。

事の経緯

濡れ衣を着せられるまで

2013年ごろ、ツイッター上で「痛いフリーソフト作者監視bot」(通称「痛フb」または「いふび」)というアカウント名で多くのフリーゲーム作者に嫌味なリプライを送り続ける迷惑アカウントがあった。2chの同人板とも連携して荒らしを繰り返しており、僕も被害者だった。
そのアカウントが2014年5月、入院していた僕が退院した時、いかにも自分も退院したようなツイートを書き、僕を装うようになった。
そこから「いふびは神無月サスケでは?」と、いわれのない疑惑を持つ人間が現れだした。
あまりに無理があるので誰も信じないと思ったが、「間違いない、あれ、神無月サスケだ」という声が、ツイートから上がり(発言者の名前は伏せます)、必死に「僕はいふびじゃない」と否定した。
しかしそのことで、その方は、「否定するくらいだから、やっぱり間違いない。本当に潔白なら黙っているはずだ」と言って、より強く確信したと言った。はっきり言って魔女裁判である。
この経緯は、悪意ある人たちによって、以下のように喧伝されている。

僕の沈黙の時期

上記の魔女裁判じみた件があったことと、ツイッター上では大半が僕の味方をしてくれたことで、悪意ある意見は無視していれば、そのうち真実は示される、そう思っていた。だが、実際はそうならなかった。
その後も僕を罵るために「神無月いふび」などと名乗ったツイッターアカウントを作成されたりして、そのたびに否定していたが、ツイッターで僕が書いた「僕はいふびではない」という意見はすぐ流れてしまう。
代わりに、前述の、僕に悪意を持って書かれたサイトが、「神無月サスケ」で検索した時、上位に来るようになったようで、ついに「神無月サスケ」と入れると、「いふび」という言葉がサジェストされるようになっていることを知った。
この結果、この濡れ衣のデマを信じる人が少なからず出てきたようで、ある人からDMで「サスケさんとは付き合わない方がいい、と忠告された」と言われたこともある。僕は濡れ衣によって、相当な風評被害を受けてきたらしい。
これは後述するが、現在、真犯人が名乗り出ているにも関わらず、未だに僕、神無月サスケの方をいふびの正体だと信じている人が多いらしい。

真犯人が名乗り出た

2016年になって、いふびの正体を名乗り出る者がいた。以下のツイッターだ。
https://twitter.com/gomikasumunhoi
このアカウントを作ったのは、眼鏡侍(メガザム)さんという方で、トキノタビビトの作者さんである。
もちろん自称なので、僕も状況証拠しか出せないが、状況証拠しかないゆえに、「神無月サスケがメガザムに罪をなすりつけている」という解釈をしている人が多かった。
現にこのアカウントに対して、「神無月サスケさん、人に罪を着せるのは見苦しいのでやめてください」などとリプライを送ってきている人もいたようである。
メガザム氏は、このアカウントで、僕に濡れ衣を着せた理由として、「自分は汗水たらして働いているのに、サスケは働きもせず食べ歩きながらゲームが評価されているから疎ましかった」と述べている。
働いていないなどという誤解もいいところだが、それならなぜ、僕に直接謝罪するなり、もっと誤解を解く行動をするなり、してくれなかったのか、不満は残っている。
住所氏名が分かれば、名誉棄損で訴えようとも考えたが、わざわざ名乗り出たこともあり、そこまでするつもりはない。

誤解は解けるのか

ただ、ひとつ言えることは、あれから3年経過した今、2019年1月、Google検索で「神無月サスケ」を検索すると、「いふび」という言葉がサジェストされ、前述の、僕に悪意を持った人達による、濡れ衣を着せるサイトが上位に来ていることである。
一体、どれだけの人が、このサイトを見て、僕の知らないうちに、僕を悪人と決めつけ、僕を避けたのだろうか。どれだけ、風評被害を被ったのだろうか。
これ以上の延焼を防ぐために、今回、こうやってブログに表明させていただいた。
ただ、これを見てもまだ、僕をいふびだと思い込む人が一定数いることも僕は承知している。そういう人は、もう好きにすればいい。何を言っても誤解を解かない人は、僕自身が気に入らないのであり、この点で誤解が解けても、別の点で僕を攻撃してくることは明白なのだから。
逆に、ここを読んで、僕の誤解を解いてくれる人には感謝したい。そういう人にこそ、付いてきてほしい。

多機能フックローププラグインを支える技術

この記事は、ツクールMVの多機能フックローププラグインの記事です。
https://forum.tkool.jp/index.php?threads/851/
https://youtu.be/PBEbrzYt3xI

本日の先の記事と合わせてお読みください。

この記事は、このプラグインを作るにあたって直面した
技術的困難を中心に扱います。
専門的な内容なので、あまり興味がない人、プラグインが読めない人などは、
適当に読み流してください。

プラグインをダウンロードして、中を見てみましょう

さて、ここからはプラグインを実際にお見せしながら
説明していきたいと思います。
プラグイン単体(動作に必要な画像素材付き)は、以下のアドレスから入手可能です。
http://www.moonwhistle.org/tkoolMV/SuperiorHookRope.zip
こちらのプラグインは、前述のサンプルプロジェクトに入っているものより、
若干バージョンアップしています。

ロープが可変長ゆえの、アニメーションの動的生成の必要性

まず最初にこのプラグインを作るにあたって一番重要だったのは、
アニメーションを、データベースに登録するのではなく、
プラグイン内で動的に生成している、ということです。
これは、プラグイン利用者にデータベースでアニメーションを作ってもらうのが
煩わしいから、という理由だけではありません。
このプラグインは、ロープの長さが可変長に延びますが、
フックロープの動作は、アニメーションによって実現しています。
もし、データベースでアニメーションを登録するとすれば、
異なる長さごとに上下左右のアニメーションを作る必要があります。
例えば長さ最大7なら、0〜7まで8通り×上下左右4種類で、
32個のアニメーションが必要になります。
この手間は、ただごとではありません。
当然、現実的ではありませんね。
このため、プラグイン内で、プログラムで直接生成する必要が
出てくるというわけです。

アニメーションの動的生成のために:データ構造の解析方法

アニメーションを動的生成するために必要なのは、
データ構造を解析することです。
アニメーションのデータはJSON形式で、テキストファイルで見ることが可能です。
しかし、データの細かい意味が、それだけでは分かりません。
ツクールMVのヘルプにもJSリファレンスがありますが、そこには簡単な説明しかなく、
データの細かい説明はほとんどないため、解析が非常に困難と言えます。
そこで僕は、奥の手を使いました。
それはRPGツクールVX Aceのヘルプを参考にすることです。
両方のツクールをお持ちの方ならお気づきでしょうが、
RPGツクールMVのデータベースのデータ構造は、RPGツクールVX AceのRGSS3の
データ構造をベースにしています。
特に、アニメーションのように、追加機能が少ないものに関しては、
ほぼ1対1対応がある、と言っても過言ではありませんでした。
この事実は、データ構造を理解する上で非常に助かりました。
実際に、ご覧ください。

ご覧のように、日本語で、なおかつデータの詳細について説明してくれており、
情報量が全く異なり豊富なのが分かるでしょう。
こうしてめでたく構造を理解できた僕は、
アニメーションの動的生成を組むことに成功しました。
よくOSやツールなどの解析で言われることですが、
「データ構造が解析できれば、半分は解析できたも同然」
ということなのです。

タッチパネル対応。移動中いつフックロープを使うか

さて。次は、RPGツクールMV特有の課題です。
ツクールMVで作る以上、マルチプラットフォームを意識する必要があるため、
タッチパネル(、マウス操作)にも対応しなければなりません。
PCの場合、マウス操作以外でも操作は出来ますが、
スマートフォン移植前提の作品で使ってもらうなら、タッチパネル対応は必須でしょう。
そこで、タッチパネル移動時は、杭やフェッチ可能なイベントをクリックすると、
「フックロープが使えるところまで歩き、使えるようになった場所で使う」という
動作が必要になってくる、と考えました。
これは、それほど難しくなく、実装出来ました。
具体的には、プラグインの一番最後、Game_Character.prototype.findDirectionTo を
再定義している部分で処理している。興味のおありの方はお確かめいただきたい。
簡単に説明すると、
「フックロープ使用可能状態で、
なおかつ目的地がフックロープ関係のイベントの場合、
目的地への移動中、
プレイヤーが目的地へフックロープ到達可能の位置にいたら、
目的地の方を向いてフックロープ使用、プレイヤー移動はキャンセル」
ということです。

フックロープが壁を通過できなくする処理

フックロープは、壁を通過できないので、その前で止める必要があります。
これは、その座標に壁があるかどうかが判別できれば簡単です。
それでは、具体的にどうやるのでしょう。
実を言うと、このプラグインでは、A3タイル(壁の上部)とA4タイル(壁)の判定のみを
行っており、タイルA5やB〜Eで準備されたカスタムの壁は、通過します。
(ここのところは、今後のバージョンアップで設定可能にするなど、
対策が必要かもしれませんね)
A3タイルやA4タイルは、4層あるツクールMVのタイルの、最下層に位置します。
(「ちょっと待った、4層ではなく3層では?」という方がいらっしゃるかも知れませんが、
2つの上層と1つの下層の間に、タイルA2の一部を置く中層というものがあるんです)
そこで、最下層(レイヤー1)のタイルIDを確認します。
タイルIDはイベントコマンド「指定位置の情報取得」でも取得が可能な値です。
ただ、タイルIDで、それがタイルA3やA4なのかどうやって判定するのでしょう。
それは、タイルID仕様を知る必要があります。
これについては、「ツクールMV タイルID仕様」で検索すると、
調べてくれている人がいます。
https://www.f-sp.com/entry/2016/09/25/131242
この数値は一部RPGツクールVX Aceとも共通です。
これが分かれば、「目の前に壁(A3、A4タイル)があるか」はすぐできます。
自分で調べると結構骨が折れるので、
調べてくれている人に感謝、ですね。

力業で乗り切った点も

プレイヤーの移動とフックロープのタイミング合わせ、実は場当たり的

重要な点として、ツクールMVでは、プレイヤーの移動と、
アニメーションの表示は独立しています。
そして、フックロープは、アニメーションで実装されています。
フックロープを使う際、イベントをフェッチしたり、プレイヤーが一歩下がったり、
という場合、その動作にアニメーションをシンクロさせなければならないのですが、
これは、かなり場当たり的にやっています。
具体的には、フックロープの伸び方に応じて、最大の長さに達した時のウェイト数を変えたり、
逆にフェッチされるイベントの移動速度を、フックロープのアニメーションに
合わせたりしています。
本当に力業のため、フックロープの長さによっては、
若干タイミングがずれることもあるのですが、
ここはイベント移動とアニメーションのシンクロという点で、仕方ないことです。
なお、プレイヤーの移動ルートも、フェッチされるイベントの移動ルートも、
JavaScriptのオブジェクト記述形式、すなわちJSON形式で、直接リテラルで記述しています。
アニメーションのデータもそうですが、
ツクールMVはデータ構造がJSONというテキストで記述しやすい形式だからこそ、
実現できた部分が、このプラグインには多いのかもしれません。

アニメーションの関係から、一般的な(48x48サイズの)キャラにしか使えない

これもアニメーションの見た目を自然にするために、力業でのりきった点です。
フックロープを、プレイヤースプライトのどの座標から出すか……
下手をすると、上を向いているとき、頭や背中からフックロープが生えてくるように見えます。
そういったことをなくすため、プレイヤーが上下左右の向きで、
それぞれ座標を補正しています。
……ただ、これが原因で、ツクールMVの標準素材やジェネレーターで作成したような規格以外の、
特徴的なキャラクターが使うと、不自然な見え方になってしまいますが、
これはもう、現時点での仕様の限界、ということになります。

まとめ

いかがでしたでしょうか。これ以外にも、プラグインの中身を見ていただければ、
いろいろと分かりにくい部分で工夫しているのを理解してくれる人も
いらっしゃると思います。
今回、「多機能フックローププラグイン」として、ゼルダの伝説のギミックのように
「複数の機能を持たせる」「直観的にする」というものを作ったわけですが、
仕様的にも、技術的にも、いろいろ悩んだりしましたが、本当に考えていて、
苦になることはありませんでしたね。
むしろ、ゼルダの伝説がいかに偉大かが、よくわかりました。
何事も経験、ですよね。自分でやってみることで、改めて、凄さを知る。
僕にとって、このプラグイン制作の経験は、自らの身体の一部になっています。
この記事が、皆さまの何かのご参考になれば、幸いです。

多機能フックローププラグインの紹介とその哲学

多機能フックローププラグインとは?

2017年、僕は、RPGツクールMV用に、マップ上のアクション系プラグイン
「多機能フックローププラグイン」を公開しました。
https://forum.tkool.jp/index.php?threads/851/
簡単に言うと、フックロープなのですが、複数の機能を持ち、
汎用性が高く作られています。
百聞は一見にしかず。こちらに、このプラグインを使用した1分弱の動画がありますので、
まずはご覧になってください。
https://youtu.be/PBEbrzYt3xI

関連プラグイン:ツミオさんのアクションプラグイン

さて、このプラグインのみならず、巷には、
同様の、アクション系プラグインは、それなりに紹介します。
そこでまずはそれらのプラグインの中から、
有名なひとつをピックアップして紹介します。
それを紹介した後で、「それではなぜ、多機能フックロープなのか」という
話をしたいと思います。

ツミオさんのアクションプラグイン

プラグイン】特殊なアクションを実装
https://forum.tkool.jp/index.php?threads/669/
僕がこれを選んだのは、僕が知っている中で、
最も多機能なプラグインだからです。
ゼルダの伝説にあるアクションをそれこそすべて搭載する勢いで
数多くのアクションが設定可能です。
これらの挙動は動画でデモを観られます。
Youtubeの「ツミオチャンネル」
https://www.youtube.com/channel/UCTIxXkDwcTkAiku5WFt6oDQ
こちらでは、アクションプラグイン以外にも、
あなたの興味を惹く多くのプラグインのデモ動画もあるため、
単に「ゼルダの伝説のような、様々なアクションを導入したい」
という方は、ツミオさんのプラグインの方がいいかもしれませんね。
なお、彼はカンパ歓迎と話しているので、
気に入ったらカンパしてあげてほしいな、と思っています。

ツミオさんのプラグインと多機能フックロープ

さて、多機能フックローププラグインに話を戻します。
このプラグインは、フックロープのみであり、
ツミオさんのプラグインと比較して、
機能のバリエーションという意味では、明らかに見劣りします。
しかし、機能を絞りこむ代わりに、ある種の「哲学」を貫いているのです。
すなわち、僕の一貫するポリシー、哲学を理解してくれた人に
使ってもらいたいと思っているのです。

多機能フックロープに込めた「哲学」

ひとつのアイテムが複数の機能を持つのが望ましい

まず、僕がこのプラグインで目指したのは
「道具と言うのは、決まった一つの使い方のみならず、
いろんな使い方が出来るのが理想」というものです。
ゼルダの伝説シリーズを思い出してください。
複数の使い方があるアイテムや、
基本的な使い方は一つだが、特定の場所で思わぬ使い方が出来る……
そんな形で、多彩な使い方が出来るアイテムが多数あります。
僕がこのプラグインで目指したのは、まさにその方向性なのです。

直観的であること

前述の「基本的な使い方は一つだが、特定の場所で思わぬ使い方が出来る」というのは、
要するに、その道具の決められた機能にはなかったけれど、
現実世界の常識に照らし合わせて、「あ、あれでああできないかな」って考えて
試してみたら、それがビンゴだった、そういうことです。
すなわち「(現実世界に照らし合わせて)直観的である」ということです。
考えてみてください。最近の大規模なオープンワールドのゲーム(GTAシリーズを始めとする)は
全てこれに従っていますね。
そして、ゼルダの伝説も、この方向性が、シリーズを追うごとにどんどん進化しているのは、
僕より皆様の方が、詳しいと思います。
このようにゲーム内に説明はないけれど、直観的に試したら、うまくいった……
プレイヤーの期待に最大限応えてあげるのが、いいゲームデザインだといえます。
ただし、これを徹底するには、壮大な人海戦術が必要です。
個人制作では、到底追いつきません。
しかし、出来ることは出来る。多機能フックロープは、3つの機能を持たせました。

多機能フックロープの3つの機能

前述の動画を観ていただいて、もうご存知かもしれませんが、
改めて、このプラグインの3つの機能を紹介します。


1.フックロープの先に杭があった場合、プレイヤーが杭の手前まで移動
 基本。
2.フックロープが接触したイベントを起動
 川を挟んだ先にあるスイッチを操作するなど。
 - サンプルプロジェクトでは、普通に話しかけた場合と、フックロープをぶつけた場合でセリフが変わる人物を配置。
3.フックロープの先に接触したイベントを、目の前に持ってくる(フェッチ)。
 落とし穴を挟んだ先にある宝箱などのアイテムを取ってくる。
 - なお、目の前が通行不可の地形の場合、プレイヤーが一歩後退する仕様。
 - 目の前が通行不可でプレイヤーが後退不可の場合、取ってこられない。
気づかなかった人は、上記を意識して、もう一度動画をご覧ください。

このプラグインを使う際の設定について

では、このプラグインを実際に使ってみることを考えてみます。
実はこのプラグイン、多機能ゆえに、設定が少しだけ、手間がかかります。
詳しいことは、プラグインのヘルプに全て載せていますので、
ここでは、要点をピックアップしてみましょう。

何の設定に手間がかかるのか

なぜ設定に手間がかかるのか。それは「3つの動作が可能」であることの裏返しです。
どのイベント(またはタイル)に、フックロープは反応するのか。
それを設定しないといけませんが、それはすなわち、
「どのイベントがプレイヤーを移動させる杭で、
どのイベントが、イベント起動で、どのイベントが、持ってくることが出来るか」
を設定するということです。
これは主に、イベントのメモで設定しますが、
ひとつひとつ「これはこの動作」とメモに書いていたら、
作業量はとんでもないことになりますね。
そこで、プラグインのオプションで、
「ひとつのイベントに<picket>と書けば、その画像のイベントは全部杭になる」
「この条件を満たすイベントは、全部、デフォルトでフックロープが触れたら起動」
「この条件を満たすイベントは、全部、デフォルトでフックロープでフェッチ可能」
といったことが可能になっています。
具体的には、「なし」「!で始まるイベントのみ」「全て」が選べます。
なお、対象は「イベントに画像が設定されている」「プライオリティが通常キャラと同じ」を
満たすイベントだけです。
こうやってデフォルトを設定すれば、
「例外的にこの機能を持たせる(あるいは持たせない)イベント」にだけ
メモを書くことで済みます。

競合を解決するための優先順位の定義

さて、複数の機能を入れたことにより、一つ課題が出てきました。
それは「機能が競合してしまう」ことです。
ひとつのイベントに複数の機能が設定されても、その中のどれかひとつしか選べません。
また、フックロープを投げた先の範囲内に、複数のイベントがあった場合、
どれに反応すればいいのでしょう。

複数の動作が適用可能なイベントの優先順位

設定により、ひとつのイベントに、複数の機能が割り振られる設定になる状況が考えられます。
しかも、設定の方法をなるべく簡略化したため、
このプラグインでは、結構起こりやすい事象になります。
そんな時のために、複数が設定されていたら、以下の優先順位をとっています。
1(杭)>2(起動)>3(フェッチ)
こうした根拠は、より直感的なものを優先したからです。

「範囲内に複数の候補が存在した場合」

例えば、最大7延びるロープで、杭が4つ先と6つ先にあった場合、どちらに移動するか?
これは、大抵の人は、近い方、と答えるでしょう。
実際、一番近いイベントを重視しています。
しかし、開発の初期では、一番遠い方のイベントを優先していました。
その方が、なんとなく直観的に感じたからです。
ところが、テストプレイした方の全員が「不自然」と言ったため、一番近い方になりました。
いやはや、僕の「直観的」は、少しずれているのかもしれません。

サンプルプロジェクトの中身

なお、上記の動画ですが、サンプルプロジェクトをアップしています。
http://www.moonwhistle.org/tkoolMV/HookRopeTest.zip
RPGツクールMVをお持ちの方で、興味がおありのお方は、お試しください。
そして、プロジェクトをいじって、いろんなギミックを作ってみてください。
ギミックについては、僕の頭ではサンプルプロジェクトの範囲が限界でしたが、
公開することで、皆に面白い使い道を見つけてもらえそうなのでアップした、
ということです。
ぜひ、興味がおありの方は、ダウンロードして、いじって遊んでくだされば幸いです。

RPGツクールMVでDarkest Dungeon風の自動生成ダンジョンを作る

本家ダーケストダンジョンでは、クエストのクリア条件は「9割の部屋を回ること」だったり
「敵がいる部屋全てに入って敵を倒すこと」だったりしますが、
MVコラボでは、「すべての部屋を満遍なく通ること」であり、
最後に行った部屋に、ボスの前にキャンプが出来る場所へのワープホールが開けます。
さて、そんなダンジョンですが、本家に倣って、
ツクールMVのプラグインを作成して、自動生成ダンジョンにしました。
そこでツクールMVでのダンジョン自動生成の方法について説明したいと思います。

ツクールMVコラボで使われたダンジョン自動生成アルゴリズム

ツクールMVコラボでは、ダンジョンは5×5マスの中に、8〜12個の部屋を作る形式。


・オープンリストとクローズドリストを準備。
いずれも配列で、部屋IDを保存する。
部屋IDは、座標(x, y)の部屋で、y × 部屋数の幅(=5) + x になる。

1.まず始点を決める。
 - この時、上下左右、どれかの壁に隣接していることを条件としている。
 - 始点をオープンリストに入れる。
2.オープンリストに対して、それぞれ以下の処理を行う
 - この部屋から上下左右、それぞれ半分の確率で道を作る。
- 作った道の先に……
  - 既にクローズドリストに入っている部屋があったら無視。
- オープンリストに入っている部屋があったら、この部屋と廊下で繋ぐ
- いずれもないなら、新たに部屋を作り、廊下で繋ぎ、
   新しい部屋をオープンリストに加える。
- この部屋をオープンリストからはずし、クローズドリストに加える
3.クローズドリストに入った部屋の数が所定の数値(今回は8〜12)になったら中断。
 そうなるまで、2.のプロセスを繰り返す。
4.マップの完成。
- オープンリストや、それにしか繋がっていない通路など不要になったデータは即消去

上記を、ダンジョンに入る際に必ず行う。
ダンジョンを出たら、ダンジョンマップを保存するデータは破棄する。

ゲームプレイ時の部屋の作り方

動的生成されるマップをツクールMVで実現するために、
まずはそれらのマップの雛形となるものが必要である。
そこで、以下の3つの雛形マップを準備した。
(注:実際のゲームでは、マップには4種類の地形があるため、
以下のものをそれぞれの地形に合わせて3枚ずつ準備している)

  • 上下左右どこにも移動できる1画面の部屋
  • 上下方向の廊下
  • 左右方向廊下

ダンジョンはこの3つの雛形から生成されたマップだけで
構成されている(キャンプの部屋やボスの部屋は除く)。
以下に、ツクール編集画面での雛形マップを示す。



ここで大切なのは、雛形となる部屋は、四方に出入り口があることだ。
しかし実際のマップでは、通行できない方角は当然ある。
例えば、上と右だけに隣接する部屋があるマップでは、
左と下の出口を消さなければならない。
それではどうするのかを説明する。

通れない方角に処理を施す方法

簡単に言うと、部屋マップの通れない方角の出口は、
読み込まれたマップデータ($dataMap)を
フェードイン前にプラグインで直接書き換え、
壁にするという処理を行っている。
具体的には、通れない方角があれば、
その方角の壁のマップデータをコピーし、
扉部分に上書きする、というやり方を取っている。

例えば、上に通行不可能の場合、上記のように、上側の扉の部分を、
上側の他の座標の壁マップのデータを扉部分にコピーし、
通れなくしてから、マップをフェードインさせている。

廊下から、部屋からの移動の際、マップの指定方法

さて、マップは整ったが、次は移動するマップの選び方を説明する。
まず、以下の前提条件がある。

  • 廊下では両端に部屋への入り口がある
  • 部屋には通行可能な方角に廊下への出口がある

ここで部屋IDが重要になってくる(マップIDではないことに注意)。
冒頭でも書いたが、部屋は以下の式で計算される部屋IDを持っている。


座標(x, y)の部屋で、y × 部屋数の幅(=5) + x
それでは廊下はどうか。

  • 左右方向の廊下では、左の部屋の部屋IDになる
  • 上下方向の場合、上の部屋の部屋IDになる

上記から、部屋を移動するたびに、部屋IDを更新している。
そして移動の際には、部屋IDを書き換えながら、雛形マップを移動している。

オブジェ(Curio)配置について


次は、ダンジョン内にあるオブジェ(Curio)や敵の配置について解説する。
前述のダンジョン自動生成の説明では端折っていたが、
部屋がクローズドリストに追加される際に、
部屋と廊下にそれらを配置する処理を行っている。
オブジェ(Curio)や敵の数は以下のように配置している:

  • 廊下なら3つか4つ、適切な間隔を取って配置
  • 部屋には中央にひとつかふたつ置く。ふたつの場合、いずれかは敵になる。

なお、オブジェは7種類、敵シンボルの見た目は2種類だが、
廊下に配置する場合は、これら9個からランダムに配置されるため、
敵だったり、オブジェだったりする。
では置くオブジェや敵はどのように配置しているのか。
あらかじめ雛形用のダミーマップに置くことで実装している。

実行時、イベントは動的生成している

実際のゲームのプレイの際には、マップに入った際、フェードイン以前に、
部屋にあるオブジェや敵を、ダミーマップのイベントから複製し、
動的にイベントを生成している。

動的生成されたイベントのセルフスイッチについて

ゲーム中に、あるオブジェ調べたか、またはその敵を倒したかの判別には、
セルフスイッチで判断しているが、イベントは複製されていることと、
動的生成イベント専用のセルフスイッチを準備しているため、
他の同型のオブジェや敵には、影響を及ぼさない。

ダンジョン脱出時の処理

ダンジョン脱出時には、動的生成イベント用に準備されたセルフスイッチは
初期化する。ダンジョン自体がリセットされるのだから、当然である。
さもなくば、次は突然最初から空の宝箱が出てきたりしてしまう。

まとめ

以上、入るたびに形が変わるダンジョンを作る方法をかいつまんで説明しました。
もし可能なら、プラグイン素材として公開することを望む方も
少なくないでしょう。しかし、それは行わない予定です。
なぜなら、このゲームの仕様に合わせて、雛形マップIDを直接プラグイン
埋め込んでいるし、雛形マップやオブジェ(Curio)のダミーマップなど、
プラグインとして配布するには、あまりにも準備すべきものが多すぎて、
全く実用的でないからです。
よって今回のダンジョン自動生成は、あくまで概要を留めるに述べました。
将来的に何らかの形でダーケストダンジョンから独立して、
自動生成ダンジョンのプロジェクトごと公開することも検討していますが、
あまり実用性はなさそうなので見送りますが、要望が多ければ準備します。

ダーケストダンジョンMVコラボにおける戦闘シーン

ダーケストダンジョンの再現にあたって、
僕が一番力を入れたのが、戦闘です。
本家には、「こうげき」や「ぼうぎょ」といったコマンドはなく、
各キャラが持っている7つのスキルのうち、4つを選択して、
戦闘時にそれを使うというものです。
さすがにこれは再現できませんでしたが、各職業ごとに、
皆がよく選んでいるだろうな、と思うものをピックアップして出しました。

結果、戦闘では、本来「攻撃」「防御」ところで
直接スキルを呼び出す形になっています。

そしてもうひとつ特徴的なのは、ほとんどの技は、
アクターが先頭から何番目にいるかで、使えるかどうかが異なること、
効果範囲も、前列にしか届かないとか、2・3列目に効果があるとか、
効果範囲が非常にシビアなのです。
しかも、複数マスを占有する敵もいるため、さらに混乱を大きくしそうです。
ここをどうするか、ヘルプの行数を1行増やして腐心して対処しました。
通常のツクールMVの戦闘では、先頭から何番目にいるかとか、
どういった範囲なのかは、完全にドラクエ風で間違えようがないと思います。
これに慣れている人にとっては、かなり面食らう事実だと思います。
ただし、ツクールMVコラボでは、一度決めた並び順は変わりません。
しかし実際の戦闘では、不意打ちで隊列を乱されたり、敵や味方が使うスキルで
自動的に頻繁にポジションが移動します。
ツクールMVコラボでも、恐らく使われることのない、
「並び替え」コマンドや、後列職専用の前列攻撃があるのは、その名残です。

敵のパラメータが見え、スキルも使い放題なのに苦戦

本家にもツクールMVコラボにも、MPの概念はありません。
スキルは、使い放題です。
ツクールMVコラボでも本家に倣い、
敵のパラメータを表示していますし、MPの概念もありません。

「MPもなくて、敵の手の内が分かるなら楽勝じゃないか」と
思われる方がいらっしゃるかもしれません。
しかし、このゲームは非常に難易度が高いため、
これだけやっているのに、まだ全滅と隣り合わせのバランスになっています。
ツクールMVコラボでは、前述の通り主人公たちが不死身なので
そこまでの難易度はないにせよ、ここは譲れなかったところです。

見知らぬパラメータや、状態異常の重ね掛けなど、ツクールMVになかった機能

その他、戦闘関係のあれこれを再現するために、
このゲーム用に相当な量のプラグインを書きました。
例えば本家ダーケストダンジョンでは、ダメージの表記が独特です。
「10-19」のように、10〜19ダメージを敵に与える、といった感じです。
ツクールMVコラボでもこの形式にして、整合性を取っています。

また、本作を代表するストレス。これは、TPを利用しています。
本作品ではTPを利用しなかったことから、扱いやすいと思ったからです。
実際、いくつかのプラグインでTPを扱うものがあり、
それをストレスの値として扱うことが出来て、かなり便利でした。
そしてひとつ苦労したのが、出血や毒(Blight)といった状態変化は、
重ね掛けが可能だということです。敵に決まった場合、効果は大きいですが、
敵から受けると、どんどんスリップダメージが増えて不利です。
今でこそ、パラメータの重ね掛けプラグインがありますが、
開発中は見つからなかったので、自分で作りました。

皆様のプラグインも使わせていただきました

例えば「大技だが使った後、使用者のパラメータが若干減る」
というような場合、トリアコンタンさんの SideEffectSkill.js を
使用させていただきました。
他にもVestalの「攻撃命中時に自分のHPが回復」といったスキルも、
トリアコンタンさんのプラグインを利用しています。
また、本家では自分のターンが回ってきたとき、包帯や毒消しを使うことが
可能ですが、何とアイテムの使用にはターンを消費しないのです。
こちらは、Torigoya_QuichSkill.js を使わせていただきました。
また、CTB(自分に攻撃の順番が回ってきた時点で、コマンドを入力)は、
Yanfly氏のプラグインで実現しています。
エンディングにもクレジットを載せましたが、改めて皆さまありがとうございました。

まとめ

このように、戦闘は、ゲームの中での見せ場のため、妥協しませんでした。
攻撃範囲制限や副作用、パラメータの重ね掛けなど、
相当数のプラグインを書いたおかげで、かなり本家のプレイヤーさんも
納得してくれる出来になったと自負しています。
次回(12月4日)は、ダンジョンの動的生成の部分についてお話ししたいと思います。