Yanfly's Advice for RPG Maker Plugin Developers - Revision history

Yanfly at 22:15, 16 December 2024

2024-12-16T22:15:42Z

Yanfly at 00:24, 10 June 2024

2024-06-10T00:24:56Z

Yanfly: /* 7. Avoid the Mini-game Trap */

2024-04-04T00:24:04Z

‎7. Avoid the Mini-game Trap

Yanfly: /* 3. Create a Bug Report System */

2024-04-03T20:36:52Z

‎3. Create a Bug Report System

Yanfly: /* 6. Custom Image Requirements */

2024-04-03T19:42:05Z

‎6. Custom Image Requirements

Yanfly at 17:41, 3 April 2024

2024-04-03T17:41:28Z

Yanfly: /* 4. Specialize Your Plugin Parameters */

2024-04-03T17:38:12Z

‎4. Specialize Your Plugin Parameters

Yanfly at 17:32, 3 April 2024

2024-04-03T17:32:50Z

Yanfly: Created page with "{{TOCright}} {| style="width: 800px;" cellspacing="0" cellpadding="0" | style="width: 100%; vertical-align: top;" | == Introduction == {{Article by Yanfly}} Hey, there. Ya..."

2024-04-03T17:29:44Z

Created page with "{{TOCright}} {| style="width: 800px;" cellspacing="0" cellpadding="0" | style="width: 100%; vertical-align: top;" | == Introduction == {{Article by Yanfly}} Hey, there. Ya..."

New page

{{TOCright}}

