Plugin Vs Engine Editing

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
I'm currently freelancing for a project and I just got asked to implement a system that would replace Yanfly's SkillLearn and JobPoints plug-ins.

I'd like to develop this so that it can be shared, and I understand that a plug-in would be more portable.

That being said, plug-ins have code overhead I'm trying to avoid.

The problem is the solution, I get that. However, is there value in editing the engine directly?

I've already co-opted the equipment system to trigger events so I can control skill learning based on equipped armor and this was after 20 minutes of work. If I had to work it as a plug-in, I know it'd be harder.

I'm also thinking, if the developers used git, my changes could be merged in.

Draw-back is: I'd need to come in to change things, but that's what hourly rates are for. And I'm trying to build the changes to leverage the database so that the details can be handled outside of code.

I'd appreciate any feedback. I know I'm making it harder for me and I'm probably just looking for a bit of validation...
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,023
Reaction score
7,026
First Language
German
Primarily Uses
RMMV
One of the biggest problems with directly editing the engine files is that all those edits vanish as soon as the project needs to be updated to a future engine version.

With plugins that override the existing code (that is what your overhead is for) it doesn't matter if the core files of the engine are replaced with newer versions (at least not as long as the function names remain unchanged, which they usually do).
But if you edited the core files, then you would have to re-enter those edits after every project update as that replaces all core files.

Because development of the core engine slowed down, this is not as critical as a few years ago when a new core update came out every few months, but it is a problem.

Additionally rewriting the original code may cause incompatibilities with plugins that make excessive use of the core functions, although that should be covered by bughunting the changes.
 

glaphen

Veteran
Veteran
Joined
Jan 13, 2019
Messages
326
Reaction score
120
First Language
English
Primarily Uses
RMMV
I don't think those plugins would cause any lag problems anyway and plugins are easier for distributing to others. Personally I've been working on combining all plugins I use and core scripts into one file since I do have lag issues and it seems easier to search in one file for things while it also helps me learn the code. Just finished up action sequences and remade them so they don't use notetags at all and use async waits instead. Removed half the plugins I didn't really need and half the code from ones that I do with no more massive alias chains and optimize anything I see for speed over readability, only like 1/10th done. As for updates it isn't really hard to add changes made by them with notepad++ compare plugin, if there's ever even an update.
 

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
One of the biggest problems with directly editing the engine files is that all those edits vanish as soon as the project needs to be updated to a future engine version.

With plugins that override the existing code (that is what your overhead is for) it doesn't matter if the core files of the engine are replaced with newer versions (at least not as long as the function names remain unchanged, which they usually do).
But if you edited the core files, then you would have to re-enter those edits after every project update as that replaces all core files.

Because development of the core engine slowed down, this is not as critical as a few years ago when a new core update came out every few months, but it is a problem.

Additionally rewriting the original code may cause incompatibilities with plugins that make excessive use of the core functions, although that should be covered by bughunting the changes.
I appreciate the response. Would git not be a viable alternative to this? If you create a new branch, update the software, then merge the branch into origin, you should be good. And if there are any conflicts, you can resolve them manually. PITA, but again, hourly rates help here.

The more I consider this, the more I'm convincing myself it's fine. It's a bit of job security for me, and I can optimize the code I'm building as opposed to having the overhead of the plug-in system.

As it stands, looks like I'm going to have a config plug-in anyway that'll load in variable data like Type IDs.
 

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
I don't think those plugins would cause any lag problems anyway and plugins are easier for distributing to others. Personally I've been working on combining all plugins I use and core scripts into one file since I do have lag issues and it seems easier to search in one file for things while it also helps me learn the code. Just finished up action sequences and remade them so they don't use notetags at all and use async waits instead. Removed half the plugins I didn't really need and half the code from ones that I do with no more massive alias chains and optimize anything I see for speed over readability, only like 1/10th done. As for updates it isn't really hard to add changes made by them with notepad++ compare plugin, if there's ever even an update.
I'd love to pick your brain on plugin development if you want to meet up over maybe Reddit?

