Today’s topic is a good one (for me—maybe not for you). It’s a line that I’ve found myself repeating over and over again in response to many RPG Maker projects: “tone down the features”. A lot of amateur game designers will crowd their games with as many “features” as they can think of—the end result is often the opposite of what they expect: too many complicated features or systems can kill an RPG.
Before we get started, let’s make sure that we are on the same page. “Features” is a pretty vague word (and it isn’t one that I’m not using arbitrarily—my usage of the word “features” in this article is a response to the overuse of the term among users of RPG Maker). When I’m talking about “features”, I’m talking about nearly any kind of extra gameplay system that a designer can add into his game. This stuff is usually an add-on to one of the core gameplay elements: for example, your battle system by itself isn’t a feature, but that limit break system sure is.
In this article, I’m going to dive deep into the idea of adding features into your RPG: what purpose they serve (if any), when they are important to keep and when they are expendable. This is gonna be a fun one.
Complexity Creep
This is a problem that plagues lots of games that continue to grow over time: as new content is created for the game, those elements naturally become more powerful and more complex. When it comes to creating new content for an established game, the game developers often have no choice but to create new game elements that simply outclass the old ones. At the same time, even if the power level of the game manages to maintain stability, the overall complexity of the game can skyrocket as the developers cram the game with feature after feature. These creep issues are visible in massive multiplayer online games (of multiple genres), and can turn away both new players and old ones.
Nicki Minaj knows the dangers of creep.
So how does creep apply to single-player RPGs that don’t receive updates or additional content? Complexity creep can (and does) occur on a genre-wide level. As more RPGs are made, the genre as a whole gets more complex: RPG developers feel the need to cram more and more features into each game just to “keep up” with the current trends in the genre, or to attempt to make their games “stand out”—even if it’s the wrong choice for the game itself. As a result, games are bloated with features that add very little to the experience. This creates complexity creep.
And within a standalone single-player game like most RPGs, complexity can be even a larger problem than in online games. If your game starts out complex (and only gets even more!), you run the risk of overloading the player and he can get turned off pretty quickly.
The most common complexity problem that I see in modern RPG Maker games is a simple overload of textual information. This often occurs at the beginning of the game, when the player is overwhelmed with instruction. It’s also common within the game’s menus, where so much information is thrown at the player at once, often without any sort of guide. Remember that as the developer, these features might be easy for you to make sense of; but the player will feel more overwhelmed with each new number, unique word, or instruction you throw at him.
If the player begins a new game and opens the menu only to be greeted with all sorts of grids and trees and statistic values that initially have little to no meaning, he’s going to feel out of his element. Especially if you’ve replaced common terms (like “magic” or “skills“) with goofy in-world names (like “aetheria” or “orb trees“). If the player spends the first ten minutes of the game trying to understand how to make sense of the menus, there’s a complexity problem. The more unique systems you have, the more the player gets confused.
At the same time, however, if you throw the player into a lengthy tutorial that explains each of your awesome unique features in detail–he’s going to get overwhelmed with a lot of information at once with too much instruction. There is also the risk of simply boring him. It’s tough to find a middle ground: too little explanation and the player is confused about how to play the game; too much explanation and the player is overwhelmed.
If the player is confused about how the game works, he is likely to get frustrated or bored with these systems as time goes on. Or even worse–he might stop playing the game altogether.
The solution I suggest? Your game probably doesn’t need all of those features to begin with.
Let’s look at ways to evaluate which features are important to your game and which are just getting in the way.
Useless and Detrimental Features
The first—and easiest—features that you can cut from your game are the ones that don’t do anything. Sit back and look at all of your features objectively—for each one, ask yourself: does it really add to the gameplay? Does it make the game more fun? Does it matter to the player?
Does it serve a function? Does it make the game more fun? Is it necessary?
You’d be surprised at the kinds of features that really don’t do anything in your game: even some of the ones that you think are really cool might not have a real impact on the gameplay. Most of these features are little visual extras: minimaps and HUDs fall pretty cleanly into this category. In the typical RPG, where battles don’t occur on the map screen, these things don’t add to the game at all. Why does the player need to see his HP/MP at times when it doesn’t matter? Often, game designers will create large elaborate HUDs that draw attention away from the actual game, covering up a large portion of the game screen with useless information that the player doesn’t need to see. In a genre where exploration is important, you don’t want to obscure parts of the map.
HUDs might look nifty, but all they do is get in the way.
What other features are useless? Anything that wastes the player’s time without reason. Take a look at the structure of your menu—is there lots of nesting that doesn’t need to be there? How many “clicks” does it take for the player to do what he wants to do. If the player wants to equip a weapon, does your menu make him jump through hoops to get to the right screen?
Does your game really need a “stamina” system for dashing? If the player wants to speed through an area, let him. Don’t waste his time by forcing his character to crawl. In fact—does your game need a “dash button” to begin with? When your player is playing your game, does he hold the dash button constantly? Does he ever feel the need to take his finger off of that button? Consider the possibility of having the high speed the default speed. Think about these things as you test-play your game.
And then there are features that are worse than useless—some features are actually detrimental to gameplay. They make the game less fun. These are the features that give unnecessary challenge to the player; the kind of challenge that seems interesting at first but ends up being a chore and causing frustration.
Think about what your player wants to do. Think about what your game—and the genre of your game (in this case, RPG)—encourages the player to do. If you have a feature that contradicts the goals that your game sets, then that feature is actively working against your gameplay.
The best example of this is a limited inventory management system. Imagine playing an RPG and finding a cool item in a chest deep in the cave—but you can’t pick it up because your inventory is full; so you’re forced to throw away something else. That just sucks.
This is what it feels like when I have too many items in an RPG and need to throw something away.
Sure, features like these aren’t always misplaced. There’s a strong argument for an inventory management system in survival horror games, for example—because it helps increase the idea of ever-present tension and danger. In the standard RPG, however, such a system is only working directly against the player. Most players enjoy collecting items; especially since these games are often littered with chests and treasures—managing inventory goes against this aspect of the genre.
Game design should encourage and reward the player to do what he naturally wants to do.
If your feature doesn’t make the gameplay more fun—or worse, it makes it less fun—consider cutting it.
Every feature in your game must have a positive gameplay application.