RPGツクールMV 良いプラグインとは

目次

  1. はじめに
  2. 良いプラグインとはどういうものか
    1. 他のプラグインと競合しにくい
      1. 既存のメソッドを完全に上書きしない
      2. グローバルな空間を汚染しない
    2. プラグインパラメータの型が指定されている
    3. スクショ付きのマニュアルがある
    4. 英語ドキュメントがついている
    5. 程よいカスタマイズ性がある
    6. 可読性に優れている（読みやすい）
      1. 良いエディタを使って書かれている
      2. マジックナンバーが使われていない
      3. 命名規則が統一されている
      4. 命名に一意性がある
      5. よりモダンなJavaScriptで書かれている
      6. 機能が単一である
    7. メンテナンス性に優れている
      1. しっかりバージョン管理されている
      2. 容易にコミットできる
      3. Strictモードを使っている
    8. 正しくオープンソースソフトウェアライセンス（コピーレフトでないもの）が設定されている
      1. 独自の利用規約は可能な限り避ける
      2. コピーレフトなライセンスは避ける
      3. ライセンスを変更する際にはバージョンを上げる
  3. おわりに
  4. 参考リンク

RPGツクールMVにおける、良いプラグインの書き方や見分け方について書きます。

はじめに

RPGツクールMVのプラグインはJavaScriptで書かれています。
これはかなりやさしい言語1で、プログラミングに初めて挑戦する人が頑張ってゴリゴリと書いたプラグインが転がっていたり、実際に使われていたりします。
中には機能として非常に優れているものも多くあるのですが、同時に書き方の作法を知らないままに書いたために、別の場所で利用者に不便を強いてしまうようなプラグインも散見されます。

この記事では、プログラミングの作法2から見た良いプラグインの書き方、良いプラグインの見分け方について記します。

プラグインを書こうとしている人、書いて公開している人はもちろん、プラグインを利用する人もぜひ読んでください。

良いプラグインとはどういうものか

良いプラグインの定義を、以下のようにします。

  • その機能がほしいと思ってゲームに取り込んだ際に不都合が起きにくい
  • 不都合が起きたとして、その原因を容易に特定でき、解消できる
  • その他、利用者にできるだけ不便を強いない

では、その詳細について説明しましょう。

他のプラグインと競合しにくい

RPGツクールMVのプラグインは、他のプラグインと競合することがあります。
異なる2つのプラグインを有効にしたとき、どちらか一方あるいは両方ともが正常に動作しなくなることがよくあります。

これを完全に防ぐ手立てはありませんが、それでも競合しにくい書き方があります。

既存のメソッドを完全に上書きしない

RPGツクールMVのプログラム内に書かれたメソッドを上書きして、プラグインの機能を実現することはよくあります。
このとき、まるごと上書きして別の処理を行うメソッドとして定義してしまうと、他のプラグインと競合しやすくなります。
元のメソッドを呼び出した上で、新しい処理を追加するほうが安全です。

ちなみに、YEPのコア系プラグインはゲームの中核を担うメソッドを大量にまるごと上書きしているため、容易に競合します。

グローバルな空間を汚染しない

良いプラグインは、基本的にプラグインの中でスコープを閉じています。
良いプラグインを読むと以下のようなコードになっていることがわかるでしょう。

(function(){
  // ここにプラグインの処理
})();

このfunctionの書き方を無名関数と言います。
この中で新たに定義されたシンボル3は他のプラグインから参照できません。
参照できるものはすなわち、そのシンボルが指し示す内容を上書きされる可能性があるということです。

意図しない上書きが発生した場合、プラグインが正常に動かなくなるのは言うまでもないでしょう。

プラグインパラメータの型が指定されている

RPGツクールMVのプラグインパラメータは、型を指定することができます。
@typeで数値、文字列、真偽値、その他様々な型を指定できます。
特にbooleanなど、ツクールエディタ上で設定する際に、利用者に親切なUIが表示されてくれるため、プラグインパラメータには必ず型を指定するようにしましょう。

また、配列や構造体を駆使してツクールエディタ上での表示を整理すると、よりユーザーフレンドリーになります。

詳細は以下のページにわかりやすくまとめられています。

RPGツクールMV　プラグインパラメータのtypeまとめ | 趣味に生きる。

スクショ付きのマニュアルがある