And yeah, git is like notepad++'s compare plugin except it does the changes for you and lets you go back to previous versions if, say, something introduced a bug.

Like I said in my last post, I'm kind of convincing myself at this point as any professional/more-serious-hobbyist project would have some sort of version control.

Ultimately I'm trying to avoid plug-in lag, conflicts, and note-tag management. At this point I'm not touching core functionality, only triggering events based on engine activity, e.g. equipment changes. But more serious changes could potentially affect the core engine which could in turn effect plug-in behavior. Again, I'm kinda seeing that as support hours versus a draw-back.

I think the benefits of building functionality into the engine, as opposed to the plug-in system, outweighs the cons. Lots more design space.
 

Eliaquim

Raze: The Rakuen Zero's Guardian!
Veteran
Joined
May 22, 2018
Messages
1,269
Reaction score
543
First Language
Portuguese - Br
Primarily Uses
RMMV
Hi!
Interesting question. When you mean using the git feature, you mean that all the codes will be handled apart from each one, but you will "mount" all of them into the core files with this git feature? (Sorry for asking a question ^^'')

But answer you now, I think the overhead of the aliasing or overwriting code is not a big thing for you to be concerned(unless you make a lot of aliasing, I mean a lot). And if you plan to share your code as you said in the first post, the plugin is really the best way.
And is important to do your code with this in mind, because I had an experience in doing a plugin just for me(no help files, no plugin parameters, etc). But later, I decided to share it, and it was a pain to "translate" the plugin code to suits other people to use and understand how it works.

Just sharing a newbie experience ^^''
 

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
Hi!
Interesting question. When you mean using the git feature, you mean that all the codes will be handled apart from each one, but you will "mount" all of them into the core files with this git feature? (Sorry for asking a question ^^'')

But answer you now, I think the overhead of the aliasing or overwriting code is not a big thing for you to be concerned(unless you make a lot of aliasing, I mean a lot). And if you plan to share your code as you said in the first post, the plugin is really the best way.
And is important to do your code with this in mind, because I had an experience in doing a plugin just for me(no help files, no plugin parameters, etc). But later, I decided to share it, and it was a pain to "translate" the plugin code to suits other people to use and understand how it works.

Just sharing a newbie experience ^^''
GIT is a version control system. Basically, you store a copy of your files in a repository. Any time you git commit a file change, GIT will keep track of those file changes. So you'll have multiple versions of a file for every change you've committed. So it's not a compiler, it's a text file change tracking system. I would recommend reading this: https://en.wikipedia.org/wiki/Git

And you're perfectly fine asking questions. This is a discussion :)

I agree with you. The benefits of a plug-in is portability. Others can plug-and-play. With my approach they would have to set up version control, configure whatever options I expose in a plug-in, and go from there. Any custom implementation would need to go through me.

That's the good and bad. Good because I can charge for support. Bad because people will be disuaded from it.

However, after having explained that, I feel only more serious efforts would be interested in my work. Which means they would be able to customize it themselves, or would be willing to pay/skill-trade with me.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,085
Reaction score
5,698
First Language
Indonesian
Primarily Uses
RMVXA
Compatibility, portability, and usability are a thing. Which is why the plugin is developed as they are. Why there is a notetag? simply because the user will use it easier. They don't know how to edit the code directly so notetag is easier. A lot of aliases because you don't know what they will use in their game.

If you only do this for your own or somewhat private, you can do it as you want. Edit it directly? yes, you can do that. In fact, I sort of do it myself (in VXAce). If you ask the value, you could consider that "harder to steal" could be the value so that the average user who probably going to hack your game unable to use the code without adjustment because you changed how the code works.
 

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
Compatibility, portability, and usability are a thing. Which is why the plugin is developed as they are. Why there is a notetag? simply because the user will use it easier. They don't know how to edit the code directly so notetag is easier. A lot of aliases because you don't know what they will use in their game.

