Postmortem 5 - Learning MZ

Learning MZ

Ever since I joined this community nearly two years ago, there's been an ongoing debate between RPG Maker MV, and RPG Maker MZ.

At first, the debate had some genuine merit.

MZ was only around a year old, and it had quite a few differences from MV.  For starters, the animation system was completely different, utilizing Effekseer instead of the in-engine animation software. Furthermore, after the controversy that occurred near the end of Yanfly's career, Visustella (the sort of "neo-Yanfly" replacement for MZ) went the route of obfuscating all their plugins, alongside placing a paywall (the latter of which I feel is certainly well deserved, but I'll touch on that in a sec). The obfuscation meant that these plugins really couldn't be altered for whatever reason, and making new plugins based on these engines would also be extremely difficult without being able to read the core functions. Lastly, Visustella changed the way Action Sequences worked, making them run through Common Events rather than pure text notetags.

All these changes are reasonable to a degree, but changes that affect me personally. I rely a lot on pixel perfect animation and am a bit of a purist, so Effekseer animations replacing the old system would add difficulty in retaining pixel perfection. I can get very ambitious with my game mechanics which often demands I make edits to plugins (or even just edit plugins for compatibility, such as needing to scratch out some code to make SRD's Summon Core compatible with Yanfly's Battle Core), which obfuscation wouldn't allow. And the changes to action sequences were a mixed bag for me. On one hand, they looked much cleaner and were much easier to look at and follow, as well as being slightly more flexible by operating on the editor rather than their own code system. On the other hand, this new system basically made it impossible to write up action sequences in something like Notepad or a Google Doc, and sharing those action sequences with others was much more impractical.

So, while I never blamed anyone for using MZ, I had decided it probably wasn't for me. It felt limiting, compared to MV where I had free reign over just about every system in the engine. However, despite this, there was a common insistence that MZ was a superior engine.

And that's the funny thing, MZ really is.

MZ started out the box with all kinds of features MV users would benefit from a ton. Baked in ATB/CTB, an event list on the main UI, a move route preview for events, and even stuff like Effekseer is really much stronger than the default animation software. Later on, MZ was even updated to support MV style animations, and even the option to change the game's tile size from 48x48 to other options which, needless to say, is a very big deal. Not just that, but I was actually wrong about Effekseer too, later discovering that it did have native pixel perfect support, removing the one big gripe I had with it over traditional MV animaitons. I can safely say now that MZ in a vacuum is an objectively better software than MV.

The tile size thing in particular was a big eyebrow raiser for me, personally. Working on Axial, I've constantly struggled with "pixel perfection". The game's pixels are actually all upscaled 3x their size, which makes the file size larger than it needs to be, and causes annoyances like text boxes cutting off mid-pixel or certain animations not quite lining up. I've been able to remove most of these issues (I'm most proud of my changes to Mog's Weather Effects plugin which I altered to snap to the 3:1 grid) , but some things were just impractical to change, and the frustration of not having true pixel perfection always irritated me (even if 99% of my players never even noticed). So, the promise of being able to reasonably create games in the native resolution I desired was extremely appealing to me. Now everything could be pixel perfect, because every pixel was just one pixel!

Not just that, but VS made plugins with features I wish MV had, such as the Bravely Default system I mentioned in the Combat postmortem. So, I decided at the very least that I had warmed up to MZ. I would wait for it to go on sale, pick it up, and then for my next game project (likely a jam), I would try it out and give it an honest shot.

And then Christmas came around and Human bought it for me!

Haha, thanks for saving me some money, my friend!

So at this point I was locked in for Harold Jam. I had already planned on giving MZ a shot, but now that my buddy Human had bought it for me, I had no excuse, both because I now owned the software, but also because I felt I owed it to him to make use of the gift he gave me. So, when jam season started to approach, the very first thing I did was boot up MZ and try to get a feel for how it worked.

It was... not what I expected.

A big issue with MV and MZ is that both programs are relatively limited on their own. They're designed with the expectation that the user will edit the code to their wishes, either through their own programming skills or the help of other users (e.g. YEP and VS). So, what this means for me as a layman with only rudimentary programming abilities is that the value of either software is heavily dependent on community support. 

And the first thing I noticed working with VS is that it's a lot to take in.

On one hand, I really appreciate how its params work. The obfuscated code means it's impossible to go into the notepad and edit each window to your liking, but the params are now completely open, allowing you to freely edit the literal scripting that defines aspects like window size or parameter effects. It goes without saying that I think this is a huge plus.

On the other hand, it's a bit too open. Editing any parameter, no matter how simple, requires at least a small amount of Javascript knowledge, and while I have the chops to make those changes, sometimes opening up a param and being greeted by a very finnicky code block was daunting. Even worse, I couldn't find any immediate way to "reset" a plugin without nuking my entire plugin file. So, any changes I made needed to be clearly documented so I could reset them at a given notice.

