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

Solar_Flare · 2026 年 6 月 13 日午後 6:23

これは一般的な意味では正しくありません。実際、RPGMaker エンジンは本質的に非同期です。「何かをスケジュール」して「次のティックで実行する」ようなシステムがいくつかあります。例えば、バトルログやイベントインタープリタなどです。

ただし、ここでは特にレンダリングについて話しているので、エンジンのその部分は同期しているのかもしれません。

JS に型がないわけではありません。JS は数値が何であるかを知っており、文字列が何であるかを知っており、「これが Game_Actor かどうか」を問いかけることも問題なくできます。これは ES6 で新しく導入されたことではありません。

クラス名にアンダースコアを戻すだけで、変更なしで古いプラグインは正常に動作しないでしょうか？

Sprite を Container にするだけで、これを互換性を持たせることはできませんか？ Container にできない技術的な理由があるのでしょうか？

Sprite に子を追加するプラグインが実際にどれくらいあるかはわかりませんが、コアエンジン自体がこれを行っていると思うので、おそらくその数は少なくないでしょう。

AceOfAces · 2026 年 6 月 13 日午後 6:37

こう考えてみてください：最小限のコンテキストしかない変数を与えられたら、その変数がどのような型なのかを当てることができますか？ JSでは変数は何にでもなります。ひょっとしたら、うっかり別の型で上書きしてしまうかもしれません。

MVでは、保存するたびにエンジンが一時的にフリーズするのを目撃しました。それは、NodeJSがファイルを書き込むのを待たなければならなかったからです。そしてエンジンにはそれをバックグラウンドスレッドに任せる方法がなかったため、処理を停止せざるを得ませんでした。MZではより適切に処理されていますが、それでもasync/awaitがないと扱いにくいです。

Psychronic · 2026 年 6 月 13 日午後 6:58

すでに実装済みですが、私のアプローチは以下の通りです。PIXI8でコマンド名が変更された場合や処理方法が変わった場合でも、互換性シェイム（shim）がそれを自動的に吸収するため、プラグインの書き換えは不要です。一方で、PIXI8の書き方に従って記述されたコードもそのまま動作します。これにより、プラグインはPIXIのバージョンに依存しなくなります。唯一の欠点は、通常は中途半端な互換性しか持たないコードを書いておきながら、それがそのまま動作してしまう可能性がある点です。つまり、「間違った書き方」をしていても動作してしまう、といったことが起こり得ます。

RPG MakerはPIXI5で一部機能を使用していますが、これらはPIXI8では完全に削除されました。ただし、古いプラグインとの互換性を壊すことなく、正しいコマンドを正しい方法で実行するようにリアルタイムで変換する方法があります。鍵となるのは、プラグインがPIXIのバージョンに依存しないようにすることですが、そのためには互換性シェイムが必要です。100以上のプラグインを使用している私のゲームでテストしましたが、100%後方互換性があります。ただし、一部のプラグインについては集中的な修正が必要でした（私が見る限りですが）。それでも十分に実現可能です。RPG Reactorの公開を楽しみにしていてください。現在、仕上げの作業を行っています。

ベータテストに興味のある方がいれば、お知らせください。ZIPファイルを送付します。

JavaScriptの型についてですが、厳密な型付けの必要性は過大評価されているか、それほど心配することではないと考えています。もし私がうっかり文字列を整数として宣言してしまい、それが機能しなくなったとしても、それは開発者である私のミスなので、自分で原因を特定して修正すればよいでしょう。

niokasgami · 2026 年 6 月 13 日午後 7:17

はい、可能です。ただ、私はクラス名にパascalケース（古いプログラミングの習慣）を使うのを好む傾向があります。しかし、アンダースコアを含む名前にするのは100%可能です。

Sprites がコンテナであることについては、少し奇妙な側面があります。もし RM のスプライトをコンテナ化すると、アンカー位置が失われ、ピボットポイントを使用する必要が出てきます（正直、面倒なことです）。

PixiJS が「コンテナのみが子要素を持てる」とした理由は、基本的にはシーングラフの複雑さを減らし、パフォーマンスを向上させるためです。

（誤解しないでください、これは PixiJS 開発者の奇妙な設計選択です）

TypeScript については、現時点では単なる好みの問題に過ぎません。

Shim 互換レイヤーについては、後日どのように実装するか検討します。これは私が十分に深く理解している分野ではないので、現時点では手が出せません。私はコーディングはできますが、魔法使いだなんて言ったことはありません（笑）。まずは、プラグインなしのヴァニラプロジェクトが正常に動作するか確認するためにコードを移植することが目的です。

