Why Certain Plugins Wont Be Ported

From Yanfly.moe Wiki
Jump to navigation Jump to search

Welcome to the wiki! This is where you can find resources from Yanfly.moe, Ækashics.moe,
VisuStella, Caz Wolf, Fallen Angel Olivia, Atelier Irina, and other affiliated content creators.

Yanfly.png This is an article written by Yanfly.


VisuMZ NoPort.png

Ever since I've started the VisuStella MZ team to port over the Yanfly Engine Plugins library from RPG Maker MV to RPG Maker MZ, I've been getting lots of questions about porting over some very specific plugins.

And for some of those plugins, there are no plans in the making for porting them over. The ones I'll be talking about are the following:

There are some more, but let's talk about the ones listed above specifically.

The Answer

Short Answer

Because of three main reasons. They can be at least any of the two (but usually all three) of the reasons listed below:

  1. They have incredibly low usage rates based off analytics.
  2. These are plugins/features with high levels of incompatibility. Even within the same library.
  3. We are on a budget. The money is better spent elsewhere on plugins/features to port over to maintain with higher traction.

Long Answer

Low Usage

The plugins that won't be ported over have incredibly low usage rates compared to the rest of the library based off analytics.

For those wondering where I am getting these analytics from, it's based off individual download quantities per unique user from my webhost tracked and powered by Google Analytics. These are also counted in tandem with the individual plugins' download quantities from itch.io when the YEP plugins were still up for download individually. Furthermore, these are also tallied up based on the amount of plugins I've seen in RPG Maker MV projects that I've downloaded (over 400 of them) from the community and mainly, from Patreon members that shared their projects with me during development. Yes, I kept track of each project I've downloaded and saw. Why? Because data is important to me to know what you guys are using so I know where to put my focus and improve things.

There's a potential argument that this isn't a large enough sample size to determine what actually gets used and that the numbers can be flubbed and tilted compared to outside numbers that weren't recorded. Yes, this is true. However, I'm narrowing the focus to the projects I've downloaded from the past and putting more weight on those from Patrons for a reason. It's because those members have willingly came up to me and showed me what their projects are like. This tells me that they cared enough to stand up, amongst the crowd, to show me that they are the consumer-base my RPG Maker MV plugins helped service and that they treat this as seriously as I do.

And, yes, some plugins are going to have higher or lower usage rates depending on when they were released, but all of the listed plugins have been created within the first year of RPG Maker MV so by then, they should have a larger advantage compared to the "newer" plugins released at a later date. However, they don't. These are plugins/features that still lagged behind despite everything else.

Some people argue that they hear so-and-so plugin being talked about all the time in the community (aka their local Discords). However, those members are often the minority. The numbers from the analytics are a far better reference point and reliable metric than how often something is talked about in a community and far more measurable. I'm sorry, vocal fans, but I'll be trusting the numbers.


Part of the reason why some plugins are more "popular" than others is because of how mechanically driving they are in the first place. However, because they're so mechanically-driven, they often come with lots of incompatibility due to how the RPG Maker core scripts work at base level. These include things like needing to completely rewrite functions, override game flow, and even change up how the game's database works as a whole.

But even then, giant systemic changes like that won't be enough to stop us from creating them unless they were super disruptive. Instead, what will stop us from creating this is if they would completely block out or hinder future compatibility with other plugins because they would change the system up to the point of it being unrecognizable.

I don't know how much that means to non-programmers, but you can think of it like turning a car into a boat. Yes, it can be done, but is it practical? The answer is "no".

Plugins like that would require so much maintenance time just to be made compatible with an ever-increasing library size that it is simply not worth the trouble. This is not a matter of being lazy. This is a matter of playing smart. How so? Because those plugins reduce the amount of time that could be spent on the production of new plugins that benefit larger groups of people as a whole.

