Rpg Maker MZ Next : The modern rpg maker MZ framework

RPG Maker Plugins
1

mz_logo
mz_logo1195×249 62.1 KB

The Modern RPG Maker MZ Framework

:warning: Work in Progress — This project is actively in development and is not yet ready for production use. APIs are subject to change, features may be incomplete, and breaking changes can occur at any time. Contributions and feedback are welcome, but use in live projects is discouraged until a stable release is announced.

What is this?

RPG Maker MZ Next is a modernisation of the RPG Maker MZ runtime, rebuilding it on top of PixiJS v8 and TypeScript to bring it in line with contemporary web development standards.

The rewrite focuses exclusively on the runtime engine — the editor remains untouched. Projects created in RPG Maker MZ are the target, but the underlying execution layer is replaced with:

  • PixiJS v8 rendering — leveraging its WebGL/WebGPU pipeline, scene graph, and performance improvements over the legacy renderer.
  • Full TypeScript rewrite — strict types throughout, enabling better IDE support, safer refactoring, and clearer contracts between systems.
  • Native ESM support — both the runtime and plugin ecosystem are built around ES Modules, enabling proper dependency management, tree-shaking, and a modern authoring experience for plugin developers.
  • Developer-focused tooling classes — a suite of utility and helper classes designed to make plugin development, scene management, and engine extension more ergonomic.

Why This Exists & Who It’s For

This project started from a mix of curiosity and frustration. Developing for RPG Maker MZ can
sometimes feel tedious — the coding experience is disconnected from the broader PixiJS ecosystem, sandboxed in ways that get in the way more than they help, and lacks the modern tooling that
developers have come to expect. So rather than working around those pain points, I decided to
address them directly.

Is it also just a fun project? Absolutely. But the frustration was real, and hopefully the result
is useful to others who felt the same way.

This project is primarily aimed at serious developers who want real power and flexibility out
of RPG Maker MZ — people who find themselves fighting the engine more than building with it, and
who want a foundation that gets out of their way and lets them work the way they actually want to.

If that sounds like you, welcome home.

Open Source & Community Driven

RPG Maker MZ Next is a fully open source project, available on GitHub. While it modernizes the runtime under the hood, it fully respects and operates within Kadokawa’s RPG Maker Terms of Service.

This thread isn’t just an announcement — it’s an invitation. This project is meant to be a collaborative effort, shaped by the people who actually use and develop for RPG Maker MZ. Whether you’re a plugin developer, a game dev, or just someone with ideas and opinions, your voice matters here.

Got thoughts on how the runtime should behave? Opinions on the plugin API design? Feature requests, concerns, or just curiosity about the direction — bring it all. The goal is to build something the community genuinely wants, and that starts with this conversation. The repository is open for contributions, feedback, and discussion. Nothing about the project’s direction is set in stone yet, and that’s intentional.

Let’s build this together.

:warning: Plugin Compatibility

Because RPG Maker MZ Next is a full rewrite of the runtime, the vast majority of existing MZ plugins will not be compatible out of the box. This is an expected and unavoidable consequence of two major shifts:

  • The rendering layer has moved from PixiJS v5 to PixiJS v8, which introduced significant breaking API changes.
  • The codebase is now TypeScript and ESM-based, departing from the original global-script architecture that most plugins relied on.

This does not mean your favourite plugins are gone forever. The plan is to ease this transition as much as possible by providing clear migration guides, a well-documented plugin API, and compatibility utilities where feasible. Plugin developers will have proper tooling to port and modernise their work.

If you are a plugin developer interested in getting ahead of the curve, contributions and early feedback on the plugin API are very much welcome.

7 Likes
2

Working on Something similar which I like to call RPG Reactor. Also runs on PIXI8, but was able to preserve backwards compatibility with a compatibility shim that dynamically re-writes function calls to their pixi8 equivalents.

All the main engine stuff is already done and working, but I’m working on what I call “the forge”. A set of tools to dynamically create various assets for the game. Also open source, coming soon!

2 Likes
3

Oh amazing!

I think for my the decision to abandon backward compatibilities was to basically allows for a more Lean restructure of the Engine?

Basically I just didnt want to make a Port of the old code but kinda improve upon it?

Such as Proper Plugin Manager toolings , plugin parameters parsing etc.