Psychronic · 2026 年 6 月 13 日午後 10:43

だから、僕はコードを書くのはそれほど得意じゃない（読むのは得意だけど）。だからAIを使うと、コードを見て、どこに問題があるかを把握し、AIに解決させたり、自分が解決策の提案やアイデアを出したりする。そしてAIがひたすら処理してくれるんだけど、その進捗ぶりに驚いた（良い意味で）。

でも、AIの力は本当に僕にとって力強かった。だって僕はコードを読むことや、それが何をしているかを理解するのは得意だったし（コンピュータの仕組み、RAM、CPU、GPU、ネットワークスタック、データベースなどの各部分の理解も）、コードを書くのはそれほど得意じゃなかった。なぜなら、構文の問題や、コマンドの名前を覚えていなくて、すべてのステップで調べなければならなかったから、それが面倒だったんだ。でも今はその部分がかなり軽減されたので、新しいツールを学びながら、趣味でこれをやってみようと思った。それが僕の視点だ。僕はコードを書くのがすごいわけじゃないよ！（笑）

でも、プログラミングの世界に深入りして、いろんな「プログラミングスタイル」があることや、みんなが何が良いか、何が悪いかについて強い意見を持っていることに気づくのは面白い。でも、たくさん学べて、楽しいよ！

AceOfAces · 2026 年 6 月 14 日午後 5:23

実は、タイルセットを処理するシェーダーを修正すれば、Pixi 6.5.10を使用することも可能です。

niokasgami · 2026 年 6 月 14 日午後 5:39

うん、交換しようとした記憶があるよ。大体のコードは結構似てると思う。

@Marix 残念だけど、僕はランタイムしか触れなくて、エディター自体には触れないんだ

niokasgami · 2026 年 6 月 14 日午後 7:20

私がプラグイン開発者向けに実装しようとしている機能の一つは、新しい関数やプロパティのためにプロトタイプパッチングを行う必要をなくすことです。

新しいメソッドやフィールドを注入する必要がある場合：

export class StatsContainer  {
  public get maxHp(): number {
    return this._hp;
  }
}

@merge(StatsContainer)
export class MyCustomsStatsContainer extends StatsContainer {
 public get maxHunger(): number {
   return this.maxHp + 100;
 }
}

/// 新しい関数やプロパティを自動的にフックします
//PluginManager.mergeClass(StatsContainer, MyCustomsStatsContainer);

関数の上書きやエイリアスが必要な場合（<extends>デコレーターを使って新しい関数を追加することもできます）：

class DummyGameParty {

  @overwrite(Game_Party)
  maxGold(this: Patched<Game_Party>){
    return Number.MAX_SAFE_INTEGER;
  }

  @alias(Game_Party, "after")
  maxLevel(this: Patched<Game_Party>) : number {
    if($gameSwitches.value(1)){
      return Number.MAX_SAFE_INTEGER;
    } else {
      return this.super();
    }
  }
}

どちらも動作し、これはまだ開発中のAPIです。
さらに、以下のようなAPIに統合される可能性があります：

@PatchClass(Game_Party)
export class MyCustomPartyExtension extends Game_Party {
  
 public myCustomField : number = 10; // 正常に動作し、通常通り追加されます。
  public override maxGold(this: Patched<Game_Party>): number {
    console.log("ゴールド制限を変更しています...");
    
    // super.maxGold() の代わりに this.super() を呼び出します！
    return this.super() + 5000; 
  }
}

これらはオプションのプラグイン開発ツールであり、開発者に強制されるものではないことを強調しておきます。

また、デコレーターはJavaScriptではまだ完全にサポートされていませんが（TypeScriptではサポートされています）、プラグインマネージャーを通じて簡単にアクセスできることをご案内しておきます。

PluginManager.merge(baseClass, childClass);
PluginManager.patchClass(baseClass,ChildClass);
PluginManager.Inject(BaseClass, MethodName, () => {});

SOURCE · 2026 年 6 月 14 日午後 10:10

2026年となった今、古くさい2020年のMZランタイムとの互換性を犠牲にしても、最新のレンダリングバックエンドを採用することはかなり良い取引だと思います。これが完成すれば、エディターを除いたRPG Makerの新しいバージョンのようなものです。

私もES6以前のJavaScriptを使いたいですが、TypeScriptは人気があり、優れたツールチェーンが揃っているため、多くの開発者の開発体験を向上させる結果になるでしょう。非常に正当化できる選択だと思います。

いや、MZゲームエンジンはかなり壊れていて、時代遅れです。

