Rpg Maker MZ Next : The modern rpg maker MZ framework

This isn’t true in a general sense. In fact, the RPGMaker engine is pretty asynchronous in nature. There are several systems where you “schedule” something and it “runs on the next tick” – for example the battle log, or the event interpreter.

That said, here we’re talking about the rendering specifically, so perhaps that part of the engine is synchronous.

JS does not lack types. It knows what a number is, and it knows what a string is, and you can ask “Is this a Game_Actor?” just fine. And this isn’t something new in ES6.

If you just put the underscore back in the class name, wouldn’t the old plugin work just fine with no changes?

Can’t this be kept compatible just by making Sprite be a Container? Is there some technical reason it can’t be a Container?

I don’t know how many plugins actually add children to a Sprite, but I think the core engine does this, so I guess the number likely isn’t small.

Lemme put it this way: If I gave you a variable, with as minimal context as possible, would you figure out what type of a variable this is? In JS, variables can be anything. Heck, you could suddenly replace it by mistake.

In MV, I caught the engine freezing for a bit every time it was saving. And that’s because it had to wait for NodeJS to write the file. And since the engine didn’t have a way to put it in a background thread, it had to halt. MZ does handle it better, but it’s still a pain without async/await.

1 Like

I’ve already built it, the way that I do it is that if a command name was changed in PIXI8 or it’s handled in a different way, the compatibility shim will account for that with no plugin rewrites necessary, but if you wrote it in the PIXI8 way, it would still work. It makes the plugin agnostic to the PIXI version, the only downside is that you might have people writing what would normally be half-way compatible code and have it still work. So they might “Write it wrong” but it works, etc.

There’s some functionality that RPG Maker uses in PIXI5 that was literally taken out of PIXI8, but there are ways to translate it in real time to do the right command the right way without breaking compatibility with older plugins, the key is to make the plugins agnostic to PIXI version, but yeah it required a compatibility shim. I tested with my game (that has over 100 plugins) and it’s 100% backwards compatibile, although I had to do focused fixes for SOME plugins (as I see them), but definitely doable. Excited to release RPG Reactor, I’m just putting the polish on it right now.

If anyone wants to beta test it, let me know! I’ll send a zip.

On the Javascript thing, I think the need for strict typing is overblown/not much of a concern. If I accidentally declare a string as an int and it doesn’t work, that’s on me I guess as the developer to figure it out when I make a mistake.

2 Likes

I could yes I just tend to prefer Pascale case for class name (old programming habit) but this is 100% douable to keep the name with underscore.

As for Sprites being a container its just kind of a weird aspect. and if we would make RM sprite container u would actually lose anchoring and would need to use pivot point (a paint in the ass tbh)

but the reason on why pixijs made that only container can have children is basically to Reduce the complexity of the scene graph and make it more performant.

(dont get me wrong this is a weird design choice by the pixijs devs)

and for TS this is bound to just preferences at this point.

as for the Shim compatibility layer, ill see how to do it in a later date. this is definitively not something I know enough in depth to do. I know how to code I never said I was a wizzard lmao. in the first place its porting the code to see if Vanilla project without plugin works fine.

Also yeah I’m not that good at writing code (good at reading it though). So with AI I’m able to just like look at the code, I can see what the problem is and I have the AI work on it or I’ll come up with suggestions or ideas of how to solve it, etc. and then it just churns away, and I was surprised at the progress (in a good way).

But yeah the AI thing has really been empowering for me because I’ve always been ok at reading code and recognizing what it does (and I understand how a computer works, the various parts like ram, CPU, GPU, Networking stack, Databases, etc), but not that good at writing it at all, the reason for this always came down to syntax stuff, or not remembering the name of a command and have to look up everything at every step, and then it was just like too tedious, but that part is kind of gone now, so I thought I’d figure this out for fun while learning the new tools. So that’s my perspective anyway. I’m no wizard either! (in terms of raw coding ability) hah.

But it’s interesting getting into the weeds and finding out there’s all these different “programming styles” and everybody’s got strong ideas about what’s good and what’s not, no matter what. Learning a lot though and having fun!

Actually, it is possible to use Pixi 6.5.10, as long as you fix up the shader that handles the tileset.

1 Like

Yeh I remember trying to swap it, I think most of the code is fairly similar.