If you only do this for your own or somewhat private, you can do it as you want. Edit it directly? yes, you can do that. In fact, I sort of do it myself (in VXAce). If you ask the value, you could consider that "harder to steal" could be the value so that the average user who probably going to hack your game unable to use the code without adjustment because you changed how the code works.
I think this mentality is great. It's very community focused.

However, at the cost of free and open availability, I think the allure of deeper customization is enticing, even if it means having less agency.

Again, I think I'm looking for validation here. Would users prefer a more deeply engrained, somewhat bespoke system? Or something designed to fit any project?

I could be wrong, but so far I haven't really heard a strong, technical argument, against my approach.
 

ImaginaryVillain

Now A YouTube Cool Kid! =D
Veteran
Joined
Jun 22, 2019
Messages
421
Reaction score
1,526
First Language
Absurdism
Primarily Uses
RMMV
I'm not going to lie, I love to try out assorted plugins. But I wouldn't really bother with unofficial base file changes. It mostly comes down to making my own plugins and not wanting to be concerned that the functions they use have been ripped out from under them, there's just no upside. Where as with a plugin I can see the code it brings to the table and make compatibility alterations.

I suspect this is going to be a very hard sell for people. Especially with the "promise" of them having to pay you money to change stuff. But who knows, maybe if you produce a good enough product people will be convinced.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,085
Reaction score
5,698
First Language
Indonesian
Primarily Uses
RMVXA
Again, I think I'm looking for validation here. Would users prefer a more deeply engrained, somewhat bespoke system? Or something designed to fit any project?
That depends on what the "user" is. Is this your "user" your client from a commission? if yes, then you should ask them directly and ask a straightforward answer. If they want your plugin to be as portable as it should be, then you do it. If they ask that it needs to be specific to their game, then you do it. If they prefer note tag, then you do it.

If the user is the wide community, like, every people around here, then you probably want to make your plugin as compatible as possible, taking a measure if the user put Yanfly's library or not. Even with that, most of the plugin dev got tired and just put a disclaimer that they don't want to bother with compatibility despite all the effort to make it compatible. After all, when your plugin infamously becomes incompatible with everything else, the user tends to stay away from yours.

If the user is yourself (or a small community). Everything else is irrelevant. You do want you to want to do. Do you want to change how eventing works? You can do it. In fact, I have changed how the game read the default database by making Weapon database as a secondary state database (which is perk system) because I don't want to dump it together into a single state database and I'm not using weapon database for a weapon (my game does not have weapon change). And I don't think many people would want this.

EDIT for TLDR
Make a general plugin as general, and specific plugin for specific.
This is also why Yanfly stopped the support for CTB prematurely because it is only for a specific niche than general use.
 
Joined
Dec 16, 2017
Messages
110
Reaction score
280
First Language
English
Primarily Uses
RMMV
But I wouldn't really bother with unofficial base file changes.
I was reading through the whole thread with the plan of just voting for a plugin implementation (for all the reasons stated above) but ImaginaryVillain's point is maybe the best of all. Beyond any potential IP issues, I would never overwrite my core files. Partly because I've made small changes in mine that I wouldn't want to lose, but more broadly because it just doesn't feel like a good idea.
 

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
I'm not going to lie, I love to try out assorted plugins. But I wouldn't really bother with unofficial base file changes. It mostly comes down to making my own plugins and not wanting to be concerned that the functions they use have been ripped out from under them, there's just no upside. Where as with a plugin I can see the code it brings to the table and make compatibility alterations.

I suspect this is going to be a very hard sell for people. Especially with the "promise" of them having to pay you money to change stuff. But who knows, maybe if you produce a good enough product people will be convinced.
I appreciate your take on it. As I'm working now, I'm finding that it's easier to keep my code organized in a plugin with the configuration. I haven't had to make any code changes yet and I'm suspecting I might not have to. But having the option is a plus. I guess it comes down to the feature request.

