プラグインなし、あるいは少なくともサードパーティ製のプラグインなしでゲームを作るのについて、どう思いますか？
エンジンに付属しているプラグインや、自分で書いたプラグインを使うのは問題ありませんが、コミュニティによって作成されたサードパーティ製のプラグインを避けることについて主に興味があります。
「いいね！」 5
良いニュースは、ゲームのコーディングとデザインがずっと楽になることです。ゲームの構成要素が少なく、厄介なバグが発生する可能性も低いため、デバッグもずっと簡単になります。
非常に珍しいのは、大多数の人がDQ（ドラゴンクエスト）風のゲームを作っていないからです。また、プレイヤー体験をスムーズにするためのQoL（クオリティ・オブ・ライフ）向上策を見逃すことにもなります。
主な危険性は、プラグインの方が適しているのに、イベントシステムを駆使してゲームのメカニクスを実装しようとしてしまう場合です。イベントは、カットシーンとして扱うのが最も効果的です。
「いいね！」 4
もちろんです。非常に簡単で、意図した効果も実現でき、バグもほとんどありません。
「いいね！」 4
つまり、長期的に見ればずっと楽になります。特に、様々な用途でイベントを上手に使える場合や、プラグインをできるだけ少なく、あるいは一切使わないように依存する場合などです。
「いいね！」 4
自分のように膨大な数のプラグインを使用しているユーザーのために、より創造的なイベント解決策を考案することは、非常に楽しい挑戦です。
「いいね！」 4
これら、すべて非常に良い点で、正直言って私は考えていませんでした。
私の最初の考えは、人々は主にプラグインを使用してエンジンの機能を拡張し、ゲームを際立たせるために使っているということでした。しかし、逆の場合もあるかもしれません。Yanfly、Galv、そして他の有名な開発者によって作られた同じ人気のあるプラグインがみんなによって使用されると、特定のメカニクス、メニュー、UI要素が多くのゲームで現れ始めます。プロジェクトが他のものと似て見えることがあります。
そのため、イベントや自分でプラグインを書くことが、ゲームを際立たせる可能性があると考えました。他の人のプラグインに合わせてゲームを調整するのではなく、ゲームのデザインに合ったシステムを構築できます。
どう思いますか？
「いいね！」 1
これはプラグインの適切な使い方ではありません。
_これこそ_が、プラグインを適切に使う方法です。作りたいシステムがある場合、最初にすべきこと（イベントエディタで実現する方法を探すことがあれば別として）は、誰かがすでにそのプラグインを作成していないか検索してみることです。すでに必要なものが誰かによって作成されているのに、自分でプラグインをコーディングするのに時間を無駄にする必要はありません。ただし、見つからない場合や、見つかったものが少し違う場合は、もちろん自分で作成しても構いません。
プラグインは単なるツールの一つです。ゲームに合えば使い、合わなければ使わない。そして理想的には、YanflyやVisuStellaのような巨大なプラグインを避けるべきです。なぜなら、それらはあまりにも多くのことを行うからです。これは問題があります。1つのプラグインの中に、ゲームに合う要素が10個ありながら、合わない要素が12個含まれている可能性があるからです。
「いいね！」 4
最初の内は、RPG Maker 単体でできることに焦点を当てましょう。イベントコマンドを使って、望むメカニクスやシステムを作り上げてください。
プラグインを使う場合と比べて、ゲームはより安定し、システムやメカニクス同士の競合も起きません。また、メカニクスを簡単に付け替えたり、組み合わせたりすることも可能になります。
私にとって、ゲーム内に複数の異なるイベントベースのバトルシステムを設け、それらをゲーム内で（イベントごとに）切り替える、あるいは連携させることは非常に簡単です。これは、異なる開発者が作った複数のバトルシステム用プラグインを組み合わせて動作させる場合とは対照的です。（メニューについても同様です。）
多くの人はプラグインに過度に依存しており、少しの手間を惜しまなければエンジン本体でできることを、プラグインに任せてしまっています。不要な処理やコードでゲームを肥大化させ、本来イベントコマンドで柔軟に調整できるエンジン内のシステムを固定かつ硬直的なものに変えてしまい、結果として他の何千人もの開発者が自分のゲームで使っているようなシステムを採用してしまいがちです。
しかし、私は主にコミュニティが作成したサードパーティ製のプラグインを避けることに関心があります
イベントコマンドを使ったシステムやメカニクスの作成（通称「イベント設計」）に熟達すれば、他の多くの人が使っているような、ゲーム全体のシステムやメカニクスを構築しUIを大幅に変更してしまうようなプラグインを導入する代わりに、イベント設計の能力を強化し、独自システムを作成するための補助的なプラグインを使うことができます。
例えば、MVには表示している画像を切り抜くことを可能にするプラグインがあります。また、移動ルート設定で歩くスプライトの角度を変更できるプラグインもあります。さらに、「テキスト表示」コマンドで、1〜32の固定コードではなく16進数カラーコードを使って文字色を変更できるプラグインもあります。
^~ これらは完全なシステムではなく、むしろ基本のイベントコマンドシステムに対するアドオンのようなものです。
私は、このようなプラグインの導入を避けるべきだとは考えていません。 
ただし、バトルシステム全体、移動システム、メニューシステムなどの大規模なシステムプラグインの導入は避けるべきです。
また、「コア」プラグインやコードが難読化されたプラグインも避けてください。
これらのプラグインの多くは、自分自身で完成したゲームを開発していない人々によって作られていることを覚えておいてください。つまり、リリースされ磨き上げられたゲームでこれらのプラグインを使用し、あらゆる側面での機能性と安定性を確認した経験がないのです。そのため、開発の進んだ後になって、完全なシステムを構築するプラグインに重大な欠陥があることに気づくことがあります。その頃には、プラグインを取り除くには手遅れになっていることが多いです。
私が上記で挙げたような、ここぞとイベントコマンドを少し強化する小さなプラグインだけをインストールしている場合、重大な欠陥を発見した際に（それらのうち）単一のプラグインを取り除くことが非常に容易になります。
「いいね！」 2
他人のプラグインを使うのは好きじゃない。気に入っているのはMZ3Dくらいで、それも自分が作るすべてのプロジェクトに使うものではない。
MZはそれほど使っていないけど、最後にやったのは謎のダンジョンのようなものをゼロから構築するものだった。
問題はやはり作業量だ。でも、基本的なシステムを構築するためなら、自分で時間をかけてやることもそれほど悪くないと思う。
「いいね！」 3
私はプラグインを活用し、ビジュアルスタイルに合わせて調整したり、機能を少し変更したりすることが多いです。プラグインを使うことで、開発時間を大幅に節約できるだけでなく、他の開発者のアプローチを学ぶこともできます。もちろん、これは主に機能的なプラグインに当てはまり、難読化されていないプラグインに限られます。もう一つの利点は、プラグインを使用する場合、コードと機能が多くのユーザーによって集中的にテストされていることです。
「いいね！」 4
実は、プラグインを一切使わず、エンジン標準機能だけでフルのRPGツクールゲームを作ろうというアイデアがあるんです。これは主に、エンジンの限界を試して、何が作れるか探るためのものです。
エンジン自体がすでに非常に柔軟なので、これは素晴らしい取り組みだと思います。必要なのは、固定観念にとらわれない発想、根気強い作業、そしてもし本当に必要ならJavaScriptの知識くらいです。例えば、上記のゲームでは、『空の軌跡』のスピリットゲージにインスパイアされた、パーティ全員が共有するTPバーを実装しました。「バニラ」RPGツクールで物を作る方法を探索しないなら、スキル向上と理解を深める機会を逃していると言えます。
「いいね！」 3
いいえ。
なぜRPG Makerにはこれほど多くのバトルシステムプラグインが存在するのかには理由があります。それは、RPG Makerのデフォルトのバトルシステムを気に入らない人が多くいるからです。気に入らないのであれば、それを置き換えても全く問題ありません。移動システムについても同様です。
それでも、まずはそのような大規模なプラグインを使わずにゲームを作ってみることは良いアイデアだと言えます。小さなゲームでも構いません。デフォルトの仕様がどうなっているか、そしてどのように変更したいのかをよりよく理解するためです。
これはそれ自体を警戒すべきことではありません。実際、プラグインの開発とゲームの開発は少し異なるスキルと言えますから、片方だけを専門に行い、両方を手がけない人がいることに驚くべきことはありません。もちろん、それでもプラグインの安定性に関するテストは開発者の責任ですが。それにはリリース済みで磨き上げられたゲームが必要というわけではなく、包括的で磨き上げられたデモがあれば十分です。
ここであなたが要点を見落としているように思えます。エンジンの柔軟性は、プラグインなしでは完全に活用できないものです。エディタは固定されており硬直的で、エンジンコードには存在しない制約をデザイナーに課しています。
例えば、属性吸収はエンジンで完全にサポートされています。単に負の値を持つ「属性倍率」特性を追加するだけです。これは完全に正常に動作し、問題はありません（2つの吸収特性が相殺されるという事実を除いて）。唯一の問題は、エディタが「属性倍率」特性を負の値に設定できないため、それを回避するためにプラグインが必要になることです。
しかし、プラグインの使用を避けることに挑戦するのは全く問題ありませんし、あなたが言うように、それはエンジンが何ができるのかを学ぶ良い方法です。
「いいね！」 4
正直、それほど気にしていません。個人的には自作のプラグインを作る方が好きですが、自分のゲームに自作のプラグインを適用する方がより適切だということは理解しています。ただ、誰でもそれができるわけではないことも理解しています ^^
「いいね！」 3
要点を見落としているとは感じていません。というのも、このトピックはプラグイン（少なくともサードパーティ製のプラグイン）なしでゲームを作ることにどう感じているかという話でしたから。私はそれに関連して、現在進めているプロジェクトの経験談を交えて自分の意見を述べました。
ともかく、あなたの指摘は正しいです。私の言葉がエンジンの独自機能を使いすぎているように聞こえたかもしれません。RPGツクールは、そうでなければ初心者が混乱してしまうため、できることを非常に制限しています。ただ、やり方が分かっているなら、多くの人が不可能だと思っているようなことを驚くほどやり遂げられるよ、と言いたいだけです。
「いいね！」 5
あなたの言葉はエンジンの能力を過大に表現していません。エンジン自体は非常に柔軟です。 rigid で柔軟性がないのはエディターの方です。ただし、あなたが言うように、それには良い理由があるかもしれません。
「いいね！」 2