Home Creators Posts Import Register Favorites Logout
haven't archived this post yet. have a subscription? use the importer!

Content

Only three more months until the end of the year, can you believe that? I could have sworn 2018 just started, but I guess the fact time's flying by sooooo fast just simply means that we've been having a great year so far! But despite how fast it's flying by, it's time to update the sample projects with the newest plugin: the Dynamic Title Screen!

Sample Project File Size: 594MB (roughly)

---

The newest beta plugin is our first Patreon-only poll winner: Stat Allocation! I've decided to rename it to Stat Allocation since it makes it a bit more meaningful as distribution actually was never really the proper terminology for it. However, that's mostly semantics! I'm sure what you're all here to hear is for what it can do!

It's pretty much the system you see in MMORPG's. Level up, get AP, use AP to allocate into the stats you want. I'm putting in a little bit of a spin on this one. And for MarkoB who asked what's going to be the primary difference between this plugin and SRDude's as well as many others, it'll be explained here:

The majority of stat allocation-like plugins tie allocated stats to the actor. This is probably the most sensible. After all, what's the point otherwise, right? Well, it just so happens that there's an exploit to this system that I see in nearly every single iteration:

(Screenshot GIF courtesy of Olivia, plugin being used in question is SRDude's Stat Distribution and no other plugins with the exception of the required Super Tools plugin).

By changing between a higher level class and a lower level class, one can amass infinite AP (or the plugin equivalent). The GIF above is using only events, too:

This is not to defame SRDude or any of the other plugin creators out there. Instead, I find it a fault of RPG Maker MV's core code for making stuff like this happen, because when multiple plugin creators reproduce this same exploit, something is definitely amiss here. And that something is the common denominator: confusing core code.

So what am I going to do? AP and allocation setups will instead be tied to each class instead. What this means is, each class will have their own AP totals and own allocation builds instead of one global setup for each actor. Changes made across classes will not affect one another.

This in turn, also gives player access to AP builds that they can customize for themselves per class. For example, the player may spec into more ATK for Harold as a Knight and more DEF for Harold as a Fighter. Yet, the player might do more DEF for Knight Therese and more ATK for Fighter Therese.

This, in my opinion, is extremely important for any RPG that decides to utilize a class changing system and stat allocation features at the same time. By splitting the allocation setups to different classes, this means that AP Builds for each actor don't have to be generalized, but instead, can become specialized, allowing room for more creativity and adding a personal touch for each type of player.

As a result, tying stat allocation to classes instead of actors themselves kill two birds with one stone: patches away the unlimited AP exploit and gives way to player customization across classes.

That won't be the only feature either. Stat allocation costs can fall into three categories: AP, JP, and items. Gaining AP is done through levels, which I'm sure many of you are already familiar with. However, stat allocation can also be done through Job Points if you decide to not use AP at all. Granted, you'll need the Job Points plugin to take advantage of this. And finally, if you don't wish to use either AP or JP, you can use items instead.

Another interesting thing about the cost system is, you can also make the cost rise depending on how many times the stat has been allocated into. This can all be done with a formula and will be shown by default in plugin itself for MaxHP and MaxMP AP allocation.

Those with access to the beta sample projects can find the Stat Allocation plugin in its beta form there to download and try out! :D

I hope you're all excited for this plugin!

Files

Previews only

Comments

Anonymous

Hey yanfly, I have a... compatibility? question... I made a custom parameters plugin (that I kinda named New Parameters for some reason and it is too late to change now)... So, not only in my case but of other custom parameters plugins, will they be able to be added to your plugin by the user, or will we have to add compatibility patches or something like that?

Yanfly

That would have to be done by compatibility patches. This is because there's too many different ways that new parameters can be added in through plugins and it's difficult to account for all of them.