Do you guys prefer writing one huge script or multiple smaller ones?

So lately, I've been working on this "battle system" and it was going pretty well.

Though lately I've been getting into a habit of trying to take certain parts of the script - and editing them so they're all independent of each other. So now I can kind of mix and match them safety if I need parts of them - and I've been wondering if there's any use to having done that.

I guess it's easier if there's an error - since I can just single things out easier, though it does make everything feel sort of "disconnected" as a result of that.

So I guess I was kind of curious to how you actual scripters feel about things like that.

Are you more comfortable with just everything in one script, or do you prefer to dig through little text pockets? And if you feel that they have any pros/cons to them that need to be looked out for?

I like one huge script much more than many little ones. Yes, modular scripts are not a bad thing, but one large script is much more optimizable, because you can simplify a ton of functions compared to a fully modular plugin.
For the illustration: the core engine is made so that people can edit it easily. However, the optimization is terrible, because the scripts are connected together rather loosely. It's far from modular, but...
Enhancing this engine we have Yanfly plugins. They're great plugins by themselves, but they're not optimized for speed, because they require functionalities if a plugin is there or not there (which hurts the performance pointlessly in case these plugins are not there) and even the endless aliasing of the update function on Scene_Map hurts the performance a great deal.

So I'd say the advantage of modular plugins is a high level of customizability and ease of use and enhancement. The disadvantage is performance damage.

Depends on what are you aiming for. For battle system, I used to make it smaller part. One handle sprite, one another handle game object, one handle scene, etc. It's easier to track that way rather than scrolling through thousand of lines. But for a script you want to distribute, I'd put together in a single large script.

For personal use like making my own game, I use separate smaller script. One slot represent one feature / modified default script for a certain function, again for easier track.

Interesting. In Ace, there is no performance damage afaik by using different slot of script. So maybe that's why rpg_object.js are packed together in one single file?

Multiple smaller ones.

I personally think of chapters or modules when scripting. A battle system for instance. Such task takes a lot of effort from one.
So I have a module that covers only the 'mechanical' part of the battle system. While another module is solely dedicated to the visual information from the battle system. That gives every plugin it's own purpose.

With modules I can work on one aspect without touching the the whole system. I can even have someone else work on another module without him changing the whole thing. Plus I can test the functionality where it matters. Do I have a visual error? So it must be found inside this module. Etc.

Naturally, having that many plugins forces you to have an optimal 'connection' between them. That might actually cause more code than one big script I believe.

The only upside I see in gigantic plugins are them taking less space inside the plugin manager.

I suppose I prefer fewer scripts. For a battle system, I would have one for the spriteset and the sprites, and another one handling the battle process.

This is a good point. I was modifying an ABS script once, and tried to modify a shielding ability to directly change the player's sprites. When I decided I wanted more characters, or different animations for the shield... well, it was a huge pain trying to put that in. Would have been easier if I'd separated animation from the actual action.

I'm all for optimization, speed, and easy distribution. But if it were me, I would at least start with code that's easy to read and swap around; only gluing it together when I know it's working.

Personally, I like to have everything as module as possible; however, mv doesnt really accommodate this. Yes, you could have each class loaded in its own plugin file, but load times....

IMO, The best way for writing rpg maker code, is to write your main core script in such a way that it allows for a certain level of modularity. For example, I wrote an input system for ace (here) where the main core of the input system defines and calls functions that do nothing. However, I then have additional plugins/scripts that utilize those functions (cheat code systems, mouse, keylogger, more...). This means I dont have to alias the input module over and over, and if someone isnt using any addon script, then they arent really affected negatively from an empty function being called. I mean, yes, it would obviously use some about of cpu performance to call the function, but over all, its negligible.

Additionally, smaller script files are much easy to manage. I'd much rather look over 20,000 lines of code with each class in its own, clearly labeled file. Compared to having all 20k lines in one file its much easier to work through.

I'm not sure you understood what the OP was asking about.
I'm talking about modular plugins in my post, because I think this is what the OP is meaning as we can see here
and here:

So I think the question is whether to make one large plugin or several modular parts that are independent of each other.
MV and VXA are not modular - you remove one module - the game will crash.