利用者にとって、使い方がわかりやすくなるため、マニュアルにはぜひ利用例や設定例のスクリーンショットを載せましょう。

筆者のプラグインはこれをサボってしまっているのであまり強くは言えないのですが、いずれ落ち着いたらしっかりマニュアルを書きたいと思っています。

英語ドキュメントがついている

RPGツクールMVは海外でも使われています。4
海外ユーザへの説明のために英語ドキュメントがついているととても良いです。

ただし、これを実現できているプラグインはとても少なく、また説明テキストの英訳は少々骨が折れる作業ですので、これを作る優先度はそこまで高くありません。

ちなみに、よく使われているMOGのプラグインはポルトガル語で説明が書かれていて、読むのが困難です。
RPGツクールMV用プラグイン投稿・告知サイト - #ツクプラにて、ムノクラさんが日本語訳を公開されているため、それを頼ると良いでしょう。

程よいカスタマイズ性がある

プラグイン作者が自分で使うためにあらゆる値を決め打ちしてしまい、ユーザーからするとかゆいところに手が届かないプラグインになってしまうケースがあります。筆者もやってしまいがちです。
ユーザーが設定できると嬉しいな、と思える値はプラグインパラメータに切り出しましょう。5
これを見極めるためにはRPGを実際に作ってみるのが一番良いのですが……。

可読性に優れている（読みやすい）

読みやすいプラグインはそれだけで良いプラグインとしての条件を一つ満たしています。
なぜなら、コードを書き慣れた人に読んでもらいやすくなるからです。

たとえプラグインの動作自体に疑問を持たれたり、あるいは衝突の要因であることが疑われても、コードが読みやすければその原因は特定しやすいでしょう。

この記事では良いプラグインの条件において、読みやすさを最重要視し、以下に読みやすいプラグインについて述べます。

良いエディタを使って書かれている

プラグインの書き方として、良いエディタを使って書かれているというのは大変重要なことです。

RPGツクールMV用のプラグインでは、これをおろそかにしているケースが大変多く見受けられます。
コードを見ただけで良いエディタを使っていないことがなぜわかるかというと、コードがまるで整形されていないからです。

プログラムには読みやすいとされている形式の書き方、すなわちお作法があり、それに則っていないコードは見ただけで、良いエディタを使っていないことがわかってしまいます。

最も重要なのはインデントで、これが揃えられているだけでも読みやすさがまるで違います。
インデントを揃えるだけでプログラムの構造が視覚的に捉えやすくなり、不具合の調査/修正や機能追加のために支払うべき労力が大幅に減ります。
良いエディタにはコードフォーマット機能が搭載されており、ショートカットキーを押したり、設定さえしておけば保存する際に自動的にフォーマットをかけてくれるものもあります。

インデントに関連して、ホワイトスペースの統一もぜひ意識するようにしてください。
インデントを頑張って揃えようとした形跡はあるが、タブ文字と半角スペースが混ざってしまっているようなプラグインをよく見かけます。
タブ文字と半角スペースを混ぜて使わないようにしてください。必ずどちらかに統一しなければなりません。
どちらを用いるかは好み次第ですが、筆者は半角スペース2つを1単位として用いています。全角スペースは論外ですので忘れてください。6

良いエディタでは、タブキーを押したときにインデントを設定した文字を使って行ってくれる他、改行する際に自動で良い感じにインデントしてくれたりします。
また、良いエディタはタブ文字や全角スペースの違いを目視で確認できるような設定ができます。

良いエディタとしては、プラグインのデバッグにも使いやすいVisual Studio Codeがオススメです。7
もちろんその他の選択肢もありますので、VSCodeがお気に召さない場合はご自身で使いやすいエディタを探してみてください。

ちなみに、よく使われているMOG系のプラグインはホワイトスペースが統一されておらず、インデントに頓着しない書き方がされているため、可読性が良くありません。
機能としてはとても優れていますが、プラグインを書く際に真似しないようにしてください。

マジックナンバーが使われていない

意味があるにも関わらず、定数に代入せずに直接プログラム中に書かれた具体的な数字や文字列のことを、マジックナンバーと呼びます。8
マジックナンバーを使うことを、定数をハードコーディングする、などと呼びます。
これはバグの温床ですので、可能な限り意味のある定数を定義しましょう。

