2016年11月27日日曜日

ファイルダウンロードプラグイン

RPGツクールMVで使用可能な自作プラグイン「ファイルダウンロードプラグイン」の紹介です。

プラグインの説明

ゲーム中にインターネット上からファイルをダウンロードしてプロジェクト配下の任意の場所に配置できます。同名ファイルは上書きされます。
配置したファイルはゲーム中で動的に参照することができます。

スクリーンショット

スクリーンショット

利用用途

開発時のプラグインの自動アップデート

ゲーム起動時に自動で配布元の最新プラグインを適用できます。わざわざ確認しなくても機能追加やバグ修正が行われた最新のファイルを利用できます。
ただし、すでに適用済みのプラグインを更新した場合、変更を反映させるにはゲームをリロードする必要があります。

※パラメータ「配布サイトURL」をデフォルトのままで以下のプラグインコマンドを実行すると、本プラグインを最新化できます。

  • FD_MY_PLUGIN FileDownloader.js

小規模なアップデートファイル配信

あらかじめ準備しておけば、プレイヤーにゲーム全体を再ダウンロードさせずに一部ファイルのみ差し替えさせることができます。

インターネット上の画像をピクチャ表示

ネット上の画像ファイルなどを取り込んでゲーム内で使用することができます。著作権等には十分ご注意ください。

おまけ機能

おまけ機能で「指定したURLを既定のブラウザで開く」プラグインコマンドが使えます。

プラグインコマンド

FD_FILE http://~.png test/     # 指定したURLのファイルをtest/に配置
FD_ファイル http://~.png test/ # 同上
FD_MY_FILE ~.json data/        # 指定したパスのファイルをdata/に配置
FD_マイファイル ~.json data/   # 同上
FD_PLUGIN http://~.js          # 指定したURLのjsをjs/plugins/に配置
FD_プラグイン http://~.js      # 同上
FD_MY_PLUGIN ~.js              # 指定したパスのjsをjs/plugins/に配置
FD_マイプラグイン ~.js         # 同上
FD_PICTURE http://~.png        # 指定したURLのpngをimg/pictures/に配置
FD_ピクチャ http://~.png       # 同上
FD_MY_PICTURE ~.png            # 指定したパスのpngをimg/pictures/に配置
FD_マイピクチャ ~.png          # 同上
FD_START_SITE http://~.jp      # 規定のブラウザで指定したURLを開く
FD_サイト起動 http://~.jp      # 同上

ダウンロード

プラグインファイルはGithubで公開しています。
https://raw.githubusercontent.com/triacontane/RPGMakerMV/master/FileDownloader.js

ダウンロード方法(Windowsの場合)

  1. リンク先に飛ぶ
  2. 右クリック
  3. 名前を付けて保存
  4. ファイル名を変えずに、プロジェクトの「js/plugins」配下に配置

このプラグインを適用すれば、以後は以下のコマンドでOKです。

FD_MY_PLUGIN FileDownloader.js

利用規約

当プラグインはMITライセンスのもとで公開されています。作者に無断で改変、再配布が可能で、利用形態(商用、18禁利用等)についても制限はありません。このプラグインはもうあなたのものです。
http://opensource.org/licenses/mit-license.php

2016年11月20日日曜日

反撃拡張プラグイン

RPGツクールMVで使用可能な自作プラグイン「反撃拡張プラグイン」の紹介です。

プラグインの説明

反撃の仕様を拡張します。
魔法に対する反撃や、特定のスキルを使った反撃、特定の条件下でのみ発動する反撃などが作成できます。

特定のアイテムを装備時のみ特殊な反撃技を指定したり、特定の攻撃に対してボスが強力な反撃を繰り出したりする設定が可能です。

具体的な機能詳細は以下の通りです。

機能詳細

  1. 魔法攻撃を受けた場合もカウンターが発動するようになります。
    専用の発動率を指定可能で、指定しない場合は、物理攻撃と同様の反撃率が適用されます。

  2. 反撃時のスキルを個別に設定することができます。
    MPなどのコストが不足している場合の挙動はカスタマイズできます。

  3. 反撃条件をJavaScript計算式の評価結果を使って詳細指定できます。反撃条件を満たさない場合は反撃は実行されません。
    特定のスキルや属性に対してのみ反撃したり、特定の条件下でのみ反撃したりできます。
    ヘルプにいくつかのサンプルが用意されています。

  4. 反撃実行時に専用のアニメーションIDを再生できます。

スクリーンショット

スクリーンショット

メモ欄指定方法

特徴を有するデータベースのスキルのメモ欄に以下の通り指定してください。

<CE_魔法反撃:50>      # 魔法攻撃を受けた場合に50%の確率で反撃します。
<CE_MagicCounter:50>  # 同上
<CE_魔法反撃>     # 魔法攻撃を受けた場合にもともとの反撃率で反撃します。
<CE_MagicCounter> # 同上
<CE_反撃スキルID:\v[1]>    # 反撃時に変数[1]のIDのスキルを使用します。
<CE_CounterSkillId:\v[1]>  # 同上
<CE_魔法反撃スキルID:3>    # 魔法反撃時にID[3]のスキルを使用します。
<CE_MagicCounterSkillId:3> # 同上
<CE_反撃条件:v(1) &lt; 100>    # 変数[1]が100より小さければ反撃します。
<CE_CounterCond:v(1) &lt; 100> # 同上(※2)
<CE_魔法反撃条件:s(1)>         # スイッチ[1]がONなら魔法反撃します。
<CE_MagicCounterCond:s(1)>     # 同上
<CE_反撃条件:skill.id === 10>              # スキルIDが[10]なら反撃します。
<CE_反撃条件:skill.damage.elementId === 3> # スキル属性が[3]なら反撃します。
<CE_反撃条件:this.hpRate() &lt; 0.5> # 自分のHPが50%を下回ると反撃します。
<CE_反撃アニメID:20>       # 反撃実行前にアニメーション[20]を再生します。
<CE_CounterAnimationId:20> # 同上
 
※ 文章、スクリプト中で不等号を使いたい場合、以下のように記述してください。
< → &lt;
> → &gt;

ダウンロード

プラグインファイルはGithubで公開しています。
https://raw.githubusercontent.com/triacontane/RPGMakerMV/master/CounterExtend.js

ダウンロード方法(Windowsの場合)

  1. リンク先に飛ぶ
  2. 右クリック
  3. 名前を付けて保存
  4. ファイル名を変えずに、プロジェクトの「js/plugins」配下に配置

利用規約

当プラグインはMITライセンスのもとで公開されています。作者に無断で改変、再配布が可能で、利用形態(商用、18禁利用等)についても制限はありません。このプラグインはもうあなたのものです。
http://opensource.org/licenses/mit-license.php