I think this sort of freedom is more positive than negative for a large scale game. More freedom is an objective good, and if users are to be stripped of the freedom of opening the code, at least this gave them a lot of the flexibility they might want out of that code. On the other hand, for a time-sensitive small scale project like a game jam, this was quite the time sink, especially when there were still a lot of freedoms that weren't afforded to me. Furthermore, VS's plugins contained a mix of a ton of the features from multiple YEP plugins, making organization and searching for specific features needlessly complicated and difficult. I found myself really missing Yanfly while working with VS, and not just out of familiarity (although there was certainly a level of that) but just out of the sheer ease of use.

Alright, but what about that pixel perfection?

I decided early on that I wanted RATD to have a Game Boy Color aesthetic. This was a practical choice, but also fueled by my desire to try out that sweet sweet 16x tile size. So, pretty much the first thing I did with the engine was try to make it line up with a 160x144 resolution (the Game Boy Color's screen size).

It didn't work. At all.

I tried for days to get the resolution to display literally anything properly, and it just wouldn't budge. It was just too small for the engine to handle, even when I hard-coded the window sizes and icons. I asked Moogs, a fellow expert of retro style games, how he would approach it, and he told me that 16x worked just fine for him in other resolutions, so simply put, the GBC screen was just too small. It's possible maybe I could get it to work, but I didn't have time for that.

So one of MZ's biggest features for me personally was now bust.

BUT it wasn't all bad! As much as I desperately wanted to return to good ol' Yanfly, the fact of the matter was that VS had quite a few plugins that YEP did not, and these plugins were essential to making RATD work.

The biggest one was Skill Containers which made the Prefix system work very elegantly. For MV I had planned on utilizing a mix of Axial Sub Commands and Passive States to sort of "force" the prefix/suffix system, but it was clunky and not very fun. Skill Containers gave me exactly what I wanted: you use a Prefix, and then you can choose a Suffix, or go back if that's not what you wanna commit to. 

There was that dastardly paywall, but I decided a $5 concession wouldn't be a huge deal for a game like this (I paid $5 for a plugin last year for Re:Punch as well, and unlike that plugin, this one actually WORKED). 

BUUUUT there were other features that were behind much bigger paywalls that I wanted. VS's Shop Common events was a big one, as one of the biggest complaints I had gotten from testers was the shop system in RATD feeling, just... bad. But that plugin cost $15, a much bigger commitment for a software I really only planned on using for small title as this point. 

Eventually, I just evented the damn shop myself using common events, but I'll concede that making the shop work properly was only possible with VS's message core, so I won't act like they didn't contribute to making it work for me.

I also got to try out Action Sequences.

And I'll admit, they're actually pretty nice. I still think I prefer the old way, largely because there's a lot of Common Event bloat here and not being able to just type this stuff up in notepad is pretty annoying. Still, they work well and are easy to copy and paste in-engine, and I can't deny that they're much easier to edit in the editor than in MV's puny notebox. I think I would honestly prefer some sort of fusion of the two systems, with an option to manually edit the text or insert the AS into noteboxes, while also having the CE option when I want it. Those who prefer the pure Common Event approach are completely valid, and for RATD it served its purposes well.

However, ultimately, MZ isn't quite for me.

I'll keep using it as needed, of course. MZ excels for smaller games with a time crunch, especially if you've already gotten the hang of navigating the plugins. However, that obfuscation is honestly make or break for me. I've had to make so many changes to Yanfly's scripts to suit my needs in Axial, and imagining pouring years of work into an MZ project only to be royally screwed when I hit a dead end due to some obscure incompatibility frankly terrifies me.

Furthermore, the paywall, while again justified, makes it difficult to "shop around". I pay Yanfly a monthly subscription on Patreon for their whole suite, both because they deserve the money and also because it's just easier having the whole plugin suite at my fingertips. If I try out a plugin and it doesn't suit my needs, the cost is nothing. For VS, however, having to pay either a couple bucks for individual plugins, or a much larger sum for packs, is a much bigger risk. I will not act like these plugins are not worth the cost, they totally are, but some plugins (such as Olivia's Aggro plugin) just don't work, or might be incompatible with a different plugin I need, or have alternatives that suit my needs better. For a lot of these plugins, it's more cost effective to simply buy the plugins you need as you go rather than paying for the entire suite outright, but the result is that you have to take a gamble every time you pick up a new plugin. It's a hard sell for me, for sure.

But on the flipside, I'm in a sticky spot, because VS has features that I would really love to use in MV. That sweet, sweet Bravely Default system has taunted me for months ever since I saw how Moogs used it. I want so badly to use it in a huge game with lots of skills to mix and match, but alas, MZ is not cut out for Sawyer-type games. At the moment, I've concluded my best option is to just learn how to make a system like that myself and inject it into MV, but it's such a painful concession knowing that the easy way out is sitting right there, but that it's an extreme risk when I have to commit to an engine (or, really, a plugin system) that feels so restrictive.

So, all in all, I do like MZ. It was very comfortable to use for the most part, and VS has some great plugins MV just doesn't have. However, for the time being, I can't use it as my main engine. Small games are great, but anything ambitious is just too risky.