RPG Maker: Scripts vs Plugins

[Tsukihime]

Is there a difference between the two?


There are many suggestions that ask for "plug-in" support for RM. That's what scripts do: plug-in and use.

 

[Andar]

not exactly - in general computer use, plug-ins are files that are placed into a specific directory, and the program automatically detects and implements them.

This makes several differences between a plugin and how scripts in RM are used:

1) Plug-Ins need to be self-contained, you can't use something like an aliased function from another script in a plug-in.

2) usage of plug-ins is easier in most cases, since they don't care about order or where to place them in the script sequence.

3) ordinary, people expect to get a new "tab" to configure a plug-in, they don't (and can't) edit inside the plug-in.

In my opinion, plug-ins are easier to use (for the developer) at the price of being more difficult to configure (for the developer) and program (for the scripter).

 

[Tsukihime]

99% of RM scripts rely on existing scripts to function properly. Using plugins seems to defeat the purpose of what the scripting system is currently being used for.


Of course, there are many game engines out there that do use plugin systems and allow developers to easily customize their game...so maybe my 99% claim is misinformed.

 

[Galenmereth]

Couldn't we make a plugin system through scripting? As in, a script that sets up a framework for a plugin system? I'm not sure why we'd want to do it, really, but for a lot of things it could provide an easier-to-use alternative to scripts for less script savvy users

 

[Andar]

99% of RM scripts rely on existing scripts to function properly. Using plugins seems to defeat the purpose of what the scripting system is currently being used for.

Of course, there are many game engines out there that do use plugin systems and allow developers to easily customize their game...so maybe my 99% claim is misinformed.

No - but those other game's plugin-options are more limited than what can be done in RM with scripting, as Plug-Ins usually can't replace the basic engine.

As I said above - plugins have disadvantages compared to full scripts, but they are easier to use for those who can't script.

Couldn't we make a plugin system through scripting? As in, a script that sets up a framework for a plugin system? I'm not sure why we'd want to do it, really, but for a lot of things it could provide an easier-to-use alternative to scripts for less script savvy users

Not really - you can only make modular scripts (like Tsukihime and several others are already doing) and add the script modules in the script editor.

Real Plugins would require Editor modifications, and that's a break of the EULA and therefore not possible

 

[amerk]

I started typing this in the Suggestions for the Next RM thread, but realized it was off topic. So I moved it here, but others may have explained this much better.

The primary difference (from my understanding with plug-ins for RM2K/3) is that plug-ins hack into the maker and alter the source code, whereas scripts do not. Plug-ins are more popular with RPG Maker 2000 and 2003 since those programs did not include a script feature. Of course, because of how they are applied, they are considered illegal. And it's been said that if RM2K3 would ever be legalized, the plug-ins could not be used.

Plug-ins are not very flexible compared to scripts. Primarily because, unlike scripts, the user doesn't have to put much effort (if any effort at all) in using them. They simply download the plug-in(s) they want and apply it to the maker as a whole. With scripts, the user typically has to do some sort of configuration, whereas with plug-ins they do not. In that sense, they are a lot like plug and play scripts but without any form of configuration. Unlike scripts, though, a plug-in can access (and even change) the source code, so somebody who knows what they are doing can create a plug-in that can add advanced script-like features without requiring the user to have any program knowledge.

David "Cherry" Trapp's plug-ins are the most commonly used for RM2K3. The David and Goliath patches are probably the two most famous, since it breaks a lot of the limitations within the database, and even allows the user to access the editor even while playing in test mode.

I really don't know why people care so much about plug-ins, since scripts can more or less do the same thing that a plug-in can. For old makers that don't include a script feature, it makes sense. For newer programs, not so much. One reason might be less compatibility issues with plug-ins than with scripts. Another reason might because newbies who are frightened of touching anything script related might think it's easier, and less of a risk, to just install a plug.

 

[Galenmereth]

There's also the fact that the current script system can very easily break (wrong sequence of scripts, scripts overwrite a class method and a subsequent script expects a different behavior), whereas plugins are usually placement agnostic. There's also the ease of use of the traditional plugin support: Plugins are, traditionally, added through a GUI or a very simple "drag and drop into folder" system.

Personally I have no issue with the script system and actually really prefer it, especially since there's no boilerplate, which too many plugin systems have. But for non-power users it is a minefield waiting to be stepped on once you accumulate 20+ scripts...

 

[Tsukihime]

I've never done any plugins before (that other plugins might interact with).


