The untold rules of RPG Making?

[Kemuja]

Are there any untold rules, when making an RPG Maker game. If there are, what are they?
Just a curious question.

 

[DrBuni]

Not really. Just make your game and have fun, if possible.

 

[Milennin]

Common newbie "mistakes" that are generally looked down upon:

• Many spelling mistakes
• Using a long text scroll for the game's intro
• Maps with too many square shapes
• Maps with too much open, unused space
• Maps that teleport players on top of the tile used to teleport back to the previous map
• NPC's that can wander into 1-tile width corridors, allowing to trap/hinder the player
• Player characters starting out with RPG Maker default Skills, or none at all
• Signs of a lack of playtesting (poor combat balancing, easy to get soft locked, wrong map priorities allowing players to clip through terrain etc)
• Too many plugins that serve no purpose, or aren't used properly

 

[AnneLaurant]

Here are some of the things I've seen other people in the RM community bring up about RM devs and their RM games (worded differently):

Spoiler

Use resources carefully.
While RTP is often frowned upon for being "repetitive" (a.k.a. people have previously formed their own assocations with certain RTP assets prior to playing your game and are having a hard time divorcing those previous assocations, AND/OR people just want some variety, period), a good implementation of these assets will make gameplay a lot more bearable, and mixing in custom assets will likely make your game more memorable.
Also, consider your time frame and your manpower: don't go too big if you struggle with following a timeline or completing project milestones.

Communicate expectations well.
Know how to market your game to the correct audience and use relevant terms. Give fair warnings and list the main features. Refrain from using commercially-released titles as points of reference if possible. People want to know what they might be getting before downloading your game.

Manage your pride.
It is understandable that you have a very high and/or positive view of your game as it is an extension of yourself. It is also understandable to say, "maybe this isn't for you," at times when people simply don't like your work.
However, you have to allocate a bit of trust in players and other devs if they say a certain part of that game doesn't work, seems confusing, or plainly "sucks". Humble yourself and acknowledge the flaws in yourself as a dev and your game design. There is still some truth to "maybe this isn't for you", and most of the time it's an issue of communicating expectations.

Know how to sort through feedback.
Good criticism will explain what worked, what didn't, and why these systems give the reviewers these experiences, and as a dev your responsibility is to acknowledge these criticisms with grace and respect. While it is completely up to you to accept or reject these comments, striking a healthy balance between what you want and what your intended audience wants is key to making your game as fun as promised. Ultimately, you must use the feedback to improve.

There's probably a few more I missed, but these are the ones I can explain well for now.

 

[SGHarlekin]

No untold rules, just plenty of already beaten to death rules, most beginners just ignore.

I gotta admit, though, the occasional "I'm going to make a massive 60 hour rpg with 20 characters, 60 classes, and 5 endings, with no budget, marketing, or skills as my first game" Always makes me chuckle. It just never gets old.

For me, there's only one thing that really matters. Making a game in rpg maker is easy. Making a good game ain't easy no matter the engine.

It takes a whole lot more dedication, endurance, research, and testing than many, if not all newcomers I've come across realize. (Myself included)

 

[BraveKing]

Know how to sort through feedback.
Good criticism will explain what worked, what didn't, and why these systems give the reviewers these experiences, and as a dev your responsibility is to acknowledge these criticisms with grace and respect. While it is completely up to you to accept or reject these comments, striking a healthy balance between what you want and what your intended audience wants is key to making your game as fun as promised. Ultimately, you must use the feedback to improve.

To expand on that, here's a nice video I found the other day:


tl:dw: Be data informed, not data driven. Case in point if players complain about a thing, it's best to try to identify the source of the problem, and from there figure out a solution, because the players themselves may not understand the exact reason they're not enjoying a game and so solutions they suggest may not actually solve the problem (but there's still a problem that you need to solve).

 

[KawaiiKid]

1.) Make sure your game is an isekai, if it's not - nobody will play it.
2.) Make sure that you have at least 18 party members that can join, and they must all be different classes.
3.) Magic must be labeled as such: Fire, Fira, Firaga. No getting around that one I'm afraid.
4.) Big bad evil guy must be extremely androgynous, hot, and brooding.
5.) Heroes must be saving the entire world from destruction.
6.) You must use random encounters, and don't skimp on them! This is what the people are here for.
7.) Never use alternate forms of advancement like using Job Points, Talent Trees, or Spell creation. All abilities and spells must be obtained strictly through leveling up.
8.) Always use the RTP. Players wanna KNOW they're playing an rpg maker game.
9.) Make sure you backup your game project folder in 3 weeks when you come up with your next great idea and "put this project on the backburner" while you make your REAL new project because it's the best idea ever.

 

