This is a question many a would-be developer asks, and many more established ones too. After all, RPGs, i.e. roleplaying games, are known to be huge, complex beasts not unlike their famous boss monsters. Even so, they have existed even in the digital space back when computers barely had enough memory to store your D&D character’s 30-page backstory. So, if a microchip with less processing power than a modern fridge could run one, they can’t be that hard to make, right?
So, is it hard to make an RPG?
Short answer: No, not necessarily.
More accurate, boring answer: it really depends.
If you’re here, on a website about developing roleplaying games, you are well aware that RPGs come in all shapes and forms, from procedurally generated roguelikes presented in glorious ASCII, to 100+ hour story-driven epics rendered in detail with the latest technology, to idle games and SNES-like RPG Maker adventures. Then the answer must be, like the one about an unladen swallow, which kind? And to make matters even worse, there’s not even an established taxonomy on all the variation found within this huge and sprawling genre, although I did write about that very thing earlier.
“But surely, there are things that most, if not all, RPGs have in common?” You ask.
Certainly, there are plenty of features people would expect a roleplaying game to have, even if they can’t agree on which ones are the minimum requirements:
- Characters. This is probably the most vital one. There should be some kind of a role to play. What differentiates an RPG character from the kinds in other games is that they are defined by some sort of explicit attributes (like “Strength” and “Outdoorsman”), and the general expectation is that during the game, those stats go up.
- Exploration. Here we already enter territory not covered by every subgenre, but historically there were plenty of dungeons, so that’s what most came to expect. It doesn’t need to be dungeons in the strictest definition of the word, as it’s usually used as a short-hand for any explorable area usually filled with enemies, traps and treasure.
- Items. Speaking of treasure, the aforementioned characters should be able to find and use a variety of paraphernalia to aid them on their…
- Quests. Sometimes implied, sometimes straightforward, oftentimes very, very violent, but one of the more essential elements of the genre.
The list goes on and on, like a particularly successful run in Nethack, but in short, we could say a roleplaying game is a game where “characters explore dungeons to gain better attributes and items in order to complete one or more quests.”
Now that we have a working definition, we can break that into pieces and see what is required.
Wait a minute! Don’t all RPGs have a story too?
They do, indeed! In fact, Janet Murray somewhat famously argued that even Tetris has a story in her book Hamlet on the Holodeck. Even if you don’t subscribe to that rather hardcore view on game stories, most RPGs tend to have explicit stories, and modern ones are known for being quite elaborate and ambitious in their narrative. The reason I didn’t include it as a separate category is that between the characters and quests, from a game design or architecture perspective, the story is already there. It’s also why the element that deals with storytelling is called the “Narrative Framework” below.
Data Model
All those attributes and items need to be stored somewhere. In tabletop roleplaying games, the place to put them would be the character sheet, and in the digital version, we usually have a representation of that in the UI and somewhere under the hood.
At the simplest, a character sheet can be one class with a bunch of variables storing the needed information, but in practice, it tends to get a bit more complicated than that, mostly because these attributes and items need to be connected to each other the rest of the game in ways that get complex very fast. You not only need to know what the character’s Attack Power attribute is, but also the bonus they get from the Sword of Salmon Slaying, but only if they’re fighting fish-type creatures, and if the Might of Many Gods buff gives any bonuses to the said stat.
This is, of course, a problem solved a thousand times, and there are plenty of pre-made solutions available, but it’s also one that’s highly specific to a game, or at least to a generally narrow slice inside the genre, and more unique your design is, more specific to your game the data model will be.
Level Environments
Most RPGs will have various environments to explore that consist of tiles, terrain or custom 3D models, have some colliders to define which areas are walkable and which are not, and contain some points of interest the player needs to reach, e.g. a treasure or an exit. While this used to be a major part of the development effort, modern engines can do most of this out of the box: in Unity, for example, it takes you mere minutes to sketch a simple terrain, drag a third-person controller to the scene and start exploring.
On a side note, the technical complexity of the environments depends greatly on your design: a sprawling open world where you can see miles ahead á la Skyrim is still a lot of work to realise, whereas a top-down 2D dungeon consisting of a handful of tiles can be done with little to no actual programming.
What is pretty much always a major part of the project is creating the content for these environments, including the level design, environment art, dialogues, interaction scripting and so on. Or, you can just generate the content, but that only starts to save time in the long run, as it has much higher starting costs.
Autonymous Interactive Objects
As mentioned before, the dungeons need to be populated with all sorts of hazards – and commonly, at least some of these obstacles need to exhibit some sort of independent behaviour: enemies patrolling the corridors, NPCs walking in circles around a city block, cars appearing out of nothing and disappearing into oblivion after having fulfilling their task of looking the metropolis look lived. A smaller subset of them should also respond to the player’s actions in some manner, either in a violent burst of hostility or providing a snippet of information in the form of dialogue.
The exact amount of these elements and their required behaviour varies greatly. In NES (J)RPGs, enemies did not appear inside the level, and NPCs seldom do much else than move a few squares randomly. In contrast, modern open-world RPGs feature a complex web of information and interactivity between the characters.
Narrative Framework
Lastly, there usually needs to be a quest, and that quest and the player’s progress along it needs to be communicated in some way. Over the years, RPGs have evolved from simple dungeon romps into a genre where having deep lore and an involved storyline is the norm rather than expectation, although by going for a more retro feel, it can be omitted for the most part. But if your story is anything more complex than “fetch the Amulet of Yendor”, you’re going to need a way to handle all that talksy stuff.
There are, again, endless tools and plugins available with varying levels of complexity, including suites like ArticyDraft and full-on scripting languages like Ink, but even when using a premade solution, you need to tie the narrative knots together with your data model, environments and NPCs somehow, which means building a narrative framework. It can be a rather barebones one, simply keeping track of a few variables (who the player has talked to, which quests have been completed, and so on) or a sprawling system of a Bioware RPG.
With all of these elements coming together, you’re finally approaching something that even the prickliest Steam reviewer could not help but call an RPG. As discussed, none of these individual parts needs to be overly complex, but their interplay will get at least moderately headache-inducing no matter what. Handling that complexity is the main part of developing an RPG, and the better you are able to plan it out beforehand, the smoother the ride will be.
So Can You Finally Tell Me If It’s Hard?
Ok, so: from scratch? Absolutely. With modern tools? Not necessarily. If you are content with the limitations an engine like RPG Maker imposes on your creativity and don’t mind the risk of drowning in the ocean of games made with the engine, it need not be anything more complicated than writing a simple story and designing a bunch of levels. Or, if you’re comfortable with Unity, there are numerous RPG engines built on it that you can purchase for a relatively small fee and have a much larger amount of freedom. If you’re more or less confident in your programming skills (especially creating the data architecture and rule systems), you can build it on just Unity or Unreal, still benefitting from most of the features these engines offer.
I guess the answer then is: you can choose your own difficulty level, depending on your vision and ambition.
And if you think you’d maybe want some pointers to get started, check out my articles on battle design and maybe leave your email address in the Subscribe box, as I’ll dig deeper into the Pitfalls of RPG Development soon, covering areas that most tutorials tend to gloss over or offer sub-standard solutions for.