Rpg Maker MZ Next: 現代的なRPGメーカーMZフレームワーク

RPGツクール プラグイン
1

mz_logo_fix
mz_logo_fix1195×249 58 KB

モダンなRPG Maker MZフレームワーク

『 :warning: 開発中 — このプロジェクトは現在活発に開発中であり、まだ本番環境での使用には適していません。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の設計に関する意見は？機能リクエスト、懸念、あるいは方向性についての単なる好奇心——何でも持ってきてください。目標は、コミュニティが真に求めるものを構築することであり、それはこの会話から始まります。リポジトリは貢献、フィードバック、議論のために公開されています。プロジェクトの方向性について何も決定的なことはまだ決まっていませんし、それが意図的です。

一緒に作り上げましょう。

:warning: プラグインの互換性

RPG Maker MZ Nextはランタイムの完全な書き換えであるため、既存のMZプラグインの大多数はそのままでは互換性がありません。これは2つの大きな変化による当然かつ避けられない結果です：

  • レンダリング層がPixiJS v5からPixiJS v8に移行し、大幅な破壊的API変更をもたらしました。
  • コードベースは現在TypeScriptおよびESMベースであり、多くのプラグインが依存していた元のグローバルスクリプトアーキテクチャから離れています。

これは、お気に入りのプラグインが永遠に消えたことを意味するものではありません。計画では、明確な移行ガイド、よく文書化されたプラグインAPI、可能な場合は互換性ユーティリティを提供することで、この移行をできるだけ容易にすることです。プラグイン開発者には、作品をポートし、近代化するための適切なツールリングが提供されます。

もし先に進みたいプラグイン開発者であれば、プラグインAPIに関する貢献や早期フィードバックを大歓迎します。

「いいね！」 6
2

「RPG Reactor」と呼んでいる、似たようなものを作っています。PIXI8でも動作しますが、互換性シェイムによって関数呼び出しをPIXI8の同等の呼び出しに動的に書き換えることで、後方互換性を維持できました。

メインエンジン部分はすでに完成して動作していますが、現在「フォーブ」と呼んでいるツールセットの開発中です。これはゲームの様々なアセットを動的に生成するためのものです。オープンソースで、近日公開予定です！

「いいね！」 2
3

おお、素晴らしいですね！

私の場合、後方互換性を廃棄する判断は、基本的にエンジンをもっと「リーン（軽量）」な構造に再編成するためでした。

単に古いコードをポートするのではなく、それをさらに改善したかったのです。

具体的には、適切なプラグインマネージャーのツールや、プラグインのパラメータ解析などです。

プレイヤーとスプライトの両方のビルトインアニメーションスプライトなどです。

当初は互換性も考慮していましたが、開発を進めるにつれて、特にスプライト操作に依存するプラグインにおいては、互換性を破ることが避けられなくなりました。なぜなら、PixiJS はもう葉ノード（leaf children）をサポートしていないからです。

TypeScript ツールリングで取り組んでいたもう一つの側面は、クラスデコレータのサポートです。

image
image1069×481 34 KB

これは非常にうまく機能しています。特に、TypeScript のデコレータは完璧にポリフィルできるためです。

@Psychronic さん、実は興味があるのですが、現在大きなボトルネックとなっているのは Window Layer クラスです。これについて、あなたはどのようにアプローチされましたか？PixiJS は内部の GL 呼び出しをサポートしていないため、どのように対応されているのか気になります。

「いいね！」 1
4

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のステンシル遮断ブロックは変更なし ...

};

  1. PIXI.TextureSourceによるバージョン検出：このクラスはv8にのみ存在します。これは安価で信頼性の高い機能スニファリングであり、同じファイルがv5/v6/v7/v8でポリモーフィックに動作することを可能にします。
  2. v8でステンシル操作が必要なくなった理由：
  • renderer.framebuffer.forceStencil() は削除され、v8のContextSystemはコンテキスト作成時にステンシルバッファを割り当てます (デフォルトでstencil: true)。
  • renderer.batch.flush() は削除され、v8にはパイプラインごとの遅延バッチャーがあり、グローバルなフラッシュフックはありません。
  • renderer.gl は削除され、v8はバックエンド (WebGLまたはWebGPU) を抽象化しているため、直接gl.stencilFunc / gl.stencilOp / gl.blendFunc呼び出しは対象を持ちません。
  1. スキップすることで失われるもの：ステンシル操作の元の目的は、上位ウィンドウが覆う領域の下に下位ウィンドウのピクセルが描画されないようにすることでした (これは小さな描画レート最適化であり、透過ウィンドウが重なり合う際のアルファブリーディングを防ぐ方法でもありました)。実際には、v8はすでにz順序でウィンドウを描画するため、上位ウィンドウは下位ウィンドウを同じフレーム内で上書き描画し、通常のMZ使用では視覚的に同一です。唯一の境界ケースは、半透明ウィンドウが重なり合い、下層とのアルファブレンディングがわずかに異なる場合ですが、実際のMZシーンではそのような透明ウィンドウの重なりは発生しないため、テストでは後退は見られていません。

