Creating a battle system in RPG

The combat systems of our Rimelands: Hammer of Thor and Trulon: The Shadow Engine games were highly rated by the players. Despite the fact that these are two very different views on the combat system in RPGs, they have much in common in the design of a mechanic and illustrate my personal design philosophy. Both games use turn-based battles, but Trulon they are based on a deck of cards, and in Rimelands - on a set of dice. In the first you control a whole batch of characters, in the second - only one hero. These games have similarities and differences not only in battles, but in this article I will talk only about basic combat mechanics.

Rimelands: Hammer of Thor (2010)

(Screenshot from an unpublished version of the game for PC)

The game takes place in a post-apocalyptic world that is recovering from the recent ice age. The main character of the game, Rose Cristo, sets off on a journey filled with magic, northern mythology and steampunk elements. Most of the time she explores Vaults - abandoned shelters that become dungeons filled with treasures and monsters. Some dungeons are generated procedurally, others are created manually.

When a player approaches the enemy, the game becomes turn-based, and the player with the opponent begins to take turns to make moves. During his turn, a character can perform one action: move, attack or use a skill. Since the move consists of a single action, the pace of the game is high, even though dice are visible on the screen.

Traditionally for a genre, characters have various characteristics that determine their chances of success in battle. In Rimelands, basic combat abilities are called Melee (hand-to-hand combat), Ranged (long-range combat) and Magic (magic); each of them is associated with a certain type of attack. When the attack begins, the game rolls dice, their number is equal to the level of ability of the character. Each bone has four possible meanings: double hit, hit, block, and miss. After a dice roll, the defender rolls to attack the dice. The defender uses the same ability to defend as the attacker. If the number of hits thrown by the attacker is greater than the number of locks thrown by the defender, then the attack succeeds.

Each character also has two defensive characteristics: Toughness (endurance, used against melee and ranged attacks) and Deflection (evasion, used against magic attacks). If the number of strokes after subtracting the locks is equal to or greater than the endurance / evasion value, then the attack is piercing. Piercing attacks do not take into account the value of the defender's armor and usually double the amount of damage dealt.

In addition, the player can roll any dice that affect the success of the throw (misses and blocks in the case of a throw to the attack; punches and double punches in the case of a throw to the defense). Throwing costs one mana point; there are five mana points throughout the game. Also, mana is used to increase the power of skills and can be restored by skipping a turn in battle.

Initially, Rimelands was born as a small prototype in which I wanted to test the management of the roguelike game for the iPhone. Its roots still show the turn-based structure of the game, however, unlike traditional roguelike, the characters act in turn, and not synchronously.

Design process

I usually start design development by asking the following basic questions:

• What actions does the player perform in each turn?
• How does the system determine the outcome of an action?
• How does a player know about the result?

Often the process of creating a game’s design does not begin with a combat system, so some information can already be extracted to answer these questions. In the case of Rimelands, it has already been decided that this is a third-person game with a tile card. This gave me two obvious actions - moving around the map and attacking enemies. The next step was the addition of bones, that is, I actually answered the third question before the second. Since I already knew that it would be a HeroQuest-style bone set with symbols instead of numbers, the system was quickly integrated into the game.

I can also recommend novice role-playing designers to learn board games and how to solve these problems, because they are much more transparent there than in digital games. Prototyping on paper allows you to quickly test and improve the basic mechanics of the system, especially for turn-based games.

Significant decisions in basic mechanics

Both Rimelands and Trulon are based on the same idea: in each turn, the player must make a decision that will not be random. In Rimelands, this is the mechanics of throwing bones: the player decides whether to spend a mana point in the hope of improving the result. Stamina / Evasion mechanics have also been added to support this choice, because it rewards the player for striving for more than necessary number of hits just to damage the enemy.

There were no bone-throwing mechanics in the original design of the game, which very much resembled the modern rethinking of the digital version of the board game HeroQuest. Initially, visual rolls of dice were introduced into the game for the sake of transparency of the game mechanics. When a player sees the dice, it’s easier for him to figure out how the game works, without long tutorials and guides.

During the first playtests, many players complained that visible dice were more distracting than beneficial, and the game seemed too random. Since I was not yet ready to sacrifice transparency, I decided to find another solution, and so the transfer mechanics was born. This had a double effect: it partially eliminated chance - the player now had a chance to throw out the best result, and also justified the existence of visible bones - now they were input for making the most important decision in the game.

Throwing Dice in Digital Space

