...

If you want it to be, that is.

This is a battle.

Last Saturday, I read this post on Kyle Labriola's Blog about how he designed the battle system in his RPG project. I'm very ambivalent about it, because while he does raise some interesting problems and it's always nice to read how someone figures out their own solutions, it is unfortunately also way too prescriptive for my liking.

I'm not blaming him, because almost all of the conversations around designing games are framed in a normative manner. It's 2025 and people are still talking about specific games having "good" or "bad" game design and then everyone yells at each other, because we all have different ideas of what these adjectives actually mean. However, I do find it a bit sad to find this type of style in a post that frames itself also as a basic "how-to" guide for people who might be looking for clues, or information about the topic in question.

So this post is going to be in parts a reply to his post and in parts an attempt of mine to demonstrate a different way to frame conversations around game design.

It starts with a Question

"When making games, I think it’s important to break everything down to its base elements and ask yourself what the point of anything is. 'Why would anyone play this?'"

This is how Kyle starts the main body of his post and you will see that already both of us have left almost all common ground, because when I make my games the question "why would anyone play this?", only ever enters my brain during intense phases of creative nihilism.

For me, the question I'm asking myself usually is a different one:

"What do I want this to be?"

Bluntly speaking: I'm not very interested in the reasons why anyone plays anything that I'm making. Everyone's different and even if they like the same things, they might like them for different reasons.

I, as a designer cannot really predict these things, but I can build something that creates a specific experience and shape that experience around a set of clearly defined principles. Of course, a player-first driven approach also does this, but you will see soon enough, how far these paths can diverge.

What actually is a (J)RPG Battle?

This is too a battle.

[Note: I'm mostly going to talk about JRPGs, because Kyle uses Dragon Quest style battles as his example, and it sounds that most of his work revolves around an abstract, turn and menu based battle system.]

Kyle, in his post defines a battle like this:

At its simplest: the only goal in turn-based combat is to bring your enemies’ combined total of HP to 0 before your party’s combined total hits 0. That’s literally it. Unless you introduce any major mechanics that demand anything else, that’s all the player does. It’s all just naked algebra. The player selects numerical values (called “Attacks”) from a menu of choices, and those values subtract from the enemy total. You keep subtracting, and when it hits 0, you win. The enemy, controlled by a set of CPU rules, takes turns subtracting from you.

I want to directly contrast this, with something I wrote back in January:

"Because of this abstract nature, and the connection they create between the game’s narrative framing and its underlying systems, at their most basic level Battles are moments of dramatic significance. It’s where characters and their obstacles act upon each other using their own descriptive qualities and powers."

I fundamentally disagree with Kyle here. Even in a scenario where two red squares fight each other and all they do is subtract a specific number from each other in turns, you're still creating a dramatic moment. It's framed as a confrontation. Sides are performing "attacks" at each other that subtract "health points" and one side will "win" the conflict. Apologies for the quotation marks, but each of these words mean something and together they frame the actions that are performed.

One of the main reasons why I started working on a JRPG myself, is because what I love about JRPG battles is how there's a very close connection to the math that is happening and the meaning that is communicated. Change two words and instead of fighting a monster, you're debating an asshole, or destroy the moon. It doesn't even have to be antagonistic. Due to some quirks, my JRPG project treats resting at checkpoints exactly like battles. Even the actions that the characters are doing are technically all attacks. The code doesn't make a distinction here, but the words on the screen and the presentation do.

The Goal

A Nice demonstration how easy it is to play with scale in these battle systems.

Kyle's overall goal is to talk about different ways to add complexity and a certain degree of depth to a battle system, which is a fine thing to do. However, once again we come to a point where he's much too prescriptive in his framing, and I just don't agree with his conclusion.

To summarise his issues:

A lot of JRPGs struggle with battles being monotonous, because there are very simple ways to end most encounters very quickly, by just spamming the same effective moves over and over again.

This leads to the game feeling boring.

He then concludes:

"Because of that, I consider one of the main goals of the RPG designer to be: convince the player to not spam the same move every turn."

First of all, I find the solutions he describes and that he ended up using for his own project really interesting. I just find the way of delivering the previous part very unfortunate.

I agree that there are JRPGs out there where your strategies eventually converge around a very specific approach, that you repeat over and over again.

Where I don't agree is:

1. Framing something feeling boring as objectively undesirable
2. Saying that discouraging players from performing the same move every time is the only way to deal with this (potential) issue.

Let's talk about boredom first. If your goal is "I want my hypothetical player to feel engaged and excited at all times!" (I'm exaggerating here for emphasis), then obviously them feeling bored is maybe not something you want.

However, I personally can see how maybe you might want to bore your players, or more broadly speaking exhaust them via monotony. There are legitimate dramatic reasons why you may want to do that and so thinking about and knowing very specific strategies how you can do that is actually quite useful. Sadly videogames is obsessed with being fun for everyone at all times, so no one has done any deep dives on how to do boring game design, but we probably should.

