Difference between revisions of "VisuStella MZ One Year Retrospective"

From Yanfly.moe Wiki
Jump to navigation Jump to search
(Super Cores)
Line 82: Line 82:
  
 
The decision to move to '''Super Cores''' instead of using split cores is a success. The positives outweigh the challenges to be faced and there's really not that many negatives.
 
The decision to move to '''Super Cores''' instead of using split cores is a success. The positives outweigh the challenges to be faced and there's really not that many negatives.
 +
 +
  
 
== Tier Hierarchy System ==
 
== Tier Hierarchy System ==
Line 92: Line 94:
  
 
=== Negatives ===
 
=== Negatives ===
 +
 +
The only negative I can really think of is that, if the user, for some reason, does not have the plugins in the right tier order, an error will occur and alert the user it's in the wrong order.
 +
The game would then automatically close down and require the user to reposition the plugin into the right tier order.
 +
However, this isn't as big of a problem as I see it to be.
 +
Users who don't have the plugins in the right tier order would not get their plugins working properly anyway.
 +
And without the alert message, they wouldn't know how to fix it either.
 +
 +
To me, this is better than having an ever persistent war with an ever updating list on how to order your plugins.
  
 
=== Challenges ===
 
=== Challenges ===
 +
 +
One of the challenges the '''Tier Hierarchy System''' will face is how to actually teach users to place non-[[VisuStella MZ]] plugins into the mix.
 +
Especially we do not have any say on how other plugin devs should design their libraries.
 +
However, this is also one of the challenges found with the [[Yanfly Engine Plugins]] library, too.
 +
The blanket-wide solution I can only offer is to have game devs place non-[[VisuStella MZ]] underneath the [[VisuStella MZ]] library in the Plugin Manager.
 +
Otherwise, to give other plugin devs some clues on how to rank their plugins based on the hierarchy.
  
 
=== Positives ===
 
=== Positives ===
 +
 +
The biggest positive of the '''Tier Hierarchy System''' is the complete shutdown of the most common cause for bug reports ever: wrong plugin order.
 +
In the past, the number of times I've encountered bug reports caused by wrong plugin orders outweigh the actual number of legitimate bug reports about 5 to 1.
 +
Shutting down any potential means of putting the plugins out of order allows the team to reclaim the time spent on responding to those reports to the development of the library.
 +
Even if this was the only positive of the '''Tier Hierarchy System''', it would have been worth it.
 +
 +
However, the '''Tier Hierarchy System''' also does something else.
 +
It causes us, the plugin devs, to be more aware of how the development of the plugins work.
 +
By designing the plugins around the '''Tier Hierarchy System''', we actually created better workflows.
 +
Maintaining the plugins adapted to the '''Tier Hierarchy System''' has never been more efficient.
  
 
=== Overall ===
 
=== Overall ===
 +
 +
The '''Tier Hierarchy System''' is a massive success.
 +
During the past year, I've often wished I would have came up with it sooner.
 +
However, it could only be something that's realized by the massive influx of plugin order-related bug reports.
 +
 +
  
 
== End of File ==
 
== End of File ==
  
 
|}
 
|}

Revision as of 12:53, 12 August 2021

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.


Introduction

At the time this article is written, VisuStella has been running for a year already. As the team director for the majority of the year, I'd like to take some time to reflect and review what went on during the year as far as developing and maintaining the library goes. There are negatives, there are challenges, but there are also a lot of positives. I'd like to take that time to talk about them so that the VisuStella MZ team can have a clearer understanding going forward. This article can also serve as insight to any potential plugin devs who plan on developing their own libraries.

Yanfly.png This is an article written by Yanfly.


Super Cores

VisuMZ.001.jpg

One of the bigger topics that have been discussed in the community in regards to the VisuStella MZ is how big the cores are. Let's call them Super Cores due to their size. Each one of these plugins are made up of several smaller plugins of related (or semi-related) features. Some of the Super Cores are made up of 20+ plugins while some are made up of only 5-ish. Either way, they're bigger than what people are used to.

And before I get started, let me just put out one thing for the VisuStella MZ team to never forget about. I know that other plugin developers are emulating the Yanfly Engine style with Cores, Core Engines, and stuff. However, they made the dependencies on them way too high. For what it's worth, in Yanfly Engine Plugins, there was only ever one plugin that was dependent on the Core Engine and that was the separated desktop-only Core Updates. Adding a dependency should only be necessary when there are features added by the Cores/Core Engine that need to be relied upon. We don't want the library to be needlessly tied to the Core Engine even if it's a good idea to have regardless.

So what do I think about the Super Cores?

Negatives

