This is an in-depth look into designing a battle system for a roleplaying game. Using two games I’ve designed as an example, the article dives into the process and particulars of designing a battle system for a digital roleplaying game.
The combat for both Rimelands: Hammer of Thor and Trulon: The Shadow Engine received a lot of praise and while they are superficially very different takes on a roleplaying game combat system, they share a lot in how the mechanics were designed and illustrate my personal design philosophy. Both games have a turn-based combat system, but in Trulon, it is based on a deck of cards and in Rimelands on a pool of dice. In the former, you are in control of a whole party of characters; in the latter, only a single character. Outside of combat, both have similarities and differences, but this article is concerned only with the core combat mechanics.
This is a two-part article, with both parts concentrating on the respective game, starting with the earlier one:
Rimelands: Hammer of Thor (2010)
Note: Rimelands was released on Nintendo Switch in 2019, I was not involved in that port, nor do I hold any rights to the IP anymore.
Set in a post-apocalyptic world recovering from a recent ice age, the game’s main protagonist Rose Cristo sets out on an adventure filled with magic, Norse mythology and steampunk elements. Most of the game is spent exploring Vaults, abandoned shelters that have become dungeons rife with treasure and monsters. Some of the dungeons are procedurally generated, and some are pre-designed.
When the player approaches an enemy, the game becomes turn-based, and the player and the opponent take turns to act. During a turn, a character can perform a single action: move, attack or use a skill. Since one turn is only a single action, the pacing of the game is fast, even with the dice rolling visibly on the screen.
As traditional in the genre, the characters have a number of statistics that determine their chance of success in combat. In Rimelands, the core combat abilities are called Melee, Ranged and Magic, each associated with a specific type of attack. The game rolls a number of dice equal to the character’s ability when an attack is started. Each dice has four distinct outcomes: double hit, hit, block and miss. After the attack roll is made, it’s the defender’s turn to roll the dice. The attacker and the defender use the same ability (e.g. attack with melee is also defended with melee). If the number of hits from the attacker’s roll is greater than the number of blocks rolled by the opponent, the attack hits.
Each character also has two defensive stats called Toughness (used against melee and ranged attacks) and Deflection (used against magic attacks). If the number of hits after the blocks have been subtracted is equal to or larger than the toughness/deflection value, the attack is a piercing one. Piercing attacks ignore the target’s armour value, usually doubling the amount of damage inflicted.
The player also has a chance to reroll any of the dice which did contribute to the success of the roll (misses and blocks in attack rolls; hits and double hits in defence rolls). Rerolling costs one point of mana, the maximum amount of which is five throughout the game. Mana is also used to power skills and can be regained by skipping a turn during the battle.
Rimelands was originally born as a small prototype where I wanted to test out controls for a roguelike game for iPhone. Its roots still show in the turn-based structure, although, as opposed to traditional roguelikes, the characters act in sequence, not synchronously.
The Design Process
I usually start designing with these core questions in mind:
- What actions does the player take each turn?
- How does the system determine the result of an action?
- How is that result communicated to the player?
Often, the game design process doesn’t start with the battle system, so there’s some information to draw from when answering these questions. In the case of Rimelands, it was already decided that it was going to be a third-person game with a tile-based map. This gave me two obvious actions: moving on the map and attacking opponents. The next step was to include the dice, so I actually answered the third question before the second one. Since I already knew that the HeroQuest-style dice pool with symbols instead of numbers on the dice worked pretty well, the system fell into place quickly from there on.
I would also recommend any aspiring roleplaying game designer to take a look at tabletop games and their ways of resolving these issues since it’s a lot more transparent than in digital games. Especially for turn-based games, paper prototyping is also a quick way to test and improve the core mechanics of the system.
Meaningful Decisions in the Core Mechanic
Both Rimelands and Trulon are based on the same ideal: on each turn, the player should have to make a non-arbitrary decision. In Rimelands, this is the re-roll mechanic: whether to spend a point of mana in hope of a better result. The toughness/deflection mechanic also exists to support this, as it gives the player a reward for striving for more hits than needed just to land a blow on the opponent.
The re-roll mechanic was not in the original design of the game, which was very close to a modern reimagining of the HeroQuest board game’s digital version. The initial reason for including the visible dice rolls was to bring transparency to the game mechanic. If the player actually saw the dice, it would be easy to deduce how the game actually works without needing to resort to lengthy tutorials or a manual.
During the early playtests, many found the visible dice more distracting than useful and the game felt too random. Since I wasn’t ready to sacrifice the transparency yet, I resolved to find another solution and thus, the re-roll mechanic was born. The effect was twofold: it removed some of the randomness by giving the player a chance to try a better roll, and it gave a reason for the visible dice to exist – they were now an input to a very central decision in the game.
Roll-playing in the Digital Space
Rimelands is very much a tabletop game at its heart. While tabletop roleplaying games have been ported into digital ones since the early days of Dungeons and Dragons in the 70s, there are some aspects that are difficult to handle in digital devices. The Dungeon Master is by far the most often discussed, as computers still can’t compete with the storytelling skills and flexibility of an actual human. Another often as important ingredient is the humble die.
Dice roll in a tabletop game is actually an active action. You are rolling the die. Even if we all know the result is ultimately random, there’s always a part of us who believes it’s possible to actually affect the outcome with a ‘good roll’ (or by choice of a die). In digital games, it’s the device that is rolling the die, or dice, and the player doesn’t have any agency in the matter. To simulate a tabletop experience on a digital platform, one must somehow design around this limitation. The Rimelands solution was to add an additional step to the process where the player could make an active decision.
The core question in traditional RPG battle design is this: how does a character deplete another character’s vital resource?
The vital resource is most often called health or hit points, and the primary way to reduce it is via damage dealt by attacks. This is usually determined by a two-step process: the to-hit roll and the damage roll:
To Hit Roll: Number of hits - number of blocks > 0 Damage Roll: If to hit < Toughness/Deflection: Damage = Random(Weapon's min damage, weapons, max damage) - opponent's armor value Else: Damage = Random(Weapon's min damage, weapon's max damage)
You can calculate your average hit percentage (two equal opponents) from the to-hit equation quite easily and in general, it should be at least 50%, preferably above 70%. From the damage roll you’ll know the average amount of damage with any weapon and usually can know how many hits a foe needs to take before going down. I tend to prefer three hits for a run-of-mill enemy.
Modern digital roleplaying games often forego the to hit roll altogether and just determine the damage for each attack. It’s usually very boring if a fight is just a series of misses, as missed attacks do not modify the game state in any way. Thus Rimelands also has a very low barrier for successfully hitting an opponent, and the real challenge is to land those devastating piercing hits. The dice are also balanced to support this, and a single die has four hits but only two blocks.
Pacing the Turn-Based Action
One of the reviewers called Rimelands a “turn-based action RPG”, a description probably born out of the roguelike influences and thus a similarity to the Diablo series and other action RPG games. However, there is merit to this classification when the pacing of the game is considered: by limiting the characters to a single action per turn, the overall rounds tend to stay short, even when fighting a larger group of opponents.
The dice rolls slow down the action, but with the reroll choice popping up at constant intervals, the player is spending most of the time making decisions instead of just watching the action unfold.
Opposed to the more common system used in the two first Fallout games, for example, the intervals between active and passive play are considerably shorter. Another effect is reduced planning. Although it is certainly preferable to plan ahead in Rimelands, the player can only execute very short action chains until the game’s state changes as the enemies make their move. This leads to a less planned feel in the combat, compared to games where you can use several actions per turn, often with each character in the party. This is not to say either approach is objectively better: they just lead to a different game feel.
Even if your first prototype is on paper (or stays on the paper, many of these principles apply to tabletop design, too) or consists of rectangles or cubes taking it out on each other, you should be able to start working on the game’s feel during combat. Different design decisions lead to divergent experiences, and all may not be suitable for the game’s overall atmosphere. For example, if you’re working on a game where the player character is a member of an intergalactic SWAT squad, you’re probably wanting more tactical combat and a panned-out feel for the turns instead of fast-paced cinematic action.
In the next part, I’ll be talking about these same decisions in relation to the design of the card-based roleplaying game with a certain Japanese flair called Trulon: The Shadow Engine and the game’s own peculiarities.
Until then, thank you for reading and happy designing!
Read the next part here.