{| style="width: 800px;" cellspacing="0" cellpadding="0"
| style="width: 100%; vertical-align: top;" |

== Introduction ==

{{Article by Yanfly}}

Hey, there.
Yanfly, here!

I figured I'd drop some advice for various RPG Maker plugin developers in hopes that many will succeed.
Success by either making a name for themselves, making some cash, or even both!
Both is good.

== 1. Make Your Quest Journal Plugins ==

[[File:YEP.152.jpg|300px|link=Quest Journal System (YEP)]] [[File:VisuMZ.016.jpg|300px|link=Quest Journal System VisuStella MZ]]

I've probably seen over 500+ different projects during '''RPG Maker MV''' and about 200+ during '''RPG Maker MZ''' made by different users.
Even in projects that are filled to the brim with [[Yanfly Engine Plugins]] or [[VisuStella MZ]], I often see Quest Journal Plugins that are made by other plugin developers.
This doesn't bother me a single bit.
Instead, it does make me curious as to what they have to offer.
And what they have to offer is a variance in style.
The style matches the way the game feels and by itself, that's a very strong reason to use a plugin from a different plugin library.

The other reason why I say to make your own Quest Journal plugins is that across [[Yanfly Engine Plugins]] or [[VisuStella MZ]]'s history, the [[Quest Journal System VisuStella MZ|Quest Journal System]] plugin is our best seller and most downloaded plugin that isn't a core plugin.
And by a long shot, too ([[Most Popular VisuStella MZ Plugins|as you can see here]]). Despite the fact there are free alternatives, this plugin still gets bought the most and downloaded the most. I feel like this would be the case for other plugin developers, too.

This also applies to plugins other than the Quest Journal, but the Quest Journal is the most obvious one to me.
Other plugins that see a lot usage are UI plugins.
Don't be shy and make those!

It's easy to fall into the trap of "But Yanfly/VisuStella already made it!" and not create a plugin that we've already made and done.
But here's the truth of it all:
Not all of our plugins work for every single game-type.
While we aim for in-library compatibility across the board when possible, some of our plugins just don't really fit certain users for a variety of reasons.
Help those users out by making your own versions of the plugin in question and see if it is a better fit for them.

== 2. Package Your Plugins ==

[[File:VisuMZ_Wave8.png|600px|link=]]

If you have a lot of plugins that do individual features, package them!
This package can be in the form of a large bundle of plugins or even a consolidated plugin like VisuStella's super cores.

Packaging was something originally noted by [[Olivia]] back when she made her [[OctoPack Battler (Olivia)|OctoPack Battler]] plugins.
The number of downloads and purchases complete outnumber the purchases and downloads for the individual plugins combined.
Plugin users like to see things that work together and when you present to them a bundle of plugins that work in immense harmony, like [[OctoPack Battler (Olivia)|OctoPack Battler]] plugins.

This became the main driving force behind VisuStella's plugin bundle structure starting from [[Inspiration Behind The Waves Plugins|The Waves]] to the more specialized plugins like the [[Inspiration Behind Visual Novel Series|Visual Novel series]].
Just like with Olivia's [[OctoPack Battler (Olivia)|OctoPack Battler]], these bundles see more downloads and purchases than the individual plugins combined.

Another method of packaging came in the form of VisuStella MZ's "super cores" and how many of these plugins put together bunches of YEP's plugins together.
We frequently get statements about "I didn't know I needed this feature until I tried it".
The other benefit of putting a bunch of features together is that it's easier to ensure compatibility between them all.
In the case of [[Unique Tile Effects VisuStella MZ|Unique Tile Effects]], we were able to make sure each new unique tile effect worked with each other and didn't clash in general.

== 3. Create a Bug Report System ==

[[File:Troubleshooting.jpg|600px|link=]]

I know it's super convenient and easy to just take bug reports from comments and/or forum threads.
That's what I did for a while during YEP and Patreon and the problems eventually piled upon themselves.

So what problems did I face from just taking bug reports and comments?

The biggest problem was replicating these problems.
It's hard to tell if a problem was created by my own plugins or if there was an external factor.
External factors ranging from user-created problems, external plugin conflicts, unintended usage, and the like.
From comments alone, I can safely say a lot of these problems came from external factors.
Sometimes, I was unable to replicate the problem at all and instead, spent a few hours of my time on a wild goose chase not knowing what I was looking for.

So the solution we've found?

Have users submit [[Troubleshooting Plugins RPG Maker MZ|bug reports with isolated projects]] reproducing the problem/bug.
Because of the isolated environment, we get rid of external plugin conflicts.
We are also able to see the bug replicated before our eyes instead of having to chase it down.
By also having the problem reproduced through an isolated project, users can sometimes pin-point that it's a user-related error and actually learn from it, too.

The best part though?
It's making sure that the bug the user is experiencing is fixed, rather than fixing some other bug that the user isn't experiencing.

This benefits both parties, the plugin dev and the bug reporter.
It's no perfect solution, but it's one that makes sure the job gets done.
Most of the time anyway.

== 4. Specialize Your Plugin Parameters ==

<html><img src="https://forums.rpgmakerweb.com/data/attachments/44/44744-476acc7f6bf1816b37de2ae2460a2acc.jpg" width="600px"></img></html>

Learn how to make Plugin Parameters specialized for certain types of inputs.
Things like making sure certain Plugin Parameters only take in numbers while others take in strings.
Other Plugin Parameters will be booleans.
There's [https://forums.rpgmakerweb.com/index.php?threads/rpg-maker-mz-plugin-creation-tutorial.128486/ documentation online] on how to do this.

This will reduce user error and save you from having bug reports all around centered around incorrect Plugin Parameter usage.
[https://forums.rpgmakerweb.com/index.php?threads/introduction-to-the-new-plugin-manager-in-rpg-maker-mv-1-5-0.79764/ Before this update was made in RPG Maker MV], Yanfly Engine Plugins suffered greatly from bug reports due to user-error from Plugin Parameters.
Sometimes, even typing in "True" instead of "true" into a Plugin Parameter would yield an error.
While it's still very possible to get errors from Plugin Parameters if you specialize your Plugin Parameters, the chances are greatly reduced.

== 5. Regular Expressions ==

<html><img src="https://user-images.githubusercontent.com/695638/192731283-82db8798-d9b9-4f3f-8f13-7a90fb581810.gif" width="600px"></img></html>

Lots of RPG Maker plugin developers prefer to use the automatic notetag meta data parsing system found in RPG Maker MV/MZ.
It's not hard to see why because the alternative is to [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions learn Regular Expressions].
This is a difficult mountain to climb for many plugin developers because Regular Expressions are hieroglyphics for programmers.

So what are some disadvantages with the automatic meta data parsing system found in RPG Maker MV/MZ?

# The notetag types they can parse are extremely basic (limits the data types accepted).
# The notetags are extremely case sensitive and space sensitive (more prone to user error).
# Certain notetag formats are impossible to create and store data with (like VisuStella MZ's JS notetags).
# Upon extracting the meta data, you still need to parse the stored data anyway (you still gotta do work regardless).

By using Regular Expressions instead of the automatic meta data parsing system for your notetags, you retain more control with how data is handled and what types of data inputs are accepted.
The control you get is often underappreciated by plugin developers and it often limits how far they can go with expanding their plugins' capabilities.
Things like being able to create things such as VisuStella MZ's JS notetags are either impossible or extremely limited.

Beyond notetags, there are also other advantages when using Regular Expressions.
Regular Expressions are extremely helpful in parsing text codes for message windows.
They're also extremely helpful in determining what information a batch of text might have.
Pattern recognition and filtering also becomes possible.

== 6. Custom Image Requirements ==

[[File:LightingEffects_RadialLight.png|600px|link=]]

Make make custom images a requirement for your plugin to be used.
Instead, they should be optional!
I often see this very often for UI plugins or plugins that produce special effects.

Let me explain.

When users first install a plugin that does this, there are two things they're concerned with:
# Does the plugin work?
# Does the image work?

When a custom image is '''required''' and they have to create or download said image, in the likely chance that something doesn't work right (and first time users typically botch something) (it happens to all of us), the user will be unsure if it's the plugin not working properly or the image not working properly.

Remove this uncertainty by removing the requirement for a custom image.
Make it so that if no custom image is detected, either because the filename is blank or something, then the plugin will produce a backup graphic to fill in for it.
Plugin developers can produce custom graphics through the various Bitmap draw functions.
Even something like a white circle is enough to provide a visual feedback to the user that it is the plugin that's working and not the graphic.
This way, the user is able to pinpoint where the problem lies.

== 7. Avoid the Mini-game Trap ==

<html><img src="https://static1.cbrimages.com/wordpress/wp-content/uploads/2023/06/a-split-image-of-minecart-yoshi-race-and-midas-river-mini-games-from-super-mario-rpg.jpg" width="600px"></img></html>

A common pattern I see from plugin developers is that the ones who eventually sit down and create a mini-game plugin will either quit plugin development altogether or only solely develop for that mini-game plugin for the rest of time.
Now, this is no slight against those plugin developers.
Far from it.
Instead, it is more of a concern.
The fact this has happened to many prominent plugin developers already is an indicator that mini-game plugins just aren't great for a plugin library if they're going to be the ones who put a stop to the creation of everything else.

I see two reasons this happens:

The first reason is that the plugin developer claims they have ran out of ideas and decided to make mini-games from their favorite RPGs.
After all, if they enjoyed those mini-games from those RPGs, maybe others will, too.
And whether or not the plugin developer succeeds in making the mini-game successfully is irrelevant.
Instead, the part that rings the loudest to me is that the plugin developer claims they've ran out of ideas and a mini-game is all they've got left.
I don't think they've really ran out of ideas, but instead, have gotten too stiff in the things they're creating plugins for and want to change things up.

The second reason is that the plugin developer really wants to add in a popular mini-game, like say, [https://finalfantasy.fandom.com/wiki/Triple_Triad Triple Triad].
This is a super popular mini-game and for good reason (it's mega addicting).
The problem: the integration aspect will take too long to incorporate everything or things just start falling apart.
Eventually, the plugin developer is either stuck fixing the mini-game nonstop or is making non-stop add-ons for this mini-game.
Now if this is what they want, all the more power to them, but when the usual pattern is that the mini-game bids the end of a plugin developer's career, it's usually not a good sign.

So what can we do as plugin developers?

My advice is to not make mini-game plugins in the first place.
You might want to because, let's be real, some mini-games are super fun.
Instead, create ways for plugins to enable the creation of mini-games.
This is what I did with the various eventing systems made possible through YEP.
This is what VisuStella MZ did with its [[QTE]] plugin.
Come up with the tools to make it possible instead and let the users expand the mini-game the way they want through their own accord.

== 8. Improve Things Little By Little ==

[[File:CustomConstructVol1.jpg|600px|link=]]

Improve your plugins little by little.
Add new features here and there.
Add some Quality of Life upgrades, too.
Add some new ways to use your plugin's functions.
When you create a plugin, don't expect it to be that plugin's final state.
There's always something to be improved and it can take some time to discover what can be done.

Make it a goal to improve something small on a regular basis.
By spending a few hours to improve something today, all of your tomorrows become better.

== End of Article ==

|}

← Older revision		Revision as of 22:15, 16 December 2024
Line 16:		Line 16:
	Success by either making a name for themselves, making some cash, or even both!		Success by either making a name for themselves, making some cash, or even both!
	Both is good.		Both is good.
		+
		+	My credentials?
		+	Well, I did make 200+ for RPG Maker MV.
		+	100+ for RPG Maker VX Ace.
		+	Around 200+ for RPG Maker VX.
		+	And now, I lead a team to create another 150 for RPG Maker MZ.
		+	Maybe I'm overstepping my bounds, but I consider myself pretty familiar with this process.

← Older revision		Revision as of 17:41, 3 April 2024
Line 213:		Line 213:

	== End of Article ==		== End of Article ==
		+
		+	<html><script type="text/javascript" src="https://www.free-counters.org/count/f7rr"></script><br>
		+	<a href='https://www.easybooking.eu/produkte/julia-hotelsoftware'>Hotelprogramm easybooking</a> <script type='text/javascript' src='https://www.whomania.com/ctr?id=817085ece42d4f9f4f94e77b9adffcc4cd6c00eb'></script></html>

	\|}		\|}

← Older revision		Revision as of 17:32, 3 April 2024
Line 5:		Line 5:

	== Introduction ==		== Introduction ==
		+
		+	[[File:YanflyAdvice.png\|600px\|link=]]

	{{Article by Yanfly}}		{{Article by Yanfly}}

@@ Line 121: / Line 121: @@
 # The notetag types they can parse are extremely basic (limits the data types accepted).
 # The notetags are extremely case sensitive and space sensitive (more prone to user error).
 # Certain notetag formats are impossible to create and store data with (like VisuStella MZ's JS notetags).
 # Upon extracting the meta data, you still need to parse the stored data anyway (you still gotta do work regardless).

@@ Line 161: / Line 161: @@
 <html><img src="https://static1.cbrimages.com/wordpress/wp-content/uploads/2023/06/a-split-image-of-minecart-yoshi-race-and-midas-river-mini-games-from-super-mario-rpg.jpg" width="600px"></img></html>
-A common pattern I see from plugin developers is that the ones who eventually sit down and create a mini-game plugin will either quit plugin development altogether or only solely develop for that mini-game plugin for the rest of time.
+A common pattern I see from plugin developers is that the ones who eventually sit down and create a mini-game plugin will either quit plugin development altogether or only solely develop for that mini-game plugin for the rest of their remaining time until they inevitably leave.
 Now, this is no slight against those plugin developers.
 Far from it.
@@ Line 189: / Line 189: @@
 This is what VisuStella MZ did with its [[QTE]] plugin.
 Come up with the tools to make it possible instead and let the users expand the mini-game the way they want through their own accord.
 == 8. Improve Things Little By Little ==

@@ Line 70: / Line 70: @@
 [[File:Troubleshooting.jpg|600px|link=]]
-I know it's super convenient and easy to just take bug reports from comments and/or forum threads.
+I know it's super convenient and easy to just take bug reports from comments, forum threads, and/or Patreon replies.
-That's what I did for a while during YEP and Patreon and the problems eventually piled upon themselves.
+That's what I did for a while during YEP and the problems eventually piled upon themselves.
 So what problems did I face from just taking bug reports and comments?
@@ Line 94: / Line 94: @@
 It's no perfect solution, but it's one that makes sure the job gets done.
 Most of the time anyway.
 == 4. Specialize Your Plugin Parameters ==

@@ Line 141: / Line 141: @@
 [[File:LightingEffects_RadialLight.png|600px|link=]]
-Make make custom images a requirement for your plugin to be used.
+Don't make custom images a requirement for your plugin to be used.
 Instead, they should be optional!
 I often see this very often for UI plugins or plugins that produce special effects.
@@ Line 158: / Line 158: @@
 Even something like a white circle is enough to provide a visual feedback to the user that it is the plugin that's working and not the graphic.
 This way, the user is able to pinpoint where the problem lies.
 == 7. Avoid the Mini-game Trap ==

@@ Line 108: / Line 108: @@
 This will reduce user error and save you from having bug reports all around centered around incorrect Plugin Parameter usage.
 [https://forums.rpgmakerweb.com/index.php?threads/introduction-to-the-new-plugin-manager-in-rpg-maker-mv-1-5-0.79764/ Before this update was made in RPG Maker MV], Yanfly Engine Plugins suffered greatly from bug reports due to user-error from Plugin Parameters.
-Sometimes, even typing in "True" instead of "true" into a Plugin Parameter would yield an error.
+Sometimes, even typing in "True" instead of "true" into a Plugin Parameter would yield an error and specializing that plugin parameter to be a boolean would avoid that problem altogether.
 While it's still very possible to get errors from Plugin Parameters if you specialize your Plugin Parameters, the chances are greatly reduced.
 == 5. Regular Expressions ==