[SOLVED] More Common Events or More Plugins?

[Ratatattat]

Hi there! I'm at the point where I can write my own plugins for many of my needs/systems in my game. For some of them, I already have evented systems set up; some involving just common events and some involving a communication between common and map events. But they all feel... messy, and "fragile", if that makes sense. And like there's a lot of different places I have to keep track of if I change or expand them.

Therefore, I was wanting to start converting some, if not most, of these systems (we're talking battle - which definitely will be a plugin - but also crafting, farming, relationships, etc.) into their own respective, centralized plugins, rather than these convoluted webs of common/map events.

However, I know that too many plugins can slow down a game or risk incompatibility (I do my best to alias and be cognizant of the other plugins I use to avoid the latter). Yet, I also thought that too many common events can also slow the game down.

From a performance standpoint, would it be more ideal to proceed with converting and/or creating these systems as custom plugins, or to keep them evented (and just try to clean them up the best I can)? If it's not that simple, what kinds of factors should I consider in making this decision for any given system?

Thanks!

 

[HexMozart88]

I don't think it makes a massive difference in performance as far as I know. I always like to see an evented system because it makes for more creative UI outcome, but I'm super biased as I am an eventer. Unfortunately, for a lot of stuff, there's no real way around making a messy system (especially menus, dear God) so if you're more comfortable using scripts, go ahead and do that.

 

[ATT_Turan]

I know that too many plugins can slow down a game

I don't know why you'd think that. The largest plugin I've seen is all of 218 KB, which your computer will load in a fraction of a second.

Doing a complex thing as an event vs. a plugin will take up slightly more space (and, again, we're talking on the negligible scale of kilobytes) and be slightly less efficient, because it needs to get parsed by the event interpreter before the JavaScript functions are called, whereas a plugin would do that directly.

But that difference in efficiency is also, like, within one processing cycle of your CPU. Effectively, unless your events are much longer or having to be called more often or having to do long loops that you'd avoid in a plugin, there's really no difference performance-wise.

Yet, I also thought that too many common events can also slow the game down.

I have no clue where you're getting this information about things slowing down the game. Neither plugins nor common events will have any appreciable effect on your game by their mere existence.

Stuff doesn't make your game slower by being there. It could make your game take longer to load when you first run it, but look at the total size of any given RPG Maker project compared to a typical video game - nothing you add in your code/events is going to have any effect on loading time.

Stuff can make your game slower by making your computer do constant/unnecessary things. So people making events that run in parallel and do loops and calculations and perform multiple commands without any wait commands...that slows down the game, but you can write code that's just as unoptimized.

 

[SGHarlekin]

Convert them is what I say. If the event-ed system feels wonky, chances are the scripted solution feels better. I don't understand all the fuzz about people trying to use as little plugins as possible anyway. If it works better, it works better. And most of the time also saves a lot of time on top of that.

(As a bonus, people will love you if you have a plugin that you think would be cool for others to have.)

 

[ShadowDragon]

evented can be good, if most need to run constantly or in parallels,
I would write those into plugins as to many parallels can make the
system lag and can break potentional parts of teh event like skipping
parts.

see an example of hour = 1, and to much lag will be 2 and breaks
the time system, specially if you want a switch flipping ON or OFF.

but do what you feel most confortable with though.

if you are unsure, create the plugins to make space in your common events.

 

[Ratatattat]

I don't know why you'd think that.

I have no clue where you're getting this information about things slowing down the game.

Just... everywhere I feel like I'm always seeing people talk about this, for example:

I don't understand all the fuzz about people trying to use as little plugins as possible anyway.

That's a thing, haha. People trying to use as few plugins as possible. And since I've seen people say too many can slow down the game, I assumed that was one of the main reasons why (in combination with the higher risk of plugin conflict).

And same with the common events, although I think it's mostly due to this:

So people making events that run in parallel and do loops and calculations

...which many of mine do Although I do add wait commands at least haha.

Doing a complex thing as an event vs. a plugin will take up slightly more space (and, again, we're talking on the negligible scale of kilobytes) and be slightly less efficient, because it needs to get parsed by the event interpreter before the JavaScript functions are called, whereas a plugin would do that directly.

BUT thank you for this information!! I hadn't thought about that, even though the difference may be negligible. At least, the reassurance that it doesn't really matter is helpful ^_^

 

[SGHarlekin]

Anything can slow down your game, if you do it wrong. But yeah. I'll always prefer plugins over eventing in most cases.

 

[Aerosys]

I think the rule of using as few plugins as possible is coming from beginners and rookies.

Devs should understand what a plugin actually is. When people start adding like 50 plugins that modify the battle system, then incompatibilities are very likely, but that's not because of the number "50", but rather because you added plugins that overlap each other.

In my project, I have Visustella plugins, Mode7, MV3D, visual filters, and my plugins... probably more than 50, and it still works fine because every plugin has its own space.

For example a crafting plugin; it will idle until the player actually does crafting.

 

[Milennin]

The upside for using events is that they will not cause potential conflicts with other mods. They also will never break due to an engine update. And they might offer you more flexibility if you can't write the code yourself and are stuck using only what others have posted.

But I guess if you can write plugins for stuff as easily as you can event it, it'll become a matter of which is the faster way to make it.

 

[ATT_Turan]

Just... everywhere I feel like I'm always seeing people talk about this

If you say so? I don't see anyone giving that advice/instruction on these boards. I've seen two or three people voice the misconception, which I recall correcting, but I've certainly never seen anyone here impart that.

The only thing I've ever seen told to people about using plugins is that the more you use (particularly from different authors), the greater chance you get of something causing a conflict. And that's absolutely true, but it has nothing to do with your game's technical performance.

...which many of mine do Although I do add wait commands at least haha.

And that's the point. You can basically have the game doing as much as you want so long as it's spaced out appropriately.

 

[Ratatattat]

Devs should understand what a plugin actually is. When people start adding like 50 plugins that modify the battle system, then incompatibilities are very likely, but that's not because of the number "50", but rather because you added plugins that overlap each other.

In my project, I have Visustella plugins, Mode7, MV3D, visual filters, and my plugins... probably more than 50, and it still works fine because every plugin has its own space.

For example a crafting plugin; it will idle until the player actually does crafting.

Thank you, this is such a good explanation! I vaguely figured as much, but I'm really diving head-first into all this so I wasn't 100% sure (traditional lessons for JS didn't work for me, I tried and forgot everything like the next day - going in to figure things out hands-on, and infer/ask how things work along the way, is what's been working for me).

I know it's a chaotic process and probably not the most efficient, haha... but hey, it's getting me results, and this kind of thread is part of my process of learning along the way So thanks again, this makes the issue much clearer to me.

If you say so? I don't see anyone giving that advice/instruction on these boards. I've seen two or three people voice the misconception, which I recall correcting, but I've certainly never seen anyone here impart that.

I must have just seen the misconceptions and not the corrections! No worries, we've just seen different things You probably see a lot more than I do - I probably have inconveniently missed any cases where nuanced discussion/corrections followed.

The only thing I've ever seen told to people about using plugins is that the more you use (particularly from different authors), the greater chance you get of something causing a conflict. And that's absolutely true, but it has nothing to do with your game's technical performance.

And I might have mixed up/melded these two concepts together in my mind, haha. Since I've only ever read posts like this in passing, before it became directly relevant to me, before working with JS and plugins myself.

That said, I was aware that how systems are evented or how code is written has the biggest impact. I just thought that was only one part of it, rather than the only real consideration. Thank you for setting the record straight for me

Thanks again guys! I feel better knowing that I just misunderstood where the performance impact of events and plugins comes from, and that I can take steps to make efficient systems regardless of which method I use!

 

[Arthran]

As other people have said, neither plugins nor events are inherently bad. It's what they're doing, and how they're doing it, that determines their performance impact.

As far as whether or not you should convert your events into plugins goes, there's not really a blanket answer for that. Some things are more suitable for plugin implementations, and some things are more suitable to implement with eventing. Some things should probably be a hybrid. Sorry if this sounds snarky, but if you're really at a level where you can convert all this stuff to plugins, then you probably should already be capable of determining which things fall into which category on your own. I'm not saying that you're not at the level that you think you are. I'm just saying that if you are at that level, then it's probably safe to go ahead and look at each situation on a case-by-case basis and trust your intuition on whether or not it should be converted into a plugin.

Now if I *had* to give some type of general response in terms of performance, I would say that plugins generally have the potential to yield better performance than events do. Aside from what ATT_Turan said about the event interpreter, there is another reason: You often have to jump through more hoops to accomplish the same thing with an event that you could accomplish with a plugin, and those hoops come with a performance cost.

For example, suppose that I want to execute some code every time the player enters a new map. With a plugin, all I would need to do is hook into Game_Map.prototype.setup(), or any of a number of other functions that could also potentially work. But if I wanted to do it through eventing (without having to scatter autorun events throughout my entire game, or having to edit every transfer event in the game), I'd probably need to create a parallel common event that is constantly checking to see whether or not the map has changed, and then have it execute said code if so.

The first example is much more performant, because the only time it ever does anything is exactly when it needs to. It has no impact on the game at any other time. The second example is impacting your game at all times, just so it can figure out when it really needs to do the real thing that it's supposed to do. Now as an isolated example, the impact is likely very small. However, enough small things can add up and become a big thing over time, so if you have the option to accomplish something less wastefully, it's probably a good idea to do so.

 

[Ratatattat]

Sorry if this sounds snarky, but if you're really at a level where you can convert all this stuff to plugins, then you probably should already be capable of determining which things fall into which category on your own. I'm not saying that you're not at the level that you think you are. I'm just saying that if you are at that level, then it's probably safe to go ahead and look at each situation on a case-by-case basis and trust your intuition on whether or not it should be converted into a plugin.

Not snarky at all! When I said I could write plugins for my own needs, I did not mean to imply that I think I'm an expert or anything. I'm definitely still a beginner, and as such will still be asking stupid questions for a while hahaha. I just learn as I go, on a step-by-step level, and inferring/working to understand how the wider scale of things works as I need to, when I need to extrapolate that understanding to do new things (I tried a top-down learning approach, didn't click; but ground-up has been really intuitive so far). There are some specific things I know I'll need to do that I don't know how to do yet, but I know I can figure it out because I've figured out similar things in the past, and at a certain point, clear patterns emerge and it's just a matter of finding a specific script call or core function to alias, etc.

But no, I'm not on a high level of coding ability and didn't intend for it to come across that way. I appreciate your answer though!

Now if I *had* to give some type of general response in terms of performance, I would say that plugins generally have the potential to yield better performance than events do. Aside from what ATT_Turan said about the event interpreter, there is another reason: You often have to jump through more hoops to accomplish the same thing with an event that you could accomplish with a plugin, and those hoops come with a performance cost.

For example, suppose that I want to execute some code every time the player enters a new map. With a plugin, all I would need to do is hook into Game_Map.prototype.setup(), or any of a number of other functions that could also potentially work. But if I wanted to do it through eventing (without having to scatter autorun events throughout my entire game, or having to edit every transfer event in the game), I'd probably need to create a parallel common event that is constantly checking to see whether or not the map has changed, and then have it execute said code if so.

The first example is much more performant, because the only time it ever does anything is exactly when it needs to. It has no impact on the game at any other time. The second example is impacting your game at all times, just so it can figure out when it really needs to do the real thing that it's supposed to do. Now as an isolated example, the impact is likely very small. However, enough small things can add up and become a big thing over time, so if you have the option to accomplish something less wastefully, it's probably a good idea to do so.

This is all very insightful in helping me make the decision for each case! Thank you

 

[slimmmeiske2]

This thread is being closed, due to being solved. If for some reason you would like this thread re-opened, please report this post and leave a message why. Thank you.