The argument I'm often given is, can't I just expand the team size to have more maintenance done for an ever increasing library? No, it doesn't work like that. Each time a new plugin gets made, it doesn't expand the number of potential conflicts for all related features by 1. No, it doesn't do that. It expands that number by an exponential amount for related features due to all the possible combinations. That's why, whenever we are going to create a new plugin, we need to consider the potential conflicts first and create around them, or else, it creates spaghetti code that will hold everything back.

Is any of that worth it? Especially for plugins that have low usage rates?

The answer our team unanimously gave is a resounding "no".


For those unaware, VisuStella MZ's team is made up of plugin developers who get paid. These developers port over plugins, refine them, ensure they're compatible with the rest of the RPG Maker MZ library, and then maintain the plugins whenever bug reports are made or upgrades are needed. Naturally, individuals who do all of that aren't going to sell their services for cheap and are given a salary to keep the library growing and thriving. If they don't get paid, these developers would soon leave and look for jobs elsewhere worth their time.

There are also some who seem to be under the impression that since we're selling the plugins, we have unlimited money coming in. This is not true. Far from it. A "business" that runs off selling RPG Maker plugins of all things have an incredibly specific niche and that niche is small. To the point where we need to budget ourselves in order to make sure we last the next month.

Therefore, we need to put focus on plugins that actually have a track record of being used and by those willing to pay. This is where the analytic data comes in and why there is extra weight on the games made by Patreon members.

Furthermore, these plugins need to be sensible in their maintenance costs, too. Yes, maintenance has a cost because it requires time spent on them that could be allocated elsewhere. A poorly maintained plugin will result in bugs. Bugs result in more bug reports. Bug reports are sent and then fixed by the same team members that could be developing the library elsewhere. In other words, a badly selected plugin will not only fail to generate capital and fail to build the library, but instead, drain finances. These plugins offer negative value to the team and library.

Specific Plugins

This section will focus on specific plugins and why there are no current plans in having them ported over to RPG Maker MZ.

Selection Control (YEP)


This is probably the one that seems to be asked the most. Naturally, the response is, if it's asked the most, why isn't it being ported over? That's because the numbers tell a different story.

For those unaware of what the plugin does, Selection Control allows the player to switch skills or items from single target to all or vice versa. It can also toggle between ally and enemy. More complex features include limiting the target selection to specific conditions such as only enemies affected by poison or what have you. All of this sounds highly useful and all, and I don't disagree. However, it had incredibly low usage rates amongst the rest of the library as a whole.

The Selection Control plugin was released within the first half year after RPG Maker MV's launch. Therefore, it's had plenty of time to build up its numbers. However, that was just one thing that never really happened. As it turned out, the majority of the projects sent to me or I've downloaded that I've looked through rarely contained the plugin. About maybe 1 out of 20. The ones that did have it only used it for a few of the features, telling me that the features aren't terribly important for their gameplay. And, upon looking at the way their games are designed, it makes sense.

Only a few features are used from the Selection Core. They are the ability to switch targeting from enemies to allies or vice versa. This is "useful" in dealing with Undead enemies. However, what percentage of the enemies in your game are undead? And is there a benefit in actually using resource costing healing spells to take care of the undead random encounters versus basic attacks which they will be defeated by all the same? When facing undead bosses, players are also more likely to save their healing for their party members rather than using up their resources against the undead boss when regular attacks deal damage all the same. The actual usage cases and "need" for this can be easily dismissed in favor of something else.

The other feature typically used from Selection Core is the ability to switch from single target to all. This makes a single target Fire spell suddenly able to target every enemy at reduced damage. However, the reality of this is, adding in an extra spell that does the all-targeting would accomplish the same thing. Not to mention that once players are given a spell that is automatically tuned to be an all-targeting spell, they would usually use that over the toggle-able single-target/all-target spells because it's just simply tuned better to do the job.

There are some edge cases where people actually used things that made it so some skills would only target specific allies or enemies with certain states. However, those cases are rare and the solution to remedy them is simple. Adjust the skill differently. Instead of making the skill affect only targets with specific states, make it a generic effect that has a bonus effect if the target is affected by the state via Action Sequences. The same goes for skills that cannot self-target the user but can target other allies. Increase the effectiveness of the skill towards other allies and not if it's against the user itself.