スクリーンショットも載せておきます、やりましたよ！

Screenshot4
Screenshot41811×1244 293 KB

Screenshot3
Screenshot3868×911 48.5 KB

reactor
reactor1292×761 326 KB

Screenshot2
Screenshot21423×1020 133 KB

screenshot1
screenshot11920×1047 334 KB

5

なるほど！私はここで大きなボトルネックに直面しており、ユーザーが作成したウィンドウを除き、ほとんどのウィンドウが互いに重なり合って実際に「前面」に来ることはほとんどないのは当然のことですね。

私が考えていたアプローチは、RenderTexture を使用してウィンドウを合成し、基本的に「バッチ処理」して不要なウィンドウを非表示（オークルージョン）することです。これは、リフレッシュ時に RenderTexture を使用するMonogameのような多くのゲームフレームワークが採用している手法です。

この方法は少し重くなる可能性を考慮しましたが、ウィンドウは本質的に毎フレーム再描画する必要はありません。

「いいね！」 1
6

実は、それを GitHub リポジトリとして投稿することは可能でしょうか？ランダムな ZIP ファイルをダウンロードするよりも、リポジトリから確認する方が安心です。（申し訳ありませんが、現在では詐欺師やマルウェアに対して、どれだけ慎重になっても足りない状況です。）

7

結局、唯一の問題は、開発中のプロジェクトディレクトリがやや散らかっており、多くのファイルやデモプロジェクトが含まれているため、GitHub にアップロードするには容量が大きすぎる点です。ただし、zip ファイルにはエンジン自体ではなく、コアスクリプト（プロジェクトフォルダに入れるもの）のみが含まれています。

GitHub にアップロードでき次第、お知らせします。少し時間がかかるかもしれませんが。

はい、この zip ファイルにはウイルスやマルウェアは含まれておらず、誰かをだますつもりもありません。私も詐欺師は大嫌いです。

「いいね！」 1
8

あ、大丈夫ですよ！ただの基礎的なサイバーセキュリティの話ですからね（笑）。あなたがどのくらい進んだか見られるのを楽しみにしています！

必要なら、GitHub にコアスクリプトだけをアップロードすることもできます（.gitignore を使ってね）。でも、気にしないでください！

MZ をより現代的にするのに興味を持ってくださる方がいて、とても嬉しいです！

「いいね！」 1
9

RPG Makerのフォークとして捉えていて、ベースエンジンには存在しなかった機能を追加して使いやすくし、イノベーションを起こそうとしています。具体的には、タイルセットレイヤーF、G、H（2048x2048）の追加、動画オーバーレイなどの新しいイベントコマンド、3Dアニメーション用の3D制御機能などを追加する予定です。

RPG Maker MZを単にコピーするのではなく、既存の会社や製品の状況が停滞しているのを見て、基本的な部分をイノベーションさせようとしています。もちろん、独自のアイデアも取り入れています。

GitHubに公開する準備が整い次第、お知らせします。プロジェクトの改善にお役に立てるものがあるはずです。

「いいね！」 2
10

そのプロジェクトでも幸運を祈っています！

マップレイヤーについては、PixiJS の新しい「Render Layer」システムを調べてみることをお勧めします。かなり興味深いシステムのようです。私はまだ試していませんが。

もちろん、すでにご存知であれば別ですが。

面白いアイデアとしては、SceneMap のレンダリングを妨げることなく、カスタムレイヤーをフックできるようにすることだと思います。