And yeah, there is an implicit promise that it'd have to be paid for. But it's a sliding scale. Someone like you would be able to take something I built and modify it.

Someone who doesn't have the programming chops would find it difficult if not impossible. At that point I would be able to "blunt the edges" at a premium. Or they could bring someone like you in to create a plug-in for them at your own pace. This is contingent on the fact that something doesn't already exist.

There isn't a clearly defined value-added component unless I can sell the inaccessibility of the feature as a trade-off for a more bespoke solution. But tech isn't sexy. I can't trade on frame-rate or load speeds. What i build is supposed to "just work" and with that ideology not a lot of people will want to open their wallets.

That depends on what the "user" is. Is this your "user" your client from a commission? if yes, then you should ask them directly and ask a straightforward answer. If they want your plugin to be as portable as it should be, then you do it. If they ask that it needs to be specific to their game, then you do it. If they prefer note tag, then you do it.

If the user is the wide community, like, every people around here, then you probably want to make your plugin as compatible as possible, taking a measure if the user put Yanfly's library or not. Even with that, most of the plugin dev got tired and just put a disclaimer that they don't want to bother with compatibility despite all the effort to make it compatible. Afterall, when your plugin infamously become incompatible with everything else, the user tend to stay away from yours.

If the user is yourself (or a small community). Everything else is irrelevant. You do want you to want to do. Do you want to change how eventing works? You can do it. In fact, I have changed how the game read the default database by making Weapon database as a secondary state database (which is perk system) because I don't want to dump it together into a single state database and I'm not using weapon database for a weapon (my game does not have weapon change).
My target audience is serious hobbyists. For a few reasons: they get projects done, their projects tend to be more interesting to me, and they tend to offer interesting challenges.

I appreciate coding. At this point I'm working for free. I'm less concerned about widely available plugins, and more concerned about solving interesting challenges with implications outside of RPGM.

I was reading through the whole thread with the plan of just voting for a plugin implementation (for all the reasons stated above) but ImaginaryVillain's point is maybe the best of all. Beyond any potential IP issues, I would never overwrite my core files. Partly because I've made small changes in mine that I wouldn't want to lose, but more broadly because it just doesn't feel like a good idea.
I appreciate your response. Your mentality is where I thrive.

First, modifying the JS engine isn't modifying the editor software so no IP conflict there.

The plug-in system is provided as a means of extending the core engine but does not indicate that modifying the engine is prohibited.

It might feel like a bad idea to you, but try to imagine it for a moment. Imagine having a different baked-in battle system. Imagine being able to do something in your game that no one else will have, that'll nudge you out of that cookie-cutter mold so many people complain about.

The system I'm working on now is kinda like materia but with purchasable permanence. Yan has the skill learn and job points systems, but you have to play by their rules. I was brought onto this project to simplify the process. They know what they want. And I'm willing to do it because so far it's been easy and fun.

That being said, isn't there any system or functionality you wish your games had that you can't easily obtain by Frankenstein'ing plugins?

End of the day, my mentality may be wrong. I'm of the mind that game makers want to distinguish themselves, not be handcuffed by the same set of rules as their peers. But I understand there's an appeal to doing things the way they've always been done. A sense of camaraderie?

Anyway, I appreciate the feedback. Thanks!

Edit: restriction breeds creativity. I've spent a lot of time defending myself. I may very well be wrong. So far I've not reached past the plugin file i created. Maybe that's all there is it.
 

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
EDIT for TLDR
Make a general plugin as general, and specific plugin for specific.
This is also why Yanfly stopped the support for CTB prematurely because it is only for a specific niche than general use.
It should also be noted that Yanfly retired. Trying to work around the bundle of Plugins they built was becoming a logistical nightmare.

I'd like to find some middle ground between plug-in and bespoke.

Also, I'm sure if Yanfly was making more money they wouldn't have stopped. Money is the ultimate motivator. It doesn't feel good to have a skill and then give it out for free. Internet karma doesn't pay for Uber eats.