Psychronic · 2026 年 6 月 14 日午後 10:27

エディターはカバーしました（RPG Reactor）。また、PIXI8に対応しつつ、完全に後方互換性のあるランタイムも更新しました（まだテストしていない一部のケースを除く）。公開するのが楽しみです。

SOURCE · 2026 年 6 月 14 日午後 10:31

そう言ってるけど、あなたはこうも言っていたよね：

だから、私は期待を膨らませすぎないようにしているよ。

niokasgami · 2026 年 6 月 14 日午後 11:01

喧嘩はしたくないよ lol

これは確かにランタイムに焦点を当てたプロジェクトだね。エディタはGGGが所有する製品だから、多少融通は利くもののね。ランタイムの方はもう少し自由度が高い。特に私は主に改善案とかを提供してるだけだし。

AIについての私の立場だけど、AIが役立つのは同意するけど、参加する人たちはコードを丸ごと生成してそのままPull Requestを投げるのは避けてほしいな。少なくとも、ランタイムメーカーの精神に則っているか確認するために、徹底的なテストはしてほしい。

後でコードの期待値に関するフォームを作ろうかな。一貫性を保ちたいから。

Psychronic · 2026 年 6 月 14 日午後 11:07

あぁ、私はコーディングにAIを全面的に使ってるよ（多くの開発者がそうだよね）。そして、単なる「雰囲気コーディング」だけじゃなくて、プログラミングの基礎もしっかり理解してる。これは間違いなく、将来のソフトウェア開発における次の標準的なスタック、そして次のやり方だ。

ゲーム制作コミュニティの多くの人々は、時代の流れに取り残されていて、デジタルな強力なツールに対してオープンに敵対的だというのも知っている。どんなに優れた出力や製品が作れても、私が何を言っても、理性的な検討もなしに、不当に、あるいは即座に無視されたり切り捨てられたりする。

私は正直にAIの使用を明かし、誠意を持ってその利点を説き、証拠を示そうとする。しかし、それらは私を貶めたり、私が提供しようとしているものを即座に無視するための武器として使われてしまう。私がコミュニティに貢献したいと願ってきたことに対して、コミュニティは常に酷く、歓迎されない場所だった。

私は1990年代からRPG Makerを使っている。コミュニティはかつては良かったんだが、2010年頃からおかしな方向へ転び始め、現在ではかつてないほどひどくなっている。コミュニティはプロジェクトを完成させることを積極的に阻害している。本当にひどい。

でも、誰も私をどう思っていようが、どうでもいい。私はそれでも作り上げるつもりだ。

そうだ、証明してみよう。

まだ仕上げの作業をしている最中だが、これが今のところの出来だ。ぜひ試してみて、感想を教えてくれないか？ zipファイルに含まれている現在のゲームプロジェクト（開くためのプロジェクトファイル）は「Star Shift Freelancers」だ。PIXI8ランタイムとエディター自体も同梱している。現在、エディターで新規プロジェクトを作成するのは動作しないが、既存プロジェクトを開くことはできるので、それをzipに含めている。

以前はMZゲームで、多くのプラグインを使用していたが、互換性シムとPIXI8ランタイムを通じて後方互換性を持たせることができており、実際に動作している。私は口で言うだけでなく、実際に行動で示している。

でも、たとえ動作していても、誰もそれを見てくれる気がないのだろう。まるで私が嘘をついているのか、成功するまで偽りを並べているのかと思われているようだ。もしそんな手を使うつもりなら、AIは一切使わず、すべて自分一人でやったと言えばいいのに、私は正直に、誠実に接している。

将来は、即座に無視されたり、 seriously に受け止められたりすることを望んでいる。私の主張に対する証拠はいつでも提示できる。また、誰かが私の仕事に価値を見出し、一緒に作業したいと思えば、コラボレーションや共有にもいつでも応じるつもりだ。

とにかく、以下がリンクだ。ぜひ試してみて、感想を教えてほしい。まだ完成ではないが、あと少しだ。機能的であり、理論的なものでも「いつか」のものでもなく、すでに動作している。

これはWindows版アプリだが、これらのプラットフォーム向けにパッケージをビルドすれば、LinuxやMacOSでもシームレスに動作する（私自身はCachyOSを使っている）：

niokasgami · 2026 年 6 月 14 日午後 11:21

では、RPGツクールNextの話題に限定していただければ幸いです。あなたのやり取りは非公開にすることも可能です。

私はオープンな議論を支持していますが、現時点ではスレッドの主題から逸脱してしまっています。