Now, let's assume we don't want our JRPG game to have boring battles. Kyle's position is that an RPG designer has to create something where players are discouraged from performing the same moves over and over again. Is this really true? Is this really the only way?

It's not and though I think it's a valid strategy and generally something to think about, saying that you have to do it is not the case.

To illustrate my point, let me talk about my experience with Lufia 2 and contrast it with my favourite game Dungeon Encounters. Lufia 2 a fine game. I find the puzzles it throws at you a bit much sometimes but the dialogue is occasionally funny. The battles I stopped caring about, even though you have a ton of options. You have a physical attack, a big pile of spells and each item you have equipped has the potential to have a special move attached to it that you can use in battle.

That's some cool stuff! Most battles however go like this: The first three characters do a physical attack and the fourth character casts a spell that targets all enemies. If I manage to figure out the elemental weakness of an enemy I try to attack that, but most enemies don't seem to have one.

Compare this to Dungeon Encounters, where basically all you can do is perform an attack (though with different properties, depending what weapon your character has equipped) and thus there isn't really much else you can do, aside from performing the same action over and over again.

However, battles in Dungeon Encounters are very tense and require attention, because the consequences of being careless can easily lead to you losing your entire party.

Lufia 2, to me feels boring, because even though the enemies look different and do different things, they are essentially indistinguishable from one another. When I'm confronted with an enemy formation, it never matters which one of them I take out first.

Dungeon Encounters requires you to pay attention to enemy formations and how you approach them. In that sense Dungeon Encounters also nicely reflects the properties that I like about a nicely designed JRPG battle system, in that random encounters are not that much about overcoming each singular enemy, but about how to most efficiently break up the entire enemy formation.

Even if all you have is a simple "attack" move, you can create complex decision making processes by having enemies with different attacks, hp and defense values, where the sequence in which you remove them from the board can vastly change the degree of difficulty of the entire fight.

This doesn't mean that thinking about how to diversify your player character's movesets in ways that might add variation, tension and more complex decision making, isn't also a valuable exercise. It's more that it's not the only way and that there might be cases and reasons where you actually don't want to go down that specific path.

Battles in a JRPG rarely exist in isolation, they exist in a longer sequence, are influenced by the resources that players have at that moment, the assumed length of the sequence they are in, the stats and current make-up of the player's party, what enemies they are fighting, what formations those enemies come in, encounter density and even how long it takes on average to get through one fight.

And even if fights end up revolving around the same strategy, what could this say about the characters that are in your party?

An example from my game: As I was thinking about how to set up my battle system, I deliberately made the decision to keep the basic, physical "attack" command, and to allow it to be useful in most simple encounters. However, there's one specific character who's not only very bad at physical attacks, but whose main strength has nothing to do with actually dispatching enemies. First I wondered if I should find a way to "make him more useful", but then I realized that this could also be an interesting tool to say something about that specific character and in return about the characters that are "useful in battle".

Encounters are part of the Game

To bring this all to a close, let me quote Kyle again, who somewhere in the first third of his post, when talking about the various reasons why players are pushed towards finding and repeating the most efficient way to get through battles, wrote this:

"If it’s a run-of-the-mill random encounter, they [the players] want to end it quickly so they can get back to the game [emphasis mine]."

(Just a note that I'm not accusing Kyle of thinking that random encounters in games are meaningless or anything like that, I just found his way of phrasing very interesting)

There's this Interview with the Director of Dungeon Encounters, who also designed the majority of the battle systems in the Final Fantasy series, where he said that Final Fantasy 1 was built with 500 Encounters in mind. Now that number was mostly picked, because of the total length it would take to get through the game in a debug session, but it also shows that the encounters were a very important part of the game and not an afterthought.

When I started building the Dungeon for my project, I started with a corridor full of encounters. The fights came first, then came the space.

Now obviously, there's more to a JRPG than the battles and random encounters, but I feel this idea that a random encounter is just a nuisance that keeps you from playing the game is deeply wrong. If you put random encounters, or non-random "minor" encounters in your game, you have to build it around them. Otherwise, you will most likely end up with something that feels more like a chore (which again, is fine if that's what you're going for).

This all brings me back to my position that battles are moments of dramatic tension where the commands, the framing of the battle and the math can be used to say something about your game's story, its characters and even its world's metaphysical makeup. You can use them to tell stories about specific characters, you can use them to tell a joke, or to laugh at the player's expense. They can be about fighting a group of little guys, or a castle, but you could also frame a date as a battle, or being stuck in a high-school debate club. They matter as much as the space you put in between them and the cutscenes you put at the end of it all.

So let me contradict myself and be prescriptive at the end:

If you want to make an RPG that has battles in it, care about them, be interested in them and ask yourself what you want them to be and how you can use them to tell the story you want to tell.

It's not that anything should be a battle, but anything could be a battle. It all depends on you.