• ツクールのプラグイン制作依頼等について

    2019-04-03 19:21
    19/10/30 お知らせ
    記事の内容そのものに変更はございませんが、
    既存プラグインの改変や競合解決をご希望の場合は
    該当する全てのプラグインの利用規約を先にご確認ください。
    明らかに改変可能であるもののみしか承ることはできません。
    ご了承ください。


    こんにちは。ご覧いただきありがとうございます。
    リベリオンれいの媚びを売る売れないゲーム作家まっつUPです。

    普段はRPGツクールMVでRPGを作っています。
    スクリプトで自作戦闘を作ったこともあります。
    今までにツクマテ内でのリクエストや
    ゲーム制作で培ったプラグイン制作技術をツクール界隈の繁栄に
    生かしたいと思い、プラグイン制作依頼受付を開始しました。
    なお、RPGツクールMV用のプラグインをメインとしますが
    RPGツクールvxaceも可能な場合があるのでご相談ください。


    以下は私のツイッターです。
    主に依頼自体はDMで承ります。(DMにはフォローが必要です。)
    もしもフォローが返されない場合は差し支えなければツイート等でご一報ください。
    可能な限り早く返信をしたいと思いますが、
    日や時間帯等によります。ご了承ください。
    https://twitter.com/mattuup

    ※ただ、途中からメールによるやりとりになる場合が多いと思います。


    現在受け付けている依頼の種類
    基本的に有償です。

    ・単体のプラグイン制作または技術提供
    もし性質の違う複数のシステムをご検討の場合はご相談ください。

    ・複数プラグイン間の競合修正
    ただし、関係する全てのプラグインの利用規約から
    明らかに改変可能と認められる場合に限ります。

    ・既存プラグインの改変・拡張
    ただし、関係する全てのプラグインの利用規約から
    明らかに改変可能と認められる場合に限ります。
    例えばMITライセンスのものなら権利表記を削除しなければ
    自由に再配布することができます。
    例えば以前に、ひきも記様のプラグインを改変させていただきました。
    主に、第三者が制作したプラグインの改変になると思います。
    RPGツクールvxaceであったシステムをRPGツクールMVで再現
    というのも受け付けますが著作権がある以上
    完全再現にはならない場合がありますのでご了承ください。

    ・ツクールの使い方やシステムの実現方法等のご相談
    あなたのツクール上でのお悩みの解決方法を一緒に考えます。
    内容が簡単であるものは無償で対応する場合があります。
    ただし、上記のようなプラグイン制作等が必要な場合有償になる場合もあります。
    その時は、こちらからの提案になりますので後から料金を請求することはありません。

    ・その他
    ツクールシリーズのユーザーゲームのテストプレイ等(公開前のテストプレイ)。
    ただし、動作テストを複数あるいはご希望の端末(条件)で行えるわけではありません。


    依頼の際に用意していただきたいもの
    ものというより、データや情報ですが…。
    ・依頼内容または相談内容、その仕様

    ・予算(金額)

    ・納期(仕様の相談のお時間があることもご留意ください。)

    ・DM以外での連絡が必要な場合、連絡先(メールアドレス)

    ・エラーや競合の原因が不明瞭な場合、エラーが発生しているプロジェクト

    依頼に関する画像やシステムの処理の流れも用意していただけると助かります。
    もし、仕様をどのようにすればゲームに使いやすくなるのか不明瞭な場合は
    こちらから提案できる場合がありますのでご相談ください。
    なお、既存の市販ゲームの○○っぽくしたいというイメージもないよりはよいです。

    注意事項
    ・DMでの相談内容に関して総合的に判断して
    当方では力になれないと判断した場合には依頼をお断りさせていただくことがあります。

    ・主にwindows上で動作する前提のプラグインを作成いたします。
     環境ごとに別の動作をするプラグインの依頼はお断りさせていただくことがあります。

    ・プラグインの改変により元プラグインの機能が大幅に失われてしまうことが
     事前にわかっている場合は依頼をお断りさせていただきます。

    ・ツクールMVの案件でエディタがver1.6.2に満たないバージョンをお使いの場合は
     アップデートをお願いする場合があります。
    (当記事の編集時点で一番安定性の高いverです。)

    ・リテイクについてはご相談がない場合は追加料金なしは1回までとさせていただきます。
     ただし、当方のプラグインによるバグや仕様の実装漏れの場合は追加料金なしです。
     また、追加料金なしのリテイクは完成後3か月以内のものに限ります。

    ・リテイクについて、明らかに大規模な仕様追加であった場合には
     追加の料金を請求させていただきます。

    ・元の仕様に明らかな問題(矛盾等)がある場合や、疑問点があった場合には
     仕様の修正を提案することがあります。

    依頼により制作したプラグインの利用規約について

    ・MVのプラグインであればMVのみで、
     vxaceのスクリプトであればvxaceのみで利用することができます。

    ・アダルト、非アダルトにかかわらず利用することができます。
     ただし、提供すること自体が違法行為に加担することにならない場合に限ります。

    ・プラグインのみでの配布、販売を禁止します。
     もちろん、ユーザーゲームを販売・配布する際に同梱するのは大丈夫です。
     (基本的にツクール上での通常通りのプラグイン利用で大丈夫です。)

    ・他作者様のプラグインに関係しない場合、作成したプラグインの著作権は
     まっつUP側に帰属します。
     ただし、readmeへの記述や完成時の利用報告は必須ではありません。

    ・改変に関しての制限は特にありませんが、サポートの保証はできません。

    ・上記の規約に反する場合やその他悪質な利用が認められた場合は
     プラグインの利用を禁止します。


    料金について
    料金についてはもちろん条件とともに要相談です。
    納期等の条件によって増減する場合があります。
    お支払方法は原則口座振込としますが
    Amazonギフトによる代用が流行っているようですね。
    ご希望であれば必ず相談ください。
    なお、料金を受け取った際に領収証は発行しますが
    請求書等が必要な場合は必ずお声掛けください。
    また、納品は現在Dropboxから落としていただく方法をお願いしておりますが
    これで問題がある場合は必ずお声掛けください。

    以下、金額の目安です。

    ・一件当たりの最低額 3,000円
     小規模なプラグインや改変はこの辺りだと思います。

    ・既存プラグインにオリジナル要素を追加(実際にあった案件) 4,000円

    ・原因が不明瞭なエラーの修正 5,000円

    ・制作に約一日分かかる場合 10,000円

    ・戦闘中の表現の大きい拡張とスキルの拡張同時(実際にあった案件) 20,000円

    ・大規模なプラグインでリテイクが多くなる場合 40,000円
     仕様の複雑さや規模の大きさでかなり振れ幅があると思います。

    なお、1件が10,000円以上の制作実績の公開を禁じる場合には
    料金が少し高くなることがあります。

    ※金額の目安に関しては予告なく変更する場合があります。


    以上です。
    依頼をご検討している方は、ご連絡いただければと思います。
  • 広告
  • プラグイン作成で気をつけたいところや自作プラグインの解説

    2017-12-06 00:04


    こんにちは、まっつUPです。
    初めましての方も多分いると思いますが
    ぼくはRPGツクールMVでゲームを作成するついでにプラグインを作っています。

    プロフィールのところにゲームの公開先リンクがあります→
    ふりーむのコンテストにも参加していますので是非プレイを→

    今回は、今ここを閲覧している皆さんがもっとプラグインに
    触れやすくなるように解説をしていくつもりです。
    もう止まるんじゃねえぞ・・・と祈るだけのプラグイン導入生活に終止符をうちましょう。

    まだブログに慣れていないので拙い部分が多いと思いますが
    温かい目で見ていただければ幸いです。
    なお、このページで得た内容で何か不利益があっても
    まっつUPは責任を取ることはできないのでご了承ください。

    しかし、解説者が信用できないのに話は聞けないという方がいると思います。
    そこで、ツイッターでぼくが信用できるか聞いてみました。
    エロゲヒロインの話は102票もらえたのに(半ギレ)
    このように他の選択肢と拮抗していることが分かりますが、結果は明らかです。
    つまりまっつUPはストーンエッジと同じくらい信用できるということです!
    さて、ぼくを信じてもらえたところで記事の内容に入っていきたいと思います。

    RPGツクールMVのコアスクリプトは軒並み優秀なので
    RPGに必要なプラグインは既存処理の拡張が主になります。
    まだプラグインを作ったことない方は
    既存のプラグインの構成を参考にするとよいと思います。

    例えば、ぼくが作っているプラグインは
    開発者YojiOjimaさんの公式プラグインや
    キノコ王国の古文書を参考にして、構成しています。
    トリアコンタンさんありがとう!

    まずこちらのツクマテのプラグインを落としてください。(行をクリックしてね!)

    BattlebustPict.jsは拙作のプラグインで、
    新規の関数も必要であったためいくらか定義しているものの
    コアスクリプトの機能や拡張を多めに使っているため
    保守性に優れます。これを解説に使おうと思います。
    (全てのコードを解説するわけではありません。)

    ちなみに、プラグインを組むのに使ったエディタはVSCです。

    最初にプラグインのユーザーが見る部分から解説します。
    皆さんが毎日のように動かしている
    ツクールMVのエディタを起ち上げておいた方がいいでしょう。



    見やすさを考慮してパラメータ等のコメントの一部を削除しました。

    最初のファイル名ですが単にコメント(コードとして実行しない)
    としているだけなので、何らかの形で表示していればいいと思います。
    なお、ファイル名は半角英数字で構成してください。

    /*:jaと*/で囲われた部分が日本語ヘルプの記入部分です。

    @plugindescの内容は
    エディタのプラグイン管理画面の「説明」で表示されます。

    @authorには
    作者名を記入してください。


    @param,@desc,@default
    はプラグインパラメータの内容です
    それぞれ「パラメータの一意の名称(半角英数字)」、「パラメータの説明」、
    「プラグイン導入時点での初期値」を記入してください。

    @type numberとありますが
    これはパラメータの入力方法を少し変更することができます。
    値に数値を取りたいパラメータの場合は@type numberがよいでしょう。
    値に真偽値を取りたいパラメータの場合は@type booleanがよいでしょう。

    パラメータのtypeの指定方法に関してはツクマテの記事が参考になります。

    (行をクリックしてね!)

    @help
    プラグインを選択した時に見ることのできる
    「ヘルプ」の内容を記入してください。
    ファイルの利用規約はここに記入することが多いです。

    なお、以上の内容はプラグイン管理画面で合っているか確認できます。

    実際のコード部分の説明に入ります。

    今回のプラグインではプラグインパラメータがあるので
    扱いやすいように変数に代入しておきます。
    varから始まっているのでローカル変数への代入だと分かりますね。
    これは拙作だけでなく、多くの方がコードの最初の方でやっています。

    var parameters = PluginManager.parameters('BattlebustPict');
    var BPstartId = Number(parameters['startId'] || 50);
    一行目は導入されているこのプラグインのパラメータを取得します。
    とりあえず入れておきましょう。引数に入れるファイル名を間違えないように。
    2行目以降には同じような表現が並んでいます。
    Numberとある通りパラメータを数値型で取得しています。
    この場合、パラメータの入力がない時には50を取得します。
    他にもStringなどがありますがNumberだけ覚えていれば困りません。

    さて、BattlebustPict.jsで行う大まかな処理は以下の2つです。

    ・バトル開始直後にパーティメンバーの立ち絵を更新する。
    (バトル開始時のフェードインまでに更新は終わります。)

    ・パーティメンバーのステータスに変化があった時に立ち絵を更新する。


    開始時



    ダメージを受ける



    この「立ち絵を更新する」の処理は全く同じ処理を使っています。



    Game_Party.prototype.TimingUpdateBPのことですね。
    このthisはGame_Partyを意味するので
    内容を見るとパーティメンバーに何らかの処理をしていることが分かります。
    forEach文は主体の配列の項目数だけ、内容を繰り返し処理するので
    パーティメンバー全員(一人ずつ)に同じ処理を行うことができます。
    (ここでのactorはパーティメンバーの一要素、
     すなわちアクターを示しています。
     Game_Actorから始まる関数を呼び出すことができます。)

    このように共通の処理を使えるようにスクリプトを組んでいきましょう。

    次にGame_Party.prototype.onBattleStartを見ましょう。
    先に説明したバトル開始直後にパーティメンバーの立ち絵を更新する。
    を実行している部分です。

    ここでは
    ・オーバーライド
    ・フック
    という
    ツクールのプラグインを組む上で
    避けては通れない二つの技術が使われています。


    オーバーライドというのは
    親クラスで定義されている関数と
    同名の関数を子クラスで定義することです。

    処理を上書きしたいなら単純に新しい関数作ればよくね?
    と言う方がいると思います。
    おっしゃる通りです。
    しかしながら、これはツクール用のプラグイン。
    後述のフックと合わせて考えた場合オーバーライドの方が優れていると思います。

    <なぜそう思うのか>
    Game_PartyとGame_Troopは親クラスにGame_Unitを持ちます。
    Game_Unit.prototype.onBattleStartという関数がGame_Unitで定義されています。

    プラグイン未導入の状態では
    Game_PartyとGame_Troopは両方ともonBattleStartとつく関数は定義されていません。

    この時、Game_Partyを主体とする場合にonBattleStartが正しく呼び出された時
    Game_Unit.prototype.onBattleStartが実行されます。
    Game_Troopを主体とする場合も同様です。

    それぞれの共通の処理としてGame_Unit.prototype.onBattleStartが
    定義されていると考えられます。

    しかし、別名の新規の関数を作った場合は
    呼び出し元の記述をonBattleStartから直接変えなければいけません。
    オーバーライドならば子クラスに関数がある時はそれを優先して実行するので
    変える必要がありません.
    これらのことを考えるとオーバーライドした方がよいと思います。


    次にフックについて説明します。

    var _Game_Unit_onBattleStart = Game_Unit.prototype.onBattleStart; と
    _Game_Unit_onBattleStart.call(this); でフックしています。

    こうするとGame_Unit.prototype.onBattleStartの内容を
    call関数により実行することができます。
    引数には内容を実行する主体を指定することができますが
    今回のフックの役割としてはthis(Game_Partyを意味する)が適切です。
    第二引数以降には実行する関数の引数を入れますが(this, a, bみたいな感じで)
    Game_Unit.prototype.onBattleStartは引数を指定する必要がないので入れていません。

    なお、applyという機能が似た関数がありますがタケノコ王国ではcallのみ使っています。
    applyを使いたい方は各自調べてください。

    これらから既存の関数の内容を実行できることが分かると思いますが
    画像のコードを見るとフック以外の処理の記述があります。
    そういうことです。
    このフックの目的は既存の処理を実行しながら、追加の処理も実行することです。
    フックなしとの違いはフックで実行する関数の内容がデフォルトと違う場合でも
    変更後のものを呼び出せるので競合の回避が期待できます。

    <何が言いたいのか>
    つまり、Game_Party.prototype.onBattleStartは
    Game_Unit.prototype.onBattleStartの処理を実行しながら
    Game_Partyが主体の時のみ実行される処理を追加した関数です。

    <プラグイン内でのノートタグの扱い>
    2つ解説します。



    まずreturn data.meta[text];
    引数のtextの値と同じ名前のノートタグの値を返します。
    同じく引数であるdataの値がthis.actor()
    textの値が'BPnormal'の場合は
    return this.actor().meta['BPnormal'];
    を実行しているのと実質同じになります。
    これは関数を実行している主体のアクターのメモのノートタグを参照します。

    次にif(this.actor().note.match(/<BPnoequip>/i)) return;
    条件式は関数を実行している主体のアクターのメモに
    <BPnoequip>と入っていればtrueを返します。
    1行ifなのでtrueのときのみreturn;を実行します。
    ノートタグが入っている時は同関数内のその後の処理を実行しないので
    呼び出す前の関数に戻って次の処理に移ります。

    <最後に>
    以上がプラグインをつくるときに使う技術の例です。
    やや冗長な説明でしたがオーバーライドなんかはコアスクリプトでも
    Window_なんちゃらで多用されているので、ぜひ利用していきたいですね。
    皆さんのオリジナルのプラグインで動くゲームが
    公開されるのを楽しみにしております。

    TimingUpdateBPで検索すればステータス変化時の更新箇所も見つかると思います。
     上述の通り共通の処理が実行されています。興味がある方はご覧ください。
    ※うまくいかなかった場合は記述にミスがある場合が多いです。
     落ち着いて手を付けた場所を見直してみてください。
    ※フックした関数が元々returnなど戻り値に使用することを期待している関数の場合
    return _Game_Unit_kinokocrash.call(this);
    みたいな感じで組むとうまくいくかもしれません。
    ※関数をフックせずに上書きすることで動作するのが正常なプラグインもあるので
    なんでもフックすればいいというわけではありません。

  • 「コモンイベント」についてぇ・・・お話します

    2017-10-23 23:201
    コモンイベントってなんだよ(哲学)


    って言う人に対するツクールMVのツクラーによるツクラーのための記事です。
    丁寧丁寧丁寧に書きました。
    ウディタリアンにはあまり関係ないので最後まで読んだら帰りましょう。

    まずコモンイベントの指定から



    割と見つけやすい所にあります。
    とはいえコモンイベントは実行内容から
    適当なものをコピペして編集した方が楽ですね。




    実際にイベントの実行内容を選ぶときは
    コモンイベントのデータベースIDを指定してします。
    データベースにはコモンイベントの実行内容を設定されるわけですが。
    さて、この意味が皆さまに分かりますでしょうか。

    そう、自分だけのイベントコマンドをつくることができるのです!

    早速実行内容を自分好みに仕込みましょう(意味深)
    例を貼っておきます。



    RPG特有の全体回復ポイントの処理に適切です。
    ボスイベントの直前で利用してくれるようにイベントでも置いておいてください。
    コモンイベントの実行内容中では別のコモンイベントを実行できます。
    指定のIDのコモンイベントを編集すればどこで呼び出しても
    編集後の処理に生まれ変わってくれるので
    一機能ごとに小分けにした方が管理しやすいわけですね。
    ただし、図のようにしてしまうと無限再帰してしまうのでしてはいけない(戒め)

    上のトリガーとかいうのは
    自動実行と並列処理をスイッチを起動条件として設定することができ
    マップイベントを置かずとも特定のスイッチがオンの時に
    それぞれのタイミングで実行内容を処理してくれるわけですね。
    あまり多用はしない部分ですがツクールでは
    変数よりもスイッチの方が設定できる部分が多いので
    変数の方が使い道自体は多いですがスイッチの設定も考えてシステムを組みましょう。

    コモンイベント自体の使い方はここまで見れば
    大体分かってもらえたと思いますが
    なんでもかんでもコモンイベントにすればいいわけではありません。
    500とかいったら長編RPGでも普通に多すぎるので
    使い道の多い処理に絞って組みましょう。
    3回以上使う(使うだろう)を目安に組むといいでしょう。

    例えば

    ◆SEの演奏:Chest1 (90, 100, 0)
    ◆移動ルートの設定:このイベント (ウェイト)
    :        :◇向き固定OFF
    :        :◇左を向く
    :        :◇ウェイト:3フレーム
    :        :◇右を向く
    :        :◇ウェイト:3フレーム
    ◆セルフスイッチの操作:A = ON
    ◆所持金の増減:+ 114514
    ◆文章:なし, ウィンドウ, 下
    :  :114514\G 手に入れた!

    これ簡易作成の宝箱で作成できるやつじゃんwwwwwwwwwwwwwwww
    って思った人は立派なツクラーです。
    ただ、この実行内容、コモンイベントにした方がいいと思いませんか?
    全てじゃなくてもいいでしょう、所持金の増減部分は
    宝箱以外でも使えそうなのでここを弄りましょう。

    ◆所持金の増減:+ 114514
    ◆文章:なし, ウィンドウ, 下
    :  :114514\G 手に入れた!

    所持金の増加はよく使う処理です。
    しかし、毎回114514ゴールドも手に入れてしまっては
    瞬く間に1145141919810ゴールドに達してしまいます(億万長者)
    よしならば所持金の増減の値は変えて・・・
    文章も同じ金額にして・・・はさすがに面倒なので

    ◆所持金の増減:+ {#0001}
    ◆文章:なし, ウィンドウ, 中
    :  :\C[6]\I[361]\V[1]\G\C[0]を手に入れた!

    制御文字の都合上スラッシュが\になってますがご容赦ください。
    何やら蟹の群れのような文章になっていますが。
    こうすることにより変数1に任意の数値を入れて
    その分だけ所持金を増減、おまけに文章表示もばっちりです。
    (左から文字色の変更、アイコン描画、変数表示、通貨単位表示、文字色リセット
     後は続く文章です。)
    アイコンにはコインの画像を指定しておくなどすると見栄えがよくなります。
    コモンイベントにしておけばいつでも文字色の変更なども行えるわけですね。

    見てわかる通り変数への数値の代入は
    コモンイベントの前に行われることを想定しています。
    引数といえばわかりやすいでしょうか。
    結果としては以下のような感じになりますね。




    RPGツクールMVではイベントテストとかいう神機能があります。
    イベントの実行内容を選択して右クリックから選ぶことができますね。
    コモンイベントの試運転にはうってつけの機能なのでぜひ使いましょう。

    コモンイベントの基本的な使い方は以上です。
    ご閲覧ありがとうございました。