Psychronic · 2026 年 6 月 14 日午後 11:23

あぁ、そうだよな。そう思ったよ（会話の遮断・検閲・隠蔽への直接的な移行ね）。

このスレッドを脱線させているわけじゃないよ。関連するプロジェクトだし、僕たちは同じことを望んでいるんだから。自然な流れとしては、協力してこれを完成させ、加速させることだよね。

君と競っているわけじゃないよ。

Baz · 2026 年 6 月 14 日午後 11:49

投稿はそのまま残しますが、スレッドの話題が逸れてしまいました。@Psychronic さん、そのプロジェクトは面白そうなので、ここで埋もれるよりも、自分自身で独立したスレッドを立てて、人々が見つかりやすくした方が良いと思います。@niokasgami さんも以前同じことを提案されていましたので、お気軽に新しいスレッドを作成し、そこにリンクを貼っていただければ、他の人々も追跡しやすくなります。

ありがとうございます！

Psychronic · 2026 年 6 月 15 日午前 12:03

了解しました。アップロード完了です：

niokasgami · 2026 年 6 月 15 日午前 2:02

RPG Maker Next の裏側で行われている新しい変更の一つに、Bitmap API の見直しがあります。

基本的な動作は同じですが、新しいテクスチャを読み込む際に非同期処理になる点が異なります。

const bitmap = new Bitmap(); 
bitmap.on("load", () => {});

bitmap.on は、ネイティブの Event Emitter に置き換えられ、.addLoadListener は使用されなくなります。

また、bitmap は内部で PingPongBuffer を使用し、パフォーマンスの高い GPU 演算を可能にしました。これにより、API 全体が CPU 依存から GPU 依存に移行しました。

これには以下のようにアクセスできます。

bitmap.buffer

BaseTexture は、PixiJS v8 の命名規則に合わせるために textureSource に名前が変更されました。

テクスチャとその textureSource の両方にアクセスすることが可能です。

テキストレンダリングはまだ実装されていません。Pixi.js の実装がどのようにテキストを扱っているかを確認するため、現在も実験中だからです。

niokasgami · 2026 年 6 月 17 日午後 6:02

アップデート！

ウィンドウの実装

ポート作業に全力で取り組んでいましたが、気になるバグに遭遇しました。

問題はウィンドウクラスの実装に関連していました。いくつか問題があり、その一つはレンダリングされないというものでした。
まだ表示されない理由をデバッグ中ですが、その過程で、RPG Maker の従来の方式ではなく、PixiJS v8 の NineSliceSprite 実装を使ってウィンドウのリサイズ部分すべてを管理したいと気づきました。
しかし、RPG Maker が window.png のテクスチャをどのようにフォーマットしているかによるもので、デフォルトの PixiJS NineSliceSprite 実装では、Dパッドがはみ出て表示されてしまいます。

残念ながら、NineSlice スプライトに穴を開けることはできませんし、リソースフォーマットを変更したくもありません。

そこで、この問題に対する私の解決策は、古い RPG Maker の方式に似たカスタム実装を作成することです。ただし、ハードコードするのではなく、再利用可能な Pure クラスとして作成する予定です。

クラス名: SpriteFrame
このクラスの目的は、NineSlice に似ていますが、中央に穴が開いています。
使用例:

  const texture = await ImageManager.loadSystem("window");
  const border = 24; // またはオブジェクトでも可

  const frame = new SpriteFrame(texture, border, rect); 
  frame.setBorder(border); /// コマンド経由で設定可能

これにより、特別な MZ ウィンドウフレームを簡単に作成できます。フレームの各 コーナー のサイズと位置が自動的に計算されます。ただし、座標を手動で指定することも可能です。

トピック		返信	表示
RPG Reactor 0.9 (ALPHA) - Open Source (MIT) Game Editor and PIXI8 Runtime. Backwards Compatible with RPG Maker (MZ/MV). ショーケース日本語 , english , mz , mv	26	168	2026 年 6 月 17 日
Cynthia Tools \| RPG Maker MZ Plugin Library — Free Plugins, Developer Tools & Gameplay Systems プラグイン plugin , mz	1	39	2026 年 6 月 16 日
[MZ] Undermax \| Official Plugins List プラグイン english , plugin , mz	0	131	2026 年 6 月 11 日
Y'all are crazy for burning down the forum in favor of this vibecoded-looking site. 雑談	108	2940	2026 年 6 月 17 日
RPG MAKER GUILD への改善要望スレッド質問	37	282	2026 年 6 月 17 日

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

アップデート！

ウィンドウの実装

関連トピック