built-in animated sprites for both player and sprites

etc.

At the start the compatibility was a thing but the more I was working on it, breaking was bound to happens especially on plugin that rely on Sprites manipulations as pixijs does not support leaf children anymore.

One of the aspect I was working with for Typescript tooling is the support of class decorator.

image
image1069×481 34 KB

it works perfectly fine especially that decorator in typescript can polyfill perfectly fine.

@Psychronic actually I am curious but right now the big bottleneck is the Window Layer class I wonder how did you approach this? as pixijs dont support doing internal GL call?

1 Like
4

Attached is the RPG Reactor Corescript, with compatibility shim in libs folder, check it out for yourself!

RPG Reactor 0.9 - Corescript.zip (642.3 KB)

Long story short:
The fix is: skip the custom GL-stencil render on Pixi v8, let the standard render pipe iterate children.

WindowLayer.prototype.render = function render(renderer) {
if (!this.visible) return;

// v8: render pipe handles children automatically. v8 removed
// renderer.framebuffer.forceStencil (stencil buffer is allocated by
// default at context creation -- see pixi8 `stencil: true` ContextSystem
// init), and renderer.batch is no longer a global flushable batcher
// (each render pipe has its own deferred batcher). Interleaving raw GL
// stencil ops with v8's deferred pipeline also doesn't honor draw order.
//
// Skip the custom render on v8 and let the standard render pipe iterate
// children. Net visual: lower-window pixels under a higher window are
// drawn, but immediately overdrawn -- no visible regression for normal
// MZ usage. v5/v6/v7 keep the stock stencil-occlusion behavior below.
if (PIXI.TextureSource) {
    return;
}

// ... original v5/v6/v7 stencil-occlusion block unchanged below ...

};

  1. Version-detect with PIXI.TextureSource that class only exists in v8. It’s a cheap, reliable feature sniff that lets the same file work polymorphically across v5/v6/v7/v8.
  2. Why the stencil dance is no longer needed in v8:
  • renderer.framebuffer.forceStencil() is gone, v8’s ContextSystem allocates the stencil buffer at context creation time (stencil: true by default).
  • renderer.batch.flush() is gone, v8 has per-pipe deferred batchers, no global flush hook.
  • renderer.gl is gone, v8 abstracts the backend (WebGL or WebGPU), so direct gl.stencilFunc / gl.stencilOp / gl.blendFunc calls just don’t have a target.
  1. What you lose by skipping it: the original purpose of the stencil dance was to prevent lower-window pixels from being drawn beneath the area covered by a higher window (a small fill-rate optimization plus a way to avoid alpha bleed between overlapping translucent windows). In practice, since v8 draws windows in z-order anyway, the upper window overdraws the lower one in the same frame visually identical for typical MZ usage. The only edge case is overlapping semi-transparent windows where the alpha blend with the layer beneath could differ slightly; in real MZ scenes the engine never overlaps two transparent windows like that, so no regression has shown up in testing.

Here’s some screenshots as well, I’m doin’ it!

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

I see! I had a huge bottleneck on this and it is fair that most winders will never really Push on top of each other (at the exceptions of user made window)

My approach I was thinking was to composite the windows using RenderTexture to basically batch and occlude out the windows. Its how most Game framework would do like Monogame where they would do a RenderTexture on Refresh.

I had considerations that might be a little BIT heavy , but by nature windows dont really redraw themself every frame.

1 Like
6

