Practice makes perfect, iterations move the project forward. It is extremely difficult to create a solid and stable game mechanic from the first attempt. Especially the combat system for a game with stealth focus. One experiments and polished the mechanic until players love it and bugs do not ruin the experience. Stages of polishing and adjusting are called iterations.
You start with quick creation of prototypes and testing them to understand in which direction to proceed. In early prototypes visual elements are often not added (unless they have a critical impact on the gameplay). At this stage you can test any concepts and ideas. Prototypes can be of any form and format. 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 iterations of the combat system we considered during development and for what reasons we abandoned them over and over again.
General principles
At the initial stages, we formed three most important principles for the future combat system:
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.
Iterations of combat system development
1. Punishing combat system
Our very first combat concept was the simplest and cheapest systems from the production point of view: discovery of the main character equals death and restart of the level. We immediately abandoned it because ,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 strong person who knows how to protect himself. A situation in which he surrenders at the slightest threat would look ridiculous.
We moved to the second concept. In this case it 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 would definitely kill him. In this case, the player has the opportunity to inflict damage to the enemies at a distance and then disappear from view. A Plague Tale: Innocence can be considered a direct analogue of this system.
This system, although it met our basic principles, was also labeled as unacceptable. 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 rules that we used in the future. At this point we wrapped up the first iteration.
2. The bots take up a perimeter around the character
The idea behind this prototype was quite simple. 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 and take away health. This is how the idea of a close combat system was born: enemies surrounded the player, outnumbered him and inflicted damage. At the same time, the concept took into account that it is possible to escape and hide from enemies.
This system worked in the following way:
There are several positions around the main character. At 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 player.
After enemies have taken their positions, one of them can make an attack. 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 finished, the enemy again selects a position according to the algorithm already described.
However, this system also had one important flaw. 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 stealth 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 number 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. This was the second iteration of the combat 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 unpleasantness of open melee 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.
So, we shaped the following system:
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/is 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 position along the main character's path and block the path to the exit.
Each position gains a number of points in accordance with the factors. The enemy will choose the position 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, which of course was not part of our plan. Still it is the most successful iteration.
Conclusion
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.