On top of all of that, Selection Core has also been the culprit of a lot of incompatibility problems across the YEP library and outside of it. Main reason being is because actions (skills and items) were never meant to be able to toggle and switch their targeting range in the first place. This caused a lot of problems, ones where I spent more time fixing them than expanding the library in a more meaningful way.

Normally, giant systemic changes that cause incompatibility problems are not something that would stop me from wanting to add it to the library unless it's super disruptive, but when the usage rates are that low and the incompatibility rates are that high, that means the very addition of this plugin will chip away at our budget for simply maintaining something that very little people get actual usage out of. Once again, the VisuStella MZ library is maintained by a group of paid plugin developers so we have to consider the amount of time that needs to be spent on a plugin's development and its future maintenance costs as a whole.

However, for that very reason, it's why we introduced plugins like Skill Containers VisuStella MZ for RPG Maker MZ to let you list variants of the skills in order to let the player select different targeting options. By pick Fire, the player can gain access to Fire (vs Foe), Fire (vs All Foes), Fire (vs Ally), or Fire (vs All Allies) should the game dev wish to do such a thing. This not only gives the player options on how to use the spell, but reminds them that such options exist, whereas in the games that had such flexibility in the first place it's easy to miss the fact a toggle is even available.

Row Formation (YEP)


Just like Selection Control, Row Formation is another plugin that is vocally suggested by what seems to be a lot of people. However, just like Selection Control, the actual usage numbers are very low.

On top of that, there just aren't that many games that benefited from it much at all. Where Selection Control saw minor usage in maybe 1 out of 20 games, I recall counting only 8 instances of Row Formation ever in the entirety of the projects I've downloaded from Patrons. From non-Patrons, maybe another 4 instances of it being used, too (and let me tell you, those 4 users were loud enough to make it feel like an entire Discord server uses them).

In one of them, Row Formation was used to perpetuate specific uses of skills and states and mechanics, but it was all too much to follow to the point where you can't do anything in each battle without moving to a specific row to use a skill that'd go on cooldown forcing you to waste another two turns moving to a different row and using the skills available there. The battles in that game just did not respect the player's time.

For the rest, Row Formation was used as a background mechanic that players could easily have not dabbled in and would have been fine regardless. It was just not a meaningful addition in most games. Some would argue that this background flavor's a fault of the game devs but I beg to differ.

I would argue the concept of changing rows just don't add much meaning in a traditional JRPG battle system at all. Yes, the player can put the squishies in the backrow and the HP sponges in the front row, but how often do players change it up? How often do they drag that squishy back to the front row and push the HP sponge to the back? Almost never because in the traditional JRPG battle system, spatial distance is not a major contributor to the mechanics of battle. Doing it for one or two specific boss fights with unique row-altering mechanics doesn't quite count either since it's not the norm but rather the exception. Simply put, when there is no need for a spatial distance factor in battle, the whole concept of rows fall apart, regardless of the plugin developer or game developer.

Incompatibility with in-library YEP and outside plugins is also another major factor. A lot of conflicts had to be resolved with Action Sequences in order to even get the Row Formation plugin working nicely with slick animations. This ranges from anchoring home positions, animation placement, sprite attachments such as gauges, and even more. In short, the incompatibility problems just suck to deal with.

So like Selection Control, Row Formation faces the problem of low usage, high incompatibility making it hard to justify putting our budget towards. The mechanic itself, as a whole, is also hard to justify giving as much attention to due to its trivial and forgettable nature.

If your game is the one who manages to use the Row Formation perfectly and draw out every aspect of it, then I would say to pat yourself on the back since you're the exception to the rule. However, as the team director for the plugin development team, I have the apologize, but I find it extremely hard to justify spending resources and time to create the plugin for a single game project out of the tens of thousands. This is where we would suggest going to the official forum's classifieds section and finding someone develop and maintain such a system for you.