Deep inside Rimelands is a very board game. Although board role-playing games have been ported to computers since the beginning of Dungeons and Dragons in the 70s, there were always some aspects that were difficult to implement in digital devices. Most often this is the Dungeon Master, because computers still can not compete in the skills and flexibility of narration with a living person. Another such aspect is often called regular bone.

A roll of dice in a board game is actually an active action. The player rolls the dice. Even if we know that by and large the result is random, some of us always believe that in fact it is possible to influence the result with the help of a “good throw” (or choosing a bone). In digital games, the computer rolls the dice, and the player does not participate in this. In order to transfer the sensations of a board game to a digital platform, it is necessary to somehow circumvent this limitation in design. In Rimelands, we came to this decision: we added another stage of processing at which the player can make an active decision.

Cruel denouement

The fundamental question in the design of battles of a traditional RPG is this: how does a character reduce the life resources of another character?

Vital resources are often called “health” or “damage points,” and the main way to reduce them is to deal damage through attacks. Usually it is determined by a two-stage process: throw to strike and throw to damage:

Бросок на удар:

Количество ударов - количество блоков > 0

Бросок на урон:

Если количество оставшихся ударов < выносливость/уклонение:

Урон = Random(мин. урон оружия, макс. урон оружия) - значение брони противника

Иначе:

Урон = Random(мин. урон оружия, макс. урон оружия)

From the equation of strokes, you can easily calculate the average percentage of strokes (for two equal opponents), and in general it should be at least 50%, and better above 70%. From the damage roll, we learn the average amount of damage for each type of weapon, and usually calculate how many hits the enemy needs to inflict in order to defeat him. Usually I prefer that the average enemy take three hits.

Many digital role-playing games often completely abandon the throw and simply determine the damage from each attack. It’s usually very boring when a fight is just a series of misses, because misses do not change the state of the game, therefore, Rimelands also has a very low barrier to successfully hitting an opponent and the real difficulty lies in delivering destructive piercing blows. The bone is also balanced for this: on each bone there are four strokes and only two blocks.

Set the pace of turn-based combat

One reviewer called Rimelands a "turn-based action RPG" - this definition probably came about due to the influence of roguelike, and therefore because of its similarity to the Diablo series and other action RPG games. However, from the point of view of pace, in this classification there is a merit of the game itself: by restricting the characters to just one action per move, we generally made the battles short enough, even in the case of a battle with a large group of opponents.

Throwing bones slows down the action, but due to the periodic occurrence of the possibility of transferring bones, the player spends most of his time making decisions, and not just watching how the action unfolds.

Unlike the more common system used, for example, in the first two parts of Fallout, the intervals between active and passive play are much shorter. Another effect is a reduction in planning. Although it’s definitely worth planning ahead in Rimelands, a player can take very short action chains before changing the state of the game. This leads to a feeling of less planning in battle compared to games where you can perform several actions per turn, often for each character in the party. I do not mean by this to say that some approach is objectively better; they just create different sensations from the game.

Conclusion

Even if your first prototype is made of paper (or remains on paper, many of these principles apply to the design of board games) or consists of rectangles or cubes attacking each other, you can already start working on the sensations of the game during the battle. Different design decisions lead to a varied gameplay, and not all of them can fit the general atmosphere of the game. For example, if you are working on a game where the player’s character is a member of the intergalactic “special forces”, then you probably need a more measured tactical battle, rather than quick cinematic action.

In the next part, we will discuss the same decisions regarding the design of a card role-playing game with a distinct Japanese flavor called Trulon: The Shadow Engine, and also tell about our own interesting moments of this game.

Trulon: The Shadow Engine (2015)

Trulon, inspired by the Finnish Powerpark amusement park, is a mixture of fantasy and steampunk. The main character of the game is the monster hunter Gladia, who was engaged in the study of the sources of a mysterious disease. On a trip, a group of people joins her, each of whom has their own set of skills.

Trulon was originally conceived as a fairly traditional JRPG, but gradually turned into something more unique. The combat system of the game is based on cards, each of the characters has their own decks. Characteristics of the characters are similar to those traditional for Japanese role-playing games, for example, “attack” and “attack”, which determine the amount of damage caused in attacks.

At the beginning of the battle, each character draws from three to five cards, which are called “tactics” in the game. Then the characters make moves by playing on one card. The action is performed immediately after entering the card into the game. There are also two additional cards: “attack tactics” and “joker”. Characters can always use attack tactics and they never disappear. The Joker is randomly selected from all tactics in the decks of all players, with the exception of tactics that can only be used by certain characters, or for which mana is required. After using the "joker," he is restored on the next turn of the character.