@Marix sadly I can only touch the runtime not the editor itself

One of the implementations that I plant to do for plugin developper and removing the need to do protototype patching for new function and proprieties and more

If you need to inject new method and new field

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

/// will automatically hook new function and proprieties
//PluginManager.mergeClass(StatsContainer, MyCustomsStatsContainer);

if you need to overwrite / alias function. (but can also add new function with the extends decorator)

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

Both works and this isi still a work in progress API.
and it might be merged into an APi that looks more closely to this :

@PatchClass(Game_Party)
export class MyCustomPartyExtension extends Game_Party {
  
 public myCustomField : number = 10; // WORK perfectly fine and will be added normally.
  public override maxGold(this: Patched<Game_Party>): number {
    console.log("Modifying gold limits...");
    
    // Instead of super.maxGold(), they call this.super()!
    return this.super() + 5000; 
  }
}

I do want to point out those are optional plugin dev tooling and are not forced upon developpers.

and knowing that decorator are not yet fully supported for Javascript (but is in typescript) I will like to kindly point that you can easily access them via the plugin Manager

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

It’s 2026, so breaking compatibility with the ancient 2020 MZ runtime to get an up-to-date rendering backend is a pretty good deal. When this is completed, it would be like a new version of RPG Maker minus the editor.

I’d rather use pre-ES6 JavaScript too, but TypeScript is popular and there’s excellent tooling for it, so it’d end up improving the development experience for many. It’s a very defensible choice.

Oh, the MZ game engine is pretty broken and outdated.

2 Likes

I got the editor covered (RPG Reactor). Also got an updated runtime that is PIXI8 but also totally backwards compatible (minus a few edge cases for things I haven’t tested for). Excited to get it out there.

You say that, but you also said:

So I won’t be holding my breath.

Lets not start a fight lol

It is for sure a project mainly focused on the Runtime, even if they are quite lenient the editor is still a product owned by GGG. Runtime is a little more free on that. especially I am mainly just providing improvements and stuff.

As for my stand on AI, while I do agree that ai can help i will appreciate that participating people avoid to just full generate codes and push Pull request to the repo . At least not without Throughout Test and make sure that it respect the spirit of the rpg maker.

ill try to wip out a code expectations form later. because I do w ant to keep consistency.

Oh yeah I totally use AI for coding (a lot of developers do), and I know my programming fundamentals as well, not just vibe coding stuff. It’s totally the next stack/next way that development is going to happen going into the future.

I know that a lot of people in the game making community are out of date and openly hostile to digital power tools, and even if the output or the product is good, anything I say will be instantly disregarded or ignored irrationally/out of hand/unfairly.

I know that when I honestly disclose AI use and am totally sincere and try to tout it’s benefits, and provide proof, it gets used as a weapon against me to discredit me or disregard what I have to offer out of hand, when all I’ve ever wanted was to contribute to the community, but the community has always just been awful/atrocious and unwelcoming. I’ve been on the RPG Maker since the 90’s. The community used to be cool but back around the 2010’s it started getting lame, and it’s worse than it’s ever been, currently. The Community actively discourages projects from actually getting done. It sucks.

But I don’t care what anybody thinks of me. I’ll build it anyway.

Tell you what…I’ll prove it.

While I’m still putting some polish on it, this is what I’ve got so far, why don’t you try it out and let me know what you think? My current game in the zip (the project file to open) is Star Shift Freelancers, I’ve included it in the zip with the PIXI8 runtime, and the editor itself as well. Currently new project wont work in the editor, but opening an existing project should, so I included it in the zip.

Formerly an MZ game with lots of plugins that I’m still developing that was able to make backwards compatible through the compatibility shim and PIXI8 runtime, and it works. I put my money where my mouth is.

But guessing that nobody’s even wiling to look at it, even if it works. It’s like people think I’m lying or trying to fake it til’ I make it or something. If I was going that route, I would have just said it was all me, that I don’t use AI for anything, but I’m being honest/sincere.

In the future I’d appreciate not being disregarded out of hand and actually being taken seriously. I am always willing to provide proof for any of my claims. I’m always cool to collaborate and share with others too if anybody sees value in the work and wants to work together.