また、カメラのロジックを GameMap クラスから分離し、独自の GameCamera クラスとして実装することを考えています。これにより、より良い制御が可能になり（ピクセル単位の移動も可能になるかもしれません）。

「いいね！」 2
11

カスタムプラグインを使って、すでにいくつかの作業を行っています。例えば、マルチパララックスプラグインを使えば、複数のパララックス画像を設定し、マップに基づいてz-indexを割り当てることができます。また、ビデオオーバーレイプラグインでも同様のことができます。

同意します。やりましょう！

「いいね！」 1
12

明らかに、私のためではない。

開発における「使いやすさ」について、私と君では考えが異なるような気がする。

君の主張するどの点にも、私には全く響かない。

  • PIXI v8？まあ、いいだろう。しかし、既存のPIXI v5のレンダリングと比較して、実際にどのような「実で具体的な」改善をもたらすのか？レンダリングプラグインの互換性がないといったデメリットなしで？ Anyway、RPGMakerで作業する際にPIXIを直接使うことはあまりないので、これが私に影響すると期待はしていない。
  • TypeScript、なぜ？私はTypeScriptよりも、ES6以前のJavaScript（つまり、RPGMakerが書かれている言語）の方がはるかに馴染みがある。最悪なのは、それがコンパイルされる言語であり、テストに追加の障壁をもたらすことだ。
  • ESモジュール – これらがウェブビルドで機能しない限り、本当に意味がない。Nodeモジュールは、本当にモジュールが欲しい場合に問題なく機能する（少なくとも、私はそう思う。私は組み込みのもの以外には滅多に使わない）。NPMも、可能であれば手を出したくないものだ。

要するに、君は壊れていないものを「修正」することに集中しているように見える。私には時間の無駄に聞こえる。それでも結構だ – 君にとっては時間の無駄ではないようだ。

しかし、それをすべて脇に置いて… 君は互換性を維持しようとして even いない。これが主に君個人のプロジェクトで、他の人が興味を持つ場合に共有しているだけなら結構だ。しかし、実際に他の人を引き入れようとしているのであれば、互換性の維持は人々を受け入れさせるために「絶対に重要」だ。95のプラグインが単に動作しなくなることを発見した途端、新しいランタイムに切り替えたいと思う人はいない。ただの親愛なる提案だ。

「いいね！」 1
13

私の記憶では、これはベースエンジンですでに動作しており、ごく少数の非常に小さな変更だけで済むはずです。（以前、これについて調べていたことがあるので、経験に基づいています。）ベースエンジンに適用するプラグインとして実装できると思います。

14

お前のトーンはかなり傲慢で失礼だと感じるが、今回はスルーする。

このプロジェクトを作った理由は、主に自分の興味、好奇心、そして使用感によるものだ。

PIXI v8？いいよ、でも既存のPIXI v5のレンダリングと比べて、本当に実用的で具体的な改善があるの？ レンダリングプラグインが互換性を持たなくなるようなデメリットなしで？ Anyway、RPG Makerで作業する際にPIXIを直接使うことはあまりないので、これが私に影響するとは考えていない。

もしPIXIの仕組みを少しだけでも知っていれば、パフォーマンスの大幅な向上、QOLの改善、多くのメモリリークの修正、そして古い奇妙な挙動の排除が行われていることがわかるはずだ。さらに、ゲーム開発、いや開発全般を簡素化する多くの新機能が追加されている。

あなたがPixiをほとんど使わないのは、RPG Makerがサンドボックス化されており、他のPIXI機能を使うことさえ困難だからだ。さらに付け加えるなら、PIXI v5は奇妙なクirkが多く、エラーを起こしやすいクラスタ（混乱）そのものだった。

TypeScript、なぜ？ 私はTypeScriptよりも、プリES6のJavaScript（つまりRPG Makerが書かれている言語）の方がはるかに居心地が良い。最悪なのは、それがコンパイル言語であり、テストに追加の障壁を生み出すことだ。

申し訳ないが、同意できない。プリES6は扱いにくく、複雑で、何の役にも立たないタイピングが多すぎる。悪夢だ。