The mana in the world of Trulon is divided into two forces: Gaudium, born of life and happiness, and Dolorum, born of suffering. This separation is the most important part of the entourage, so I needed to include it in the game mechanics. Some tactics require mana, and each character can use only one of the two. Using magic tactics reduces the player’s mana pool (it can be expanded with various items), which is not restored in battle. This is balanced by the fact that mana-spending tactics are more effective than regular ones.

The basic cycle of the game

An important point in creating the design of any game is that you need to have a clear idea of ​​what the basic cycle of the game looks like. In fact, this is the input-feedback cycle, which is the foundation of the whole game. The basic loop or feedback loop in Trulon is as follows:


Each player feedback element has three separate effects: positive, negative, and random. The positive effect is the direct result of the player’s actions, the main driving force of the player’s progress. Depending on the action, this may be the effect of a change in state or a cure of the player, but the most common effect is damage. Negative effects interfere with the player and lead to his defeat, usually causing damage to the player’s characters.

Negative and positive effects can be seen as an increase in two separate counters: the victory counter and the “death” counter (I borrowed this term from the board game Arkham Horror). These two counters do not interact with each other and progress on one does not affect the progress of the other. In fact, this means that the battle can be won even with the counter of "death" almost full, and vice versa.


In role-playing games, these two counters are usually represented as player and enemy damage points, but this is not necessary. The introduction of a new mechanism of victories and defeats that are not directly related to the character’s health is a good way to break patterns and do something new.

An important aspect of the victory counter is that it should be filled linearly, and going back on it is a source of annoyance for players. That’s why I avoid using the healing power of enemies, because they usually lengthen the battle without adding almost any strategic value.

The third effect is a random element of the game, added to increase the variability of battles.

Cards as a changing playing field

Although randomness is a common basic element of role-playing games, we usually strive to create a large share of determinism in gaming systems. Players should have an approximate understanding of the possible outcomes of the action, and the greater the variation, the less they feel that they affect the game. This leads to the fact that similar fights are played approximately the same. Creating a unique design for each battle would be too costly, so we need a mechanical way to add variation to the battles.

Trulon does this by restricting random choices. Although attack tactics are always available as a backup option, other tactics are designed so that they are always better than a “vanilla” attack.

The purpose of the design was to solve one of the common problems of the JRPG genre: “attack spamming”, in which battles often come down to the constant choice of a standard attack, because the player does not have the motivation to use skills or resources that can deplete his reserves.

Contingency management

Trulon has gone a long way from design and early prototypes to completed combat mechanics. Although the basic concept of combining card gameplay and JRPG-style battles seemed solid, the game itself felt somehow wrong. Most of all, we were afraid that the game would seem too random, and the player might not have cards that can be used in the current situation. This led to the addition of a base attack card, which is always available, and a “joker”, which gives the player a chance to get something better than a “vanilla” attack.

It was very difficult for us to assemble a prototype of the battle, which would be interesting to play. At such an early stage of the development process, we did not have a large set of cards or enemies with a bunch of special features, so the goal was to bring the basic mechanics to the level at which a game with a limited number of choices would seem interesting.

Unlike Rimelands, we worked for Trulon for hire, which resulted in a tighter budget and schedule. Although Powerpark was a great, very understanding client, trusting us in the field of game development, we still had to create something that the customer would believe. By the end of the alpha version, we had a deadline for creating working mechanics of card battle. If we didn’t succeed, we would return to the more traditional JRPG combat system.

The puzzle was suddenly solved when references to the unpredictability of attack mechanics appeared in the reviews of the first testers. In the prototype, the damage of each of the attacks was also random. This meant that even if the action taken by the player is optimal for the situation, it may seem bad due to bad luck. By eliminating randomness from the calculation of damage and removing the throw to the blow, we made the battles much more tactical, even though from the point of view of mathematics the changes were insignificant.

Critical hits

Eliminating random damage from calculations had one serious problem: it destroyed the chance of a “critical hit." Although players are annoyed by random misses on the enemy, an extremely good punch gives satisfaction on a psychological level. This dilemma led to the last piece of the Trulon combat system puzzle piece: assault maps. Assault cards are cards with special effects, determined by the outfit worn on the character. At the beginning of each battle, a fifth of the cards are marked as “Assault Tactics”.

The assault tactic has many effects, depending on the items worn on the character playing this card. Effects include double damage, stunning, healing, and attacking all enemies with one hit. It also added a new change to the meta-game: in addition to managing the character decks, uniforms became an important element of the battle.

