Building an RPG Battle System - Part 2

This is the second part of the article detailing the battle system design for my two roleplaying games, Rimelands: Hammer of Thor and Trulon: The Shadow Engine. Last time I wrote about my design process and how I applied it in Rimelands. This article continues in the same vein, using the second game as an example. 

You can find the first part here.

Trulon: The Shadow Engine (2015)

Based on the world created by the Finnish amusement park Powerpark, Trulon is a mixture of fantasy and steampunk. The protagonist is a young monster hunter called Gladia, who sets out to discover the origins of a mysterious disease. She's joined by a group of people during her adventure, each of which brings a different set of skills into the foray.

Trulon was first conceived as a rather traditional JRPG, but soon became something more distinctive. The game's combat system is based on cards, with each of the characters having their own unique decks. The characters have stats common to the Japanese roleplaying game tradition, such as attack and defence, which dictate the amount of damage dealt in an attack. 

At the start of a battle, each character draws a hand of three to five cards, which are called Tactics in the game's vernacular. The characters then take turns to play one card each. The action is taken immediately after the card has been played. There are also two additional cards: an attack tactic and a wildcard. The character can always use the attack tactic and it's never removed. The wildcard is selected randomly from all the tactics in the all of the characters' decks, excluding tactics that can be played only by certain character or which need mana to play. Once the wildcard is used, it is refreshed on the next character's turn. 

Mana in Trulon's world is divided into two forces: Gaudium, born from life and happiness and Dolorum, born from suffering. This division is central to the setting, so it was imperative to also include it into the game mechanics. Some of the tactics require mana and each character can use only one of the two. Using the magic tactics depletes the character's mana reserve (can be expanded by equipping certain items), which does not replenish after combat. This is balanced by the fact that tactics with a mana cost are more effective than the ones without.

The Core Loop

An important point in any game's design is to have a good picture of what the game's core loop is. Basically it's the input - feedback loop that's the backbone of the whole game. Trulon's core or feedback loop looks like this:

For every piece of player feedback, there are three distinct effects: positive, negative and random. Positive effect is the direct result of the player's action and the main driver of the player's progress. Depending on the action, it can be also a status effect or healing a player character, but the damage is the most common effect.Negative effects hinder the player and drive them towards defeat, usually by dealing damage to the player characters. 

The negative and positive effects can be seen as increasing two distinct tracks: the victory track and the 'doom' track (a term I borrowed from the Arkham Horror boardgame). These two tracks do not interact with each other and progress in one does not affect the progress in the other. This effectively means the battle can be won even if the 'doom' track is almost full, or vice versa. 

In roleplaying games, these two tracks are usually represented by the player and enemy character hit points, but it needs not to be so. Introducing a different victory and defeat mechanism not directly linked to the character health is a good way of breaking the mold and going somewhere new. 

One important point is that the victory track should fill linearly and backtracking on it is a source of player frustration. This is why I avoid any healing powers on enemies, as they usually make the battles longer without a notable strategic value.

The third effect is the random element in the game, introduced to bring variation to the battles.

Cards as a Varying Playing Field

Even though randomisation is so common as to be a core element of roleplaying games, we usually strive for a good amount of determinism in the overall design of the game's systems. The players have to have a rough idea of what results to expect when performing an action, and the bigger the variance, less agency they feel. This leads to a situation where similar battles usually play out roughly the same way. It's too resource consuming to design each battle to be totally unique, so we need a mechanical way to add variance to the combat encounters. 

Trulon achieves this by limiting the player's options to a random selection of actions. Even though the Attack tactic is always available as a backup, the other tactics are designed always be better than the vanilla attack. 

The goal of this design is to resolve one of the most common problems in the JRPG genre: the "attack smashing" where the battles are often reduced to spamming the default attack since there's no motivation to use skills or spells which would deplete the player's resources. 

Controlling the Randomness

Trulon had a rocky road from design and early prototypes to the finalised combat mechanics. While the basic concept of combining the card gameplay and JRPG style battles seemed sound, the game didn't feel right. The biggest fear was that the game would feel too random and the player would get stuck with no cards they could use in a given situation. This lead to adding the basic attack card that would be always available and the wildcard which would give the player a chance to always have something better than the vanilla attack that to play. 

The big hurdle was getting together a prototype battle that felt fun to play. At a point this early in the production process we couldn't have a large collection of cards or enemies with tons of special abilities, so the goal was to get the core mechanics to a point where playing with a limited collection of options felt satisfying. 

Unlike Rimelands, Trulon was a work-for-hire project, which lead to a stricter budget and schedule. While Powerpark was a great and very understanding customer who trusted us to know best when it comes to developing games, we still had to make sure what we had was something they could also believe in. We actually had a deadline by the end of alpha to get the card combat mechanic working, or we'd switch back to a more traditional JRPG battle system.

The puzzle finally fell together when an early tester feedback referenced the unpredictability of the attack mechanic. In the prototype, the damage of each of the attacks was also randomised. This meant even if the action you took was the optimal one for the situation, bad luck might make it seem like a wrong decision. Removing the randomness from the damage calculation and eliminating the 'to hit' roll made the battles far more tactical, even if in mathematical terms the change was miniscule. 

Critical Hits