Plugins sound like they would be very difficult to make compatible with other plugins. So for example, if someone wanted to use yanfly's scripts, then you can ONLY use yanfly's scripts (and anyone that developers plugins according to yanfly's specifications).


Has anyone developed plugins before and can address the compatibility issues?

 

[Galenmereth]

@Tsukihime: Plugins work by communicating with the host application via an interface intermediary. Wikipedia has a pretty good explanation: http://en.wikipedia.org/wiki/Plug-in_(computing)#Mechanism

So instead of having direct access to application class methods and functionality that you can extend, plugins would rely on a unified interface that it communicates through. This way, you don't have to worry about plugin compatibility; every plugin only relies on the common interface, thus Yanfly's plugin would work with any other plugin.

Of course, this also sheds light on the limitations of plugins versus scripts; plugins require an interface. If you need new interface functionality, you have to worry more about backwards compatibility. You can't go ahead and extend the host application interface from within your plugin.

I've not made plugins myself, but I've worked with quite a few in Rails and browsers. The challenge for the RM community if we wanted to make some kind of plugin system would be to all agree on using a common interface. It could be an open-sourced github repo, for example, with official builds compiled for easy "install" of the plugin script framework. But it would be a lot of work

 

[Tsukihime]

That makes sense. The plugins I've written for programs (eg: Noesis, Blender, etc) provided a few API calls required to work with the target application, but everything else I was free to do however I wanted to.


I guess the whole RM script base would need to be trashed because it simply isn't an interface but instead is a full game.


Things like the battle system and whatnot are hardcoded and therefore would need to be abstracted to allow different types of battle systems and whatnot (I've tried writing a plugin battle system using ruby aliasing conventions and such, but I never made a complete interface)


Definitely sounds like a lot of work, and not something RM in its current state can accomplish.


Especially since all scripts would basically be worthless since none of it is written for such an API.


Even the SDK I see for XP is not a real API, but just some re-writes for increased compatibility between scripts.

 

[Engr. Adiktuzmiko]

Personally, I would prefer the scripts thing, mainly because it seems to be more open to what the scripter wants (or how to do it, since we don't have a common interface)

 

[Ellie Jane]

From experience of using both, plugins are nice and all but they aren't as customisable. With RPG Maker, there's a lot of copy-pasting going on, games looking identical to other games because they use the same scripts and whatnot. With scripts there's a greater chance of it being edited and tailored to that game - even using parts of scripts to make something unique to that game. I think plugins have a greater risk of games just being drag-and-dropped feature lists.

 

[Engr. Adiktuzmiko]

I think plugins have a greater risk of games just being drag-and-dropped feature lists.

Which is the reason I think on why they want the plug-ins... 

 

[orochii]

I think plugins have a greater risk of games just being drag-and-dropped feature lists.

I anyway think scripts are too :V. Unless you can make/edit them, in which case you consider making changes so they really fit what you wanted.

But on this RPG Maker world, plugins are not worth it. It's hard enough to make custom DLLs (well, not really x'D, but sometimes it gets tedious when testing). The only plugin thing that made me get invested enough was Cherry's DynRPG SDK.

I think that instead of a plugin thing, could be useful to have an "Database Extension". A csv-like place where you add data. Or something similar to MySQL databases, where you make a table, and then add entries. You can manage, add and delete more databases and stuff. And you can make a certain field to receive images, text, number, boolean, or an object/array of objects. Here a graphical example, just for the lulz (?) xd.

But anyway, Ace people already have those sexy annotations everywhere,

Orochii Zouveleki

 

[Engr. Adiktuzmiko]

I anyway think scripts are too :V. Unless you can make/edit them, in which case you consider making changes so they really fit what you wanted.
But on this RPG Maker world, plugins are not worth it. It's hard enough to make custom DLLs (well, not really x'D, but sometimes it gets tedious when testing). The only plugin thing that made me get invested enough was Cherry's DynRPG SDK.

of course that means you at least need to be able to understand them a bit... because how can you customize something if you don't understand how to in the first place?

The idea was simply that scripts are less susceptible to being drag and drop since you can easily edit anything about that script as opposed to plug-ins

 

[Tsukihime]

You don't need to understand databases to use them well, just like how you don't need to understand scripting to customize and use them.


I've had the idea of an external database editor that complements RM's database so that we can pretty much move away from RM's own database, but I only thought of using simple serialization formats to store them as opposed to a full RDBMS, as you really don't want to force people to install it just to play your game.

 

[Engr. Adiktuzmiko]

depends on what you mean by customization... what I meant was modifying the actual running parts of the code (not just some constants etc) so you need to at least understand how to do it, else how will you modify it correctly?

 

[Tsukihime]

By customization, as in what muramasa described: create a table, add some columns, enter some values for each record.


Which is basically what the note-tags are doing as pointed out as well, except...more structured I suppose.

 

[Engr. Adiktuzmiko]

oh yes, notetags are really good at acting as an extra database as long as you have a script that reads them... though native support for that will be nice for most... but I think that topic is far too specific as opposed to this thread's general topic of plug-ins vs scripts and is more fit into the next maker suggestions thread...