2016年11月15日火曜日

BGS並行演奏プラグイン

RPGツクールMVで使用可能な自作プラグイン「BGS並行演奏プラグイン」の紹介です。

プラグインの説明

複数のBGSを並行して演奏できます。プラグインコマンドからBGSの演奏ラインを変更すると元のBGSを演奏したまま、新しくBGSを演奏することができます。
並行演奏しているBGSはそれぞれ個別に、音量やピッチ、左右バランスを調節できます。
演奏ラインのデフォルトは[1]です。

追加機能

追加機能として、BGS演奏中にSEを演奏すると自動でBGSを一時フェードアウトするプラグインコマンドを提供します。SEがより明瞭に聴き取れるようになります。
フェードアウト時間やSEの演奏タイミングを設定することもできます。

ダウンロード

プラグインファイルはGithubで公開しています。
https://raw.githubusercontent.com/triacontane/RPGMakerMV/master/ParallelBgs.js

ダウンロード方法(Windowsの場合)

  1. リンク先に飛ぶ
  2. 右クリック
  3. 名前を付けて保存
  4. ファイル名を変えずに、プロジェクトの「js/plugins」配下に配置

利用規約

当プラグインはMITライセンスのもとで公開されています。作者に無断で改変、再配布が可能で、利用形態(商用、18禁利用等)についても制限はありません。このプラグインはもうあなたのものです。
http://opensource.org/licenses/mit-license.php

2016年11月7日月曜日

「第三回自作ゲームフェス勉強会」に参加してきました!

 家に帰ってブログを書くまでが勉強会、ということで「第三回自作ゲームフェス勉強会」に参加してきました!

 自作ゲームフェスMVについてはこちらをご参照ください。

バナー

 結論から言うと、同人ゲーム作者としても、プラグイン作者としても、またラノベ作家志望者としても、非常に得るものの多い濃い勉強会でした。今回、貴重な機会を作ってくださった主催者様に改めてお礼を申し上げます。

なんで参加したの?

 もともと私は、自作ゲームフェスMVの企画のひとつとして「ノベルゲーム総合プラグイン」の作成や「ツクールMVでプラグインを作るための現実と作法」の記事執筆などでフェスと関わらせて頂いた関係上、興味はありましたが一方で、現在はゲームそのものは作っておらず、参加するかどうか迷っていました。
 しかし、市販の有名ホラーゲーム『零』シリーズを手掛けた柴田誠氏が講師として招かれるということで、参加する決意を固めた次第です。ホラーというジャンルは、ラノベ業界では滅多に見られない異端である一方、フリーゲーム業界では(実況という前提もありますが)一大勢力を築いているのでその勢いをなんとかラノベに応用できないかと常々考えていたのです。(この話は長くなるので適当に切り上げます)

柴田誠氏の講演を聴いた感想

 あくまでも私の解釈なので氏の実際の発言意図とは異なる可能性があります。

ホラーゲームの難しさ

 まず『零』シリーズのコンセプトと企画書が紹介されました。端的に言えば「カメラ」を使って霊から身を守りつつ進めていくゲームです。私はホラーゲームについてはあまり明るくなく当該シリーズも未プレイなのですが、やはり小説に限らずゲームでもホラーならではの「難しさ」というのが感じられました。
 ホラーというジャンルは基本的に矛盾を孕んでいます。人が忌避するモノをあえて見せていく。見たくないのに見たい。怖いのに遊びたい。他のジャンルであれば、そのジャンルの特性を突き詰めることがそのまま面白いゲーム作りに直結するところですが、ホラーは必ずしもそれが正解とは限らない。その点については、プロである柴田氏すらも悩まれて試行錯誤されたようです。私は、その相反する感情を抱かずにいられないことこそが(媒体を問わず)ホラーの何よりの魅力だと思います。

媒体による恐怖演出の違い

 個人的に興味があり、事前に「小説や映画とは違ったゲーム独自の怖さ」というテーマで質問させて頂きました。そこで挙げていただいた内容として「主人公になりきって恐怖を直に体験できる没入感」「主人公の行動に応じて最適なタイミングで恐怖演出を見せられるインタラクティブ性」というものでした。とても腑に落ちる内容でしたが、一方でこれは欠点にもなるようで、一度対処法を確立してしまえば、あとは流れ作業となってしまい恐怖感が長続きしない側面もあるそうです。
 そういう意味で『零』シリーズでは、対抗手段が一般的な武器ではなく「カメラ」というなんとも心許ない道具が使われているのだと思います。カメラ自体が武器でないのはもちろん、構えている間は無防備で、かつ視界が遮られつつも、対象を凝視しなければならないというリスクを背負うことになりますから……(想像で言っています)

3Dと2Dによる演出の違い

 また、興味深かったのが、同じゲームというジャンル内でも3Dと2Dとでは演出手法はもちろん、最適なストーリーすら異なるのだそうです。たしかに音響を使った演出や、恐怖の対象が迫ってくる感覚というのは、3Dだからこそ十分に表現できるものですよね。そういう意味ではフリーのホラーゲームの盛況と市販のホラーゲームとではアプローチの仕方からして異なり、2Dは小説に近い部分もあるのかもしれません。

その他

 懇親会の際に柴田氏に個人的に伺ったのですが、サイコホラー(主に人間そのものの怖さを炙り出していくホラー)はやはりゲームにはあまり向かないのだそうです。当然と言えば当然かもしれませんが……
 なので私がホラーゲームを作る際は、そこから考え直さないといけないかもしれません。

自作ゲームプレー企画

 自作ゲームを互いにプレーする企画でした。今回はただ遊ぶのではなくて、作者からは一切説明を受けずゲームの意図を付箋に書き出すという面白い試みが行われていました。
 「作者視点で」他人の作品に触れるというのは、映画でも小説でも意識的なインプットをする際にとても重要な考え方だと思います。ただ受け身で遊ばせてもらうのではなく、ゲームを面白くするための作者の意図を理解しながらプレーすることではじめて自分の中で経験値として蓄積される……ということですね。

グループワーク

 「新しいゲームをデザインする参加型のコーナーです。グループをくんでゲームを完成させます」という説明を事前に拝見したときは、正直行くの止めようかと思いました(笑)。グループ活動にはそれなりのトラウマがあって、他のメンバーが黙々と作業をするかたわら、自分は何をやっていいのか分からなくてオロオロしてしまうのです。(思い当たるフシがある方が一人でもいることを祈ります……)
 しかし、実際に参加してみるとそういった心配は無用でした。ゲームデザインのアプローチについて用意された仮説に従ってグループで議論を重ねて、限られた材料の中からアナログゲームを作っていくという内容で、特に役割分担して作業するような内容ではなかったです。

カメラの設定がおかしくて周囲が黒いですが気にしないでください

