1. The base price of RMMZ is too expensive compared to what it added and improved over RMMV(But they'd be positive for RMMZ if there will be a big sale)
2. RMMZ isn't even RMMVA, but just RMMV 1.7, because everything "new" in RMMZ are already provided by plugins in RMMV
3. RMMZ improved too little from RMMV, meaning that the RM franchise has become trapped in the past
4. The 3D effekseer doesn't work well with the RMMZ animations, because it's a 2D engine
5. The RMMZ RTP is worse than that of RMMV(images are ugly, audios are unpleasant to listen to, etc), and the former isn't compatible with the latter
6. There are still some unnecessarily hardcoded assumptions, like the tileset size still being fixed to 48
7. RMMZ doesn't work well when the screen size isn't 816 * 624(1280 * 720 can already cause the side view battler sprites to be mis-positioned to the left of the screen), like, ugly scaling of battler sprites
8. The RMMZ character generator still sucks so hard that the generated adults look like kids
9. There's no way to make porting RMMV animations to RMMZ an easy, simple and small task, because of effekseer
10. RMMZ still doesn't make good use of multiple CPU cores nor the GPU, causing inferior performance even with the Pixi v5 upgrades and other performance optimizations over RMMV
11. RMMZ only lets you use 4 map layers, which is far from being enough
12. The hardcoded limit of 2000 items per database type isn't high enough
13. The sprites are still hardcoded to using 3 frame per action
14. There's no way to make exporting to mobile platforms an easy, simple and small task, when RMMZ is advertised for optimized for such platforms
15. Many features that are provided by RMMZ plugins should've been done by RMMZ itself
16. The audio loading still isn't optimized in RMMZ, causing large audio files to have too long to load(and this issue already exists in RMMV and is well-known by the community for years)
17. The amount of resources including by the RTP still isn't large enough, and should've been much, much larger
18. While this engine advertise itself as easy enough for a child, it's not the case when you've to learn effekseer, which is a must to use RMMZ
19. An exported project can be as big as way more than 200MB in RMMZ, while similar projects in RMMV would've been just around 50MB, and 50MB is already too much
20. Sometimes the engine can just suddenly crash, like when clicking edit on a show text event, causing unexpected loss of progresses
21. The default RMMZ JavaScript codebase is so poorly-documented that documentation there is effectively nonexistent
22. The RMMZ is obviously very, very unpolished and just rushed for launch, and the current state of RMMZ is clearly an incomplete product
23. In general, the RMMZ plugins aren't as generous as the RMMV counterparts, because of the pricing, terms of use, and source code accessibility, and RMMZ is nothing without plugins
24. Enemy skill animations aren't displayed in front view battles
25. The battler sprites aren't animated enough, and they're behaving like static ones(no shadows, floating motions, etc)
26. RMMZ just isn't worth it before it has as many plugins as that of RMMV
27. Many improvements in RMMZ should've been implemented in RMMV
28. RMMZ should let you use either effekseer or the traditional RMMV like animations
29. The RM franchise has been working in the form of buying the engine with the use of many scripts/plugins from the same scripter/plugin developer(without him/her RM would be nothing), with tweaks of those scripts/plugins made, and some other scripts/plugins(that are compatible to those made by that particular scripter/plugin developer) from the other scripters/plugin developers to make games, but this formula no longer works in RMMZ, because of the successor of that particular scripter/plugin developers start making closed-source plugins in RMMZ(and some of them are paid too)

 

1. In terms of free vs commercial projects:

i. Always Free on all RM projects

ii. Always Free on free RM projects but paid on commercial ones

iii. Always paid on all projects(perhaps more expensive on commercial ones)

 

2. In terms of payment model:

i. One time fee for a license lasting forever for the buyer

ii. One time fee for a license lasting for a project for the buyer(so the buyer will have to pay again to renew the license for the next project)

iii. Periodic license subscription fee for the buyer(so the buyer can't use the resource anymore until the license's renewed)

iv. A small portion of net(or even gross) profit's taken by the resource maker

v. Some combinations from the above

 

3. In terms of project members:

i. The project can use the resource if any member has the license

ii. The project can use the resource if all members have the license

iii. The license's owned by the project but not any member

iv. The project can use the resource if at least 1 members actually using that resource directly has the license
v. The project can use the resource if all members actually using that resource directly have the license

 

4. In terms of effective period:

i. Always free/always paid

ii. Free for a while but add a paywall later(those having the resource before having the paywall can still use it)

iii. Free for a while but add a paywall later(those having the resource before having the paywall can't use it without buying a license)

iv. Have a paywall that will be lifted after a while(with refunds to those having a license)

v. Have a paywall that will be lifted after a while(without refunds to those having a license)

 

5. In terms of paid resource accessibility:

i. Accessible for free but must be paid to be used

ii. Must be paid to be accessed or used

iii. Accessible/usable for free with a limited period/1st project, but must be paid afterwards

 

6. In terms of paid resource granularity:

i. Everything as a single bundle that can't be partially bought(with bundle discounts)

ii. Everything as a single bundle that can't be partially bought(without bundle discounts or even with an additional "bundling fee")

iii. Everything as a single file that can be bought individually

iv. Buying some resources need some other resources to be previously bought as well(with discounts)

v. Buying some resources need some other resources to be previously bought as well(without discounts)

vi. Some combinations from the above

1. Always paid on all projects(and more expensive on commercial ones)

2. One time fee for a license lasting for a project for the buyer

3. Periodic license subscription fee for the buyer

4. A small portion of gross profit's taken by the resource maker

5. The project can use the resource if all members have the license

6. Free for a while but add a paywall after taking most of the "market share"(those having the resource before having the paywall can't use it without buying a license)

7. Must be paid to be accessed or used

8. Everything as a single bundle that can't be partially bought(with an additional "bundling fee")

1. Always Free on free RM projects but paid on commercial ones

2. One time fee for a license lasting forever for the buyer

3. The project can use the resource if any member has the license

4. No paywall addition/removal later on

5. Accessible for free but must be paid to be used

6. Everything as a single bundle that can't be partially bought(with bundle discounts)

7. Everything as a single file that can be bought individually

1. Free projects are unable to generate profits(except those getting tons of genuine donations while still fitting the "free" definition), so it'd be hard for resource users to use paid resources for free projects.

 

2. No matter how unbelievably fantastic a paid resource and its supports are, one still has to actually use it to judge whether it'll really suit the needs, so those planning to make commercial projects with paid resources can try the latter on free projects first, without having to pay anything for such tries.

 

3. The absence of periodic subscription fee means the absence of time pressure from paid resources, thus decreasing the pressure towards resource users when making commercial projects, with usually an already tight budget other than time(on the flip side, such an additional time pressure can actually motivate them to be more effective and efficient when making commercial projects).

 

4. Unless a commercial project has a very large profit margin, even taking a small portion of gross profit away from the resource users can already cause the whole thing to become not profitable, thus largely(but still not totally) defeating the purpose of making the project commercial(although it still gives invaluable commercial project experience to those resource users); On the other hand, taking a small portion of net profit instead would probably give resource makers so little money that it won't be worth the effort for the resource makers to enforce this term of use.

 

5. If all commercial project members have to have the license, the development cost of commercial projects can increase a lot when many such paid resources are used and the team's large, even though it's likely an edge case anyway. In extreme cases, the team might have to decide between not using such resources and reducing the number of team members.

 

6. If the paywall isn't a constant, then resource users won't know what to expect. If the paywall's added later, then it's questionable whether the resource makers can really make much money, due to the fact that those already owning those resources before having the paywall can "carelessly leak" them to those who'd have to pay without the resource maker being able to prove anything; If the paywall's lifted later without refunding, then those already paid the resources will likely go insanely mad - so mad that the reputation of the resource maker can be shattered instantly(if there's refund then the resource maker will have serious money issues).

 

7. While making paid resources accessible for free will lead to an increased amount of piracy, plagiarism and sometimes outright stealing profits(accessing the resources for free then selling them without the original resource maker knowing), but it'll more friendly to fellow resource makers resolving compatibility issues among resources, which especially apply to plugins(although plugin developers can still ask the fellow for special permission to fix the compatibility issues). Of course, making paid resources accessible for free is still a very big risk, so not all resource maker can keep affording this, therefore it's also common for them to shut down free accessibility when they're indeed hurt by scumbags too many times and too seriously.

 

8. Letting resource users buy resource files both individually and as a bundle with bundle discounts can take care of both users using only few resource files and those almost using everything. Also, because of the existence of bundle discounts, users will be highly encouraged and recommended to buy the bundle even if they don't really need everything inside, thus on one hand increasing resource maker profits, and on the other hand doesn't impose much moral issues due to such a choice being optional and well-informed in advance.

Advantages -

i. Users don't have to pay anything for any resource regardless of whether those resources deserve to be paid, meaning that those with tight budgets can use all resources, causing the number of resource users and thus useful feedback given to the resource makers to increase, leading to increased RM sales and resource quality(provided that resource makers have the passion to do all these for free).

While this also comes with toxic feedback which makes the lives of resource makers and those giving useful feedback harder, there are ways for resource makers to deal with the toxic feedback, like standardizing feedback providing formats/procedures and declaring policies on toxic feedback, even though it does mean more work on the resource maker and sometimes those giving useful feedback(and sometimes some resource users are unfortunately too toxic to deal with).

ii. Resource makers having a hard time making high quality resources and/or providing high quality supports can learn from those who do without having to pay anything regardless of whether they should, meaning that more resource makers will improve more quickly, leading to the increased overall quality of resources and their supports(that isn't the only way to reach so of course).

While this leads to a kind of unfairness to those already making high quality resources with high quality supports, and in extreme cases, even an increase of objectively provable plagiarism, the community can always get rid of these losers quickly and is already experienced in that(such losers will always exist no matter what the community do but one can always try), and the unfairness can be somehow compensated by the unmatched popularity and reputations.

 

Disadvantages -

i. Eventually, those consistently providing high quality resources with high quality supports will take most of the "market share", and it's likely that there will be only few such resource makers per resource type, meaning that the workload of at least some of those resource makers will eventually be too high to bear anymore, probably leading to retirement that could've been reached later(and sometimes comebacks that could've happened to happen a lot later at least).

While these retirements will eventually happen and will eventually be compensated by the existence of new resource makers providing high quality resource with high quality support anyway, early retirement that could be postponed would still not be what the community wanted(but the community can and will still accept of course).

ii. Similarly, those hardly being able to provide any high quality resource nor resource with high quality supports(no matter how hard they try) will almost always have such a small number of "customers"(no matter what they do) that they'll be demotivated eventually, and it's likely that such resource makers will be the majority, meaning that the number of active resource makers of this kind will be eventually lower and lower, causing more resources to be left without supports(even though they don't have many users to begin with).

While one can always switch from one resource to another and resources will eventually be unsupported anyway, having many unsupported resources with a lot fewer supported counterparts would still not be what the community wanted(but the community can and will still accept of course).

Advantages -

i. While not many can be a good resource maker, nearly everyone can be a bad one, and when all resources are supposed to be paid, even a bad junior programmer like me can earn some quick money by making paid resources(in my case, plugins) without worrying too much about the resource quality or proper supports, due to the fact the paid resources are now the norm.

This can actually cause some resource makers to be motivated enough to be more proficient more quickly, and thus surprisingly lead to the increased number of good resource makers and high quality resources with high quality supports in the long term, all due to the desire to have a larger and larger amount of market share.

ii. Those taking free yet high quality resources with high quality supports for granted will finally learn just how wrong they're, as the only other way for them is to leave RM entirely(Even if they're to be resource makers themselves, they'll still learn the lessons 1st hand).

This not only can increase the relationship between resource makers and users remaining, but also cause the latter to take resources and sometimes projects using them more seriously, thus reducing the amount of published trash games in the RM community(even though they'll always be there no matter what the community does).

Disadvantages -

i. Eventually, the RM resources will be so contaminated by scammers and innocent but still utterly incompetent resource makers that the whole thing will effectively become a massive cesspool, damaging the reputation of not just those deserving to have their reputations damaged, but also those not deserving so, due to the fact that now resource users will have a hard time separating the wheat from the chaff.

Similarly, the whole RM community or even RM itself will suffer from the unstoppable loss of members, severe drop of sales and eventually the severe damage to the whole RM brand, and all these tragedies are hard or even impossible to reverse.

(If the "all resources are paid" is lifted after that to try to save the day, then resource makers will have much, much higher demands on even free, let alone paid, resource makers, as a kind of revenge towards the perceived betrayal from the latter)

ii. Those not having the balls to make paid resources(including dumb noobs like me) and take the upcoming obligations(including legit ones like fixing bugs/internal compatibility issues quickly, questionable ones like "the customer is king" mindset or being compatible with every foreign resource used, and perhaps some totally unsound self-entitlement as well) will either have to improve their proficiency quickly the hard way, or be forced to leave the RM community until the "all resources are paid" is no longer a thing, and the number of such resource makers is better not to be underestimated.

Advantages -

i. The "entry barrier" of making paid resources will be a lot lower, leading to the increased number of resource makers making money out of their resources, thus increasing resource maker sustainability, and sometimes even resource quality and supports due to the increased incentives.

Similarly, resource users will be more willing to accept that free but high quality resources with high quality supports shouldn't be taken for granted, thus reducing tensions between resource makers and users and the amount of toxic feedback.

ii. Those not having the balls to have paid resources(including dumb noobs like me) can still make free ones, and it's likely that such resources will have many users, as there are not many such resources and the demand to use free resources will be high regardless of how many resources are paid.

Similarly, resource users will also have a choice to use free resources, even when they can be of low quality and have poor supports.

Disadvantages -

i. Eventually, more and more resource makers will make free resources to try to steal the "market share" from the paid counterparts, causing more and more users to switch to the free ones, meaning that the entire "most resources are paid but some are free" will eventually be unsustainable, and this can mean a world of hurt of resource makers having made tons of paid resources.

ii. Even if this whole thing's sustainable, the number of users per free resource would still be too high for most free resource makers, due to the fact that many resource users will rather use free but low quality resources without proper supports than paid but high quality resources with proper supports, meaning that the workload of at least some of those resource makers will eventually be too high to bear anymore, probably leading to retirement that could've been reached later(and sometimes comebacks that could've happened to happen a lot later at least).

While these retirements will eventually happen and will eventually be compensated by the existence of new resource makers providing free resources anyway, early retirement that could be postponed would still not be what the community wanted(but the community can and will still accept of course).

Advantages -

i. It's very likely that those consistently making high quality resources with high quality supports will be the ones making paid resources, as those unable to do so but still trying to make paid ones will be out of the paid resource business very quickly, due to the drastic and obvious contrast between the wheat and the chaff there.

Similarly, those unable to do so can stick to making free resources(without the competition from the best resource makers as well), and they don't have to feel obligated to make high quality ones with high quality supports no matter what(even though it's still highly encouraged and recommended), as such demands can be handled by the paid counterparts(they can start making paid counterparts when they become proficient enough).

ii. Resource users can choose between paid but high quality resources with high quality supports, and free but low quality resources with low quality supports, with clear expectations from both groups and without having to constantly worry about being scammed much(even though there will always be scammers no matter what the community does).

Of course, there will be free and high quality resources with high quality supports even with "most resources are free but some are paid", but that's good for almost everyone, as long as the free resource makers involved can be sustainable and aren't stealing too much "market shares" from the paid counterparts.

Disadvantages -

i. If many free resources and their supports outclass the paid counterparts in almost every way, the latter will eventually vanish and the whole thing will become "all resources are free", meaning that some kind of tacit understanding among resource makers will have to exist in order to maintain the equilibrium, and it's possible that resource users will have to have the same understanding as well, none of which are easy, simple nor small tasks.

ii. Sometimes maintaining the equilibrium can mean some free resources outclassing paid ones will become paid later, causing severe outrages from many of those using those resources(and in extreme cases even a feeling of being betrayed by their idol like figure), thus killing the reputation of said resource makers and seriously shaking the confidence of users using free but high quality resources with high quality supports, even when those already owning those previously free resources don't have to pay after they become paid ones.

More precisely, I prefer the resources with the highest qualities and best supports to be paid in order to protect the best plugin developers from excessive workload and some toxic plugin users(usually they don't have the balls to pay just to leave toxic feedback, which is a main trouble for some of the best plugin developers), and let the not-so-good plugin developers to face a less fierce competition among free plugins(at least not so fierce that it feels useless no matter how hard you try and what you do) , even though it's still good for the best of the best to make free plugins and the not-so-good ones to try to make paid ones.

 

On the plugin user side, this means a more effective and efficient way to separate the wheat from the chaff, and a more serious thought on using high quality plugins instead of just throwing everything together and expect an utopia to come instantly(and even expect high quality supports to quickly right the wrong from them for them) :)

 

On the RM side, I think that's the best balance between having so many low quality plugins with poor supports that it's too hard to find high quality ones with proper supports, and having so few free plugins that some RM users consider RM pricing a scam(most considers RM nothing without plugins so most plugins being paid effectively means an uninformed mandatory paid "DLC" in RM for most of them).

I may as well do the same to myself...