The untold rules of RPG Making?

[Soul_Narrative_Games]

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)

60 hours is quite the commitment for the player as well. I stick to 2 to 3 playable characters. If I am feeling adventurous I go up to 4. I completely agree an engine is just the tool, the developer is what makes the game great

 

[Gallas]

The most important thing to do is to make back-ups.

Lots and lots of back-ups!

You need a back-up on another harddrive (somewhere) and another back-up on a cloud (somewhere).

"Why do I need to make so many back-ups?"

Outside of hardware failures (which will happen), there are two other big reasons to do so.

One, YOU will screw up YOUR OWN game. You'll do something like accidently delete something or screw something up. Good thing you have a back-up!

Second, iterative new back-ups will show off your progress as a developer. Development has its highs and lows. Most RPG Maker games are not finished. What keeps me going (fives years going) is looking at the back-ups and realizing just how far I've come. "I used to think THIS WAS GOOD!? How INSANE was I!???"

Some people think making and publishing a game that sets the world on fire is victory. I think victory is truly growing as a developer over years of progress. This will only be reflected when you can see the old versions of your project.

So make back-ups. Lots and lots of back-ups!

 

[Iron_Brew]

It sounds like a cliché, but:

Make your opening last, that way you can benefit from all the lessons you learn along the way, and you'll have a concrete understanding of your plot beats.

Don't forget, your opening is arguably the most important part of your game

 

[Soul_Narrative_Games]

A rule I follow is play to your strengths. If you are good at art have custom art, if you are masterful composer incorporate your own songs and so on.

 

[BubblegumPatty]

Oh another one that comes to mind:

• Don't work on a dozen projects at once.
  There's nothing wrong with having multiple ideas ,or putting current projects aside for later if the passion wanes... But try to avoid constantly starting new projects. The "Wooo New cool idea that I love a lot yay!" Honey moon phase will fade every time. Try to Keep your focus to 1-2 projects at a time or else you'll never finish anything.
• You don't have to do everything at once.
  Aka you don't have to completely finish the database before doing xyz, you don't have to finish all the eventing in every town before moving to the next, don't need to do all your assets before programming, etc. Placeholders exist for a reason. Just make a note and come back later when you have time, or have the passion to focus again.
• Keep your database organized! Pair like items with like items, use Blank entries for formatting, plot out how many entries in each section you will likely need, etc. It'll save you a lot of headache trying to find things later.
  

 

[fatalis357]

Organization is key! What I found helps is make a to-do list using google docs and check them off as I go along. This was invaluable near completion as it helped me tackle specific things each time I was working on the game.

 

[DredgenJinn]

What I could say from personal experience is that you don't always need a critic or a proofreader. Valuable as they are, if you're at a point where you spend more time searching for a response than you are working on what you want a response for, you wind up in a rather desperate limbo of relying on pure chance. One of my writing projects had wound up delayed for months because I constantly needed to know what other people would think about it. You are your own best critic, and while an outside opinion is invaluable, it's not worth waiting for it or overly searching for it.

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?

For all I've been told, I'm surprised I've never been told nor even realized the value of saving money during the creation of a game. I've already been aware of the value in using strictly placeholder assets until you're at a point where money spent won't go wasted, but it's never dawned on me that you should be using the creation period to stockpile money. So you certainly have my gratitude.

 

[fatalis357]

What I could say from personal experience is that you don't always need a critic or a proofreader. Valuable as they are, if you're at a point where you spend more time searching for a response than you are working on what you want a response for, you wind up in a rather desperate limbo of relying on pure chance. One of my writing projects had wound up delayed for months because I constantly needed to know what other people would think about it. You are your own best critic, and while an outside opinion is invaluable, it's not worth waiting for it or overly searching for it.


For all I've been told, I'm surprised I've never been told nor even realized the value of saving money during the creation of a game. I've already been aware of the value in using strictly placeholder assets until you're at a point where money spent won't go wasted, but it's never dawned on me that you should be using the creation period to stockpile money. So you certainly have my gratitude.

Agree with this. When it comes to writing, write it out all first then edit after. Don’t make it try to sound good right away

 

[Tai_MT]

@DredgenJinn Not a problem. It's something a lot of people don't necessarily realize for all sorts of things. It's just a "common tactic" for me when there's something I want.

You will get people who say, "I can't afford X, it's so spendy", but I budget for it. If I want X within a year, I need to save Y amount of money each month.

The up-side with assets is that you don't need them until the project is complete, so you just take $20 a month out of your budget for that, and set it aside until you need it. If it turns out that you didn't need all of it... hey, whatever is left over rolls into the new game's budget, or it goes into your account for something else.

 

[Kissa]

What I can think of now is:

1- Don't have too many large empty spaces (this is good advice);
2- Don't use the game's RTP, because it makes your game be generic (debatable in terms of quality advice);
3- Always try to event before searching for a plugin;
4- Begin with a small game.

This is not an untold rule for game making in general, may even not be advice in which I agree with... those are just four "untold rules" of RPG making in RPG Maker I could think of.

 

[ATT_Turan]

2- Don't use the game's RTP, because it makes your game be generic (debatable in terms of quality advice);
3- Always try to event before searching for a plugin;

I strongly disagree with these as advice. There are many threads ad nauseum discussing it, and many image showcases where it's obvious that RTP assets used well look perfectly distinguishable.

And there are many things that can only be done via plugin, or that are way easier to do with a plugin. It doesn't make any sense to waste your time trying to event it in those cases.

Those sound less like "untold" rules and more like things you've seen people say

 

[Kissa]

I strongly disagree with these as advice. There are many threads ad nauseum discussing it, and many image showcases where it's obvious that RTP assets used well look perfectly distinguishable.

And there are many things that can only be done via plugin, or that are way easier to do with a plugin. It doesn't make any sense to waste your time trying to event it in those cases.

Those sound less like "untold" rules and more like things you've seen people say

This will definitely be what I heard people say or imply more.

I started using RPG Maker and talking in English speaking and portuguese speaking communities of the subject in about 2010, but I never keep the same profile. Always made a new one if I didn't remember I had one already (because I never care much, this is my bad and probably against the rules, maybe I have another profile in this forum).

I guess what I saw most was people talking "trash" about lways using the assets that came already in the engine, like music, for commercial games on steam. About plugins I guess it was for people who used too many different scripts from different sources in the times of the VX and VX Ace and they were getting some strange bugs in which the source was hard to spot.

 

[Dalph]

-Use placeholders for graphics.
-Make regular maps before parallaxing.
-Don't be a scope creep.
-Watch out for spelling mistakes.
-Make a short game first. (I made 3 in the past)
-Custom music all the way. Never use RTP music. Music is actually the easiest thing to find in terms of resources and a lot of it is FREE.
-RTP graphics is ok and has plenty add-ons.
If you can't draw or cannot afford resource packs, there's not much choice in terms of resources to cover a long game, so you're stuck with the RTP.

 

[Ms Littlefish]

There's never a shortage of talking trash in any variety of spaces. I'd definitely say when it comes to commercial games, you'd be wise to carve out an identity through all aspects of the game.

Though, blanket statements like "don't use the RTP" kinda just tends to be gatekeep-y AF. And, yeah, we tend to have that conversation monthly around here so it hardly seems untold.

 

[Trihan]

If we told you what they were, they wouldn't be untold any more.

 

[BubblegumPatty]

Since it's all a matter of taste, the RTP debates will never ever end.


But on a related noted here's another rule: Don't assume Custom Graphics, custom Music, or a ton of plugins will magically make your game good. it's all about using your resources well, not how many you have.

 

[Tai_MT]

@BubblegumPatty

Part of the argument about the RTP debates is what you just posted. The assumption that custom everything get you noticed and automatically make your game better. While having the RTP assets mean "you didn't care enough about your game". That's where a lot of the friction in the topic tends to come from. Just basic elitism.
---

I kind of wanted to post another "unwritten rule" inspired by the recent posts in here. Well, okay, a couple.

Players Are Not The Enemy
I know it's very tempting to take criticism from a player and perceive it as a personal attack against you or even your own skills. I advise you don't do this. Rarely is such criticism "personal". Most of it comes from a place of the user wanting your product to improve.

Don't dismiss what your players are saying "out of hand". Yes, their complaints are probably going to be extremely vague and difficult to understand. Yes, they may strongly word an issue (usually proportional to the amount of frustration they experienced with it). No, there are not all that many people who leave "troll reviews". They are out there, sure, but they're sort of rare unless you've done something to anger a lot of people.

Do not treat your players as the enemy. They are a tool. An asset. You can use them to make a better game or track down issues.

Likewise, just because they want something removed or changed, doesn't mean they "want to change your entire vision". You can't view your product as sacrosanct and be unwilling to fix or change things so that your "vision" reaches more people and becomes a more memorable experience. Well, unless the point of your experience is that it can deliver boring/annoying/depressing/frustrating moments. Then... I dunno what to say. I'm bad at helping people who just want their games to be "an arthouse piece".

Know Your Audience
As easy as it is to say "I'm making a game that I want to play", it's important to remember who your audience is. If you release a game to the public, you should know what players you're targetting, what they like, and why they like it. This will help you implement QoL stuff in your game.