スクリーンショット

ゲームの要素を3つに分割する

 仮説ではまずゲームの構成要素を3つに分割して説明していました。以下の3つです。

  • ゴール(ゲームの最終目的)
  • 障害(最終目的であるゴールを阻む要素)
  • 行動(障害を乗り越えてゴールに辿り着くために、プレイヤーの行うこと)

 例えば「スーパーマリオブラザーズ」だと以下のようになります。

  • ゴール:一番右に辿り着くこと
  • 障害:敵と穴
  • 行動:ジャンプ 

作業手順

 ここで重要なのは「行動」で、多くのゲームでは「行動」が必然的に反復されるのでここが面白くなければゲームとして成り立ちません。
 そこでまずは「行動」から決めていきます。チームごとに固有のアイテムが割り当てられ、私の所属したチームでは「おはじき」でした。そして議論を重ねた結果、「行動」は「はじく」となり、他の要素は以下の通りになりました。

  • ゴール:フィールド内の敵を殲滅する
  • 障害:敵のHP(おはじき)
  • 行動:はじく

 簡単に説明すると、プレイヤーのおはじきを「はじく」ことで敵おはじきを外に押し出すアクションゲームです。大きなおはじき(主人公)をはじいて、色つきのおはじきを対応する陣地から追い出します。こうしてあえて説明しなくても三要素から推測できるあたり、なかなかよく考えられていますね。

ゲームの外観

スクリーンショット

反省と総括

 RPGというジャンルは上記三要素がすでにおおよそ確立されていることもあり、今までゲームデザインを理屈として意識することは正直なかったのでとても勉強になりました。上記三要素については、ストーリーを作る上でも流用できる考え方だと思っています。(その場合は行動よりも障害の方が重要になるかもしれません)
 また、ゴールがひとつでなくても、複数の小ゴールと最終的な大ゴールみたいな入れ子構造があってもいいかもしれません。(あまり複雑になり過ぎるのも考えものですが……)

勉強会を終えて

 人それぞれ得意分野は違っても、モノを創るというのはとてつもなく面白い、ということを再認識できた勉強会だったと思います。ある程度成熟した社会では、すべての人が何らかの創作をする……くらいでちょうどいいのではないでしょうか。
 そういう意味で、技術や才能にとらわれず個人ゲーム制作の間口を広げてくれるツクールというソフトやそれを取り巻くコミュニティが私は好きですし、発表の場を設けてくださる自作ゲームフェスには深く感謝しています。
 最後に、「ノベルゲーム総合プラグイン」ぜひ使ってくださいね。

 以上です。お付き合いくださりありがとうございました。

2016年11月1日火曜日

動的変数プラグイン

RPGツクールMVで使用可能な自作プラグイン「動的変数プラグイン」の紹介です。

プラグインの説明

指定範囲内の変数、スイッチを参照しようとした際に、「変数名称」及び「スイッチ名称」をJavaScriptとして実行した結果を返すよう変更します。

プラグインの使い道

イベントページの出現条件に設定

イベントエディタにおける「出現条件」に対象変数もしくはスイッチを指定することで、イベントページにより複雑な条件を設定することができます。
下記の例では、スイッチ欄が「変数[1]が[0]より大きい、またはスイッチ[1]がON」という条件になります。

スクリーンショット

戦闘行動に設定

条件にスイッチを指定することで敵キャラの行動をより奥深く管理できます。
スクリーンショット

定数値として使用

スイッチに「true」、変数に「'AAA'」などと記述すると常に同一の値を返す定数値として使用できます。
スクリーンショット

その他の変数・スイッチを参照する例

  1. 条件分岐
  2. イベントコマンドの各種オペランド
  3. 文章の表示の制御文字
  4. スキルやアイテムの計算式(ただしv[1]で参照した場合は除く)
  5. その他プラグインによる参照

スイッチ、変数名称の設定方法

JavaScriptを利用して記述するため難しいイメージがありますが、スキルやアイテムの計算式と同様の感覚で設定すればOKです。また、式の簡略化のために以下のローカル変数が利用できます。

v(n)      # [n]番の変数の値
s(n)      # [n]番のスイッチの値
max       # Math.maxに変換されます。(例 : max(1, 2) -> 2)
min       # Math.minに変換されます。(例 : min(1, 2) -> 1)
gPlayer   # $gamePlayerに変換されます。(例 : gPlayer.x -> プレイヤーX座標)
dSystem   # $dataSystemsに変換されます。(例:dSystem.startX -> 開始位置X座標)

Math.max以外にも一般的なMathモジュールのメソッドが使用可能です。また、他のゲームオブジェクト、データオブジェクトも同じ記法で参照できます。
いずれも利用には、多少のJavaScriptの知識が必要になります。

また、スクリプト中でさらに動的変数およびスイッチを参照することもできますが 同じ番号の変数 or スイッチを参照しようとすると循環参照となりエラーが発生します。

  • 設定例1 イベントページの「スイッチ」に「名称」が以下のものを設定する。

    v(1) > 0 || s(1) # 変数[1]が[0]より大きい、もしくはスイッチ[1]がON

    以上の条件を満たした場合に対象ページが表示される。

  • 設定例2 イベントページの「スイッチ」に「名称」が以下のものを設定する。

    v(1) < v(2) && !s(2) # 変数[1]が変数[2]より小さい、かつスイッチ[2]がOFF

    以上の条件を満たした場合に対象ページが表示される。

  • 設定例3 イベントページの「スイッチ」に「名称」が以下のものを設定する。

    gPlayer.x % 2 === 0 # プレイヤーのX座標が偶数

    以上の条件を満たした場合に対象ページが表示される。

使用上の注意

通常、イベントのページを決定する処理は、いずれかのスイッチもしくは変数が変更されたときにのみ実行されます。本プラグインでは、パフォーマンス上の理由からその仕様を維持します。もし、指定している条件がスイッチおよび変数と完全に無関係な場合(設定例3のケース等)イベントのメモ欄に以下の通り入力すると、そのイベントのみ常にページの条件チェックを行うように変更できます。

ダウンロード

プラグインファイルはGithubで公開しています。
https://raw.githubusercontent.com/triacontane/RPGMakerMV/master/DynamicVariables.js

ダウンロード方法(Windowsの場合)

  1. リンク先に飛ぶ
  2. 右クリック
  3. 名前を付けて保存
  4. ファイル名を変えずに、プロジェクトの「js/plugins」配下に配置

利用規約

当プラグインはMITライセンスのもとで公開されています。作者に無断で改変、再配布が可能で、利用形態(商用、18禁利用等)についても制限はありません。このプラグインはもうあなたのものです。
http://opensource.org/licenses/mit-license.php

2016年10月21日金曜日

