Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
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 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 of the core combat mechanics.
This is a two part article, with both parts concentrating on the respective game, starting with the earlier one:
(Screencapture from the unpublished PC version of the game)
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 in exploring Vaults, abandoned shelters that have become dungeons rife with treasure and monsters. Some of the dungeons are procedurally generated, 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 defender's turn to roll the dice. The defender uses the same ability to defend as the attacker used. 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 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.
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.
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 for 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 to 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.
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 who 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 percent (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, a single die has four hits but only two blocks.
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 a 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 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 of 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 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 to 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 panned out feel for the turns instead of fast paced cinematic action.
In the next part, I'll be talking of these same decisions in relation to the design in the card-based roleplaying game with a certain japanese flair called Trulon: The Shadow Engine and of the game's own peculiarities.
Until then, thank you for reading and happy designing!
The next part is now available here.
Read more about:
Featured BlogsYou May Also Like