Towards a Better Roguelike: Breaking Down the JRPG

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.

---

Image Credits

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.