Anyway, here’s the link, hopefully give it a shot and let me know what you think, still not done yet, but very close. It’s functional, it’s not theoretical or “someday”, it’s already working.

This is the Windows version of the app, but it also works seamlessly on Linux and MacOS if I build the package for those platforms (I’m on CachyOS myself):

Alright I would prefer this to stay on topic of rpg maker Next, your conversation can be kept to private.

I am all for open conversation but at this point its just derailling the thread.

1 Like

Ah yeah, that’s what I thought (straight jump to blocking/censorship/hiding of conversation).

It’s actually not derailing the thread because it’s a related project and we both want the same thing, the natural course of action is to work together so that this can get done/put into overdrive.

I’m not competing with you. My editor can use multiple runtimes, so there’s some overlap here, and as you said you don’t have the editor/access to the editor.

I’m keeping the post up, but the thread has drifted. @Psychronic the project sounds interesting and I think it’d do better as its own thread where people can find it, rather than getting buried in here. @niokasgami suggested the same earlier, so feel free to start one and link it back so folks can follow over.

Thanks!

1 Like

Ok, sounds good, it’s up:

1 Like

one of the new change under the hood for rpg maker next is the rework of the bitmap API.

it basically work the same at the exception of it being async when trying to load a new texture.

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

bitmap.on will now replace .addLoadListener for a native Event emitter

bitmap now also use internally a PingPongBuffer to allow performant GPU operations the entire API is now GPU bound instead of CPU bound.

It is accessible with :

bitmap.buffer

BaseTexture has been renamed to textureSource to match the pixijs v8 naming scheme.

it is actually possible to both access the texture and its textureSource.

the Text rendering has yet to be implemented as I am still experimenting with text to see how the Pixi js implementation deals with it.

2 Likes

Update!

Window Implementation.

So I have been hard at work trying to do the port, and I have met a curious bug.

It was the implementation of the window class. I met various issues with it, one of which was that it wouldn’t render.
I am still debugging this aspect to see why it doesn’t show, but as I was debugging the show issue, I noticed that I wanted to use PixiJS v8’s NineSliceSprite implementation to manage all the resizing parts of the window instead of the way that RPG Maker manages it.
However, due to how RPG Maker formatted its texture for window.png, the default PixiJS NineSliceSprite implementation causes the d-pad to bleed into it.

And sadly, you can’t just poke a hole in the NineSlice sprite, nor do I want to change the resource format.

So my solution to this was to create a custom implementation similar to the old RPG Maker way. But instead of hardcoding it, I was planning to create a reusable Pure class for it.

Named: SpriteFrame
The purpose of the class will be similar to NineSlice but with a hole in the middle.
Usage:

  const texture = await ImageManager.loadSystem("window");
  const border = 24; // or can be an object

 
  const frame = new SpriteFrame(texture, border, rect); 
  frame.setBorder(border); /// can be set via a command

With this, you can easily have special MZ window frames. It will automatically compute the size and position of each corner of the frame. HOWEVER, it is also possible to manually specify the coords.

2 Likes

Another update:

I have figured out the issue with the window system.


It now works!

However, the reason why it wasn’t working was due to how the new Bitmap/Resources loader now proceeds.

In the old RPG Maker, you could do this:

 const bitmap = Bitmap.load("url");
 bitmap.addLoadListener(callback);

which allowed you to listen to the function.

I intended to add an event emitter to the Bitmap class with the function:

 const bitmap = await Bitmap.load("url");
 bitmap.on("complete", callback);

but due to the async nature, it always completes and the thread is always locked. It is based on promises, so complete always fires once you subscribe. This is an issue in some areas, such as the windowSkin.

The way I found a fix for this issue is this:

  set windowskin(value: Bitmap) {
    if (this._windowskin === value) return;
    this._windowskin = value;
    // because of the nature of PixiJS being async and the new Bitmap API, we use a *once loaded* approach
    value.onceLoaded(() => this._onWindowskinLoad());
  }

onceLoaded is a function that checks if the Bitmap is ready to be used, and if it’s not done loading, it adds it to the event callback stack.

However, I know that in some cases, people might want to listen to a Bitmap loading.

How would you suggest I approach this? I could remove the EventEmitter in this case, as it’s not very efficient, since generally Bitmap loading is promise-based?

1 Like