So, just know who your audience is. Or, potential audience. Market to them specifically. Highlight parts of your gameplay that would appeal to only that audience. There's no need to "cast a wider net" to get people who wouldn't be interested in what your game is meant to be. But, you should attempt to cater to the people who are or would be interested in what you're making.

You should also know the size of the net you are casting. That way, you don't get upset that more people aren't enjoying your game. If you know that your audience size is roughly 5% of the gaming community, you should set expectations accordingly.

 

[Trihan]

@BubblegumPatty

Part of the argument about the RTP debates is what you just posted. The assumption that custom everything get you noticed and automatically make your game better. While having the RTP assets mean "you didn't care enough about your game". That's where a lot of the friction in the topic tends to come from. Just basic elitism.
---

I kind of wanted to post another "unwritten rule" inspired by the recent posts in here. Well, okay, a couple.

Players Are Not The Enemy
I know it's very tempting to take criticism from a player and perceive it as a personal attack against you or even your own skills. I advise you don't do this. Rarely is such criticism "personal". Most of it comes from a place of the user wanting your product to improve.

Don't dismiss what your players are saying "out of hand". Yes, their complaints are probably going to be extremely vague and difficult to understand. Yes, they may strongly word an issue (usually proportional to the amount of frustration they experienced with it). No, there are not all that many people who leave "troll reviews". They are out there, sure, but they're sort of rare unless you've done something to anger a lot of people.

Do not treat your players as the enemy. They are a tool. An asset. You can use them to make a better game or track down issues.

Likewise, just because they want something removed or changed, doesn't mean they "want to change your entire vision". You can't view your product as sacrosanct and be unwilling to fix or change things so that your "vision" reaches more people and becomes a more memorable experience. Well, unless the point of your experience is that it can deliver boring/annoying/depressing/frustrating moments. Then... I dunno what to say. I'm bad at helping people who just want their games to be "an arthouse piece".

Know Your Audience
As easy as it is to say "I'm making a game that I want to play", it's important to remember who your audience is. If you release a game to the public, you should know what players you're targetting, what they like, and why they like it. This will help you implement QoL stuff in your game.

So, just know who your audience is. Or, potential audience. Market to them specifically. Highlight parts of your gameplay that would appeal to only that audience. There's no need to "cast a wider net" to get people who wouldn't be interested in what your game is meant to be. But, you should attempt to cater to the people who are or would be interested in what you're making.

You should also know the size of the net you are casting. That way, you don't get upset that more people aren't enjoying your game. If you know that your audience size is roughly 5% of the gaming community, you should set expectations accordingly.

I would add a caveat to this in the form of "Not everything a player says should be removed or changed would be of benefit if you listened". Although it's important to recognise the player feedback *is* useful, just making every suggested change is likely to result in your game losing cohesion and focus, and some people ask for things they don't truly want.

 

[ATT_Turan]

I would add a caveat to this in the form of "Not everything a player says should be removed or changed would be of benefit if you listened"...some people ask for things they don't truly want.

And many people don't know how to articulate what they feel or what they actually want.

I've read some really good articles on board game design and getting feedback on it, and much of it describes how the average player of things isn't skilled at analyzing what about their experience made them happy or dissatisfied.

Just look at how many posts with game design questions on here can be answered by "Play a game you like and analyze how it works."

 

[Tai_MT]

I would add a caveat to this in the form of "Not everything a player says should be removed or changed would be of benefit if you listened". Although it's important to recognise the player feedback *is* useful, just making every suggested change is likely to result in your game losing cohesion and focus, and some people ask for things they don't truly want.

Sorry, I was kind of vague in what I meant, maybe?

I didn't mean you SHOULD change everything a player wants. What I mean is simply that as a dev, you don't want to treat your audience as "wanting to change your vision" just because they want something removed or changed. A complaint where a player says "remove this" or "change that" shouldn't be dismissed as a dev as the player "wanting to make a completely different game than I want to make, so I don't have to listen to the complaint".

I think it's better to be open to changing than not be. You don't have to change a thing. But, it's important to not go into any criticism under the assumption that your players want you to compromise your vision of the game, or even, want something entirely different than what you want.

I think the minute we start treating the players "as the enemy" and dismissing anything they have to say as "they don't know what they're talking about" or, worse, "they just want me to make a game that caters to just specifically them, rather than what I want to do", we get into really bad territory.

If you make a grilled cheese sammich and 1 out of 100 people say the sammich tasted bad or they didn't like it, you just parse the criticism. You take a look at it. Maybe you decide it's a "non issue" since the other 99 people didn't care. So, you change nothing. Perfectly acceptable response. But, the dev should always treat the criticism as valid, even if they don't agree with it.

Does that maybe make a little more sense? I didn't mean to be so vague.