また、誰かにTypeScriptで作業することを強制しているわけではない。最終的にリリースされる製品は、完全に普通のJavaScriptにコンパイルされる。しかし、もしあなたが小さなスクリプト以上の規模のプロジェクトに関わったことがあれば、TypeScriptが大きなプロジェクトにおける多くの痛みを軽減するのに役立つことにすぐに気づくはずだ。RPG Paper MakerのランタイムV2で作業した経験から、これはすぐに学んだことだ。しかし、もしそれが誰かに大きな苦痛であれば、プラグインを作成したり、コアスクリプトを拡張したりする際には、プレーンなJavaScriptを使用すればよい。これはコアスクリプトのランタイム開発のためのものであり、JSDocを使って適切な型付けを取得しようとするのは地獄だと確信しているからだ。

TypeScriptは、2026年の現代のWeb開発、またはWebゲーム開発において、最も基本的な要件である。

つまり、今あなたは自分の好みを語っているだけだ。

ESモジュール – これらがウェブビルドで機能しない限り、意味がない。Nodeモジュールは本当にモジュールが欲しい場合にのみ機能する（少なくとも私はそう思う、組み込みのもの以外にはあまり使わない）。NPMも、可能であれば関わりたくないものだ。

ESモジュールは単なるimportとexportであり、そもそもNPMとは関係がない。はい、多くの場合node_modulesを指すが、それは現代のJavaScriptにおける最も基本的な機能の一つであり、基本的なJavaScriptファイルを指すこともでき、バンドラーでも使用できる（これもまた現代のJavaScriptだ）。

要するに、あなたは壊れていないものを「修正」することに集中しているように見え、私には時間の無駄に思える。それでも構わない – あなたにとって時間の無駄ではないことは明らかだ。

しかし、それらをすべて脇に置いても… あなたは互換性を維持しようとしていない。これが主にあなた個人のプロジェクトであり、他の人が興味を持つ場合に共有しているだけなら構わない。しかし、実際に他の人をプロジェクトに引き入れようとしているのであれば、互換性の維持は人々を受け入れるために絶対に重要だ。誰も、新しいランタイムに切り替えた結果、使用している107個のプラグインのうち95個が単に動作しなくなるなんてことにはならないだろう。ただの親切な提案だ。

これもまた、純粋な好奇心と「なぜやらないのか」という気持ちから生まれたものだ。時間の無駄だと思うなら、どうぞ通常のRPG Makerを使い続けてくれ。RmNextを使うことを誰かに強制しているわけではない。これは初心者やカジュアルユーザー向けに作られたものではない。PixiJS v8の現代のエコシステムにアクセスしたい開発者向けに作られたものだ。

互換性が必須条件か？ そんなことはない。これはRMユーザーベース特有の非常に有毒な思考だ。彼らはエラーなしでプラグアンドプレイを期待するが、MVとMZのリリース両方に関わった者として、MVのプラグインをMZにプラグアンドプレイで使えないことがわかったとき、人々は空に向かって叫んでいたことを覚えている。RPG Makerの開発者がバージョン間の後方互換性を気にしたことは一度もなく、さらに言えば、もし次のRPG MakerがPixiJS v8（Unityではなく）で、互換性を維持していたとしても、ユーザーベースはまたしても叫んだに違いない。ループの繰り返しだ。

初期段階では適切なプラグイン互換性サポートについて考えていたが、PixiJS v8で何が変わったかを知ると、すべてを動作させられると期待するのは無理だと気づく。なぜなら、スプライトやコンテナ/レンダリングの動作がPixiJSではあまりにも異なるからだ。もし適切なシムレイヤーを書こうとしても、おそらく作業があまりにも面倒すぎて実用的ではないだろう。

この問題を回避し、切り替えたい人や試したい人にとって容易にするために私が取ったアプローチは、APIを元のものと極めて近い状態に保つことだ。そうすれば、彼らはコードの一部を変更するだけで済む。

（ほとんどのgame_objectクラスは基本的に同じか、少なくとも古いものに近い挙動をする）

再設計された唯一のクラスは、マネージャーだ。これらはサービスローカライザーのように振る舞うようにした。これは主に私の好みであり、まだドラフト段階だ。

また、シーンがどのように扱われるかについては、PixiJS v8のアセット読み込みが非同期であるため、ハイブリッド非同期読み込みを使用している。

そして、一部のスプライトセットがどのように扱われるかについては、コンテナのみが子要素を持てるようになっている。