Removing the randomness from the damage calculation had one big problem: it removed the 'critical hit' chance. While occasionally missing the target due to bad luck is frustrating, occasionally getting an extremely good hit is satisfying on a psychological level. This dilemma lead to the final piece in the Trulon combat puzzle: the assault cards. Assault cards are cards with a special effect dictated by the gear the character is wearing. In start of each battle, a fifth of the cards is marked as an 'Assault Tactic'. 

Assault Tactics can have a multitude of effects depending on which items the character playing the card is wearing, including double damage, stun, healing and hitting all the enemies in the single blow. This also added a new dimension in the game's meta: in addition to managing the character decks, the gear has a very concrete effect on the battles. 

One thing I learned from Rimelands was that gear with an actual gameplay mechanics was far more interesting than the ones that only offer better damage or stat boosts. While Trulon certainly has it's share of stat boosting items, I strove to design something more interesting for many of them. The items with actual game mechanics are tied to the Assault Tactic system, giving the character new abilities when using the gear. 

Iteration Through Testing

I usually divide testing in three broad categories:

The type of people you want to play your game depends on what you are currently testing. For functionality testing, you will want actual quality assurance people who are thorough and familiar with professional testing procedures. While there's no harm in also using the QA department for gameplay and usability testing, you will also want a wider variety of people. The ones working as game testers tend to be very active and experienced players, and you seldom want to limit the game's audience to such a group of people.

In the early phases of the project, what you want to concentrate on is naturally the gameplay testing. I like to test the gameplay on three types of people: insiders, gamers and the common people. Insiders are the ones in your team or company and are the easiest to obtain. They'll tell you what the glaring problems are, but are often too knowledgeable about the game to be able to notice subtler problems. After that come the gamers, your friends or other game industry people. They won't know about the game's design or goals, so they can provide a fresh perspective. Finally, I find it very advantageous to show the game to people who have little to no experience in your game's genre or in more casual games, games in general. If they like and are able to understand the game, you will know you have something instantly accessible on your hands. 

For Trulon, our target demographic was teenagers, so we set out to test the game with people aged 13 and up in a very early stage of the project. We took the first playable version and went to schools (which are often very welcoming to such distractions) to gather feedback. The results were literally game changing. 

Accessibility

One the of the design pillars behind Trulon and Rimelands was to avoid any obstacles before the player gets to experience the actual gameplay. Roleplaying games (digital and otherwise) are traditionally not very good at this, requiring character creation and lengthy bits of introductory story before the player actually gets to do anything worthwhile. I'm not trying to say digital roleplaying games should never have character creation or an epic introduction, but personally I feel that first immersing the player with the gameplay and only then with the story and the nuances of the character makes the game more accessible to a larger demographic.

Trulon's introduction was designed to play out like a opening of a TV show, showing glimpses of what's to come. I'm well aware of many player's habit of skipping introductory videos like these, so in this way the player at least doesn't miss anything crucial about the story. After the game starts in earnest, the player only needs to go through two short conversations before the first battle begins.

I wanted to make the tutorial a part of the game's story, so it's framed as a lesson from Gladia's teacher Marcus. The short tutorial battle only concentrates on the very basic mechanics of the game: using Tactics and wildcards to attack enemies. Again, I didn't want to flood the player with too much information so early in the game, rather than getting them playing. 

After the tutorial battle, there's a slight story and exploration segment before the first actual level of the game. The battles are of increasing complexity, introducing new elements in each battle. There's only one fight with any real tutorial content: teaching the player about how mana works in the game. Otherwise I wanted to let the players learn by playing. 

Enemies

The last piece of the battle system puzzle is designing the enemy mechanics. Often the mechanics are symmetric, the player and the enemy characters play by exactly the same rules, the enemies are just controlled by an AI instead of a player. There are other ways to do this, such as using asymmetric mechanics, a situation where the enemies differ in some aspects from the player. In Chrono Trigger, one of the inspirations for Trulon, the enemies do not use the combo mechanics for instance. 

I opted for a slight asymmetry in Trulon. The enemies do not use Assault Tactics at all, and they don't actually have a deck or a hand to draw cards from (and thus also lack the wildcard). Instead, the AI is programmed to use certain cards either once or as many times as needed, with certain triggers to change the AI behaviour. Some of the enemies are more predictable than others and I found that the harder enemies should behave more consistently, making them more like a puzzle to solve. For example, Hunter in the Dark, an optional boss, changes its tactics and the cards it has at its disposal when its health drops below a certain threshold. An earlier boss always performs a targeting action before launching a devastating special attack, the target of which can be seen if the player has turned on a steam valve before the battle.

Conclusions

While I do have a 'design philosophy', and certain routines I fall back into when designing new games, the process is a fluid one and never quite the same from one project to another. The important thing is to find the way that suits you personally, as well as the project at hand. 

Getting the core loop right is one of the most important and often most difficult parts of designing any game, and it's no different for roleplaying games, even if the core loop itself is more complex than in simpler games. In many cases a paper prototype or a digital one with crude assets may be enough to fine tune the core mechanics, but in some cases, especially in more action oriented games, you may want to have some proper assets to test the game flow with animations and effects, as it influences the game feel quite a bit. 

Thank you for reading, please chime in below if you have anything to add,  or if you have any questions!