モダンなRPG Maker MZフレームワーク
『 
開発中 — このプロジェクトは現在活発に開発中であり、まだ本番環境での使用には適していません。APIは変更される可能性があります。機能は不完全な場合があり、破壊的変更がいつでも発生する可能性があります。貢献やフィードバックは歓迎しますが、安定版が発表されるまではライブプロジェクトでの使用は推奨されません。
これは何ですか？
RPG Maker MZ Nextは、RPG Maker MZランタイムの近代化版です。PixiJS v8とTypeScriptの上に再構築し、現代のWeb開発基準に合わせています。
この書き換えはランタイムエンジンにのみ焦点を当てています。エディターは手つかずのままです。RPG Maker MZで作成されたプロジェクトが対象となりますが、基盤となる実行層は以下のように置き換えられます：
- PixiJS v8によるレンダリング — 従来のレンダラーよりもWebGL/WebGPUパイプライン、シーングラフ、パフォーマンスの改善を活用します。
- TypeScriptによる完全書き換え — 全体に厳密な型指定を行い、IDEのサポート強化、安全なリファクタリング、システム間の明確な契約を可能にします。
- ネイティブESM対応 — ランタイムとプラグインエコシステムの両方がESモジュールを中心に構築されており、適切な依存関係管理、ツリーシェイキング、プラグイン開発者向けのモダンな作成体験を実現します。
- 開発者向けツールリングクラス — プラグイン開発、シーン管理、エンジン拡張をより使いやすくするために設計されたユーティリティおよびヘルパークラスのスイート。
なぜ存在するのか、そして誰のためのものか
このプロジェクトは好奇心と不満の混合から始まりました。RPG Maker MZの開発は、時に退屈に感じられることがあります。コーディング体験は広範なPixiJSエコシステムから切り離されており、役立つよりも邪魔になる方法でサンドボックス化されており、開発者が期待するモダンなツールリングが欠けています。そのため、これらの痛み点を回避するのではなく、直接対処することにしました。
それが単なる面白いプロジェクトでもあるかどうか？もちろんそうです。しかし、その不満は現実のものであり、同じように感じた他の人々にとって有用な結果になることを願っています。
このプロジェクトは主に、RPG Maker MZから真のパワーと柔軟性を求めるシリアスな開発者向けです。 エンジンと戦うことよりも、それを使って構築することに疲れた人々、そして自分の邪魔をせず、実際に望むように作業できる基盤を求めている人々向けです。
それがあなたに当てはまるなら、ようこそ。
オープンソースかつコミュニティ主導
RPG Maker MZ Nextは完全なオープンソースプロジェクトであり、GitHubで入手可能です。裏側でランタイムを近代化していますが、KadokawaのRPG Maker利用規約を完全に尊重し、その範囲内で動作します。
このスレッドは単なる発表ではありません——参加の招待です。このプロジェクトは、実際にRPG Maker MZを使用し、開発する人々によって形作られる協力的な取り組み meant です。プラグイン開発者であろうと、ゲーム開発者であろうと、アイデアや意見を持つ人であろうと、あなたの声がここで重要です。
ランタイムの動作についてどう考えますか？プラグインAPIの設計に関する意見は？機能リクエスト、懸念、あるいは方向性についての単なる好奇心——何でも持ってきてください。目標は、コミュニティが真に求めるものを構築することであり、それはこの会話から始まります。リポジトリは貢献、フィードバック、議論のために公開されています。プロジェクトの方向性について何も決定的なことはまだ決まっていませんし、それが意図的です。
一緒に作り上げましょう。
プラグインの互換性
RPG Maker MZ Nextはランタイムの完全な書き換えであるため、既存のMZプラグインの大多数はそのままでは互換性がありません。これは2つの大きな変化による当然かつ避けられない結果です：
- レンダリング層がPixiJS v5からPixiJS v8に移行し、大幅な破壊的API変更をもたらしました。
- コードベースは現在TypeScriptおよびESMベースであり、多くのプラグインが依存していた元のグローバルスクリプトアーキテクチャから離れています。
これは、お気に入りのプラグインが永遠に消えたことを意味するものではありません。計画では、明確な移行ガイド、よく文書化されたプラグインAPI、可能な場合は互換性ユーティリティを提供することで、この移行をできるだけ容易にすることです。プラグイン開発者には、作品をポートし、近代化するための適切なツールリングが提供されます。
もし先に進みたいプラグイン開発者であれば、プラグインAPIに関する貢献や早期フィードバックを大歓迎します。
「いいね！」 4
「RPG Reactor」と呼んでいる、似たようなものを作っています。PIXI8でも動作しますが、互換性シェイムによって関数呼び出しをPIXI8の同等の呼び出しに動的に書き換えることで、後方互換性を維持できました。
メインエンジン部分はすでに完成して動作していますが、現在「フォーブ」と呼んでいるツールセットの開発中です。これはゲームの様々なアセットを動的に生成するためのものです。オープンソースで、近日公開予定です！
「いいね！」 2
おお、素晴らしいですね！
私の場合、後方互換性を廃棄する判断は、基本的にエンジンをもっと「リーン（軽量）」な構造に再編成するためでした。
単に古いコードをポートするのではなく、それをさらに改善したかったのです。
具体的には、適切なプラグインマネージャーのツールや、プラグインのパラメータ解析などです。
プレイヤーとスプライトの両方のビルトインアニメーションスプライトなどです。
当初は互換性も考慮していましたが、開発を進めるにつれて、特にスプライト操作に依存するプラグインにおいては、互換性を破ることが避けられなくなりました。なぜなら、PixiJS はもう葉ノード（leaf children）をサポートしていないからです。
TypeScript ツールリングで取り組んでいたもう一つの側面は、クラスデコレータのサポートです。
これは非常にうまく機能しています。特に、TypeScript のデコレータは完璧にポリフィルできるためです。
@Psychronic さん、実は興味があるのですが、現在大きなボトルネックとなっているのは Window Layer クラスです。これについて、あなたはどのようにアプローチされましたか？PixiJS は内部の GL 呼び出しをサポートしていないため、どのように対応されているのか気になります。
「いいね！」 1
RPG ReactorのCoresscriptを添付します。互換性シェイムはlibsフォルダに入っていますので、ぜひご確認ください！
RPG Reactor 0.9 - Coresscript.zip (642.3 KB)
要約すると：
修正方法は、Pixi v8でカスタムGLステンシルレンダリングをスキップし、標準レンダリングパイプラインに子要素の描画を任せることです。
WindowLayer.prototype.render = function render(renderer) {
if (!this.visible) return;
// v8: レンダリングパイプラインが子要素を自動的に処理します。v8では
// renderer.framebuffer.forceStencil (ステンシルバッファはコンテキスト作成時に
// デフォルトで割り当てられます -- pixi8の `stencil: true` ContextSystem
// 初期化参照) が削除され、renderer.batch はもはやグローバルなフラッシュ可能バッチャーでは
// ありません (各レンダリングパイプラインは独自の遅延バッチャーを持っています)。生のGL
// ステンシル操作とv8の遅延パイプラインを混在させると、描画順が正しく反映されません。
//
// v8ではカスタムレンダリングをスキップし、標準レンダリングパイプラインに
// 子要素の反復処理を任せます。見た目の結果として、上位ウィンドウの下にある
// 下位ウィンドウのピクセルが描画されますが、直ちに上書き描画されるため、
// 通常のMZ使用では視覚的な後退はありません。v5/v6/v7は以下のストックステンシル
// 遮断動作を維持します。
if (PIXI.TextureSource) {
return;
}
// ... 以下のv5/v6/v7のステンシル遮断ブロックは変更なし ...
};
- PIXI.TextureSourceによるバージョン検出：このクラスはv8にのみ存在します。これは安価で信頼性の高い機能スニファリングであり、同じファイルがv5/v6/v7/v8でポリモーフィックに動作することを可能にします。
- v8でステンシル操作が必要なくなった理由：
- renderer.framebuffer.forceStencil() は削除され、v8のContextSystemはコンテキスト作成時にステンシルバッファを割り当てます (デフォルトでstencil: true)。
- renderer.batch.flush() は削除され、v8にはパイプラインごとの遅延バッチャーがあり、グローバルなフラッシュフックはありません。
- renderer.gl は削除され、v8はバックエンド (WebGLまたはWebGPU) を抽象化しているため、直接gl.stencilFunc / gl.stencilOp / gl.blendFunc呼び出しは対象を持ちません。
- スキップすることで失われるもの：ステンシル操作の元の目的は、上位ウィンドウが覆う領域の下に下位ウィンドウのピクセルが描画されないようにすることでした (これは小さな描画レート最適化であり、透過ウィンドウが重なり合う際のアルファブリーディングを防ぐ方法でもありました)。実際には、v8はすでにz順序でウィンドウを描画するため、上位ウィンドウは下位ウィンドウを同じフレーム内で上書き描画し、通常のMZ使用では視覚的に同一です。唯一の境界ケースは、半透明ウィンドウが重なり合い、下層とのアルファブレンディングがわずかに異なる場合ですが、実際のMZシーンではそのような透明ウィンドウの重なりは発生しないため、テストでは後退は見られていません。
スクリーンショットも載せておきます、やりましたよ！
なるほど！私はここで大きなボトルネックに直面しており、ユーザーが作成したウィンドウを除き、ほとんどのウィンドウが互いに重なり合って実際に「前面」に来ることはほとんどないのは当然のことですね。
私が考えていたアプローチは、RenderTexture を使用してウィンドウを合成し、基本的に「バッチ処理」して不要なウィンドウを非表示（オークルージョン）することです。これは、リフレッシュ時に RenderTexture を使用するMonogameのような多くのゲームフレームワークが採用している手法です。
この方法は少し重くなる可能性を考慮しましたが、ウィンドウは本質的に毎フレーム再描画する必要はありません。
「いいね！」 1
実は、それを GitHub リポジトリとして投稿することは可能でしょうか？ランダムな ZIP ファイルをダウンロードするよりも、リポジトリから確認する方が安心です。（申し訳ありませんが、現在では詐欺師やマルウェアに対して、どれだけ慎重になっても足りない状況です。）
結局、唯一の問題は、開発中のプロジェクトディレクトリがやや散らかっており、多くのファイルやデモプロジェクトが含まれているため、GitHub にアップロードするには容量が大きすぎる点です。ただし、zip ファイルにはエンジン自体ではなく、コアスクリプト（プロジェクトフォルダに入れるもの）のみが含まれています。
GitHub にアップロードでき次第、お知らせします。少し時間がかかるかもしれませんが。
はい、この zip ファイルにはウイルスやマルウェアは含まれておらず、誰かをだますつもりもありません。私も詐欺師は大嫌いです。
「いいね！」 1
あ、大丈夫ですよ！ただの基礎的なサイバーセキュリティの話ですからね（笑）。あなたがどのくらい進んだか見られるのを楽しみにしています！
必要なら、GitHub にコアスクリプトだけをアップロードすることもできます（.gitignore を使ってね）。でも、気にしないでください！
MZ をより現代的にするのに興味を持ってくださる方がいて、とても嬉しいです！
RPG Makerのフォークとして捉えていて、ベースエンジンには存在しなかった機能を追加して使いやすくし、イノベーションを起こそうとしています。具体的には、タイルセットレイヤーF、G、H（2048x2048）の追加、動画オーバーレイなどの新しいイベントコマンド、3Dアニメーション用の3D制御機能などを追加する予定です。
RPG Maker MZを単にコピーするのではなく、既存の会社や製品の状況が停滞しているのを見て、基本的な部分をイノベーションさせようとしています。もちろん、独自のアイデアも取り入れています。
GitHubに公開する準備が整い次第、お知らせします。プロジェクトの改善にお役に立てるものがあるはずです。
「いいね！」 1
そのプロジェクトでも幸運を祈っています！
マップレイヤーについては、PixiJS の新しい「Render Layer」システムを調べてみることをお勧めします。かなり興味深いシステムのようです。私はまだ試していませんが。
もちろん、すでにご存知であれば別ですが。
面白いアイデアとしては、SceneMap のレンダリングを妨げることなく、カスタムレイヤーをフックできるようにすることだと思います。
また、カメラのロジックを GameMap クラスから分離し、独自の GameCamera クラスとして実装することを考えています。これにより、より良い制御が可能になり（ピクセル単位の移動も可能になるかもしれません）。
「いいね！」 1
カスタムプラグインを使って、すでにいくつかの作業を行っています。例えば、マルチパララックスプラグインを使えば、複数のパララックス画像を設定し、マップに基づいてz-indexを割り当てることができます。また、ビデオオーバーレイプラグインでも同様のことができます。
同意します。やりましょう！
明らかに、私のためではない。
開発における「使いやすさ」について、私と君では考えが異なるような気がする。
君の主張するどの点にも、私には全く響かない。
- PIXI v8？まあ、いいだろう。しかし、既存のPIXI v5のレンダリングと比較して、実際にどのような「実で具体的な」改善をもたらすのか？レンダリングプラグインの互換性がないといったデメリットなしで？ Anyway、RPGMakerで作業する際にPIXIを直接使うことはあまりないので、これが私に影響すると期待はしていない。
- TypeScript、なぜ？私はTypeScriptよりも、ES6以前のJavaScript（つまり、RPGMakerが書かれている言語）の方がはるかに馴染みがある。最悪なのは、それがコンパイルされる言語であり、テストに追加の障壁をもたらすことだ。
- ESモジュール – これらがウェブビルドで機能しない限り、本当に意味がない。Nodeモジュールは、本当にモジュールが欲しい場合に問題なく機能する（少なくとも、私はそう思う。私は組み込みのもの以外には滅多に使わない）。NPMも、可能であれば手を出したくないものだ。
要するに、君は壊れていないものを「修正」することに集中しているように見える。私には時間の無駄に聞こえる。それでも結構だ – 君にとっては時間の無駄ではないようだ。
しかし、それをすべて脇に置いて… 君は互換性を維持しようとして even いない。これが主に君個人のプロジェクトで、他の人が興味を持つ場合に共有しているだけなら結構だ。しかし、実際に他の人を引き入れようとしているのであれば、互換性の維持は人々を受け入れさせるために「絶対に重要」だ。95のプラグインが単に動作しなくなることを発見した途端、新しいランタイムに切り替えたいと思う人はいない。ただの親愛なる提案だ。
私の記憶では、これはベースエンジンですでに動作しており、ごく少数の非常に小さな変更だけで済むはずです。（以前、これについて調べていたことがあるので、経験に基づいています。）ベースエンジンに適用するプラグインとして実装できると思います。
