I said in my first post that I wanted to make a roguelike JRPG. But what does that even mean, exactly? What are the fundamental features that make a game a JRPG? How could those best be translated into the traditional roguelike framework? What do they bring to the table in terms of clarity and flexibility?
Good questions, all. Let’s get into it!
JRPG stands for Japanese Role Playing Game, a term coined to refer to a particular style of video game that was produced in Japan from the 80s to today. It is sort of a sub-genre of RPG, with a set of particular traits. Much like the term “roguelike”, it has come to be very fluid, and could be used to refer to any RPG that was produced in Japan, or ones with a very specific set of features.
The ur-JRPG is called Dragon Quest, a phenomenally popular series dating back to 1986. The first game was inspired by Wizardry, a very popular PC RPG by the American developer Sir-Tech, which was released in Japan the year before. That series went on to inspire its own particular sub-genre of RPGs focused solely on crawling through dungeons in first-person. But that’s a whole ‘nother kettle of fish.
Dragon Quest set the standard. It was a very early NES (or, rather, Famicom, the Japanese name for the NES) RPG, and inspired legions of copies in the immediate aftermath. These copies then started branching out, changing things up, adding new mechanics, doing things differently.
The basic gameplay of Dragon Quest is essentially an attempt to translate tabletop RPG mechanics to a computer interface. You are given a series of verbs to use in the world. Since the Famicom lacked a keyboard interface, these had to very specific to the things that you would have to do in the course of the game: Talk to people, open doors, go down or up stairs, search the ground, and so on. This sort of thing was replaced with a single context-sensitive button in future installments, greatly simplifying things.
But what hasn’t changed much over the years is the battle system. You face enemies head-on, from the perspective of the player character. You have as much time as you need to select your command, which is then executed. This is the basic, bedrock foundation of JRPGs, this sort of turn-based gameplay, where all other considerations outside of the battle and thrown away for the duration. Your attention is captured completely by the combat, it’s as if it takes place in another dimension.
This is the primary distinction between JRPGs and western RPGs, after the days of Wizardry at least. Modern western RPGs, your Elders Scrolls and Preys and Deuses Ex, have stayed closer to the original goal, replicating the idea of playing a particular role in a fantasy world. Everything flows together, you can move cleanly from combat to platforming to stealth to talking, all within the same world, using the same systems. There is not the sharp break between combat and non-combat that you see in JRPGs.
Within this paradigm, there are many, many variations, over the past 33 years in which this genre has existed. You get all sorts of changes to the battle system, and the way that it relates to the world outside of it. Battles can happen randomly when you’re in a dangerous area, enemies could be represented on screen and cause you to into battle when you into them, or both. Combat itself could be strictly turn-based, or fully real-time controlled, or a combination of both, as in the ATB system in Final Fantasy games.
For the purpose of translating roguelike gameplay, I think something very traditional would work best. My goal, after all, is to use the part of a JRPG combat system where you can slow down and absorb relevant information before making decisions. Real time combat would be neat, but also defeat the purpose.
My original inspiration for making a JRPG roguelike was actually the battle system in the first two Paper Mario games, but I think crafting something like that is beyond me. Too many moving parts, and I’ve seen it imitated to… less than stellar results, just recently (YIIK). So, rather than that, I look to the Dragon Quest games for the basic structure. If it ain’t broke, don’t fix it, and they’ve been using this same one for three decades, so it must be very sturdy.
The key aspect, though, is presenting the information the player needs to make decisions. There are a lot of ways to accomplish this. Little innovations and quality-of-life features in more recent JRPGs that I may draw from.
For example, in older Dragon Quest games, you would pick all the actions for your party, and then the turn would actually take place. The order of those actions, mixed in with those of your opponents, were completely opaque and out of your control. You could try and suss things out by looking at the “speed” statistics of your party, but in general you just had to guess, or keep track in your head.
Some games, though, show a simple turn order at the top of the screen. This way, you can plan things out, knowing which things will hit when. It also allows for more mechanical depth, skills that change the order around and whatnot.
There is something lost, though. That feeling of leaving things to chance, a sort of hope that things go well. You can only plan so much, and then you just have to react to the results you get. This is the central tension between different kinds of strategic games. On the one hand, you get things like Into the Breach, where you will always know exactly what the enemy is going to do, every single turn. On the other end, there are games where enemies work on a completely random AI, where dice rolls determine everything, and it’s up to you to work with what little agency you have to turn things in your favor.
Roguelikes have traditionally lived more in the latter category. You just throw the dice over and over, work out better strategies of improving your odds. But that type of gameplay just isn’t very engaging to me. I like to come up with more specific plans, and then see them execute and work, or not. That more direct feedback keeps the player engaged more actively with what is happening, the actual mechanics of the game at work.
The amount of possible relevant information in an RPG is enormous, especially if you are leaning more towards the traditional tabletop model. The reason that western RPGs lean towards simulating an entire world all at once, with every mode of interaction available all the time, is that they’re built out of tabletop RPGs, like Dungeons & Dragons.
The thing is, they can never truly live up to that standard. A tabletop RPG has a game master, a real person who you can ask questions of about the fictional world. They can make stuff up on the spot, and so answer basically anything. That’s not possible, or at least extremely difficult, with a computer.
So, in an RPG, is it relevant to know what the current temperature is? What direction the wind is blowing? Hey, it might be! In Caves of Qud, your current temperature can either slow down your ability to act or cause you to burst into flames, at opposite extremes. Most of the time, it’s not relevant, but it could be at any moment! So, you have to find a way to show it to the player, all the time.
This leads to very cluttered UI, where it can be difficult to parse what the most relevant information is at a given moment. The advantage of a JRPG system is that it allows the player and the designer to focus in and go in depth on a single type of interaction. To cordon off a certain time, and say that these are the rules for this and these are the things you need to know, right now.
In all role playing games, there is a dichotomy between things that are simply game mechanics, and the notion that you are simulating interactions in a fictional world. I’d like to be a little closer to the former, than the latter, is all.
Dragon Warrior (1989), developed by Enix.
Wizardry: Proving Grounds of the Mad Overlord (1981), developed by Sir-Tech.
Dragon Warrior (1989), developed by Enix.
Final Fantasy X (2001), developed by Square Soft.
Caves of Qud (2015), developed by Freehold Games.
1 thought on “Towards a Better Roguelike: Breaking Down the JRPG”
You do realize that by making a “jrpg roguelike” you’re essentially pigeonholing yourself.
Why make a “jrpg roguelike”? Why not just make “a game”? Ever considered that?
What is the point in game design if you’re just going to follow the formula? Create your own formula.
Sure there are many games that follow the formula and are enjoyable but you need to realize that they do not intentionally follow the formula, they do so coincidentally, not intentionally.
It is important to realize that videogame genres are nothing more than a marketing tool to grab the attention of a specific audience, game developers should disregard genres, especially genres like “jrpg/wrpg” because everything is a RPG these days. Put simply, the RPG genre does not exist. Dungeons And Dragons is a strategy game, not a RPG. Roleplay is a metagame associated with DND. Therefore the genre never truly existed, the only reason why it continued to be used was because it helped target people who enjoyed games like DND.
Nowadays it has a whole different meaning… in terms of marketing anyways. Now pretty much any game which focuses on exploration/storytelling is considered an RPG… look at Horizon Zero Dawn… that game has more in common with Farcry Primal than it does with Dungeons And Dragons… yet it is considered a RPG…
The Point is, instead of pidgeonholing yourself by selecting a genre to build around. Instead you should build around a personalized vision because a vision has no rules other than the ones you decide yourself. You make the rules, therefore you make the mechanics, therefore the end result is deliberately designed to support your vision, that makes the game focused, tight and ultimately more engaging.
Think about it, how many games these days have a level up system? Why have a level up system? Because the rules of “RPG” state that it’s a defining facet? Or because it grants players the rewarding of experience of growth?
There are many ways to provide growth in gaming and game developers have yet to explore these methods because they are too busy pidgeonholing themselves in pre-established design. Don’t be that guy, think about what it is you want to make not what you want to replicate.
LikeLiked by 1 person