From the experience of working on Rimelands, I realized that objects with gameplay mechanics are much more interesting than those that provide only increased damage or increased performance. Although Trulon has, of course, a set of items to enhance performance, I tried to create something more interesting for many of them. Items with game mechanics are tied to a system of assault tactics and give characters new abilities.

Iterating through testing

I usually divide testing into three general categories:

• Gameplay testing : is it fun to play a game?
• Usability testing : do players quickly enough understand how to play?
• Functional testing : does everything work as intended?

Testers need to be selected depending on which aspect you are going to test. To test the functionality you need people from the quality control department who are well acquainted with the procedures of professional testing. Although they can sometimes be used to test gameplay and usability, this will require a wider variety of players. Game testers are very active and experienced players, and we rarely want to limit our audience to such a group of people.

In the early stages of the project, it is naturally necessary to concentrate on testing the gameplay. I prefer to test the gameplay on three groups of people: team members, gamers. and ordinary people. Team members are inside the company, so the easiest way to get involved. They can tell what the obvious problems are, but often they have too much knowledge about the project to notice less obvious problems. Then come the gamers - your friends or other people from the gaming industry. They will not know about the design or goals of the game, so they can take a fresh look at it. Finally, I find it very useful to show the game to people who have not played or almost never played in this genre of games, in more casual games, or in games in general. If they like the game and they are able to understand it, then you will know that your project is available to everyone.

When working on Trulon, our target audience was teenagers, so at the very early stages of the project, we started testing the game in people from 13 years of age and older. We came up with the first playable version of the game in schools (who often take such actions favorably) to get feedback. The results literally changed the rules of the game.

Availability

One of the pillars of the design of Trulon and Rimelands was to avoid any obstacles in front of the player before participating directly in the gameplay. Role-playing games (digital and board) are traditionally not very good at this, they require the creation of a character and a long introduction to the plot. I do not want to say that in digital role-playing games there should never be character creation or an epic introduction, but personally it seems to me that the game becomes more accessible to the general public if you first immerse the player in the gameplay and only after that introduce the character to the plot and nuances.

The introduction to Trulon was conceived as the beginning of a television series showing what the player would face. I am well aware that many players often skip such introductory videos, so in this case the player will at least not miss anything important about the plot. After the start of the game, the player just needs to participate in two short conversations, after which the first battle begins.

I wanted to make the tutorial part of the game’s plot, so I designed it as a lesson from teacher Gladia Marcus. In a short training battle, only the most basic game mechanics are considered: the use of tactics and "jokers" to attack enemies. I repeat, I did not want at the very beginning of the game to load the player with a ton of information instead of the game process.

After the training battle and before the first real level of the game, there is a short segment of plot and research. The real content of the tutorial is the only battle: it teaches the player how it works in the mana game. I wanted the players to know the rest during the game.

Enemies

The last puzzle piece of the combat system is the mechanics of the enemies. Often, the mechanics are symmetrical: the player’s characters and enemies often follow the same rules, only the enemy does not control the player, but the AI. There are other ways of implementation, for example, asymmetric mechanics, situations where enemies in some aspects differ from the player. In one of Trulon’s sources of inspiration, Chrono Trigger, enemies, for example, don’t use combo mechanics.

I decided to use a slight asymmetry in Trulon. Enemies do not use assault tactics at all, and they do not have a hand or a deck from which to draw cards (and therefore there is no "joker"). Instead, the AI ​​is programmed to use certain cards once or as many times as needed, and various triggers change the behavior of the AI. Some enemies are more predictable than others, and I found that more complex enemies must behave with greater consistency in order to fight them like a puzzle. For example, the optional boss Hunter in the Dark changes tactics and cards at his disposal when his health drops below a certain value. The boss previously met before launching a powerful special attack always performs an aiming, which can be seen if you turn the steam valve before the battle.

conclusions

Although I have a “design philosophy” and I use certain procedures when creating new games, the process is very flexible and always differs from project to project. It is important to find what suits both you and the game you are creating.

The correct implementation of the base cycle is one of the most important and often the most difficult part of developing any game. This is also true for role-playing games, despite the fact that the base cycle is more complicated in them than in most games. In many cases, to fine-tune the basic mechanics, a paper or digital prototype with rough resources is quite enough. But in some cases, for example, in action-oriented games, real resources are needed to test the process of a game with animations and effects, because they greatly affect the feeling of the game.