One of the biggest negatives I hear about from the community is how difficult it is to make plugins compatible with the Super Cores. However, this is one of those statements where I have to disagree with. All of the Super Cores are designed to reuse the base RPG Maker MZ functions as much as possible. When approached by plugin devs looking to create compatibility with the VisuStella MZ Super Cores, we often discovered that the non-VisuStella plugin devs just didn't know a better way to approach the compatibility. This can come in the form of which functions to alias/monkey patch or which Plugin Parameters to turn off in order to bridge the two plugins. When there are actual compatibility bridging problems, we revisit the respective Super Core and fix it as you can see in our Changelogs. With that in mind, this isn't an actual negative but a perceived one.

Aside from that, the only real negative I can think of is that looking through the code for a Super Core can be extremely daunting. Even with everything commented, it's still tricky to navigate. However, I believe this is something that the team is already used to by now.

Challenges

One of the biggest challenges encountered with the Super Cores is how high maintenance they are. However, this is to be expected given how large they are. When a plugin has 20+ plugins shoved inside it, there's a high likelihood that it'll be updated often. However, it is worth it for all the positives that maintaining a Super Core provides.

Positives

One of the best things about making the Super Cores is how in-library compatibility is easily maintained. A common problem throughout the past RPG Maker iterations for scripts and plugins alike is the concept of putting everything in the right order. Plugins that were installed in the Plugin Manager in the incorrect order were bound to have problems and conflicts. With the Super Cores, that is mitigated for the majority of the plugin features added. Combined with the Tier system, errors of incorrect plugin order are practically non-existent.

Another major bonus of a large Super Core is the systemic synergy it creates with other features within the plugin. Certain features only became plausible by combining the features together. They allowed for better new feature integration across the VisuStella MZ library as a whole.

And the last big bonus of the Super Core that I want to talk about is the ease of starting up new projects. I've received a lot of positive feedback about them despite the negative comments on the modularity. The majority of users are happy they can grab the ten Super Cores and get going. This beats the past experience of needing to hunt down basic functions split across 100+ functions. This saves a lot of the users' time and allows them to focus on the experience.

Furthermore, there's lots of positivity coming from users where they are discovering features they didn't know they needed. Such examples include the diagonal movement from the Events and Movement Core or the tilted dash. The extra layout styles made it easier for users to get the appearance they want for their games. Other things include not needing to download external plugins for HP Gauges from the Battle Core.

Overall

The decision to move to Super Cores instead of using split cores is a success. The positives outweigh the challenges to be faced and there's really not that many negatives.


Tier Hierarchy System

The Tier Hierarchy System is developed for the VisuStella MZ library to combat incorrect plugin order errors. For a reminder on how it works, watch the video below:

So, let's get into it.

Negatives

The only negative I can really think of is that, if the user, for some reason, does not have the plugins in the right tier order, an error will occur and alert the user it's in the wrong order. The game would then automatically close down and require the user to reposition the plugin into the right tier order. However, this isn't as big of a problem as I see it to be. Users who don't have the plugins in the right tier order would not get their plugins working properly anyway. And without the alert message, they wouldn't know how to fix it either.

To me, this is better than having an ever persistent war with an ever updating list on how to order your plugins.

Challenges

One of the challenges the Tier Hierarchy System will face is how to actually teach users to place non-VisuStella MZ plugins into the mix. Especially we do not have any say on how other plugin devs should design their libraries. However, this is also one of the challenges found with the Yanfly Engine Plugins library, too. The blanket-wide solution I can only offer is to have game devs place non-VisuStella MZ underneath the VisuStella MZ library in the Plugin Manager. Otherwise, to give other plugin devs some clues on how to rank their plugins based on the hierarchy.

Positives

The biggest positive of the Tier Hierarchy System is the complete shutdown of the most common cause for bug reports ever: wrong plugin order. In the past, the number of times I've encountered bug reports caused by wrong plugin orders outweigh the actual number of legitimate bug reports about 5 to 1. Shutting down any potential means of putting the plugins out of order allows the team to reclaim the time spent on responding to those reports to the development of the library. Even if this was the only positive of the Tier Hierarchy System, it would have been worth it.

However, the Tier Hierarchy System also does something else. It causes us, the plugin devs, to be more aware of how the development of the plugins work. By designing the plugins around the Tier Hierarchy System, we actually created better workflows. Maintaining the plugins adapted to the Tier Hierarchy System has never been more efficient.

Overall

The Tier Hierarchy System is a massive success. During the past year, I've often wished I would have came up with it sooner. However, it could only be something that's realized by the massive influx of plugin order-related bug reports.


End of File