ツクールMVでプラグインを作るための現実と作法

ツクールMVでプラグインを作るための現実と作法

はじめに

 本稿は株式会社ドワンゴ様から依頼を請けてニコニコ自作ゲームフェスMVの企画の一部として執筆しています。ニコニコ自作ゲームフェスMVでは、みなさんのツクールMV作品を随時募集しています。私が作成したノベルゲーム総合プラグインによる「企画」なんかもありますので、ふるってご参加ください!

ニコニコ自作ゲームフェスMV

 早いものでRPGツクールMVの発売からもうすぐ一年が経過しようとしています。私は、去年の十月末に海外版がSteamで先行販売されたときに衝動買いをして以来、プラグイン制作に的を絞って活動してきました。その過程で私なりにプラグイン制作と公開に関していくつかの知見を得ることができたと思っています。

 そこで本稿では、これからプラグイン作成(自作品用のプラグイン制作含む)を始めようという方を主な対象に、プラグインの作成から一般公開までの流れの中で重要なポイントを簡潔に説明しようと思います。JavaScript(以下JS)に関する知識としては、変数や関数、オブジェクト指向を把握している程度の方を想定していますが、専門的なことには一切触れないので、それらは後回しでもOKです。逆に言うと、本稿はJSやプラグインそのものの講座ではありませんのでご注意ください。

 繰り返しますが専門的な記述は一切ありません。プラグインは使うだけ、という方でも多少は得るものがあるように頑張って書いたのでお付き合いくださいませ~。

準備編

優秀なお手本を参考にする

 さあプラグイン制作を始めよう、と意気込む方がよく行うのが本屋に駆け込んで教本を買うことです。ですが、個人的にはあまりオススメできません。プラグイン制作は一からアプリケーションを作成するのとは勝手が違います。すでにコアスクリプトという優秀なお手本が存在するので、そのレールに従えばいいのです!
 もちろん、これを機にJSを本格的に勉強してみたいという方はその限りではありませんよ! 書籍に関しては以下の記事が参考になるかと思います。

参考:初心者ツクラーの為のJavaScript入門

 とはいえ個人的には、よほどガッツリと学習するのでなければ以下のサイトで事足りると思います。基本的なことはすべてここに載っているはずです。

参考:Mozilla Developer Network JavaScript

 お手本は二つあります。ひとつは前述したコアスクリプト。プロジェクトのjsフォルダに入っているファイル群ですね。ツクールMVを動かしているすべての記述がここにあり、JSの基本文法に関してはここを読んでいれば嫌でも身につきます。どうせ何度も読み返すことになるでしょう。

 そして、もう一つのお手本は公式プラグインです。新規プロジェクトの「js\plugins」以下に最初から入っています。作者が「Yoji Ojima」(尾島陽児氏)となっていて、かつ構造がシンプルなもの……となるとTitleCommandPosition.jsがベストでしょう。基本的なプラグインの作法はこのファイルに詰まっています。

 参考にするうえで重要なのは次の二つです。

  1. 即時関数
  2. 再定義