[RCXGaming]

1.) Make sure your game is an isekai, if it's not - nobody will play it.
2.) Make sure that you have at least 18 party members that can join, and they must all be different classes.
3.) Magic must be labeled as such: Fire, Fira, Firaga. No getting around that one I'm afraid.
4.) Big bad evil guy must be extremely androgynous, hot, and brooding.
5.) Heroes must be saving the entire world from destruction.
6.) You must use random encounters, and don't skimp on them! This is what the people are here for.
7.) Never use alternate forms of advancement like using Job Points, Talent Trees, or Spell creation. All abilities and spells must be obtained strictly through leveling up.
8.) Always use the RTP. Players wanna KNOW they're playing an rpg maker game.
9.) Make sure you backup your game project folder in 3 weeks when you come up with your next great idea and "put this project on the backburner" while you make your REAL new project because it's the best idea ever.

God forbid a new person takes this to heart and genuinely thinks this is what you're meant to do.

 

[KawaiiKid]

God forbid a new person takes this to heart and genuinely thinks this is what you're meant to do.

Hey now, #9 is actually good advice

 

[TheoAllen]

Here is an untold rule from me.

If you plan to promote your game to people, don't promote it to fellow developers (here, or else) or at least don't do it too much, unless you want to flex technical skill or something because fellow developers usually have their own hands full of their own projects, and only care about your project if you somehow make something that impresses them on a technical level ("how do you do that?").

Promote it to actual people/gamers to get a variety of feedback.

 

[Iron_Brew]

Rule 1:

Know your scope. Actually figure it out, and don't overreach.

Rule 2:

Dispassionately listen and implement feedback. Other people aren't being mean by trying to help you make your game better, they are trying to help you.

 

[Kanori24]

I'm guilty of the scrolling text intro in my main project. But in my defense, it's not very long. It just gives a bit of context as to why the character beings in a dungeon and what she was trying to accomplish before being captured.

 

[coyotecraft]

I think a lot people assume that once you change maps the event process ends. So what they do is Fade Out, Transfer, and then on the new map have a different parallel process that Fade In. It works. BUT from what I've seen, during the course of development, they'll add on new scenes and edit that parallel process to change the BGM or something under a new event page and story switch condition. They'll forget the Fade In command, because naturally they'll playtest the new scenes direct on the new map instead of transferring in.
I've seen it 100 times by 100 people. I'll be playing their game. I transfer to a new area. But the game doesn't fade back in. So I can't see anything. I can't play.

What they should to is Fade Out, Transfer, and then change weather, tint screen ect...and fade in. All in the same event process.

Of course playtesting your game normally should be a rule too.

 

[Corygon]

Here's some advice: Just because it's a trope that has been used numerous times, doesn't make it bad to have in your project. Sometimes, some tropes are popular for a reason. Or something like that.

 

[matthewwells]

The biggest most trustworthy principle I've discovered in my many adventures building and playing games: balance in everything.

You can go overboard on dialogue, but also on battle sequences. You can overboard on back story, but also on overly long dungeons, etc. etc. The key is to balance all of these things, and there's very little science to determining the right levels of any of these things. It's an art that has to be developed based on experience and intuition. I, for example, probably tolerate long dialogue sequences better than most, which is why I make sure I'm really careful about making sure the player gets an opportunity to do other stuff often as I develop a game.

Be aware of your predilections and understand that the thing you can gorge on is not necessarily great game design for most players.

For the vast majority of design principles people come up, exceptions can be found where the opposite of the rule is a better game experience. This one, however, I've found no true exceptions to so far.

 

[Darth Equus]

Thou shalt make clear to thine player where to go or what the next objective is.

Edit: Thought of several more:

Thou shalt allow easy and prompt access to any item or skill necessary to vanquish a non-optional boss.

Thou shalt make the description of items, usage of equipment, and gameplay intuitive and sensical: A snake ring shalt not protect against ice, but poison.

Thou shalt apply the same reasoning to the enemies: A fire sprite shalt not weak against lightning be, but to water or ice.

Thou shalt not make thine player walk all the way back to the entrance of a dungeon they've just cleared, unless they choose so. Thou shalt thus provide an instant means to exit, at no cost.

 

[Redleg]

I'm guilty of the scrolling text intro in my main project. But in my defense, it's not very long. It just gives a bit of context as to why the character beings in a dungeon and what she was trying to accomplish before being captured.