構わない。しかし、実際に他の人をプロジェクトに引き入れようとしているのであれば、互換性の維持は人々を受け入れるために絶対に重要だ。誰も、新しいランタイムに切り替えた結果、使用している107個のプラグインのうち95個が単に動作しなくなるなんてことにはならないだろう。ただの親切な提案だ

またまた、私はまさに「求めている」わけではない。もし彼らがこのようなプロジェクトで作業したいのであれば、参加を呼びかけているだけだ。私の英語がそれほど上手ではないので、おそらく「求めている」という響きになってしまったのかもしれない（？）。

正直なところ、私はこれを共有し、興味を持つ人々が参加できるようにしたいだけだ。これが時間の無駄かどうかを人々がどう思おうと、私は気にしない。

しかし、もしうまくいかなかったとしても、まあ少なくともそこから学び、興味深い経験になった。私がしているのは、ただそのプロセスを楽しんでいるだけだ。

「いいね！」 1
15

TypeScriptに関するあなたの見解については色々言いたいことはあるが、このスレッドをこれ以上横道にそれさせない。

ここで明確にしておきたい。互換性は、自分自身や数人のマニア以外の人がそれを使うことを望むなら必須条件だ。プラグインが使えなくなることを承知の上で、大多数の人はRMNextフォークに移行しないだろう。だが、それはあなたにとって問題ないようだから、頑張ってください、としか言えないね。

16

互換性の重要性には同意します。個人的にはTypeScriptの価値をあまり感じません（通常のJavaScriptで十分だと思いますが）、RPG Makerエンジンが停滞しているのは確かで、新しい方向性を模索しながら後方互換性を維持したまま革新を図りたいと考えています。現在、ゲームの開発中ですが、多くのプラグインを使用しています。まだ見えていないエッジケースもあるかもしれませんが、発生次第修正していくつもりです。

「いいね！」 1
17

そこにはかなりの混乱があるように思えますが、TypeScriptはコアスクリプト用であり、プラグイン開発用ではありません。これは、エンジン開発時に全体の見通しを良くするため（そして型付けのため）です。プラグインについては、デフォルトのJavaScriptを使用すれば問題ありません。私は個人的にプラグイン開発でもTypeScriptを使っていますが、これは基本的には安全性の層を提供し、エラーの起こりやすい問題を大幅に減らすためです。コアスクリプトについては、文書化を比較的容易に行えるため、TypeScriptであることが理にかなっています。

互換性については、リワークはまだ初期段階なので、完成時期は見てから判断しますが、説明した通り、すべてを互換性にするのは不可能です。申し訳ありませんが、それは現実的ではありません。革新を起こすためには、時には卵を割らなければなりません。

この件について議論が長引くだけだと思うので、これが私の最後のメッセージとなります。

18

申し訳ありませんが…、すべてでなくても、少なくとも90%のものは互換性を持たせることは可能です。100%にすることも「可能」かもしれませんが、根本的なレンダリングライブラリが完全に置き換えられていることを考えると、実現のコストが極めて高額になる可能性があります。ただし、互換性の範囲をRPGMakerオブジェクトの外部API（Game_*、Sprite_*、Window_*、および*Managerクラス、およびいくつかのコアクラス）に限定すれば、完全に実現可能でしょう。ただし、それが容易になるわけではありません。互換性を維持するために実際に努力を払う必要があります。

これはあまり意味を成しません。TypeScriptには、ものをより予測可能にするような機能はありません。TypeScriptは、理論的には、関数に間違った型を渡してしまったために見逃してしまうようなエラーを検出するのに役立つことは事実です。しかし、そのようなエラーはJavaScriptのリンティングツールでも十分に検出できます。TSはそれを容易にするわけではありません。実際に型を指定したいときに使用する構文が変わるだけです。

いずれにせよ、これがTSに関する私の最後の投稿になるでしょう（少なくともこのスレッドでは）。

「いいね！」 1
19

これはより複雑な問題ですが、v5からv8への移行では100%の互換性は達成できません。v7以降、Pixiは非同期処理に重点を置いています（つまり、コードはスレッドをブロックせずにタスクを実行できます）。RPG Maker MZは本質的に同期処理であるため、これを処理するには大規模な書き直し（または回避策）が必要です。私は非同期と同期の処理を扱うという不運な経験をしましたが、（少なくともJSでは）これを扱うのは大変です。カスタム暗号化がMVとMZの両方で動作するようにするために、コールバックを使用する必要がありました。これは非常に厄介です（特にC#のTask処理と比較すると）。

