Difference between revisions of "VisuStella MZ One Year Retrospective"
(→Budget and Pricing Models)
(→Budget and Pricing Models)
|Line 269:||Line 269:|
== Budget and Pricing Models ==
== Budget and Pricing Models ==
We'll be talking about the pricing models used by [[VisuStella MZ]].
We'll be talking about the pricing models used by [[VisuStella MZ]].
Revision as of 04:33, 13 August 2021
- 1 Introduction
- 2 Super Cores
- 3 Tier Hierarchy System
- 4 Plugin Port Exclusion
- 5 Obfuscation
- 6 Budget and Pricing Models
- 7 End of File
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. We'll be analyzing each of the negatives, challenges, and positives. This way, we can avoid making mistakes in the future based off the ones we have encountered in the past.
This article can also serve as insight to any potential plugin devs who plan on developing their own libraries.
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?
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.
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.
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.
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.
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.
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.
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.
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.
Plugin Port Exclusion
The majority of the VisuStella MZ plugin library consists of ports from the Yanfly Engine Plugins library. There are also additions from Olivia's, Irina's, and Arisu's libraries, too. However, not everything will be ported over. Some plugins will be excluded from being ported over. This section is not the explain the reasoning behind why certain plugins aren't ported over. There's already an article for that found here.
Instead, we'll be discussing what are the negatives, challenges, and positives of excluding some plugins from being ported over.
There is an argument that with each plugin or feature that isn't ported over from past plugin/script libraries, there will be a gaping hole in the library. I will say that this isn't true on account of two things. The first is that the statement is often said to try to guilt trip plugin devs into making a work they don't want to touch. The second is that in my 10+ years of script/plugin development for RPG Maker, the only time there is a gaping hole in any library is when a plugin dev is unable sustain him or herself.
People typically express that specific plugins or features are absolutely vital to their game(s). It can be true, it can be an exaggeration. However, as far as I'm concerned, everything that's needed for the traditional RPG is already located within the Cores that we have released. Everything else is luxury. To determine if specific plugins or features are essential, list out ten RPG series (not individual games) out there in the world. Then count up how many of those series have those features in all of them. Such a method will reveal what is essential and what is luxury.
I think the most obvious challenges is that some users won't be happy that their favorite plugin(s) from past libraries aren't going to be ported over. This goes for features, too. There's a certain type of pressure when people keep requesting for specific plugins over and over again. However, I want to remind the team to know why those plugins aren't being ported over. And usually, the reason is because the actual usage numbers don't match up to how often the suggestions appear. With how they are often a mess towards incompatibility, adding those plugins into the library just isn't viable for keeping VisuStella MZ going.
The positives are easy. Time saved from maintaining those highly incompatible plugins means more time that can be spent being productive elsewhere. This can be in the form of polishing the current library's plugins or creating new plugins. The money spent maintaining it is also better spent on creating new plugins or working on other VisuStella projects.
I don't think there's much else needed to be explained here on why I think the decisions we've made to exclude certain plugins from being ported over makes sense. Yes, it's unfortunate for the users that absolutely love them. However, we are also a team that needs to maintain probably the largest plugin library in RPG Maker MZ. I would much rather that we don't create/port those plugins in the first place only to drop support for them later.
Obfuscation is the process of making the code hard to read and redistribute. It is the method that VisuStella MZ uses to protect its own code.
Biggest negative would be drama. There exists a lot of controversy towards VisuStella MZ because of obfuscation. However, my stance is this: typically, the people using RPG Maker and plugins are those who aren't familiar with programming anyway. Therefore, it adds little benefit for those users if the code is openly readable. For those who do happen to be familiar with programming, that's why we add in Plugin Parameters and Notetags to enable their own freedom for using JS code.
However, if I'm to be honest, obfuscation just so happens to be the low-hanging fruit that the drama-inciters are taking advantage of. Having done the research myself, the majority of the individuals using the obfuscation argument are those who were already speaking ill of team VisuStella to begin with. There were already comments made by those individuals about VisuStella before the obfuscation of code was even discovered. As such, they were never the target audience to begin with as their sole interest was to promote FUD. But with that in mind, the high majority of VisuStella users say that the quality we bring out is well worth the obfuscation. The record-breaking sales we have gotten as of late indicate that as well.
Another common argument is "If I have bought a product, I should be given the code". This is a rather poor argument. How much of the software have you bought is openly readable? The RPG Maker MZ's editor/client isn't openly readable. Neither are some of the JS files found in the /js/libs/ folder. We are not selling open-source code to pick apart. We are selling plugin features for make games with. If the person does not agree with this, they can buy or use plugins from other libraries. It doesn't have to be ours. We aren't going to jeopardize our own safety.
Nearly every member of team VisuStella has already experienced some form of code theft. Obfuscation is here to stay due to that very reason. I have no intentions of letting my team members suffer for that again. People can hate me for that, but I have my own beliefs to stick to.
While the majority of VisuStella MZ's users are unfamiliar with programming, there are those who are. Obfuscation will obviously be a thorn in the side for these individuals. That's why it's important that when creating plugins, we have to provide potential notetags and Plugin Parameters for programmers to utilize. This is always going to be extra work for us, and it might not even pay back all that much. However, we have already been doing this since the start and as long as we keep at it, we will overcome this challenge.
Code security is easily the biggest positive. Being able to work without worrying about work being stolen and redistributed is more golden than one would think. Peace of mind is often taken for granted, so we must be appreciative of it.
Obfuscation also allows us to compile the code better for application by removing not-so-useful metadata, unused dead codes, or duplicate codes. This minification, in turn, speeds up the compilation process and results in quicker code execution and faster results, thus upping the ante on code performance. After all, this is why nearly everything in the js/lib/ folder is minified in the first place.
I also encourage any plugin devs who are worried about their works being stolen to obfuscate, too. VisuStella MZ has high usage numbers, with users in the tens of thousands. We have yet to find our works to be stolen yet. It's not that the obfuscation cannot be cracked, it's that it's not worth it for a thief who is just trying to make a quick buck by breaking apart complicated messes like this.
Some claim that code theft does not exist in the RPG Maker community. However, it certainly does. CutieVirus, the creator of MV3D and MZ3D, has had their works stolen before and resold on the same platform. Hudell had his code copied and lifted, too. Then re-released in the same forum. Just ask them and they will tell you their tale.
Therefore, I always say to protect your code if possible.
The positives of obfuscation easily outweigh the negative. However, I won't deny that it's hard to ignore the negativity that VisuStella MZ gets due to obfuscation. Just remember that it's low-hanging fruit that nay-sayers often bring up to just argue about VisuStella MZ in general. These are often the individuals who were outspoken against VisuStella to begin with. They are also not the target demographic for the VisuStella MZ plugins. Do not worry about them. Let them worry about it instead.
Budget and Pricing Models
The beginning was a rocky start. We had to port over an entire library from RPG Maker MV to RPG Maker MZ. We had to hire a lot of help from all over the community to get the ports made. The ports also had to be polished. All in all, a lot of money was spent during this time.
A good chunk of the money spent went to the Super Cores. Each of those were made of many individual plugin ports. Some of them had as little as five ports. Others had as many as over twenty. Roughly 120 plugins were ported over for the Super Cores. This is especially hard since the Super Cores are free to download and don't cost anything. They're given out to the RPG Maker community at a financial loss on our part.
The next negative came in how we overstuffed the 'Wave bundles. With the calculations made here, we can see that each Wave reduced the potential earnings of its set of plugins by 60% to 70%. It would have been more lucrative to put only 6 plugins per Wave instead of 8 to 10. This would have made it easier for the team to maintain and produce, too. As such, this was a bad judgment call on my part. Thankfully, most users find these to be very reasonably price and even say it's a good deal, too. If anything, at least users are very happy with their purchases.
Next big negative was the handling of the All Waves Bundle Collection. In short, it was something that further decreased the potential earnings we could have by another 10% to 20%. Where the total amount of plugins it held was worth around the $500 range, we sold it at $100. Stuffing 8 Waves into it caused us to stay in the red even longer. However, since users were very happy with their purchase due to its high value, I say it's best to see this as a positive if possible.
The naming schema for All Waves Bundle Collection was also poorly thought out. It was confusing for some users as they thought it mean they would own every plugin released from there-on out. No, it's only those released within the Waves structure.
Keeping the budget above the red to pay team members to maintain and expand the library was a big challenge at the start. Most team members had to be okay with being underpaid for a bit before we made up for it later. Thankfully, the team members were on board and knew of VisuStella MZ's potential causing them to stay.
Also due to budget issues, we also had to have longer and longer breaks in between Waves. While we would have had the breaks anyway, the longer breaks still allowed the budget to grow back. Simply put, 8 to 10 plugins per Wave was simply too much and caused a lot of team members to overwork.
I would personally like to reduce the break period between product releases to a month in between. With the current release schedule of 3 plugins per pack and per month, I think it's a good balance. Budget-friendly while not overworking everybody.
While running the Patreon for Yanfly Engine Plugins, I often found myself overworked. During YEP, I had a large volume of users (over 300,000 users) and roughly 3.5 million downloads total). However, my Patreon only ever amassed a total of 650-ish users during its lifetime. This isn't the highest, just a lifetime value. The highest I've ever reached was 520-ish users ever. This means I had roughly only a 0.2% ratio of users even providing financial support to the library.
This is why I say the shift to a straight up sold product is better for VisuStella MZ. We narrowed down the userbase to tens of thousands. We increased the buy ratio to over 50%. And we still have over 100,000 downloads in total. This is pretty good for the first year.
And with how the trends are going, it'll do even better in the upcoming years. I believe that as long as we keep to the principles we've established for how the plugin library would develop, we'll be fine.
End of File