消費税をあちこちにハードコーディングしていたため、増税のタイミングで修正が追いつかず大騒ぎになった、なんて話をよく聞きます。
筆者も今どき、そんな古めかしいシステムが本当に動いているなんてことは伝聞でしか知りませんが。9

命名規則が統一されている

変数や定数の命名規則が統一されていると、とても美しく読みやすいプラグインになります。

JavaScriptにおいて、メソッドや変数はキャメルケース、定数は大文字スネークケースを用いるのが一般的です。
特に強いこだわりがなければ、元のRPGツクールMVのコードを参考に、それに統一しておくと良いでしょう。

命名に一意性がある

良いプラグインでは、変数やプラグインコマンドの名前が、それを見ただけである程度伝わります。

ダメージ計算の際に、ダメージの値として使われる変数の名前が a としてしまうと極めて不格好で、計算が複雑になればなるほどその a の意味がつかみにくくなり、バグの温床になります。
ちゃんと damage などと意味のある名前をつけてあげましょう。

よりモダンなJavaScriptで書かれている

JavaScriptは歴史の長い言語ですが、その過程でよりモダンな書き方ができるよう改良されてきています。

var でなく let const を用いるほうが良いです。
var と let に関してはスコープに関する知識がないとピンと来ない話なので、気になる人はググってください。10
const は再代入ができなくなるため、定数を定義する際にはこちらを用いましょう。

また、配列を操作する際にはfor文はできるだけ使わず、 map filter などの配列操作関数とラムダ式を組み合わせて使うとスッキリとした良いコードになります。

機能が単一である

単一の機能を実現するために書かれているプラグインは、自ずとプラグインそのものの規模も大きくなりにくく、読みやすい傾向にあります。
一つのプラグインに欲張ってあれもこれもと詰め込むとコードが肥大し、可読性を著しく下げてしまいます。

YEPのコア系は機能が多く、長大になっていて読み解くのに苦労します。

メンテナンス性に優れている

プラグインはその時動いているように見えれば良いというものではありません。
将来に渡って（RPGツクールMVが使われる限り）、バグが見つかる可能性はあります。
また、機能追加の要望が来ることもあるでしょう。

そんなとき、容易にバグを特定し修正できたり、機能を簡単に追加できてほしいことは言うまでもありません。

そのために重要と思われる内容を以下に説明します。

しっかりバージョン管理されている

プラグインを見ると、バージョン1.0.0 のような表記があるかと思います。
このバージョンは飾りではありません。良いですか、飾りではないんですよ。

これは、プログラムを更新するときに変化させるべき数値です。
バージョニングについては、筆者はセマンティックバージョニングが好きなのでそれを用いています。

RPGツクールMV やさしいプラグインの書き方 基礎編の最下部、余談の項目を参考にしてください。

必ずしもセマンティックバージョニングに従う必要はなく、しかし規則的にバージョンを振ると良いでしょう。

さて、公開しているプラグインについて、必ず最新のバージョンにアクセスしてもらう方法があります。
GitHubでプラグインを公開することです。常に最新のコミットが前面に表示されるため、利用者が誤って過去のバージョンをダウンロードする心配はありません。

最新版に容易にアクセスできること、どれが最新版か明らかであることは、それだけで利用者に優しいのです。
ツクマテや公式フォーラムの掲示板の書き込みに無造作に貼り付けてあるだけだとこれがとてもわかりにくく、混乱を招きます。

容易にコミットできる

GitHubで最新版を公開すると、利用者からバグ報告だけでなく、修正方法を提案しやすくなる利点があります。
プルリクエストを受け付ければ、他の人からのコード修正を取り込むだけでバグ修正が完了することもあります。11

GitとGitHubを利用したバージョン管理の重要性については、RPGツクールMV やさしいプラグインの書き方 基礎編にも詳しく書いてあります。長い文章ですので、余裕のあるときに読んでみてください。

Strictモードを使っている

第一に strict モードでは、JavaScript でエラーではないが落とし穴になる一部の事柄を、エラーが発生するように変更することで除去します。第二に strict モードでは、JavaScript エンジンによる最適化処理を困難にする誤りを修正します: strict モードのコードは、非 strict モードの同一コードより高速に実行できることがあります (Firefox 4 ではまだ strict モードにあまり最適化していませんが、将来のバージョンで実現するでしょう)。第三に strict モードでは、将来の ECMAScript で定義される予定の構文を禁止します。

