Why Extension Plugins Are Not Standalone
- 1 Introduction
- 2 First Things First
- 3 Why We Create Cores
- 4 Why We Create Extension Plugins
- 5 Why Extension Plugins Aren't Standalone
The following is a suggestion that the VisuStella team has acquired through the Suggestion Box.
I figured we should talk about it. Not the berate the suggestion maker, but to answer some commonly asked questions for educational purposes and to explain why we do things the way we do. Namely, why we create cores, why we create extension plugins, and why those extension plugins aren't standalone plugins. We'll answer some other questions, too.
First Things First
A slight bit unrelated to the topic at hand and more towards the suggestion, we want to clarify that the Battle Core does not change the game drastically. The majority of the changes invoked by the Battle Core are mechanically driven and not visible in a default scale. The only things that are visible however, are HP Gauges, Automatic Action Sequences, and the Extra Options with the Party Command Window. Each of these features can be disabled within the Battle Core's Plugin Parameters. Take a little bit of time to search them and you'll find them easily.
We're just getting this out of the way in case anyone who sees this article becomes suddenly afraid to use Battle Core without understanding the purpose of the plugin and what it actually does.
Why We Create Cores
This section will answer two things: Why we create Core Plugins (Tier 1) and why we created them the way we did for VisuStella MZ.
The Purpose of Cores
The VisuStella MZ Cores, despite what some people think, are actually conglomerations of mostly basic features. They're huge bundles of basic features that are otherwise unnoticeable to the passerby. However, they're important in the sense that they need to be rooted deep within game project's code, the core. The reason behind this is because that while they're basic features, rooting them deep into the core of projects allows the basic features to extend outward and affect more aspects of the game project, the plugins that may come after the cores, and the plugins dependent on the cores.
This is not to say that all features provided by the cores are basic. Some things like Action Sequences for the Battle Core are incredibly advanced features that can be optionally utilized. However, their integration in the cores are necessary for the accessibility and functionality towards the game development process in which plugins can alter the game state in a stable way.
If we are to compare this to real world objects, the cores would be the motherboards to a computer. They are the engines to a car. Or they can be the power plants of a city. Each of the listed objects are deep rooted for their functionality in order for the supplemental parts to be efficiently utilized. The same goes for core plugins and extension plugins.
The code provided by these core plugins make it possible for extension plugins to work with the game project in question with maximum efficiency and minimal conflicts.
Why Are Cores Created The Way They Are
One of the more common questions we're asked as the VisuStella MZ team is "Why are your Cores so huge and packed full of features?"
To answer the first question of why they're so huge and packed full of features, it's because of one of the inherent problems discovered with the Yanfly Engine Plugins library. That problem is known as Plugin Order. It's not entirely obvious to non-programmers, but the order in which the plugins are installed in the Plugin Manager matter a lot to ensure the compatibility of the plugins working together. This was a problem that was previously unforeseen during RPG Maker VX and RPG Maker VX Ace since script libraries and script usage tends to be a lot smaller. Therefore, when RPG Maker MV came along and plugin usage was at an all time high, the problem became more evident. In fact, more than 90% of the bug reports sent for Yanfly Engine Plugins was due to incorrect plugin orders.
With that in mind, we created the VisuStella MZ Core plugins as large as they did to incorporate the mostly commonly used but core features in the proper order to avoid conflicts. And it worked. Bug reports regarding plugin order no longer exist (for VisuStella MZ at least).
"But not everybody wants all of those features!"
And that's why we included options to disable them. Despite what the suggestion says about it being "hard work" to turn off everything, the majority of those features can be turned off by just turning the associated Plugin Parameter to "OFF" or "Disabled". For the other features, they're usually optional. Being optional, this means you wouldn't be able to know that feature is there if you don't use it at all.
If there are features you can't figure out how to turn off, then I suggest paying a visit to the plugin's help file. If there is no way to turn something off specifically, then there's usually a good reason why we don't allow the option to turn it off. However, those features are rare and the vast majority of features have toggleable options.
The ones that cannot be turned off? Well, we turn those into Extension Plugins instead, so that you don't have to install them at all.
Why We Create Extension Plugins
When features get too big and complex to be toggleable to work with Cores, we turn them into Extension Plugins (Tier 3) instead.
Extension Plugins are purely optional features that aren't necessary for the core traditional RPG experience. These are optional effects or mechanics that fit within smaller subsets of traditional RPG's. Therefore, it doesn't make much sense to include them into the Cores themselves.
However, Extension Plugins are also Extension Plugins because they rely on some functionality from the Cores. This applies to a few of the System Plugins (Tier 2), too. The Extension Plugins (and selected System Plugins) expand upon the base to which the Core Plugins offer. This is to maintain the modularity of the plugin library and game engine while keeping the cores strong but flexible.
Previously with my RPG Maker VX libraries, I rarely was able to go past 30 to 50 scripts per library unless they were completely small scripts that were more like tweaks. However, a script library of tweaks doesn't create a full game engine. Instead, to expand past that and to create a proper game engine, the concept of core scripts/plugins and extension scripts/plugins had to be made.
This is why Yanfly Engine Ace script library for RPG Maker VX Ace was able to scale past 100 scripts. It is also the same reason why Yanfly Engine Plugins for RPG Maker MV was able to reach 200 plugins. This is also the reason why VisuStella MZ for RPG Maker MZ is able to scale to the size it is today.
The majority of RPG Maker VX Ace scripters and users at the time frowned at the dependency requirement of cores for extension scripts. However, there is undeniable evidence that the cores facilitate the process. Atoa, the creator of Victor Engine for RPG Maker VX Ace and RPG Maker MV, utilize the core and extension model. It's why our respective libraries were able to grow to the sizes they are without having the majority of our published scripts/plugins be five-lined tweaks.
So Why Do People Complain About Cores?
The only Cores that I've seen people complain about are those from lesser known Plugin Libraries.
These are often made by beginner plugin devs who don't understand the purpose of Core Plugins. Instead of providing a mechanical foundation to enhance gameplay, the Cores made by the rookie plugin devs are often centered around convenience. The convenience isn't directed towards the game dev, but instead, towards the plugin dev. They contain functions that allow the plugin dev to quickly parse notetags, shuffle arrays, or the like. While on the surface, it seems "helpful", the issue most users have is that these Cores offer very little changes to the game project itself.
I've almost never seen people argue about the dependency on VisuStella MZ's Core Engine. Or any of the other cores bar the few times there are misunderstandings on what they do. The Cores provided by VisuStella MZ and Yanfly Engine Plugins are evident in what they do and the game devs can feel the changes themselves. However, the same cannot be said about "Convenience Cores".
Does this mean Convenience Cores bad? I cannot answer that. However, I can only guess that the reason why people complain about "Cores" is when they install Convenience Cores and don't see any changes to their games, major or minor.
Why Extension Plugins Aren't Standalone
There are three main reasons why Extension Plugins aren't Standalone Plugins (Tier 4): compatibility, cost reduction, maintenance.
Let's assume that we have made our Extension Plugins into Standalone Plugins. They would need to bring with them the functions and changes that they depend on from the Core Plugins. Normally, including these aren't a problem. BUT that's only true if it's on a small scale.
It's become no surprise that plugin usage has grown over the years. Unlike the days of RPG Maker VX Ace where people use only a small handful of scipts, the vast majority of projects I've encountered in RPG Maker MV and RPG Maker MZ reach fifties to hundreds of plugins. When Core functions and changes like that are taken out en masse, they cause conflicts, especially in regards to core function changes.
Too many and it will set a precedent where the plugin order suddenly matters again, too. So with that in mind, for all the hard work we've done implementing the Cores in the way we did to the development of the Tier system, this will be all reversed. If you're to ask me from the viewpoint of a programmer, I don't think such a thing is worth it.
To bring this into better perspective, imagine if your electric devices didn't use the universal electrical socket. Each one you buy requires you to manually attach it to the electrical wiring in your house instead of just plugging it into the wall socket. Not only is this more tedious to do, it's potentially dangerous because of unregulated power distribution across the devices. Each of these problems are solved with the more common wall socket. Wall sockets look ugly as hell when they're unused, but they're essential to modern day living. The same goes for the Core Plugins.
Imagine if every time you wanted to buy a new game, you had to buy an entirely new console for it. Pokemon Yellow came with its own Game Boy and can only be played with that specific Game Boy. Pokemon Red came with another Game Boy and can only be played with that specific Game Boy. There are no cartridges, they are independent machines on their own.
Naturally, the cost of these games would be a lot more expensive than if they were just cartridges that can be swapped out across a median game console, right? The same works with Extension Plugins and their Cores. The development time (and therefore cost) of an Extension Plugin is usually far less than if it were to be developed as a standalone. The code doesn't have to be made in such a way where it has to be self sufficient because that code already exists in the Cores. And if there are any updates made to the Cores, the Extension Plugins benefit from it, too. The same way cartridge games benefit if there's a firmware update to the console it's on.
For those saying that this is an unfair comparison and that dedicated machines are likely to be cheaper as they're more specialized, you're partly correct. However, it's not nearly as cheap as you think. Look at arcade cabinets. They cost on average around $1000 USD. If you're to compare that to a single TV ($1000), Console ($500), Game ($60) combination, yes, it's potentially cheaper at around $1560 USD total. But the problem comes in when you suddenly want to own a different game. The cost of two arcade cabinets equal to about $2000. Whereas the cost of a single TV ($1000), Console ($500), and 2x Games ($60 x2 = $120) will cost $1620. The scaling is far more reasonable for modular Game support than dedicated.
The same applies for plugins.
Plugin maintenance is a massively overlooked component when it comes to the development of plugins. This factor becomes exponentially more important the larger the plugin library is. Maintaining 30 plugins versus 60 plugins isn't double the amount of work. It's a lot more, exponentially more. And that's because in order to ensure compatibility between 60 plugins versus 30 plugins, there and more and more combinations to factor in.
However, with Cores, the maintenance work becomes streamlined. If someone is wrong with the Battle System plugins as a whole, chances are, it's a fix that needs to be done with the Battle Core itself. Fixing the Battle Core itself would mean that the dependent plugins for the Battle Systems are fixed, too. This isn't always the case but it's the majority of it. This is why if you ever visit the VisuStella MZ Changelog, you would see that the majority of bug fixes are tied to the Cores themselves.
Some would just argue to make the plugins bug-free and compatible from the start. We try. We seriously try to. However, as we are human, we are prone to make errors. That is why we maintain our plugins in order to ensure that they're as error free as possible.
Turning what are otherwise Extension Plugins into Standalone plugins would also greatly inflate the cost of the plugins we're offering them at. What is originally a $5 to $8 plugin can reach higher cost values with Standalone status. However, if you're willing to buy these features at higher cost values with Standalone status, we will have to recommend that you find someone else to handle it. We would suggest that you find a programmer to commission. They would need to create the code from scratch, make sure it works standalone, and maintain it with your other plugins for your game.