Yanfly's Advice for RPG Maker Plugin Developers

Welcome to the wiki! This is where you can find resources from Yanfly.moe, Ækashics.moe,
VisuStella, Caz Wolf, Fallen Angel Olivia, Atelier Irina, and other affiliated content creators.

Introduction This is an article written 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 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 plugin is our best seller and most downloaded plugin that isn't a core plugin. And by a long shot, too (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 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 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 plugins. This became the main driving force behind VisuStella's plugin bundle structure starting from The Waves to the more specialized plugins like the Visual Novel series. Just like with Olivia's 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, 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 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 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 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 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 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. 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 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 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 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 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. 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 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. 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, 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 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 Hotelprogramm easybooking