On another note to address just the problem of one file vs many files, I like it more when there's a bigger file instead of when they're separated to myriads of class files. The reason for that is, when the classes are well put together in files, I find it easier to navigate in them, because when there's a function call, I usually don't need to search in other class files to find that one function's/method's definition (sometimes they're not as easy to find, because you have to find what's its class and then you'd have to open the file, if it's not there, you have to open its super's class file,...). I also find it rather easier to implicitly understand what the classes together serve for as a whole if they're in one larger file. There would be no performance difference in one very large file vs. ten thousand small ones, just separating them is just syntactic sugar.
And no, I usually don't have problems with scrolling through 20k lines - I can use Ctrl+F to find what I'm searching. :D So most of the time I'm right where I need to be, even with a larger file.

Whether understand or not I think it has nothing to do with my original question. Like, if you separate js script in MV, does it impact performance than putting it together in a single file? My question was all about performance.

Because thing like this in Ace doesn't have much performance damage

@TheoAllen

Then can u explain what is this for?

I repeat once again. There's no performance loss if you separate one huge script into dozen small ones. But this is NOT the case. The case here is making one huge plugin vs. making a modular plugin consisting of small modules that are working together if they're used, but are independent on each other. Which means you're going to have to spend extra code making these small plugins work together and since that means extra ifs, you're going to impact performance due to the extra code.
In other words it's not the case where, for illustration, you just separate rpg_core.js into its class files. It's a case where you make all classes inside rpg_core work independently and deleting one won't crash the game. In order to make that work extra lines of code would need to be spent and dozens of ifs every framw. That is going to hurt performance.

If it can be done that way, multiple smaller ones. Obviously if the whole system is dependent on everything and can't be split up then one huge script is the only way but if it's lots of functions that all work but it can work with some missing, then multiple smaller.

When I'm writing a plugin I write all my code in separate files and then bundle them together into one main plugin, so much easier to retain the code as well as debug. This also helps you keep things modular, I mean you can easily make your code modular in one large file or many small files, making modular code has nothing to do with files.

I could give you a ton of reasons why you should make your code as modular as you can, obviously not all code can be modular but do your best to make things function without a ton of outside influence. This makes less buggy code, it makes readable code and readable code is easier to debug and retain. Modular and functional code is far superior than those who write code imperatively, but a good plugin developer will mix both styles and use what they can to their advantage. In the end though, make the code readable, try your best to lessen outside influence and you will forever be grateful for how much easier it is to debug and maintain code.
Those who argue against modular code either don't do it enough to see the benefit or are too comfortable with the way they program and have a hard time changing that to a more functional/modular programming style. So, do what you feel is best but don't be afraid to try new things, which is exactly what you did here. The best way to figure out what works is to try many different options so you know what to expect, and in the future you can plan your code based from previous experiments. Happy coding!

This is pretty much my set up for most of the Battler Sprite functions.

It does look kind of cluttered to me, like this, but there is a small comfort in going in to these and seeing not too much text in them. I don't know if it's just me but sometimes I eyes have trouble keeping up with much longer scripts.

A lot of them used to be a single script, like the idle sprite and animations we're. I think I do have to agree that it might be best in the long run, to maybe condense them back together when I got everything I need - when I start attempting the next game.

Though I think it wouldn't be a bad idea to just save them all as separate text files in the case I end up not needing some of them later on. And there is some kind of comfort in the idea that they all work independently for the most part - outside of the Idle index needing some variables added to Sprite Index.

I come from an object oriented background so I will always separate into multiple files. This is actually more important in compiled languages as if everything was in one file, even if you have a bunch of classes defined in that one file, you have larger compile times as everything within that file needs to be recompiled again, which can be a nightmare on larger projects. Breaking them up into smaller files allows only files that have changed to be recompiled again, which on larger projects can greatly reduce compile times.

Of course with JS, this isn't much of an issue as code is interpreted so number of files isn't as relevant as Poryg already said. There is an organization benefit to breaking your code up into multiple files or plugins for organizational and maintainable reasons. It is also useful in testing a 3rd party plugin (Yanfly for example) and then seeing that it doesn't work as advertised. Multiple plugins that you can disable help in isolating where the problem is in one of your plugins over one mega plugin. Sure as Poryg said that you could get more performance out of one big file over many modular files, but the performance gain at the lost of convenience is generally trivial and not worth having more organized and maintainable code in my opinion. I mean MV in of itself is a convenience over performance engine to begin with.