TypeScriptは、JSには欠けている機能（型など）を提供することで、開発者がより良いコードを構築できるようにするライフクオリティ機能を提供するように設計されています。JSとC#の両方を使用している私としては、変数が文字列であることを知っているため、可能な限りC#を使用します。JS（少なくともES5以前）にはそのような利点はありません。ほとんどのJS開発者がTypeScriptを使用するのには理由があります。それは、より良いJSコードを作成するのをずっと簡単にしてくれるからです。

「いいね！」 3
20

はい、その通りですが、内部のSpriteシステム、つまりものの扱い方が異なります。少なくとも親と子の関係においてです。

（以前に説明済み）PixiJS v8では、コンテナのみが子を持てるようになりました。それ自体は悪いことではありませんが、避けることができない破壊的変更をもたらします。（Spritesetのようなケースで顕著です）

少なくともポーター（移植）の問題を緩和する方法の一つとして考えていたのは、例えば、旧版のSpritesetと同様に動作するSpritesetクラスを提供することです。

export class SpritesetBase extends Container { 
   
   protected _anchor: ObservablePoint; // Spritesetのxアンカー動作を再現するため
  constructor(){ 
  
  }

}

前述の通り、ほとんどのGameオブジェクトクラスは似ています（いくつかの例外を除く）。

Windowsクラスは、以前のRPG Makerと同じように動作します。ウィンドウの内部構築方法を変更しただけで、Core_window.jsクラスに手を入れる必要はありませんでした。

基本的には、独自のシステムではなくPixiJSの内部のナインスライススプライトシステムを使用しています。

（また、IntelliSenseとの奇妙な競合を避けるためにRpgWindowに名前を変更しました）

シーンのレンダリング方法は現在、ハイブリッド非同期ですが、基本的にシンプルになるように構築されています。awaitを追加するか、新しいImageManagerキューシステムを使用するだけです。これは、RPG Makerの古いグラフィック読み込み方法（スレッドをブロックする）をある程度再現するものです。

ImageManager.requestQueue("folder","assetsName");

読み込みとBitmap処理の大部分は、CPUバインドからGPUバインドに変更されました。

適切な互換性についても考えましたが、正直なところ、プラグインを差し替えるだけで動くようにするのはそれほど簡単ではありません。しかし、基本的に必要なのはこれだけです：

OLD :

//PluginA 

Scene_Menu.prototype.create = function(){
  this._mySprite = new Sprite();
  this._mySprite.bitmap = ImageManager.loadSomething("spriteName");
  this.addChild(this._mySprite);
};

NEW :

import {SceneMenu} from "rm-next";

const alias =  SceneMenu.prototype.create;
SceneMenu.prototype.create = async function() { 
  alias.call(this); 
  this._mySprite = new Sprite();
  this._mySprite.bitmap = await ImageManager.loadSomething("spriteName");
  this.addChild(this._mySprite);
}

// スレッドをロックする必要があるエッジケース。しかし、これは以前のRPG Makerであなたがしていたこととほぼ同じです

SceneMenu.prototype.MyLockingFunction = function(){
  ImageManager.request("folder", "assetName").then((bitmap) => { 
     this._mySprite.bitmap = bitmap;
   });
}

SceneMenu.prototype.checkIfSpriteIsReady = function() {
 if(ImageManager.isReady()) { // ImageManagerが読み込み中である限り、何も行われません。
 // 何か処理を行う
 } 
}

APIはほぼ同じですが、もし人々が以下のようなプラグインを持っていた場合：

const sprite = new Sprite();
const sprite2 = new Sprite();
sprite.addChild(sprite2);

エラーになります。この問題を修正する方法はありません。これがPixiJS V8の現在の動作です。

この問題を修正するには、以下のようにする必要があります：

 const container = new Container();
 const mySprite = new Sprite();
 const mySprite2 = new Sprite();
 container.addChild(mySprite,mySprite2);

すべてを考慮し、摩擦をどう修正するか考えましたが、できることには限界があります。

「いいね！」 1