NOVEMBER 14, 2022

In game development, iterations are extremely important. Create quick prototypes and test them in order to understand which direction to go. In such prototypes, visual elements are often not worked out very much (unless they have a critical impact on the gameplay). This allows any concepts and ideas to be quickly tested. Prototypes are different. Sometimes a paper prototype is sufficient, sometimes real-world elements are used (recall that all the levels in the first Metal Gear Solid were originally built from LEGO), and sometimes the prototype is built in the engine. This article will focus on just what variations of the combat system we considered during development and for what reasons we abandoned them over and over again.
General principles

While working on the design document, we understood from the very beginning that our game involves a certain combat system. We knew for sure that we needed to create a certain model of enemy behavior upon detection that would look logical to the player.

At the initial stages, we formed three most important principles for ourselves, which we wanted to focus on:

1. The player must be able to survive the combat encounter
2. The combat system should push the player into stealth
3. An open fight should be a tough experience

With these three principles in mind, we started working on the first iterations.

Stages of combat system development

1. Punishing combat system.

Our very first options were the simplest and cheapest systems from the production point of view. From the option that the discovery of the character leads to a restart of the level, we immediately abandoned it, since this, firstly, contradicts one of our principles, and secondly, creates a certain narrative problem. The fact is that the main character in our game is a military man, he is a strongly built person. A situation in which he surrenders at the slightest threat would look ridiculous.

Our main concept in this case was the so-called "punishing" combat system. We assumed that direct collision of the player with other enemies should lead to his death. This does not mean that the player dies as soon as they are discovered by the enemy. The main idea was that upon detection, the enemies tried to get to the character and if they succeeded, they were guaranteed to kill him. In this case, the player has the opportunity to damage the enemies at a distance and then disappear from view. A Plague Tale: Innocence can be considered a direct analogue of this system.

These developments, although they created the basis for further systems, have shown us the inoperability of such an approach. This system, although it met our basic principles, was perceived as foreign. We wanted to give the player the option to be aggressive if they felt confident enough, but this approach made direct confrontation ineffective for the player. We felt that we were cutting off some of the gameplay possibilities. Apart from this, the narrative question did not disappear anywhere. Yes, the character did not give up immediately, but in fact he could not offer any resistance even to a single target, which looked strange, given his military background.

This prototype did not go beyond the paper presentation, but it helped us to formulate a number of postulates that we were guided by in the future.

2. The bots take up a perimeter around the character.

The idea behind this prototype was quite simple. As was mentioned before, we wanted to push the player into stealth. In order to implement this, we had to show the player that open combat is not quite the right strategy if there are too many enemies or the player does not feel the game well enough. And how can you show the player that he is doing something wrong? Somehow to punish him - to take away health. This is how the idea of a close combat system was born, in which enemies surrounded the player and outnumbered him and caused damage. At the same time, the concept took into account that it is possible to escape from this ambush and hide from enemies.

This system worked in the following way:

There are several positions around the main character. During the beginning of the battle, the enemies choose one of the free points, depending on their position. The position selection algorithm works in this way: if one position is already selected by some bot, then the other one will select the opposite position. Thus they surround the main character.
After the enemies have taken their positions, one of them can make an attack on the character. The rest cannot engage the character at this moment, otherwise the player would not be able to dodge several attacks at once. After the attack is made, the enemy again selects a position according to the algorithm already described.

However, this system also had one extremely important problem. We solved the narrative question and met all three principles, but the problem lay at a much more fundamental level.

If you try to remember games with a similar combat system, you will quickly realise that they are extremely rarely stealth or, even if they are, significantly different from the classic representatives. The reason is that such a combat system assumes a fairly wide area for combat. Games such as Batman: Arkham Knight or Sleeping Dogs, having a similar combat system, offer quite extensive and free combat locations along with it. In our game, stealth, on the contrary, involves a large accumulation of covers and obstacles behind which the player could take cover so as not to attract the attention of enemies. It was this spatial conflict that prevented this prototype from moving forward, since we abandoned it in the first tests of the enemy movement system.

3. Role-playing game system

After the previous iteration, we had to formulate a combat system in which the enemies would feel comfortable in stealth locations. At the same time, we still wanted to show the player the incorrectness of his actions through the character damage, and for this reason, we stuck to the concept in which the enemies should behave aggressively and force the player into stealth.

The system represented itself as follows:

The basic principle is that there are 3 roles in combat and each bot can take one of these roles. At the same time, it is not necessary that during a combat encounter all 3 roles work simultaneously. The scenario when only 2 or even 1 role are used is quite possible.

Role features:

1. Attack - bot simply runs to the position of the main character to attack him with a melee attack. This role performs a reconnaissance function and pushes the player into stealth. He constantly tries to reveal the position of the hero and communicates it to the rest of the bots.

2. Control - does almost the same thing as the previous role, but the differences are that it will bring the distance closer to the value we define, and there will be direct visual contact.
In this case, the bot fires and the loop repeats until the hero is dead or hides.

3. Position - the most interesting and technically difficult role. There are a lot of points placed in advance on the arena, one of which can be occupied by a bot that has this role during the battle.

The point that the bot will take depends on several factors:

The distance from the point to the character
Distance from the point to the bot that wants to take it
How far the point is turned towards the character

4. Distance - the distance from the point to the exit from the arena. Due to the fourth factor, bots can take points along the main character's path and block the path to the exit.
Each point gains a number of points in accordance with the factors. The enemy will choose the point that scores the most points. But the division by points happens all the time, and as soon as a new, more advantageous position appears, the bot switches to it.

The system also assumes the priority of issuing roles.

Based on the screenshot above, we can conclude that first of all there should be a Control role and only then Position role, this means if only one bot is left alive, it will start to perform the Control role.

During the attack, bot can request the system to switch roles with another bot if its role does not suit it. This can happen when the main character runs close to the Position bot and then the game manager will decide to change roles.

This system had the most complete prototype and did a lot of the job it was supposed to do, but still had a number of problems: some bots were easy to lure out to make damage, or sometimes it was hard for the bots to catch the player as they constantly changed roles, etc.

And in fact, all this was possible to solve by setting up the system but there was another key issue. At the beginning of this part, we mentioned that we wanted to make the bots aggressive so that they would force players into stealth. But we have implemented this aspect too well. The bots were so stubborn that they chased the player constantly and literally did not let him escape. Instead of squeezing the player out, they forced open clashes on him, which of course was not part of our plan.


It may seem that we have wasted a lot of time doing all these prototypes. But in fact this is of course not the case. You can see that each prototype answered previous questions and asked new ones more and more to form the final look. The latest version of the combat system was already playing much better than its first iterations, and we were getting more and more precise about what exactly we wanted. Some systems require fewer iterations and some more, but only the ability to create and test concepts gives a clear idea of ​​the final form of the system.