actually is it possible for you to post it as a github repo? I would feel more comfortable to look at it than downloading an random zip. (I apologize for that we cant be safe enough with Scammers/ malware nowadays.

7

Eventually, the only issue is that the project directory while developing it is kind of messy and I got a lot of files/demo projects in it which take up too much space to let me upload to GitHub, but the zip includes just the corescript though (what you would put in your project folder), but not the engine itself.

When I do upload it to GitHub, I’ll let you know, might be a bit though.

Yeah, I think you’ll find that the zip contains no viruses or malware and I’m not looking to scam anybody, I hate scammers too.

1 Like
8

Oh no worries its just basic Cyber security haha. ill be excited to see how well you did as progress!

and if needed u can post just the corescripts on the github (using .gitignore) but no worries!

im happy to see other people interested into making MZ more modern!

1 Like
9

I’m looking at it as a fork of RPG Maker, I’m trying to innovate and add stuff to it that makes it easier and didn’t exist in the base engine, I’m going to be adding tileset layers F, G, H (2048x2048). Additional event commands (like video overlays), 3d controls for 3d animations, etc.

I am not just trying to copy RPG Maker MZ, but trying to innovate it basically as I’ve seen the situation stagnate with the existing company/product. But yeah putting my own spin on things too.

I’ll let you know when it’s on GitHub though when it gets closer, I’m sure there will be something useful in there for you to help with your project as well.

2 Likes
10

I wish you goodluck on that as well!

as for the mapping layer, I would invite you to look into the pixijs new Render Layer system it seems to be quite interesting system. I have yet to mess with it tho.

of course if you already look into it.

I think a cool thing would be the be able to hook custom layers to the SceneMap without having to disrupts its rendering.

I was also thinking to split the camera logic from the GameMap class in its own GameCamera class to help having better control (and possibly pixel movement)

2 Likes
11

I’ve already been doing some of this with custom plugins. For example my multi-parallax plugin lets me have multiple parallax images and set them to z-index based on the map, same with my Video Overlay Plugin, etc.

I agree, let’s do it!

1 Like
12

Clearly, not me.

I have a feeling we have different ideas of what makes development “ergonomic”.

None of your talking points resonate with me at all.

  • PIXI v8? Okay, sure, but does it actually bring any real, concrete improvements over the existing PIXI v5 rendering? And without any downsides, such as rendering plugins incompatible? I don’t really use PIXI directly when working in RPGMaker anyway, so I wouldn’t expect this to impact me.
  • TypeScript, just why? I’m much more at home in pre-ES6 JavaScript (ie, what RPGMaker is written in) than I am in TypeScript. The worst part is that it’s a compiled language, adding an additional barrier to testing.
  • ES modules – unless these work in web builds, there’s really no point. Node modules work just fine if you really want modules (at least, I assume they do, I don’t use them other than occasionally the built-in ones). NPM is also not really something I ever want to wrangle with if I can possible avoid it.

In short, you seem to be focused on “fixing” something that isn’t even broken, which to me sounds like just a waste of time. That’s fine though – it’s clearly not a waste of time to you.

But setting all that aside… you’re not even attempting to maintain compatibility. If this is a project mainly for you personally and you’re just sharing it in case others are interested, fine. But if you’re actually seeking to get other people into it, maintaining compatibility is absolutely key to getting people onboard. No-one wants to switch to a new runtime only to find that 95 out of the 107 plugins they use simply don’t work anymore. Just a friendly suggestion.

1 Like
13

From what I recall, this actually works already in the base engine, with just a few very minor changes. (I was poking around at it awhile back, so this is from experience.) I think it could actually be done as just a plugin applied to the base engine.

14

while I find your tone quite arrogant and rude, I will let it slide.

The reason I created this was mainly from my own interest, curiosity and usage.

PIXI v8? Okay, sure, but does it actually bring any real, concrete improvements over the existing PIXI v5 rendering? And without any downsides, such as rendering plugins incompatible? I don’t really use PIXI directly when working in RPGMaker anyway, so I wouldn’t expect this to impact me.

if you are remotely aware of how PIXI work, it had a lots of performance improvement, QOL improvement, a lots of memories leaks were fixed and OLD weird quirk phased out. and a LOTS of new features has been added that just simplify game development or just development in general.

The reason you never use pixi is because of how rpg maker is Sandboxed making it horrible to even use any of the other PIXI features. GIVEN that pixi v5 is a Clusterf*ck of weird quirk that are prone to erroring.

TypeScript, just why? I’m much more at home in pre-ES6 JavaScript (ie, what RPGMaker is written in) than I am in TypeScript. The worst part is that it’s a compiled language, adding an additional barrier to testing.

Kindly I will disagree, Pre-ES6 is a nightmare to work with its convoluted and to much typing for nothing.

Also I am not forcing anyone to work with Typescript. In the end the released product will be compiled to perfectly normal JavaScript. But if you remotely worked on any bigger project than a little script, you will soon discover that typescript HELP reduce a lots of the pain stake in any bigger project, as I someone who worked on the RPG Paper maker runtime V2 I had to discover this really fast. but if it pain someone so much they can easily just do plugin / extends the core scripts by using plain java script. Its just for the core script runtime development because I am sure hell no trying to get proper typing by using Jsdoc.

Typescript is literally the most basic requirement in modern web development OR web game dev development in 2026.

So right now you just talking your own preferences.

ES modules – unless these work in web builds, there’s really no point. Node modules work just fine if you really want modules (at least, I assume they do, I don’t use them other than occasionally the built-in ones). NPM is also not really something I ever want to wrangle with if I can possible avoid it.

ES modules are straight up just import export there are not even related to NPM in the first place. yes they often point to node_modules but its one of the most basic features in modern JavaScript and can point to literally basic javascript file or can be used in Bundler. (which again is modern JavaScript)

In short, you seem to be focused on “fixing” something that isn’t even broken, which to me sounds like just a waste of time. That’s fine though – it’s clearly not a waste of time to you.

But setting all that aside… you’re not even attempting to maintain compatibility. If this is a project mainly for you personally and you’re just sharing it in case others are interested, fine. But if you’re actually seeking to get other people into it, maintaining compatibility is absolutely key to getting people onboard. No-one wants to switch to a new runtime only to find that 95 out of the 107 plugins they use simply don’t work anymore. Just a friendly suggestion.

Again it was simply born out of pure curiosity and of if you find it being a waste of time sure? stay on the normal rpg maker I am not forcing anyone to use RmNext. I never intended it to be for beginner or casual. It was created for developers that wanted to access Pixijs v8 modern ecosystem for their own game.

As for compatibility being a prerequisite? Not really this just a very toxic mindset that RM user base have. They expect everything to be plug and play with no error, but as someone who was around both MV and MZ release, people were screaming to the sky when they learned they couldn’t plug and play MV plugin into MZ without having to actually port them. Never once, the rpg maker devs cared about backward compatibilities between versions AND HECK if they did the next rpg maker in Pixijs v8 (instead of unity) they would have broke the entire ecosystem and YET again the user base would have screamed. rinse and repeat.

I have thought about proper plugin compatibility supports in the early stage but as you discover what is the change of pixijs v8 you realise you cant just expect to make everything work. Because, the way sprites and container/ rendering behave in pixijs are so god damn different that even if I wanted to write a proper shim layer, it would probably be too tedious to work with.

The way I did to circumvent this problem or at least make it easier for people that want to do the switch or try it out is to keep the API EXTREMELY close to what the original is so they only have to change some of their code.

(Most of the game_object classes are basically the same or at least behave closely to the old one)

The only classes that have been reworked was The Managers to be more like Service locator, but this is mostly my own preferences and it is still in the draft.

and the way that scene are handled as it now use hybrid async loading (as pixijs v8 assets loading is asynchronous)

and how some Spriteset are handled as ONLY container can have children.

fine. But if you’re actually seeking to get other people into it, maintaining compatibility is absolutely key to getting people onboard. No-one wants to switch to a new runtime only to find that 95 out of the 107 plugins they use simply don’t work anymore. Just a friendly suggestion

Yet again, I am not exactly seeking. I am inviting people if they want to work on a project like this. While I am not supra good in English so maybe it was sounding like I was seeking I guess(?).

I honestly just want to share this and let people that are interested participate into it. I couldn’t care less if people find this is a waste of time or not.

Yet if it doesn’t work out, EH at least I learned from it and was an interesting experience. all I am doing is enjoying the ride.

1 Like
15

There’s a lot I could say about your views on TypeScript, but I won’t derail your thread any further.

I want to be clear here. Compatibility is a prerequisite if you want people to use it other than yourself and a few enthusiasts. Most people aren’t going to switch to your RMNext fork if they know their plugins are going to stop working. But that seems to be fine with you, so good luck with it, I guess.

16

I agree that compatibility is important. I don’t really see the value in Typescript personally (regular Javascript is fine), but I do think that the RPG Maker Engine has stagnated and I’m looking to innovate and put a new spin on things (while maintaining backwards compatibility). Currently working on my game (with a lot of plugins). I’m sure there’s some edge cases that I haven’t seen, but able to be fixed as they pop up.

1 Like
17

I think theres a lots of confusion there, Typescript is for the initial corescripts, not for the plugins development. It just make the overall Engine more predictable when developping it. (plus Typing). for plugins people can just use default JS. I PERSONALLY work with typescript for plugins because its basically just offers the layer of security and remove a lots of the error prone issue. but for the corescript it just make senses that its in Typescript to allow to document it fairly easily.

as for compatibility. the rework is still at its early stage so I will see when it arrives but as explained we cant make everything compatible. I am sorry but this is not realistic. sometime to innovate you gotta break some eggs.

and I think the conversation will just drag itself on this matter so its kind of my last message about it.

18

I’m sorry, but… it absolutely is possible to make, if not everything, then at least 90% of things compatible. It’s probably possible to get 100%, but might be prohibitively difficult given that the entire underlying rendering library has been replaced. But if you limit compatibility to the external API of the RPGMaker objects (the Game_*, Sprite_*, Window_*, and *Manager classes, and a few other core classes), it should be totally doable. Though, that doesn’t make it easy or anything – you’d need to actually put in the effort to ensure it stays compatible.

This doesn’t really make any sense. TypeScript doesn’t have anything to make things more predictable. It’s true that TypeScript can, in theory, help you catch errors that you’d miss because you passed the wrong type to a function. But you can catch those errors just fine with a JavaScript linting tool too. TS doesn’t make that any easier. It just changes the syntax you use when you actually do want to specify a type.

Anyway, this’ll probably be my last message on the topic of TS too (at least in this thread).

1 Like
19

This is more nuanced, but it can’t be 100% compatible, jumping from v5 to v8. From v7 onwards, Pixi is async focused (meaning that the code can do tasks without blocking a thread). RPG Maker MZ is synchronous by nature, which means that it would need a big re-write (or work-arounds) to handle it. I had the displeasure of dealing with async-synchronous handling and (at least in JS) it’s a pain to handle this. I had to do a callback, so the custom encryption I made could work for both MV and MZ. It ain’t very pleasant (especially compared to C#'s Task handling).

TypeScript is designed to provide quality of life features (like types, which JS lacks) that allow devs to build better code. As someone who works with both JS and C#, I’d use C# wherever possible, since I know that a variable that I marked as string is a string. JS (at least ES5 and older) don’t have the luxury. There’s a reason most JS devs use TypeScript. It makes it a whole lot easier to make better JS code.

3 Likes
20

It is yes but when it comes to the inner Sprite system / the way it handle things is just different. At least when it come to Parent and child.

(has explained prior) Only container can have children now in pixijs v8. WHICH is by itself is not bad but it does lead to breaking change that you cant really avoid. (in cases like Spriteset)

one of the way I was thinking to approach at least to mitigate the porting issue. was by example provide an Spriteset class that behave similar to how the old spriteset works.

export class SpritesetBase extends Container { 
   
   protected _anchor: ObservablePoint; // to replicate spriteset x anchor behavior
  constructor(){ 
  
  }

}

and said prior. MOST of the Game object classes are similar (to some exceptions)

Windows class behave exactly the same than the prior rpg maker. I just changed the way that windows are built internally AND no one would touch the Core_window.js class

it basically use pixijs inner nine slice sprite system instead of its own.

(it also got renamed to RpgWindow just for avoiding weird clash issue with intelissenses)

The way scenes are rendered are now a hybrid async. but it is built to basically be as simple as it is. it just matter to add await or have the new ImageManager Queue system. which basically replicate somewhat the old way rpg maker load graphics. which blocks the thread.

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

Most of the loading and Bitmap processing is now GPU bound instead of CPU bound.

I have thought about proper compatibility, but tbh plug in play is not that easy. but its mostly just a matter to do this :

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);
}

// in edge cases where  you need to lock the thread. but this is BASICALLY what you would do in older rpg maker

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

SceneMenu.prototype.checkIfSpriteIsReady = function() {
 if(ImageManager.isReady()) { // AS LONG that imageManager is loading it wont do anything.
 // do the thing blabla
 } 
}

the API is MOSTLY the same but if people had plugin that does this :

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

then it will error out. theres no way to fix this matter. this is how pixijs V8 works now.

you would have to fix the issue with this :

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

all to end I did think about how to fix the frictions but you can only do so much.

1 Like