Creating a RPG fighting system

The combat systems of our games Rimelands: Hammer of Thor and Trulon: The Shadow Engine were highly rated by the players. Despite the fact that these are two very different views on the combat system in RPGs, they have a lot in common in the design of a mechanic and illustrate my personal design philosophy. In both games, turn-based battles are used, but Trulon they are based on a deck of cards, and in Rimelands they are based 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 only talk about basic combat mechanics.

Rimelands: Hammer of Thor (2010)

(Screenshot from unpublished version of PC game)

The game takes place in a post-apocalyptic world that is recovering from the recent Ice Age. The main heroine of the game Rose Christo goes on a journey filled with magic, northern mythology and elements of steampunk. Most of the time she explores Shelters - abandoned shelters that have become dungeons filled with treasures and monsters. Some dungeons are generated procedurally, others are manually created.

When a player approaches the enemy, the game becomes turn-based, and the player with the opponent starts taking turns in turns. During his turn, a character can perform one action: move, attack, or use a skill. Since the course consists of a single action, the pace of the game is high, even though the game dice are visible on the screen.
')
Traditionally for the genre, characters have different characteristics that determine their chances of success in battle. In Rimelands, basic combat abilities are called Melee (hand-to-hand combat), Ranged (long-distance combat) and Magic (magic); each of them is associated with a specific type of attack. At the beginning of the attack the game rolls the dice, their number is equal to the level of the character's ability. Each bone has four possible meanings: a double hit, a hit, a block, and a miss. After throwing the dice, the defender rolls to attack the dice. The defender uses the same ability to protect as the attacker. If the number of hits thrown by the attacker is greater than the number of locks thrown by the defender, the attack succeeds.

Also, each character 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 locks is equal to or greater than the stamina / dodge value, then the attack is piercing. Piercing attacks do not take into account the value of the defending armor and usually double the amount of damage done.

In addition, the player can throw any bones that affect the success of the throw (misses and blocks in the case of an attack roll; shots and double shots in the event of a defense roll). A throw is worth one mana point; throughout the game there are five mana points. Also, mana is used to increase the power of skills and can be restored when skipping a turn in battle.

Originally 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, but unlike traditional roguelike, the characters act in turns rather than in sync.

The process of creating a design

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 result of an action?
• How does a player know about the result?

Often, the process of creating a game design does not begin with the 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 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 this would be a HeroQuest set of bones with characters instead of numbers, the system was quickly integrated into the game.

I can also recommend novice designers of role-playing games to study board games and their ways of solving these problems, because there they are much more transparent 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 move a 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. The mechanics of stamina / avoidance are also added to support this choice, because it rewards the player for striving for more than the number of strokes needed just to cause damage to the opponent.

Bone transfer mechanics were not in the original design of the game, which was very much like the modern rethinking of the digital version of the HeroQuest board game. Initially, visual bone rolls were introduced into the game for the sake of transparency in game mechanics. When a player sees the dice, it is easier for him to understand how the game works, without long tutorials and guides.

During the first playtests, many players complained that visible bones 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 mechanic was born. This had a double effect: 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 the input data for making the most important decision in the game.

Dice roll in digital space

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

Throwing a 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 we can actually influence the result with the help of a “good throw” (or choice of the dice). In digital games, dice throws the computer, and the player does not participate in it. To transfer the sensations from the board game to the digital platform, it is necessary to somehow get around this limitation in design. In Rimelands, we came to this decision: we added one more processing step, at which the player can make an active decision.

Cruel denouement

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

Life resources are often called “health” or “damage points”, and the main way to reduce them is to do damage with attacks. It is usually determined by a two-step process: throwing a blow and throwing damage:

:

- > 0

:

< /:

= Random(. , . ) -

:

= Random(. , . )

From the strike equation, you can easily calculate the average percentage of hits (for two equal opponents), and in general it should be at least 50%, and better than 70%. From the damage roll, we know the average amount of damage for each type of weapon, and usually we calculate how many blows the enemy must inflict in order to defeat him. Usually I prefer to hit the middle enemy three times.

Many digital role-playing games often completely refuse to throw a punch and simply determine the damage from each attack. Usually it’s very boring when a fight is just a series of blunders, because blunders don’t change the state of the game at all, so Rimelands also has a very low barrier to successfully hitting an enemy 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 from the influence of roguelike, and therefore, from the similarity to the Diablo series and other games of the action RPG genre. However, from the point of view of tempo, in this classification there is a merit of the game itself: by limiting the characters to just one action per move, we generally made the fights quite short, even in the case of a battle with a large group of opponents.