Area of Effect (YEP)


Even lower usage rates than Selection Control and Row Formation. However, unlike the other two, there wasn't as many (if any) incompatibility issues. However, the problem stemmed elsewhere.

What this plugin does is it allows some skills to target an enemy and strike nearby enemies in an area of effect (thus the name). Sounds good on paper, but in practice, it's pretty forgettable and adds little meaning to the games that use it as a whole. Why is that? Because for the majority of the RPG Maker games that utilize the traditional JRPG battle system, spatial distance doesn't matter. When spatial distance doesn't matter, there are usually no skills that influence where a player or enemy battler will be on the screen. And since enemies don't move around while they idle, there's no way for players to wait for the perfect opportunity, too. So instead, they're just lined up neatly in on their own sides of the screen without ever giving AOE skills a chance to shine throughout the battle.

As a result, there's no way to influence whether or not an AOE attack would strike multiple enemies or not. Instead, it's just based on how chonky an enemy is and how uncomfortably close to another that enemy is in order for an AOE skill to be able to strike them. This is all outside of the player's control.

Normally, this plugin would pair nicely with the Row Formation plugin as long as the player has access to skills that can shift the enemy's row and put enemies into range, but the moment the player gains access to an All Enemies target scope skill, AOE skills are dropped in the blink of an eye in favor of that, causing both plugins' effects to be useless and contribute little to the game overall.

As a result, I told the team to focus on something else.

Item Core (YEP)'s Independent Items


Unlike the plugins mentioned above, Independent Items saw more usage (although still not as much as what some people would think). However, the large amounts of problems that came up with Independent Items made me not want to deal with them ever again even if I were to sell an extension plugin that enabled them for $1000 each.

For those that don't know, Independent Items are items, weapons, and armors that can be altered and have their changes remain there permanently. A Longsword's stats can differ from another Longsword's stats while still being from the same base item. This works completely different from how items, weapons, and armors work normally in RPG Maker as a whole. Normally, items, weapons, and armors all have predetermined stats and these stats would never change nor their effects. As such, to get Independent Items working, a lot of things had to be changed, including how items, weapons, and armors worked and how their data was stored.

However, for these changes to happen, a lot of other things had to happen, too. Items that can be modified cannot stack. Items that can be modified should not be a part of crafting ingredients. Items that can be modified need to be stored within the actual save file itself. To me, as a programmer, I thought all of these made sense. But, to users, I was constantly bombarded with the questions on why the modified items couldn't stack, why they couldn't be a part of crafting ingredients, why their save files are so big, etc. These questions lasted to the end of YEP's life cycle.

Another thing, Independent Items users typically had their own ideas on how to handle item modification, too. I'm sorry, but there's no way to account for all those possibilities and still keep the plugin general purpose, especially since a lot of them (the requests/suggestions regarding Independent Items) are edge cases. Upgrades were originally meant to be permanent, but people wanted them to be slotted in and out like a Materia system. However, when I made Attachable Augments and then saw that people would just use the same number of slots for everything. At that point, why not just let the default RPG Maker equipment system handle that kind of customization? But I digress.

I understand the need and demand for this, too. Independent Items open a way to enable game dev expression, it's a way to make the game different from those out there, and to establish originality and personality. However, to make this full-fledged item customization a possibility and accessible to everybody, especially those without programming knowledge, is near impossible to fulfill and meet expectations. And with each attempt to do so during the YEP era, people always had different ideas on how they wanted Attachable Augments, Item Disassemble, Item Discard, Item Durability, Item Upgrade Slots to work. In short, it felt like nobody was happy with the releases as a whole because there was always something someone didn't like about those extensions, and when those were added in, more complaints kept arising.

This is on top of the incompatibility issues that come with Independent Items, too. So, to spare the development team the trouble of needing to rework the entire system and the endless questions about why Independent Items don't stack, and/or why certain aspects of upgrading don't meet their vision of how the game mechanic should be, I've decided to forgo the feature entirely from ever being a part of the VisuStella MZ Library.

