MZ - Your opinion about releasing plugin features?

I'm currently working on a complete refactoring of my Advanced Character System plugin. Over time, and with my new discoveries about how RMMZ works (from a code perspective), I've started adding new features that weren't available before, like:

• disassociating 8-direction moves from 8-direction character sprites
• managing party formation on the map, including the ability to manage follower moves independently of the player
• adding new moves and actions to make beautiful cutscenes with specific character sprites
• adding a proximity sensor to make some specific moves more natural
• and many more to come...

In short, I've gone from a plugin that just lets you customize character sprites on the map, to a plugin that lets you perform advanced actions for cutscenes.

The point I'm getting at with this thread is whether, in terms of best practice or preference, it's better to have an all-in-one plugin, or a plugin that does one specific feature at a time... even if it means developing/maintaining multiple plugins to get the desired feature set.

So from a game developer's point of view, what would be your preference? And for plugin developers, what's your recommendation?

Really doesn't matter imho. Whatever makes the most sense efficiency-wise I would say. I got plugins that rely on the "Main thing" (Eli Book for example) and got independand plugins. The only thing I would not recommend is an all in one plugin. Too many parameters and settings to disable/enable is just overwehlming to work with.

From the user's perspective, it's generally preferable to have plugins related to a specific functionality.

Look at the VisuStella plugins, especially the cores - they're so huge, with so many features, that very many people can't process all the information or find what they're looking for when it comes to the plugin parameters or documentation.

You might logically say "well, this is my cutscene functionality plugin," and that works fine. But it might also make more sense to split "follow control" into its own plugin separate from "character motions" and separate from an 8-directional movement plugin.

Having them split is easier to read, imo. Everything bunched up can get overwhelming.
It can be a teeny tiny bit irksome to have to download a plugin or two I've no interest in using in order to use another due to dependencies, but its pretty much a none issue. I just stick those in the plugin folder, add to project, then leave them be

IMO... Compatibility with competing features and plugins is the top concern. After that, combining as many related features into one plugin is preferable. After that, expansiveness of individual customizability is desirable.

Good point. That's why I try to create plugins that are as plug&play as possible (i.e. with no to few settings to manage).

It's also good that you mentioned @Eliaquim's plugins... I would have liked to hear their opinion on when they decided to develop their core plugin (Eli's Book) as a base to make the others. Was it a design choice from the start?

Although the proposal is relevant, what happens if the user wishes to use a feature-plugin (e.g. follow control) in his game outside the general context for which this feature was developed (managing cutscene)? I see a risk of increased support with requests such as “can you make this plugin work without the XYZ plugin”, when it was designed as one of the building blocks of a more complete package.

I love how two back-to-back comments have opposing visions :). From my point of view, I think that by limiting yourself to 1 plugin = 1 “feature”, you limit the risk of incompatibility with third-party plugins... but you also make the ecosystem of your plugins more complex, since you also need to ensure that they are compatible with each other while optimizing performance and avoiding duplication of code/functions.

I like plugin features to be a la carte so I can choose the best plugin for each feature for my use case. It also makes them easier to search and edit.

Another good point... I often forget that the user is also (sometimes) a developer and that he may be able to customize my plugin to meet his specific needs (which I haven't necessarily covered in the first place).

Even if the user isn't a developer we get people here requesting changes to existing plugins.

if your plugins are dedicated to one feature and are entirely self contained, its actually easy to make them compatible with an outside feature as it interfaces with a limited number of things.

if you have an all in one plugin that you use for one specific feature, but it also does a separate thing that makes it incompatible with a secondary plugin you installed for another feature, your options are to now
- go through the first one and all of its features, change it, and hope it doesnt cause some ripple effect within itself or cause further incompatibilities down the line
- edit every future plugin you use to be compatible with the first one
- replace the first plugin entirely and lose ALL of its features to not break another
- wait for the author of the first one to make an addon for the second feature

while none of these are "ideal" per se, if the first plugin was its own single feature, then removing it would only result in temporarily losing one feature until a replacement is found/made

With all the comments received so far, and the partial votes results, I think it's time for me to dive back into my plugin code and think about how to cut it up in a smart way... :LZSgrin:

One question puzzles me though: is a core plugin (a la Eli's Book) good practice? I've always managed to avoid developing one, even if it means duplicating code (e.g. Scene_Boot.prototype.loadGameFonts, which is overwritten in two of my plugins with exactly the same code called separately each time I load custom fonts).

Hi there!

Well, I will give my thoughs. using a core plugin has it's pros and cons.
My reason to use it was, mainly, to avoid repeat the same code in all plugins.

See, on my core plugin, I have this code:


They are responsable to make easing animations, kinda like the Move Picture can move with an ease animation(Slow Start, Slow End, etc...).

A lot of my plugins, uses that to position windows or sprites. As you can see, they have 682 lines. If I don't use a core plugin, I would have to copy and paste that same code, on all plugins that uses them.
This would make each of these plugins, bigger, with more code.

If it, perhaps, has any bug on that Anime codes, I would have to fix every one of these plugins.
But, if I use a core plugin, I just need to fix it once, on the core plugin.

This is good for one side, but bad for other. Because, if something is wrong with the core plugin, it will affect all the other plugins.

So my opinion is, that is a matter of design. But if it get well implemented, I believe it turns out a performance improvement on the workflow of the developer.

It also, only makes sense, if you have a lot of plugins. Like, I do have 60+, so, a core plugin helps me a lot by not repeating the same code on my other plugins. That speeds up my development a lot.

Thank you @Eliaquim for sharing your experience. In my case, I'm far from having a plugin ecosytem as full as yours... but if I take @ATT_Turan's recommendations into account, I'll soon arrive at a sufficient number of plugins to think about a core plugin. :)

I don't see why core script has any problem. A core doesn't have to be a plugin, it can be a lib file, a dependency for your plugins.
For example, rmmv/mz use pixi.js, it is a lib and the code can't work without it.

Or you can use some package manager like npm to build your source code, so you don't need to copy the same code.
But personally I prefer individual lib files, so I don't need to install a dev environment.

That gets more complicated with nonstandard installation instructions for the users, to no real benefit - what point is there to making it not a regular plugin file like every other plugin author for MV's and MZ's lifetime has done?

How can that be more complicated? You just copy and paste the file(s), like other plugins. >_>

Because it's pasting a file into a directory that most RPG Maker users never touch. A directory that's separate from the other actual plugin.

If you don't see how that's different and potentially confusing to the average user, I'm not sure what else to say.

Just look at the number of support threads about the SRD plugins that have you place image assets into a different folder and how many people completely screw up those instructions. And that has a reason for it, those other files are needed by the plugin. You're suggesting this...just 'cause :stickytongue:

using a core plugin that I have uses a core code, to parse the plugins,
which saves me to make a lot of parameters to start with.

if 1 use 10 parameters, than 20 or recursive and more of those, it can go
into 100 of lines, with my core code to parse and recursive the params
with 1 line of code, it parses them correctly, saving me to add constant
recursive, parsing code or map to read the params or struct.

that is my main part :) as I save all my other functions in it too that I
could use over my other plugins.