Why Are RPGs So Hard to Create?

Posted by Rampant Coyote on June 1, 2010

Computer RPGs have a reputation for being among of the most difficult and time-consuming game genres to develop. This is one of the reasons so few mainstream developers shy away from them. But why is that?

Maybe I should ask this question of people like Amanda Fitch, Jeff Vogel, or Inidinera Falls. They make it look easy. However, they use well-established, familiar engines (evolved painstakingly over time), and I do know that for a while Amanda was making casual games in-between her RPGs because they were significantly easier – and more profitable – than the RPGs. The appearance of ease is deceptive.

The problems faced by RPG developers are hardly unique to the genre, but are often more severe. I’m still not an expert. But that never stopped me from throwing in my $0.2 before.  So here are some of the top challenges I’ve found:

Content Consumption – RPGs are traditionally exploration-based and very content-intensive.  The player is always pushing forward to see something new. In addition, older content – enemies, items, etc – quickly becomes obsolete. While there are still many opportunities for repetition of content as found in other genres (combat, usually the core mechanic, offering the most opportunities for repetition – but too much of that and players resent the “grinding”), it’s nothing like, say, an old-school fighting game where you are just changing the backgrounds from level to level. Players want a constant flow of upgrades to their equipment, lots of opportunities to customize their characters, and a constant opening of new areas to explore.

Variety of Player Choices – Having many different ways of resolving a challenge is a good thing in RPGs. Non-linear, open-ended progress is likewise critical, at least for western RPGs. The downside is that the designers and programmers have to jump through all kinds of hoops to provide that variety, or to resolve all kinds of weird cases caused by the open-endedness. Things like: What happens if the player resolves the quest conditions before the quest gets assigned? What happens if half the quest conditions have already been met – we have to avoid a “deadlock” situation where the rest of the triggers never fire because the other ones were handled prematurely.

The thing is, the player never sees all this. At least not in a single play-through. All they see is the path that they took — all those paths not traveled are effectively “wasted effort.” In a more linear game with more forced action, the designer could have scripted seven times as many quests / events of similar complexity in the time it took to create just one for a somewhat open-ended RPG.

Duration – Blame it on the old-school RPGs that took dozens and dozens – often over a hundred – hours to complete.  And yes, I LOVE that about ’em. But players typically expect more hours of gameplay out of an RPG than other genres. Sheesh – I’m not saying either of these are good things, but in the time it takes to complete some third-person shooters on the consoles, you are still feeling like you are in the tutorial in Final Fantasy XII. So RPG makers remain compelled to make their games “big” to meet audience expectations. On top of the average RPG designer’s insatiable desire to do that anyway.

Variety of Interconnected Game Systems and Activities – A good RPG is effectively several games in one. The player may participate in several activities – combat (usually lots of combat), conversations, puzzle-solving, trading, crafting, breeding Chocobos, whatever. This would be bad enough, as the developer creates several games in one, but the various systems interact with each other in subtle yet powerful ways. Or at least they’d better, or they are stupid make-work activities.  For example, being able to do more effective trading or crafting will impact combat, as you will soon be entering the battlefield with superior equipment.  Being able to thrive in combat may in return improve your trading, as you can take down opponents with better loot. That’s a positive feedback loop that could go out of control – which is why you often find merchants in “lower level areas” with only very limited gear to offer for sale.

Balancing these different systems – effectively different games (even if not very good ones by themselves) – so they all make a complete whole can be a daunting task, and many mainstream games do a horrible job of it. But others have done an excellent job of it, and it shows. But the bottom line is that it’s a lot of extra work, even if done poorly.

Game States – RPGs have gigantic game states, compared to most other games. In, say, a platformer, you may have to save the player’s current score, number of lives, what level he’s on, what his location is in the level, and probably the states of the other enemies, pick-ups, or triggers. Its still a lot of data, but reasonably manageable. Compare that to a more open-world RPG – with treasures that have or have not been looted (or partially looted), conversations, quests, factions, attitudes, monsters, triggers, and so forth for an entire world. Not to mention the player’s state – all his stats, equipment, location, current spell effects, etc. Now, good programming methodology can limit the difficulty of representing all of this state info (and saving / loading it properly)  – but there’s still a problem of when these things do go wrong, they can go very very wrong, and they can be a real pain in the butt to tease out.

This is a challenge not only to software architecture and organization, but also to the design process. There are quite frankly a lot of variables to consider.

Testing and Debugging – All those things above combine to make testing and debugging an RPG a pretty challenging chore. Testing out a simple quest, for example, can be pretty labor intensive:

1. Create a saved-game or other situation (cheat codes, etc.) that starts you in a “reasonable” state to begin the quest at an appropriate “fresh” state.
2. Begin the quest in a fresh state from the
3. Play through the entire quest sequence, which could take anywhere from a few minutes to a couple of hours. Until it goes wrong. Then fix & repeat from step 2.
4. Now repeat the previous steps for all possible varieties of approaches to complete or screw up the quest.

The end result may be many man hours just to test and debug a quest which only represents fifteen minutes of player time. Of course, the tester will have tons of cheat codes to accelerate the activity, and probably tries to handle bugs in “batches” (rather than restarting and repeating each time). Still – debugging any game (or software) can be a laborious activity, but the scope and scale of most RPGs make them stand out.

Are these challenges insurmountable? Absolutely not. There have been approaches to RPG design that have bypassed or simplified all of these issues. For an extreme case, check out Desktop Dungeons – which is probably more of a puzzle game than an RPG, but I’ll count it for the purpose of illustration. But I thought it might be helpful to point out these kinds of difficulties faced by RPG designers. It may help players appreciate the kind of effort that has to go into making RPGs, and why indie RPG makers can’t crank out new titles at a very rapid pace (unless they are Aldorlea Games).

And it may help us recognize why so many mainstream studios are embracing a much simpler style of gameplay and calling them “RPGs.” They are trying to dodge these very issues.

Filed Under: Game Development - Comments: 7 Comments to Read



top