// これが即時関数です。JS(ES5の場合)ではこの方法でしか変数のスコープを規定することができません。
(function() {
 
    // 上書きする前の関数を変数に入れます。(JSでは関数への参照を変数に代入することができます)
    var _DataManager_setupNewGame = DataManager.setupNewGame;
    DataManager.setupNewGame = function() {
        // 関数の最初で保持しておいた上書き前の関数を呼び出します。(applyは変数に入れた関数を実行するメソッド)
        var result = _DataManager_setupNewGame.apply(this, arguments);
        // 自分が入れたい処理を実行します。
        $gameParty.gainItem($dataItems[4], 1);
        // 上書き前の関数が戻り値を返している場合は、それを返します。         return result;     };
})();

 即時関数とは、定義したその場で実行される関数です。なぜそんなものが必要なのか? それは関数内で定義したローカル変数の有効範囲をプラグイン内に限定するためです。簡単に言うと、変数名が他のプラグインと競合することを防ぐためです。即時関数内で定義するローカル変数は、競合の心配は一切無用です

 次に再定義です。これは既存のコアスクリプトの関数の定義を保持したまま、独自の処理を追加することを可能にします。

 海外のプラグインの中には、お手本とはかけ離れた独特なプラグインが多数あります。内容を把握したうえで記述方を取り入れるぶんには全く問題ないですが、もっともシンプルかつ実害の少ないやり方が公式プラグインの記法であることは間違いないと思います。

エディタを用意する

 さて、これからプラグインの作成を……といきたいところですが、その前にやることがあります。エディタ(IDEを含む)の準備です。

 JSはテキストファイルなのでテキストエディタであればなんでも編集できます。しかし、プログラミングに適したエディタを選択することで、コードの静的解析や補完、デバッグ実行などプログラミングをするのに役立つ恩恵を受けることができます。前作でRGSSを扱っていた方にはピンとこないかもしれませんが、ツクールMVでは自分で自由に制作環境を選択できるのです。JSはRGSS(Ruby)と比べて扱いにくいと言われていますが、前述の各種アシスト機能に頼ることで大幅に負担を軽減できます。

  • エディタの表示例(画像はWebStorm) Web Strom

 JSに対応したプログラミング向きのエディタはたくさんあり、すべてを比較検討していてはそれだけで一つの記事になってしまうのでここでは割愛してエディタの代表的な機能を見ていきましょう。

  • 静的コード解析
     静的コード解析とはコードを直接実行せずに内容を解析して、文法エラーや不適切な記述を事前に見つけ出してくれる機能です。エラーや危険な記述を未然に防ぐことはもちろん、独自の検査ルールでコードの品質を全体的に高めてくれます。
  • コード補完
     オートコンプリートとも呼ばれる機能で、入力しようとしている処理(変数やメソッド等)を予測して候補としてポップアップで提示してくれます。単なる前方一致のものや、あいまい検索で柔軟に候補を提示してくれるものもあります。
  • 定義先にジャンプ
     正式な名前が分からなかった(笑)。関数や変数を定義している場所に瞬時に移動できる機能です。コアスクリプトは無数の関数に分割されていますが、この機能があれば迷うことなく処理の流れを追うことができます。もちろん元の場所に戻ることもできます。エディタによって同一ファイル内に限定されるものと、別ファイルまでジャンプできるものとがあります。
  • アウトライン解析
     エディタに表示しているファイル内に定義されている変数や関数を一覧で表示してくれる機能です。クリックするともちろんエディタ上の実際の場所にジャンプします。
  • デバッグ実行
     少し難しい話になってしまいますが、デバッグ実行では、ブレークポイントというものを実行前に張っておけば、実行時に処理がそこで停止し、その時点での変数やオブジェクトの中身を確認したり、任意のスクリプトを自由に実行したりできます。さらにステップ実行といって止まった箇所から一行ずつ実行することも可能です。
  • Webサーバ機能
     これは一部のIDEに限定された機能ですが、ローカル環境上で仮想のWebサーバとして動作し各種ブラウザ(Chrome, Firefox, Edge)での動作確認を行うことができます。Firefoxなどは直接実行しても一応動作しますが、より実際のブラウザ版に近いかたちで動作確認できるメリットは大きいです。

 肝心のエディタですが、私が軽く確認したところ比較的よく使われているのが「Sublime Text3」「Brackets」「Visual Stadio Code」「WebStorm」あたりのようです。(後ろにいくほど高機能な代わりに起動が遅いです)機会があれば、それぞれの使い勝手も検証したいところですね。

作成編

プラグインをStrictモードにする

 お手本にエディタ、材料と道具の準備が完了したところで、早速プラグインを作成……といきたいところですが、お手本にひとつ追加して欲しいコードがあります。

'use strict'という構文です。

(function() {
    // 必ず即時関数の先頭に定義します。
    'use strict';
 
})();

 これはJSをstrictモードで実行するために必要な一文です。必ず即時関数の「直後」に入れてください。strictモードに関する解説はこちらの記事が参考になるでしょう。要はそのままだと自由すぎるJSに対して、制限を掛けてくれるモードです。リスクのある書き方や紛らわしい書き方を未然に防ぐことができます。

参考:Mozilla Developer Network Strict モード

発生したエラーの対処をする

 プラグインを作成して試しに実行したら、あるいはプラグイン素材を適用したらエラーが発生した……としても落胆することはありません。

 エラーが発生したときの一番の手掛かりは「スタックトレース」です。スタックトレースとは、処理がどのような経路で最終的にエラーに至ったのかを示してくれるものです。ツクールで実行している場合はF8キー押下で、エディタから実行している場合はコンソールを見れば、スタックトレースを確認することができます。

  • スタックトレースの表示例 スタックトレースの表示例

 スタックトレースを確認すると、多少慣れた人ならエラーのおおよその見当を付けることができます。もしあなたがプラグイン素材の利用者なら、ぜひこのスタックトレースの情報を提供してあげてください。ただし、スタックトレースにはご自身のローカルファイルパスが含まれている場合があります。必要に応じてマスキングするなどの対処をしてください。

 次に発生したエラーごとの対処法……といってもJSはゆるい言語なので、エラーの種類もさほど多くありません。そして、エラーの原因はほとんどひとつに絞られます。それは「存在しないものを」参照しようとした場合です。

  • ReferenceError: aaaa is not defined
var aaa = {};
console.log(aaaa); // ReferenceError: aaaa is not defined

 定義されていない識別子を使用した場合に発生します。ほとんどの場合、ただのタイプミスです。スタックトレースから発生した行数を特定すればすんなりと解決できます。そもそもエディタの静的解析を使いこなしていれば事前に教えてくれることがほとんどなのであまりお目にかかることはないです。

  • TypeError: undefined is not a function
var aaa = {};
aaa.bbb(); // TypeError: undefined is not a function

 なんとも不親切なエラーメッセージですね。関数以外のプロパティを実行「()」しようとすると発生します。いや存在するはずだ! という場合は、処理をさかのぼって、メソッドの実行主体(この場合は「aaa」)に想定する値が入っているかどうかを確かめましょう。ここでスタックトレースが役に立ちます。

  • TypeError: Cannot read property 'ccc' of undefined
var aaa = {};
aaa.bbb.ccc; // TypeError: Cannot read property 'ccc' of undefined

 存在しない値に対して、さらにプロパティを参照すると発生します。ここでundefinedなのはbbbです。対処方法は、前のヤツとほとんど同じです。

競合を解決する、あるいは未然に防ぐ

 多数のプラグインを同時に動かすときの脅威が競合です。まずは競合が発生する主な要因と対処法をまとめてみました。

  • 同一処理に対する複数の再定義
     複数のプラグインが同じメソッドを再定義して、かついずれか一つが元のメソッドを呼び出していない場合、単独では呼ばれたはずの処理が呼ばれないことがあります。
     運が良ければプラグイン管理画面からプラグインの順番を入れ替えることで解決できますが、そうでない場合は、どうにかして元の処理を呼び出すように変更するしかありません。
     効率は悪くなりますが、元の処理を呼び出すことでオブジェクトの状態が不都合に変えられてしまう場合も、再定義で変えられた処理を元に戻すことができる場合があります。実行時間は当然伸びてしまいますが、競合するよりはマシです。たとえ無駄な処理だとしても極力、元の処理を呼び出すようにしましょう。
(function() {
    var _DataManager_setupNewGame = DataManager.setupNewGame;
    DataManager.setupNewGame = function() {
        _DataManager_setupNewGame.apply(this, arguments);
        // 後に定義した処理が、元の処理を呼び出していなければ先に定義した処理は呼ばれません。
        console.log('呼ばれない');
    };
})();
 
(function() {
    DataManager.setupNewGame = function() {
        console.log('呼ばれる');
    };
})();
  • 追加した識別子の名前が衝突
     追加したメソッドや変数の名前が衝突してしまうケースです。命名には一定の規則があるので意外と起こります。これは即時関数や名前空間などを用いても防ぐことはできません。
     ただし対処法は簡単です。名称が衝突しただけなら、どちらかの名称を変えればいいだけです。
(function() {
    DataManager.newMethod = function() {
        // 追加したメソッド名称がたまたま衝突してしまった場合、先に定義した処理は呼ばれません。
        console.log('呼ばれない');
    };
})();
 
(function() {
    DataManager.newMethod = function() {
        console.log('呼ばれる');
    };
})();
  • 既存変数の状態を変更
     厄介なケースです。たとえば、あるプラグインが既存の変数の値をnullに変えてしまい、直後に別のプラグインがその変数のプロパティを参照するとエラーになってしまいます。
     変数の型を変える場合、特にリスクが高いです。とある海外のプラグインでは、boolean型の既存プロパティを配列に変えたりしていました。自由なJSならではの荒技ですが、そのぶん影響も大きくなります。
     対処するには、事前にチェックを入念に行うことです。特に配列に対して繰り返し処理をする場合は、想定外のものが入っていた場合に弾けるように、特定のプロパティや関数を保持しているかなどの分岐を作っておきましょう。  もっともこのケースは実際に競合を確認してから対処する場合が多いですが……
(function() {
    var _DataManager_setupNewGame = DataManager.setupNewGame;
    DataManager.setupNewGame = function() {
        _DataManager_setupNewGame.apply(this, arguments);
        // 先の処理でnullが入れられているのでエラーになる
        var length = this._databaseFiles.length;
    };
})();
 
(function() {
    var _DataManager_setupNewGame = DataManager.setupNewGame;
    DataManager.setupNewGame = function() {
        this._databaseFiles = null;
        _DataManager_setupNewGame.apply(this, arguments);
    };
})();

命名に関する約束ごと

 プラグインを作るうえで、数多くの命名が必要になります。ファイル名はもちろん、関数名やメソッド、変数名。さらにプラグインパラメータやプラグインコマンドの命名も含めて、命名は可読性はもちろん、使い勝手にも大きく関わってきます。

  • プライベートなプロパティ・メソッド
     JSでは定義したプロパティは外部から自由に参照できます。コアスクリプトでは先頭にアンダースコア(_ ) が含まれているプロパティやメソッドは外部から参照してはならない、という意味のようです。(とはいえ、そのコアスクリプト自身が一部でその約束を破っているので微妙ですが、意図としては間違いないと思います)
     なので参照したい場合は、取得および設定するためのメソッドを別途、定義してやり取りするのがお行儀の良い書き方になります。
  • プロパティとメソッドの区別
     オブジェクト指向において、プロパティとは主体の持つ属性であり、値が入っているだけです。一方、メソッドは主体の動作であり、処理を実行して必要に応じて結果を返すものです。アクセサプロパティなどの例外もありますが割愛します。
     よってこれらの命名の際は、プロパティには「名詞」、メソッドは「動詞」を最初に付与すると分かりやすく区別できます。続けて「目的語」などを付与すると一層、分かりやすくなるでしょう。実際の値や動作を十分に説明しているかが肝要です。  何故そんなことに拘るのかというと、オブジェクト指向のソースコードは、「実行主体」+「プロパティ(メソッド」で一つの英文になるからです。その英文が処理を正しく説明しているのならコメントはほとんど不要になります。実際コアスクリプトは、この要件を十分に満たしているのでコメントなしでも成り立っているのです。 (一部誇張あり)

公開編

ヘルプを作成する

 プラグインの使い方はプラグイン管理画面のヘルプに表示されるようにします。具体的なやり方は最初に示した公式プラグインのお手本が参考になるでしょう。意外と横に狭いので横スクロールバーを出さないためには工夫が必要です。

 では、具体的な必須事項を挙げていきます。

  • プラグインを適用しただけで必ず変化すること
     この説明がないとゲームの挙動をユーザが判断する際、正常に動いているのか、バグなのか、プラグインによる追加仕様か、デフォルトの仕様かが区別できなくなってしまいます。
  • プラグインコマンドの使用例
     パラメータの説明は別途記述欄がありますが、プラグインコマンドについてはヘルプの自由記入欄に書くことになるので、最低限、コマンドと引数に関する説明が必須で、できれば記述例があるといいでしょう。
  • バージョン
     バージョン表記の方法は色々ありますが、私は「メジャーバージョン」「マイナーバージョン」「リビジョン」の三つの数字(1.2.0等)で構成しています。ツクール本体と同じ表記法ですね。
     メジャーとマイナーで事足りるようにも思えますが、個人的には、「1.11」と「1.2」のどちらがより新しいバージョンなのか区別がつきにくいので苦手です。(ドットを小数点と解釈するか、しないかで異なる)
  • 作者連絡先
     ブログやSNSのアカウントなど、連絡先が記載されていればフィードバックを得やすくなりますし、安心して使ってもらうことができます。
  • 利用規約
     必須事項です。MITライセンスなど、既存のライセンスを使用するのが望ましいです。(理由は後述)

ライセンスを決める

 RGSSの頃は、素材提供者がそれぞれ規約を作成してWebサイトに掲載するのが一般的でしたが、ツクールMVでは公式がMITライセンスを推奨しています。

参考:ツクール開発部公式ツイッター@tkool_dev

 MITライセンスとはOSSライセンスの一種でコピーレフトの考え方を持たない寛容なライセンスのひとつです。利用者は原作者の著作権表記とライセンスの全文(もしくは全文に繋がるハイパーリンク)を明確にする義務のみを負い、改変しての二次配布や、商用利用などすべて自由にできます。

参考:自作ソースコードに、MITライセンスを適用する3つのやり方

  • どうしてMITなのか?
     端的に言うと、原作者を尊重しつつ、作者と利用者、双方の負担を軽くすることができるからです。作者は一切のサポート義務を負う必要はなく、利用者もソフトウェアの説明書やクレジットに表記する必要はありません。
  • 独自規約の問題点
     規約を独自に作成すると、どうしても定義が不明確な箇所が出てきてしまいます。元来、自然言語とは曖昧さを宿命として孕むものです。不明確な点について言葉を尽くして説明しようとすると、かえって曖昧さが増す結果にもなりかねません。  そうなると規約を誤解する人や守らない人が必ず出てきます。そういう人を見付けてイライラするくらいなら、最初から寛容にしておいた方がマシです。
  • グローバルスタンダードなライセンスのメリット
     MITライセンスの定義はOSD(オープンソースの定義)を満たしており、解釈について議論の余地はありません。加えて、日本語が分からない海外のユーザにも、MITの三文字だけで安心して使ってもらえるメリットもあります。
     同じく寛容なOSSライセンスとしてApacheライセンスなどがありますが、事実上のスタンダードしてMITを定着させるべくあえて公式が明言するかたちで推奨したであろうことを考慮すれば、無理に逆らうこともないかと思います。
  • MITライセンスの注意点
     MITライセンスと明記すると自動的にいくつかの権利を利用者に与えることになります。利用者は改変および商用、非商用の有無にかかわらず単独での再配布が可能です。また作者は、利用者がプラグインをツクールMV以外の目的に利用することを禁止できません。さらに、特定の個人や集団に対してプラグインを使用禁止にすることができません。(たとえば、ネット上でトラブルになった相手に対して使用禁止を宣告する等)これらを許容できない場合、MITライセンス以外を選択する必要があります。
  • MITライセンスの適用方法
     詳細は先に挙げたURLをご参照ください。基本的には、著作権表記をしっかり行うこととMITライセンスの全文をソースコードと公開するWebサイトに掲載したうえで、MITライセンスであると宣言すれば問題ありません。

プラグインを配布する場所

 公開方法は色々あって、自身の運営するWebサイトや各種オンラインストレージなどがあります。ですが、OSSのソースコードを公開するという意味でならGitに特化したサービスであるGitHubがオススメです。

参考:GitHub トップページ

  • コードをコミットする際に差分が確認できる
     コードの差分を比較して、コミット前の最終確認ができます。デグレードを防ぐ意味でも予期しない箇所が変更されていないかどうかのチェックは重要です。ローカルコミット、リポジトリコミットという二段階を経ているので安心です。
  • 以前のバージョンが履歴からログ付きでいつでも復元できる
     バージョン管理システムの恩恵です。これにより求められればいつでも過去のバージョンを復元して渡すことができます。
  • プルリクエストがもらえる
     ツクールの文化上、あまり頻繁ではありませんが、誰かがバグを見付けて修正したものを送ってくれるかもしれません。もし送られた場合は、内心キョドっていたとしても平静を装い、中身を確認して問題がなければ承認しましょう。私は以前に、二回送られたことがあります。
     自分が作ったものを勝手に修正されることに最初は抵抗があるかもしれませんが、そういうものなので慣れましょう。
  • GitHub Pagesでそのままツクール作品が公開できる
     リポジトリにあがっている内容をWebサイトを公開できるサービスです。これを使えばツクールMVのブラウザ版を直接公開できます。MVのプロジェクトをそのままアップロードすればいいだけなので煩雑な手順も不要です。

 参考:Qiita:RPGツクールMVで作ったゲームをGitHubPagesで公開してみる

  • 英語なので使う側にとって不便
     デメリットです。一般ユーザにはJSファイルを直接参照するURLのみを自身のWebサイトやフォーラム等で提示するのがいいかと思います。私の場合は、別途スプレッドシートを用意して、そこでプラグインの一覧を紹介しています。スプレッドシートは、表形式の一覧を作りやすく、またFTP等の不要で更新が楽なのでオススメです。

おわりに

 いかがでしょうか。今回は外堀を埋めたかたちで、本丸であるプラグインそのものには切り込んでいないので物足りなかったかもしれません。しかし、こういった周辺知識を固めていくことで後顧の憂いなくプラグイン開発に没頭することができます。

 ツクールのコアスクリプトは残念ながらOSSではありませんが、プラグインを作って自由に公開できることは事実上コアスクリプトをOSS化しているのと同じことだと思っています。プラグイン制作には、いちユーザがツクールというツール開発そのものに参画し、自身の裁量で想像力を駆使して自由に使い勝手を向上していけるという楽しみがあります。

 より実践的、具体的なプラグインの作成方法については、また機会があればやろうと思っています。何かご要望などありましたらお気軽にコメントください。

2016年10月2日日曜日

コアスクリプトのver1.3.1ではウィンドウカラーを変更すべきでないという話

ver1.3.1ではウィンドウカラーを変更すべきでないという話

 RPGツクールMVのver1.3.1が公開されてからしばらく経ちました。描画エンジンのバージョンアップに伴い、パフォーマンスやメモリ問題について改善された部分はたくさんありますが、一方で新たな問題も散見されていて、私の元にもパフォーマンスについてご質問、ご相談を寄せられる機会が増えてきています。

 正直に言うと、私のプラグインが1.3.1に最適化されていない部分も多々ありまして、それも含めて対応可能な箇所は対応を進めているところです。

 その調査過程で見付けたのが、「ウィンドウカラーを変更すること」によるリスクです。ウィンドウカラーはデータベースの「システム」もしくはイベントコマンドで変更できます。しかし、結論から言うと少なくともver1.3.1ではカラーは0,0,0から変更しない方が無難と言わざるを得ないのです。

ウィンドウカラー変更

 まずは、以下の測定結果をご覧ください。

測定結果

 パフォーマンス調査にあたり、様々なタイミングやフレーム更新に掛かる時間を測定するプラグインを作成(ブログの最後で紹介しています)して、それを利用して測定しています。ゲームを起動して、以下の手順で操作を実行しました。

  1. ゲーム起動
  2. ニューゲームを選択
  3. メニュー画面を開く
  4. スキル画面を開く
  5. 3.と4.を繰り返す

 これらの動作を条件を変更して合計三回、実施したのが以下の表になります。すべてWebGLモードで計測プラグイン以外は適用していません。

  1. v1.3.1でウィンドウカラーをデータベースから変更している。
  2. v1.3.1でウィンドウカラーをデータベースから変更していない。
  3. v1.2.0でウィンドウカラーをデータベースから変更している。

ウィンドウカラー変更の有無による処理時間の違い

v1.3.1(変更あり) v1.3.1(変更なし) v1.2.0(変更あり) 計測対象
12.8MS 17.8MS 12.2MS シーン遷移 to Scene_Boot
46.7MS 59.9MS 44.3MS シーン遷移 to Scene_Title
214.8MS 210.2MS 185.9MS 背景キャプチャ作成
216.1MS 211.4MS 187.1MS シーン遷移 to Scene_Map
111.4MS 65.6MS 111.5MS マップ表示オブジェクト作成
69.2MS 68.4MS 38.1MS 背景キャプチャ作成
130.8MS 103.1MS 115.2MS シーン遷移 to Scene_Menu
129.7MS 78.6MS 108.1MS シーン遷移 to Scene_Skill
60.9MS 22MS 71.3MS シーン遷移 to Scene_Menu
127MS 69.2MS 142.3MS シーン遷移 to Scene_Skill
59.4MS 22.3MS 42.7MS シーン遷移 to Scene_Menu
107.3MS 62.1MS 158.2MS シーン遷移 to Scene_Skill
62.9MS 21MS 94.7MS シーン遷移 to Scene_Menu
100.8MS 32.3MS 135.8MS シーン遷移 to Scene_Skill
49.4MS 19.5MS 54.9MS シーン遷移 to Scene_Menu
114.2MS 31.1MS 103.7MS シーン遷移 to Scene_Skill

 ウィンドウカラーの変更が存在する場合、メニュー画面からスキル画面への遷移がおよそ60ミリ秒ほど遅延しているのが分かると思います。60ミリ秒とは0.06秒なので大きな影響はないように思えますが、実際に動かしてみると(スペック次第ですが)体感できるほどのカクツキを感じられるはずです。
 とはいえ、ウィンドウカラーの変更で時間が掛かっているのはv1.2.0も同じ。問題はここからです。

処理時間の違い(遷移を繰り返した場合)

v1.3.1(変更あり) v1.3.1(変更なし) v1.2.0(変更あり) 計測対象
287MS 31.7MS 130.1MS シーン遷移 to Scene_Skill
117.2MS 41.6MS 56.4MS シーン遷移 to Scene_Menu
174MS 35.4MS 151.1MS シーン遷移 to Scene_Skill
123.8MS 36.7MS 86.9MS シーン遷移 to Scene_Menu
221.2MS 31.8MS 133MS シーン遷移 to Scene_Skill
123.9MS 45.1MS 90.1MS シーン遷移 to Scene_Menu
264.5MS 78.3MS 115.1MS シーン遷移 to Scene_Skill

 何度も画面遷移を続けていくと差が広がっていき、酷いときでは200ミリ秒を上回る差異となっています。こうなるとカクツキは深刻です。長時間プレーしていると何度もメニューを開いたり閉じたりするので、イヤでも体感することになると思います。(ただし、メモリ上はおかしな点は見当たらないので根本原因については不明です)

考察と対策

 ウィンドウカラーを変更した場合、ウィンドウを作成するたびに「Bitmap.prototype.adjustTone」という処理が呼ばれますが、どうやらこれが元凶のようです。カラーを変更しない場合はもちろん呼ばれません。前述のとおりウィンドウは、画面遷移するたびに作り直されるので、戦闘→マップ→メニューと遷移を繰り返していけば処理の低下は避けられません。

 当然のことながら、プラグインによってメニュー画面に立ち絵や独自のウィンドウ等を追加すると、それに応じてさらにパフォーマンスが低下します。私が実際に確認したケースでは400ミリ秒を超えるケースもありました。

 すでに述べたとおり、対策は 「長編作品ではウィンドウカラーを変更しないこと」 です。もちろん今後の本体バージョンアップにより状況が改善されることは期待できますが、それでもカラーを変更することによって余分な処理が実行されることは避けようがありません。カラーの変更は手軽で便利ですが、ペイントソフトを使えば比較的簡単に色調を静的に変更できます。

 ただでさえ、パフォーマンスについて懸念点の多い現状ですから、できるところから対策していきたいですね!

プラグインの配布

 今回、パフォーマンス測定のために作成したプラグイン「パフォーマンス計測プラグイン」をMITライセンスで配布します。自作品のパフォーマンス改善の手掛かりにご利用頂ければと思います。詳細は以下の通りです。

処理に掛かる時間を計測してログに出力します。
正確な結果を計測するため、このプラグインは一番下に配置してください。
(このプラグインより下に配置されたプラグインの処理内容が計測時間から漏れる可能性があります)
ログが出力されるタイミングは主に2通りです。
 
1.フレーム更新ログ
1フレームに掛かる時間を計測します。出力内容は指定された間隔ごとの平均値です。
また、ゲーム更新と描画の時間を分けて出力することも可能です。
平均値が指定された閾値を超える場合、警告ログになります。
頻繁に警告ログが出力されなければ、概ね快適なプレーであるといえます。
 
2.その他ログ
同期実行され、かつ時間の掛かる以下の処理の時間を計測します。
・シーン遷移時
・マップオブジェクト作成時
・キャプチャ取得時
・セーブ実行時
 
結果が指定された閾値を超える場合、警告ログになります。
頻繁に警告ログが出力されなければ、概ね快適なプレーであるといえます。
 
パフォーマンス改善の手掛かりにしてください。
テストプレー時以外も動作しますが、製品版には付属しないことを推奨します。
 
このプラグインにはプラグインコマンドはありません。

ダウンロード

プラグインファイルはGithubで公開しています。
https://raw.githubusercontent.com/triacontane/RPGMakerMV/master/PerformanceRefine.js

ダウンロード方法(Windowsの場合)

  1. リンク先に飛ぶ
  2. 右クリック
  3. 名前を付けて保存
  4. ファイル名を変えずに、プロジェクトの「js/plugins」配下に配置

利用規約

当プラグインはMITライセンスのもとで公開されています。作者に無断で改変、再配布が可能で、利用形態(商用、18禁利用等)についても制限はありません。このプラグインはもうあなたのものです。
http://opensource.org/licenses/mit-license.php

2016年9月25日日曜日

直接攻撃演出プラグイン

blog

RPGツクールMVで使用可能な自作プラグイン「直接攻撃演出プラグイン」の紹介です。

プラグインの説明

スキル実行時にターゲットまで近寄ってから実行します。追加で以下の機能を提供し、簡単なバトラーアニメーションを実現します。
主に競合等の理由でYEPアクションシーケンスを使用しない方向けです。

  • 放物線移動
  • 座標直接指定移動
  • 戦闘アニメーション表示
  • 残像表示
  • アクターモーションや武器モーションの個別指定

スクリーンショット

対象まで放物線を描いて飛んでいきます。設定で残像表示も可能です。 スクリーンショット

メモ欄指定方法

スキルのメモ欄に以下の通り指定してください。

<DAE攻撃:12,10,0,0>      # 12フレーム、高度10で対象まで移動
<DAEAttack:12,10,0,0>    # 同上
<DAE帰投:18,25>          # 18フレーム、高度25で元に位置に戻る
<DAEReturn:18,25>        # 同上
<DAE姿隠し>              # 移動する際にバトラーの姿を隠します。
<DAEHidden>              # 同上
<DAE残像>                # 移動する際にバトラーの残像を表示します。
<DAEAfterimage>          # 同上
<DAE帰投なし>            # 発動後に元の位置に戻らなくなります。
<DAENoReturn>            # 同上
<DAEアニメ:1>            # 発動者にID[1]のアニメーションを再生します。
<DAEAnimation:1>         # 同上
<DAE対象者アニメ:1>      # 対象者にID[1]のアニメーションを再生します。
<DAETargetAnimation:1>   # 同上
<DAE絶対位置:320,240>    # 座標[320, 240]に移動します。
<DAEAbsolutePos:320,240> # 同上
<DAE相対位置:30,10>      # 対象者から[30, 10]の位置に移動します。
<DAERelativePos:30,10>   # 同上
<DAE自己相対位置:5,0>    # 自分自身から[5, 0]の位置に移動します。
<DAESelfRelativePos:5,0> # 同上
<DAE瞬間移動:320,240>    # 座標[320, 240]に瞬間移動します。
<DAETeleport:320,240>    # 同上
<DAEアクターのみ>        # アクターが実行したときのみ演出が有効になります。
<DAEActorOnly>           # 同上
<DAE敵キャラのみ>        # 敵キャラが実行したときのみ演出が有効になります。
<DAEEnemyOnly>           # 同上
<DAE武器:1>              # 攻撃時のモーションが「攻撃:武器タイプ[1]」になります。
<DAEWeapon:1>            # 同上
<DAEモーション:dead>     # 攻撃時のモーションが「戦闘不能」になります。
<DAEMotion:dead>         # 同上

ダウンロード

プラグインファイルはGithubで公開しています。
https://raw.githubusercontent.com/triacontane/RPGMakerMV/master/DirectlyAttackEffect.js

ダウンロード方法(Windowsの場合)

  1. リンク先に飛ぶ
  2. 右クリック
  3. 名前を付けて保存
  4. ファイル名を変えずに、プロジェクトの「js/plugins」配下に配置

利用規約

当プラグインはMITライセンスのもとで公開されています。作者に無断で改変、再配布が可能で、利用形態(商用、18禁利用等)についても制限はありません。このプラグインはもうあなたのものです。
http://opensource.org/licenses/mit-license.php