Strict モード - JavaScript | MDN

12

わかりやすく言うと、以下の通りです。

  1. エラーではないが落とし穴になるようなコードに対してエラーを発生させてくれる（結果、落とし穴にハマらずに済む）
  2. コードの実行が早くなったり効率良くなったりしやすくなる
  3. 将来的にJavaScript自体がバージョンアップしていっても動かなくなる心配が減る

正しくオープンソースソフトウェアライセンス（コピーレフトでないもの）が設定されている

いわゆるライセンスと呼ばれるものです。
ライセンスは利用者に対し、そのプラグインをどう使っても良いかを明示する非常に有効な手段です。

良いプラグインには正しくライセンスが設定されています。

今現在、主流となっているMITライセンスについて知っていればだいたい事足りるでしょう。

RPGツクールMVのプラグイン MITライセンスについてに詳しく書いてあるので、ぜひ読んでみてください。

ライセンスを明示しないと No License と受け取られ、使ってはいけない展示物であるという意味になってしまうため、必ずライセンスは設定しましょう。

独自の利用規約は可能な限り避ける

十分に調査した上で、好みのライセンスが存在しなければ仕方がありませんが、基本的にはよく知られた既存のライセンスを用いるようにしたほうが良いです。
よく知られたライセンスを用いるということは、利用者に対して安心感を与えます。
独自の利用規約はまず、利用者にそれを注意深く読ませるという負担を強いることになります。
その点MITライセンスはその意味さえ知っていれば、たった3文字読むだけで良いのです。実質ノーコストですね。

コピーレフトなライセンスは避ける

いわゆるGPLライセンスは避けましょう。
詳しくはRPGツクールMVのプラグイン MITライセンスについてにも書きましたが、それを用いて作られたゲームそのものも、同じライセンスで配布しなければならなくなるからです。

ライセンスを変更する際にはバージョンを上げる

これは徹底してください。
ライセンスは、利用者への許可であり、約束事です。
バージョンを変えずにライセンスのみを変えてしまっては、約束を反故にしたことになります。
つまり、そのプラグインは一切の信頼を失うということです。

過去のバージョンを公開し続ける必要はありません。
最新のバージョンのみ公開しても良いですが、過去のバージョンを遡ってライセンスを変更したり、バージョンを上げずにライセンスを変更するような非道な行いは絶対に許されません。

おわりに

良いプラグインとはなにか、どんな条件を満たすとより良いプラグインになるのかを書きました。
特に可読性については、かなり細かい粒度で説明しました。

全てを一度に意識するのは難しいことかもしれませんが、プラグインを作成される方は少しずつでもこれらを意識して、できるだけ読みやすいコードを書いてください。

そして、利用者でもこれらの項目に気をつけてみてください。
同じ機能を持ったプラグインが複数公開されていたとき、どちらを選ぶかの参考になるでしょう。

参考リンク

  1. 言語のやさしさの定義は諸説あるが、ここではとりあえず書いて動かすのが簡単、くらいの意味としておく。
  2. 単にコードを書くだけでなく、そのコードの管理方法や公開方法も含めてプログラミングの作法と呼ぶ。
  3. 変数や定数、クラスを指し示す名前のこと。
  4. RPG Maker MV, RMMV などと呼ばれる。
  5. 利用者にプラグインの中身を直接触らせるのは論外です。
  6. 実はJavaScriptの仕様上、全角スペースは半角スペースと同じものとして扱われるため、動作自体に影響は出ない。極めて気持ち悪いコードになってしまうので、絶対に使ってはならないが。
  7. 「Visual Studio Code」+「Chrome」で「ツクールMV」のローカルでデバッグなテクニックの紹介 - Qiitaを参照。
  8. 問題になるケースが多く例をあげやすいのは数字だが、文字列でも同様の問題が起きる。
  9. 大昔にCOBOLで書かれた金融系のシステムがヤバい、とか。
  10. RPGツクールMVは初期の頃letが普及していなかったのか、varを使って書かれている。varを使ったからと言って極端に悪いものではない。
  11. もちろん、動作確認は必要だが。
  12. Strict モード - JavaScript | MDN