Do We Really Need Plugin Commands...?

[Ratatattat]

I've been making a ton of personalized plugins for myself, but some of them are general or versatile enough that I would like to release them here eventually. The only thing I'm having trouble with is how to make them more user-friendly (i.e. I know what's going on and how to use them, but some of them are quite complex and I imagine could easily get confusing for anyone who isn't me and didn't literally write it).

If anyone saw my other recent poll thread about how people prefer help info to be formatted/organized, this is what that was about haha.

But my question today is... do we really need plugin commands?

I don't use them in my own plugins, instead just doing everything with script calls. When I decided to optimize some of my plugins for other people to use, however, I started adding plugin commands for the sake of giving people more options... only to realize that most of them have turned out to be super redundant. Like, a majority of the time, my plugin commands just end up passing their parameters into their script call counterparts, effectively just adding an extra step and superfluous code (and subsequently bloats the help section) when the script call might as well be used directly.

So... is there any reason to NOT ditch the plugin commands altogether? If they function the same as my script calls (and even end up leading back to them anyway), is there any "meta" benefit of providing them despite the redundancy? Are they truly easier to use for beginners (because frankly, I view them as basically the same thing just typed in a different format)? Perhaps there are performance considerations? As far as I can tell, script calls are more flexible than plugin commands anyway - but is there some hidden limitation of script calls I don't know about, that plugin commands offer a way around?

Thanks for all insight!

P.S. If it makes any difference, I primarily use MV.

 

[ShadowDragon]

I do use scriptcalls and plugin commands in my ULS plugin.

reason for that is for them to choose.

plugin commands are in 1 way shorter to type out than scriptcalls.
plugin commands are also a slightly slower to read than scriptcalls,
as scriptcalls are faster to execute, the notice is barely visible to none.

if you make both available, they can choose what they want and feel more
comfortable with

 

[ATT_Turan]

When I decided to optimize some of my plugins for other people to use, however, I started adding plugin commands for the sake of giving people more options... only to realize that...a majority of the time, my plugin commands just end up passing their parameters into their script call counterparts

That's kind of the point. Plugin commands are meant to be a user-friendly interface for people who don't know JavaScript.

You can thus tell people "you type 'Bob, 13, knuckle'" instead of $gameActor.actor(), $dataStates[], whatever.

(and subsequently bloats the help section)

It's up to you - it's certainly friendly to list your functions in the help, but as you say it does also bloat it. For the most part, people who are advanced enough to use the JavaScript directly can also search your plugin to find the appropriate functions (presuming the code isn't obfuscated).

 

[Blindedjourneyman]

as a newb It is useful to me, I do get easily confused at first with the coding part. But if you dont want it ya dont need it, Just leave a decently detailed help and Ill adjust, been trying to get used to javascript (tho I might keep a notepad with templates/formula of sorts ready just incase I forget something or type it out wrong)

 

[PoptartPresident]

I can confidentially tell you as someone who's coding/scripting isn't their strong-suit in game making...yes. Yes it absolutely is needed.

Why complicate things for me?
If I use someone's Plugin (either by purchasing it or getting many of the free-to-use ones), I hope there are user-friendly interface commands. I have had many instances where I'm researching a plugin for something I want in my game, and their instructions to use the plugin are just so bad that I can't really comprehend what I'm supposed to do to make it work. So I find alternatives as a result.


For me, the greatest satisfaction I get from game making is building the art assets I use/parallax mapping, creating stories, and making puzzle/designing game progression/sidequests.

I bet I'm not the only one who thinks this either.
Plugin Commands make the less-nicer part of game making (at least for me) so much easier to manage. I would take Plugin Commands over Script calls anyday.

 

[Arthran]

On MV, as a user, I think that it's usually not really any easier to input a plugin command than it is to just go ahead and use the corresponding script call. In fact, I probably actually prefer using a script call, since the script call text box is bigger than the plugin command one.

On MZ, the difference can be much more significant, since plugin commands work differently.

 

[SGHarlekin]

I'm on MV and I can say I don't care whatsoever as long as your documentation is easy to understand with plenty of script call examples to copy/paste from. So at the end of the day either explain your script calls very detailed and easy to understand, or make plugin commands that can be figured out on their own.

 

[Andar]

do we really need plugin commands?

the plugin commands are there for people who have no programming background to be easier to use.

I can give you an example from a decade ago when VXA was current and no one had ever imagined plugin commands.

Someone was following a video tutorial to use a script command, and nothing was working for him.
And because he had also problems giving us screenshots of what he typed and only linked to the video tutorial "I made everything exactly as there" "then it would have worked, you must have done something different", it took a while to find the cause:

As a non-programmer he saw absolutely no difference between using () [] and {}, having mixed them up in what he typed.
(It was also complicated even more by the fact that the tutorial was low-resolution and the difference was extremely difficult to see in the video, with most programmers using the tutorial automatically knowing which one to use despite bad quality of the video)

 

[Trihan]

Yes, we absolutely do. It makes more sense in MZ than MV, but both are useful.

 

[Mac15001900]

This might be a fairly minor point, but encapsulating everything with plugin commands does make JavaScript's global namespace slightly cleaner.

 

[TheoAllen]

I'm both a programmer and a user.
When a certain function can only expect a predetermined argument, a dropdown list helps.
When a certain function can only expect a certain type of data type (i.e, only numbers), it helps.
When I forgot what kind of functions I have, a dropdown list of plugin commands helps.

About the last point, I hate that I need to remember all of the script calls. I recall when I came back to my project after months, it has a certain script call and I forgot what it does and what other script calls I have made. Granted, I can just look at the code and see what it does, but with plugin command and short description of it, I could remember faster/better.

Many programmers struggle with documentation. And writing plugin command is like the documentation itself.

 

[Trihan]

One thing I think they absolutely must add to MZ at some point though is the ability to collapse plugin command parameter lists in the event editor.

 

[Ratatattat]

Thank you all so much for the insight!! I guess I've lost touch a bit from being a beginner - I had no idea how crucial plugin commands really are for some This is good to know, I will keep going with making the plugin commands then~

When a certain function can only expect a predetermined argument, a dropdown list helps.
When a certain function can only expect a certain type of data type (i.e, only numbers), it helps.
When I forgot what kind of functions I have, a dropdown list of plugin commands helps.

This only applies to MZ, though, right?

But nonetheless!

This might be a fairly minor point, but encapsulating everything with plugin commands does make JavaScript's global namespace slightly cleaner.

Could you please elaborate on this? I have a basic understanding of what a namespace is, but it was definitely one of those things I just "did what I was told" in the beginning, and now just do with each new plugin out of habit, and never went back to understand exactly how they work once I started to learn other things

Thanks again everyone for all the answers!

 

[Aerosys]

This might be a fairly minor point, but encapsulating everything with plugin commands does make JavaScript's global namespace slightly cleaner.

Depends on how you design your code. Many developers use personalized global objects to establish their API. For example, I provide one global instance called $dungeonGenerator from its unique class (Aero_Dungeon_Generator). This way, it is very unlikely to conflict with other plugins unless somebody really uses the same class or instance name that I did.

In the end, I decided that my users have to memorize either

$dungeonGenerator.template("Cave").withExit("top").withExit("bottom").finalize()

or

DungeonGenerator : template(cave) : exit(top) : exit(bottom)

So it doesn't matter whether they are programmers or not given they copy-paste from my tutorials anyway. Hence I just stuck with the first line.

 

[Mac15001900]

Could you please elaborate on this? I have a basic understanding of what a namespace is, but it was definitely one of those things I just "did what I was told" in the beginning, and now just do with each new plugin out of habit, and never went back to understand exactly how they work once I started to learn other things

It's basically just all the names (of functions etc) that JavaScript needs to keep track of globally, i.e. everywhere. For various reasons it's generally a good idea to not add too many things to it. Though that is assuming that the functions you're providing are indeed global, but as @Aerosys rightfully points out you can also encapsulate them by only creating one global object for your plugin and putting all those functions there.

 

[TheoAllen]

This only applies to MZ, though, right?

Correct.
If we are talking about MV, I agree with you.

 

[Ratatattat]

Depends on how you design your code. Many developers use personalized global objects to establish their API. For example, I provide one global instance called $dungeonGenerator from its unique class (Aero_Dungeon_Generator). This way, it is very unlikely to conflict with other plugins unless somebody really uses the same class or instance name that I did.

It's basically just all the names (of functions etc) that JavaScript needs to keep track of globally, i.e. everywhere. For various reasons it's generally a good idea to not add too many things to it. Though that is assuming that the functions you're providing are indeed global, but as @Aerosys rightfully points out you can also encapsulate them by only creating one global object for your plugin and putting all those functions there.

Ahh okay this makes more sense now. Thanks guys!