Check out the cartoon Oscar's Oasis. Has multiple full stories and not a single word of dialogue. One of the best cases of show don't tell I have ever seen.

 

[Flannery]

When it comes to art, there are only two rules:

1. Know what you want to do.
2. Know how you want to do it.

As long as you can follow those, your art is good. That doesn't mean it will be enjoyable, plenty of art is unenjoyable by design/intent... but it will be good. After that, everything else is really just a guideline. As long as you know what you are doing, every guideline that exists for RPG making can be broken. You just have to be careful that you understand the reasons for the guidelines and why you are breaking them.

Some general guidelines have been mentioned already but I'm just going to list off a few of the, in my opinion, most valuable:

• If your game is a commercial project, invest in it and its resources.
  • Players usually don't want to see RTP and commonly-used resources in a game they spent money on because it feels like they're being ripped off. That isn't to say you can't use any RTP or common resources. Just, make sure you know which ones you're using and why.
  • It's also important to make sure your assets all fit each other, which is why you should invest in the assets. You want to invest in having someone who can ensure that even with different art styles at play, your assets are still visually coherent.
• If your game is a non-commercial project, don't invest into it like it was a commercial project.
  • It's fine for non-commercial games to use RTP and commonly-used assets. You don't need to stand out. It's more impressive to just finish making a game. Many people start. For every 1 amazing game out there, there are a hundred that are only good or worse. For every 1 of those, there are a hundred projects that were never finished. By finishing a game, you're already in the 1% of game devs. And since this game is non-commercial, the valuable part of your project is
• If you are in the US or intend on selling on Steam, do notuse AI generative software to make anything.
  • To be clear, I'm not saying you cannot use AI in your creative process. I am saying not to have AI make anything for you. If assets are made (or suspected to have been made) using AI, Steam will automatically reject your game because of the uncertainty of copyright ownership for assets made using AI. They will reverse their decision if you can provide them adequate confirmation (by some standard that I do not believe they've outlined) that you made the art yourself or that all art the AI was trained on was your own or public domain.
  • In the US, AI art has no copyright. If you do distribute your game with AI art, then anybody can take those assets and reuse them as they please. You cannot get those assets protected. It's a little more complicated than that but not much.
• Tutorials should be easily digestible.
  • Don't make tutorials Walls of Text.
    • Your players WILL skip them.
  • Don't make the tutorial take more than a couple minutes at a time.
    • Your players want to play the game. It's fine to spread tutorials for things throughout the game as the mechanics and systems become relevant.
  • Teach things by letting the players use them then encourage the player to keep using them.
    • If your player only needs to use something once then it becomes less worthwhile to keep using that feature, they'll forget it when the time comes that it's an important mechanic then wonder what they're supposed to do to beat something.
  • Your tutorials should be Chekhov's Guns for later gameplay.
    • Anything the player learns in the tutorials should come up later in the game.
• Make your game as accessible as you are able to.
  • Common phobias should be able to be opted out via a Setting on their computer or in the game.
    • Darkness can be dealt with for players by changing their screen brightness.
    • If you're playing a game that's underwater, a setting to make it feel less like you're in water. Horizon Forbidden West for example.
    • Arachnophobia can be managed with a toggle that replaces spiders with something else or removes them completely. Star Wars Jedi: Survivor, Grounded, Shadows Over Loathing, and Evil West do this.
  • If you can manage it, voice acting for the visually impaired or some other clear audio cues for their benefit.
  • Likewise, if you use lots of audio, offer an on-screen indicator of sound cues for the hearing-impaired.
  • If you can afford to, allow more detailed sound-mixing options for players. There are some who are sensitive to certain stimuli and might want that lowered and there might be others who struggle to hear certain sounds and might want those louder. It's a challenge, but players who need it will be grateful.
  • Colorblind-friendly mode for anything that makes color relevant to gameplay.
  • Of course, you don't have to do all (or any) of these, but it just helps certain players and makes your game accessible to more people.
• Don't uncritically use offensive content.
  • Real-world slurs, certain triggers (child harm, animal abuse, etc.), slavery, S. Abuse, etc. should be used sparingly (if at all) and when used should be followed with some sign that the person doing so is not being treated neutrally by the story. Even in an "everybody sucks" story, some lines should be rarely crossed and not rewarded for being crossed.
    • Even with fictional slurs that only have context in-universe... be careful how you use them. Ben 10 as a show literally had the main characters find out "Mudpuppy" was a slur and they responded by continuing to call the species by the slur even going as far as to say, "It's okay, my cousin is a mudpuppy," when later called out for it. You can imagine how uncomfortable it is for racial and ethnic minorities to hear the main character be racist, get called out for it, then use a common racist rebuttal with no consequences. Even as children we can identify how gross that is.