Throwing bones slows down the action, but due to the periodic emergence of the ability to transfer bones, the player spends most of the time on making decisions, rather than just watching the action unfold.

Unlike the more common system used, for example, in the first two parts of Fallout, the intervals between active and passive games are much shorter. Another effect is a reduction in planning. Although it’s definitely worth planning in advance in Rimelands, the player can perform very short action chains before the game state changes. This leads to a feeling of less planning in combat, compared to games where you can perform several actions per turn, often for each character in the party. I do not want to say that some approach is objectively better; they simply 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 consist 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 variety of gameplay, and not all of them can fit the overall atmosphere of the game. For example, if you are working on a game where a player’s character is a member of the intergalactic “special forces”, then you probably need a more measured tactical battle, rather than a 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 describe our own interesting points of this game.

Trulon: The Shadow Engine (2015)

Trulon, inspired by Finnish amusement park Powerpark, is a mixture of fantasy and steampunk. The main heroine of the game is the hunter for monsters Gladia, who has taken up research of the sources of the mysterious disease. On the journey, 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 traditional Japanese role-playing games, for example, “attack” and “attack”, which determine the amount of damage dealt in attacks.

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

The mana in the world of Trulon is divided into two powers: Gaudium, born out of life and happiness, and Dolorum, born out 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. The use of magical tactics reduces the player’s mana (he can be expanded with various items), which is not restored in combat. This is balanced by the fact that mana-consuming tactics are more effective than normal ones.

Basic game loop

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 “input-feedback” cycle, which is the foundation of the whole game. The basic loop, or feedback loop, in Trulon is as follows:


Each element of the player’s feedback has three separate effects: positive, negative and random. The positive effect is the immediate 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 changing the state or curing the player, but the most frequent 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 viewed as an increase in two separate counters: the victory counter and the “doom” 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 essence, this means that a battle can be won even with an almost-filled “doom” counter, and vice versa.


In role-playing games, these two counters are usually represented as points of damage for the player and the enemy, but this is not necessary. Introducing 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 must be filled linearly, and returning back on it is a source of irritation for players. That is why I avoid using treatment options for enemies, because they usually lengthen battles without adding almost any strategic value.

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

Maps as a changing playing field

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

Trulon achieves this by limiting the options for randomizing actions. Although the attack tactic is always available as a backup option, other tactics are designed in such a way that they are always better than the “vanilla” attack.

The design goal was to resolve one of the most common problems of the JRPG genre: “spamming attacks”, in which battles often boil down to the constant selection of a standard attack, because the player lacks the motivation to use skills or resources that can deplete his reserves.

Accident Management

Trulon has gone the hard way from design development and early prototypes to complete combat mechanics. Although the basic concept of a combination of card gameplay and fights in the JRPG style seemed solid, the game itself felt somewhat wrong. Most of all, we were afraid that the game would seem too random, and the player may 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 that would be interesting to play. At such an early stage of the development process, we did not have a large set of maps or enemies with a bunch of special features, so the goal was to bring the basic mechanics to the point where a game with a limited number of choices would seem interesting.

Unlike Rimelands, we worked on Trulon for hire, which resulted in a stricter budget and schedule. Although Powerpark was a great, very understanding customer who trusts us in game development, we still had to create something that the customer would have believed. By the end of the alpha version, we had a deadline for creating working mechanics of a card battle. If we hadn’t succeeded, we would have returned to the more traditional JRPG combat system.

The puzzle was suddenly solved when, in reviews from the first testers, there were references to the unpredictability of attack mechanics. 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 because of bad luck. By eliminating randomness from the calculation of damage and removing the throw, we made the fights much more tactical, even though the changes were insignificant from the point of view of mathematics.

Critical hits

Eliminating accident damage from calculations had one major problem: it destroyed the chance of a “critical hit”. , . Trulon: . — , . « ».

, . , , . -: , .

Rimelands , , , . Trulon , , , . .

:

• : ?
• Usability : , ?
• : , ?

, . , . usability, . — , .

. : , . . , . , , , . — . , . , , , . , , .

Trulon , 13 . ( ), . .

Availability

Trulon Rimelands . ( ) , . , , , , .

Trulon , , . , , . , .

, . : «» . , .

. : , . , .

— . : , , . , , , , - . Trulon, Chrono Trigger, , , .

Trulon . , , ( «»). , . , , , . Hunter in the Dark , . , , .

findings

« » , . , , .

— . , , , . . , , , , , .