Remember how I said earlier that we aren't afraid of making giant systemic changes that cause incompatibility problems are not something that would stop me from wanting to add it to the library unless it's super disruptive? This is that very thing that is super disruptive. Unfortunately, my team and I have decided that it's best if we don't work on Independent Items in order to be able to focus and create better gameplay plugins outside of its scope. That and we believe these features would be better off made by another plugin developer or plugin team who could dedicate their time and focus on them instead. Unfortunately, it wouldn't be from VisuStella MZ.

Related Extension Plugins

Naturally, since Independent Items won't be a thing, neither would the Item Upgrades, Attachable Augments, Item Disassemble, and plugins of the like.

Instant Cast (YEP) as a Standalone Plugin


Now, this plugin saw huge amounts of usage. It also had huge amounts of incompatibility. However, I was initially against bringing this plugin to RPG Maker MV for YEP until Archeia convinced me otherwise. After proving the massive amounts of incompatibility issues again, we as VisuStella MZ decided to not release it as a standalone plugin, but instead as a feature limited to very specific battle systems.

What this plugin does is it allows certain skills to be used instantly, without taking up the character's turn, in-battle. The turn doesn't have to start yet, it can be an action that occurs immediately during the planning phase. This can be used for things like minor buffs/debuffs that wouldn't otherwise be worth consuming a turn.

So why aren't we making it a standalone plugin? Because of the incompatibility issues specifically. In short, any kind of battle-related mechanic that gets made and affects how turns are handled with come in conflict with this plugin if it was made as a standalone. The problem lays with the instant nature of this effect and the way the default battle system works. The default battle system has to shift to an action phase outside of the input phase in order to carry out the action. However, that is exactly where the problem lays. By shifting in and out of these battle phases, problems will occur with other plugins that depend on the battle phase.

This is why we made it so that Instant-like effects only exist within certain battle systems like Battle System - OTB VisuStella MZ or Battle System - STB VisuStella MZ because in those battle systems, it actually makes sense. Otherwise, it breaks the flow of the default battle system or Battle System - BTB VisuStella MZ. For battle systems like Battle System - ATB VisuStella MZ or Battle System - CTB VisuStella MZ, just make the after gauge go to full 100%. Yes, it's not going to guarantee the action will happen immediately, but it's still a better workaround than something that's going to topple the flow of battle. For Battle System - FTB VisuStella MZ, just set the action cost to 0.

To us, we already added in all these battle system-specific Instant-like effects that emulate the effect when it makes sense. But for the battle systems where Instants do not make sense in, such as the default battle system or BTB, we're not going to release a standalone version for it to brute force in the effects when it's going to break so much compatibility and battle flow with everything else. I'm sorry, but you'll have to make do with what tools you're given with, whether they're slight changes to the after gauge or a zero cost. It's better to get a game mechanic closely fit the bill and still have the rest of the game working than the game mechanic working exactly how you want and breaking everything else.


So for those making use of the VisuStella MZ Suggestion Box, don't be terribly surprised if nothing will come out of these specific five. Through numbers, past experiences with incompatibility, and just downright incompatible design philosophies, there won't be any plans for these plugins to be made by team VisuStella MZ.

However, as far as my opinions are concerned, these plugins are also highly optional features and don't dictate the success or failure of a game. Frankly speaking, designing around the absence of these plugins is much more fruitful than designing with them in mind and having incompatibility issues throughout. Aside from maybe Independent Items, I've never really seen the other game mechanics be completely game-defining as the key feature that would carry the whole game so being without them might even be for the better.

Also, I've seen some users in a few servers consider the absence of these plugins to be walls prohibiting them from progression, but to those, I can only say to that is that you'll have to find help elsewhere. Here's a link to the official forum's classifieds section, where you can make posts to request and/or commission people to program and maintain the effects of those plugins for you and your game project.

We wish you good luck!

End of File