• Don't forget to run your content past "beta readers" and "sensitivity readers".
  • Beta Readers differ from Beta Testers in that they care less about the gameplay and more about the story. They check for spelling and grammar. They evaluate the story's cohesion. They make sure the writing side is good. You need this if you want the story to be something people even slightly remember positively.
  • Sensitivity Readers go through your game and let you know where your game might run afoul of cultural sensitivity.
    • For example, WotC in DnD a year or so ago ran into controversy because they released an update to the Hadozee: a primate-based race that were slaves taken from a primitive world and civilized by their masters into being able to act like real people before said slaves gained their freedom.
      There was massive controversy (obviously) because it was just how white people described black people historically... primitive monkeys who the white folks saved them, civilizing them as slaves before they gained freedom. A sensitivity reader would have pointed out, "Hey, maybe using this Gygaxian-era race that has unedited lore, porting it into our modern game... that might be a bad idea considering Gygax himself was open and proud about being racist?"
    • Likewise, a lot of modern elves, especially if there's a "Wood Elf" or similar, run into the issue of being just reskinned stereotypes about Native Americans. This normally isn't too much of an issue since it's vague stereotypes from a bygone era but, for some of us, it makes us uncomfortable as we're watching a twisted, funhouse simulacrum of our cultures and identities being portrayed in a way that it's specific enough to be upsetting but vague enough that if we call it out people accuse us of being "too sensitive."
    • And if you explicitly include real world cultures, a sensitivity reader born and raised in that culture can make sure you're being respectful toward the culture even if there are certain inaccuracies that crop up.
• Playtest, playtest, playtest.
  • Not just scene by scene, but actually play through the entire game, every route, every event, every option. Make sure everything works correctly. Then, once you've playtested everything until it was perfected, playtest it again.

These are all things I think anyone who makes games of any form should keep in mind. For RPGs, I feel like these are all the more true since a large part of these games is being able to immerse yourself in the worlds.

I hope you found this to be of some value.

TLDR: The best things you can do are put in the appropriate amount of labor for your game's scope, make sure your content is accessible, and make sure you're running your game past people who are qualified to make sure it's okay for release.

 

[BubblegumPatty]

Less an unspoken rule and more an Unspoken Law ala Gravity: Your first game probably won't be the 100 Hour 10/10 Magnum Opus that will rival Final fantasy/Pokémon/Dragon quest/Undertale/Persona/Etc. Not to say your game will be bad, but I can guarantee it won't be perfect. You will make mistakes that you will (hopefully) learn from, and then take those lessons into your next project.

Some other things I can think of:

• Make sure you're familiar with game making and the engine before you tackle your first commercial project, for your own sake and everyone else's.
• Plan ahead as much as possible before you even touch the programming of your game.
• Keep track of who made what Resource/Plugin/Script and their terms. You can't guarantee you'll remember or that their website/forum post will be still up.
• Make games you want to play. If you're not having fun, your player's probably aren't.

 

[Tai_MT]

The big two that I promote:

Triage - It's right in my signature line. Yeah, I got tired of repeating myself about it, so it's in there for anyone who reads it.

Put simply, is it worth spending 5 hours coding "Blackjack" into your game, or can that 5 hours be better spent buffing the rest of your game in some other way? You can never get "time" back. It isn't infinite. It's a finite resource. You need to cut things that aren't working, not waste time on things that aren't worth the time you spent on it (by all means, if you can code Blackjack in 20 minutes and implement, good on you! But, you probably shouldn't spend 10+ hours on it if it isn't central to your game in some way).

Triage is important. If you can't make it work, you remove it. Or, you figure out how to fix it. If it's taking too long to fix it, maybe you "shelve it for next time".

Asset Purchases - It was already slightly touched on here. My advice on this is always the same: Use placeholders on all your assets until you have a completed game. Then, you do the "polish" phase, which is when you buy the assets you for sure, 100%, need for your project. There is little sense in wasting money on projects you won't finish or will continue to not finish after you have 8 or 10 of them started.

Save up some money during your normal dev cycle and when your game is "done", then you spend that cash requesting resources from artists. You will know exactly what you do and don't need by the end of your dev cycle, and you will have a very sizable chunk of cash to throw at a single artist so that your assets won't "clash aesthetically".

I personally recommend putting aside $5 a week from the start of your project until the end of it ($260 a year as a budget for assets for you!), but you can do more/less if you want. 10 years into my project and you can imagine how much I've got set aside for "assets", 'eh?