But, I don't think this is the right environment to try to deploy a monetization strategy on. It's mostly hobbyist and false-starters (I should know, I was in the latter camp myself a long time).

I guess I'll have to see where this project takes me.
 

mlogan

Global Moderators
Global Mod
Joined
Mar 18, 2012
Messages
14,650
Reaction score
8,079
First Language
English
Primarily Uses
RMMV

@Geovane , please avoid double posting, as it is against the forum rules. You can review our forum rules here. Thank you.


You can quote multiple posts in one response by hitting the +Quote button for each post. Better yet, just tag people you want to specifically address by using the @ symbol and their username like I've done here.

Also, I'm going to move this to Learning Javascript as Plugins in Development are for showing progress on a plugin you are working on for release. Learning Javascript might not be the perfect place for this discussion, but it's better.
 

ImaginaryVillain

Now A YouTube Cool Kid! =D
Veteran
Joined
Jun 22, 2019
Messages
421
Reaction score
1,526
First Language
Absurdism
Primarily Uses
RMMV
It's worth noting that you can use plugins to just completely overwrite the core functions of MV if you want. People often do it with their "Core" plugins, such as Yanfly, Quxios, or Victor. Yanfly's literally rewrites the below player event interaction amongst other things, and reworks the error system.

But really I think you overestimate the overhead the plugin system causes. Sure, poorly programmed plugins, or a bunch of conflicting ones are an issue. But stuff like the Chrono Engine, Ultra Mode 7, or even just my current project (see the video in my signature) showcase that you can do impressive things all with just plugins.

That being said, if you release some variant of RM.... I will at last look at it, if nothing else than out of pure curiosity. Though clearly I'm way too far into my project to change core files/engines now even if I wanted to. :LZSwink:
 

geovanie

Freelance Dev
Member
Joined
Aug 19, 2016
Messages
15
Reaction score
7
First Language
English
Primarily Uses
RMMV
@ImaginaryVillain I'd love to pick your brain about your project some time.

At this point I've gotten far enough along to realize that plugin development is actually the way to go. The reason for this is that modifying the engine files does not expose functionality. With the plugin update from v1.5.* you can do a lot more with it.

So, rather than writing a tool to duplicate the functionality of the plugin system, I'll just use it. And, if I find some issues down the line, then I'll consider making a GitHub repo for deeper changes that'll likely use the plug-in system to provide a user-friendly interface vs managing JSON files.
 

ImaginaryVillain

Now A YouTube Cool Kid! =D
Veteran
Joined
Jun 22, 2019
Messages
421
Reaction score
1,526
First Language
Absurdism
Primarily Uses
RMMV
Now that I'm publicly showing off my project, I'm always down to talk about it. Feel free to PM me whenever. Can't promise I'll tell you how I did some things though. My random map generator is soooooo a trade secret at the moment. :LZSwink:

But yeah, it's just so easy to setup a "mini engine" with a core plugin and build plugins off of that. So reinventing the wheel just sounds time consuming. The only real limitation I often come up against is the hard limitations of PIXI. But the plugin system can't exactly overwrite those, at least not that I've seen.
 
Last edited:

GE_Peter

Villager
Member
Joined
Dec 13, 2016
Messages
25
Reaction score
3
First Language
English
Primarily Uses
RMMV
@geovanie
You said there was overhead in using the plugin system rather than editing the engine .js files directly. Do you mean in performance in terms of FPS?
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

Currently playing final fantasy 3 on DS. It's an old one but its a classic.
BCj
Gotta love some gossip :D
Please do not buy games from g2a.com. The sellers have total power over you. The website has many scam sellers. It looks cheap, but the key code didn't work.
A while back I was having fun making my own custom tiles, then I hit carpet... why is it so difficult!? Lol.

Forum statistics

Threads
97,946
Messages
948,074
Members
129,200
Latest member
jakeofblades
Top