Discord 
Hi, my name is Dmitry Borodin and I work as a game designer on the combat team for Skyforge. I've been part of the Allods Team for more than four years, and in that time I have learned a lot of new and interesting things from many areas of game development. My job on Skyforge has been largely associated with the implementation of combat and now I’d like to tell you about how we did it.
Combat can generally be described as active interaction between players and a hostile environment. In modern MMOs combat is 90% of the game, and the task of making it enjoyable is one of the most important and, at the same time, one of the most difficult. Therefore, on Skyforge, a special team was put together exclusively for combat.
Combat in MMO has three main components:
-
Classes - skill sets that the player will use in combat.
-
Mobs – monsters that are hostile towards the player.
-
Interface - the camera and controls.
Each of these points should be covered in separate articles. Today, I'm going to discuss the first one - Classes.
We decided at a very early stage of development that we wanted to create visually striking, dynamic and intuitive combat. Since large game development projects do not have a ready-made "overall design" that simply needs to be implemented and brought to life, we began to experiment starting with our classes.
Our initial experiments were quite viable - we mainly used proven, well-established mechanics. However, after a while, playing a PvE these classes became the monotonous grind typical found in many MMOs: select a mob, press 1-2-1-3-4, rinse and repeat. It was clear that something was not right: with every passing day, developers in our playtests were becoming increasingly bored with combat. And, although this could be attributed to the fact that they were just not getting adequate rewards, we decided that if we wanted to make something really cool, something really engaging, we needed to change everything. A series of major revamps followed, which affected almost the entire project.
First, we decided to revive the combat process by making the class resources more dynamic, reducing cooldowns, as well as sprucing up each classes’ basic attacks, which are frequently used between other skills. To make basic attacks look good, we decided to use alternating animations, and the animation of each hit would begin with the end pose of the previous attack. A basic attack of the Paladin - one of the classes that we used for our experiments – appeared as alternating diagonal slashes of the sword as the character stepped towards the enemy, with each hit taking 800 milliseconds. These basic attacks made fighting appear more exciting, but we didn't stop there.
Over the course of our experiments, we started to look more closely at combat in games like God of War, Devil May Cry, and Darksiders. Combat in these games felt dynamic, impactful, and were continually rewarding. It’s at this point, we decided to roll up our sleeves and redo our entire combat system, transitioning from traditional MMO combat to a more dynamic action combat system.
Before embarking on a large-scale redesign, we looked into one of the key action features in these games – combo attacks, which are abilities activated in a certain sequence that have additional effects. We looked at how they were implemented in games like; Mortal Kombat,Tekken, and Street Fighter, evaluating the different approaches and results. We thought about how we were going to adapt combos to an MMO. We couldn't do it the same way it's done in a fighting game because of the differences between the gameplay and technology of both genres. After redesigning everything "on paper", we spent many hours discussing it with the artists, looking for ways to implement our ideas that would suit everyone.
Finally, we decided on a version of combo attacks that consists of different "basic" attacks performed by pressing the left mouse button and special attacks activated by pressing the right button after the required basic attack. Paladins now had 4 basic attacks that ended in a strike which tosses the enemy up into the air. Instead of three special attacks - after the first, second and third basic attack – we added Seal of Light (two fast sword strokes that inflict damage in a rectangular area in front of the Paladin), Punishing Bolt (strikes one enemy with a powerful downward blow), and Divine Scourge (the Paladin hits the ground after a jump and inflicts damage to all enemies nearby). We decided not to add another special attack after the fourth basic one, because having to perform five attacks in a row without interruption did not fit the combat dynamics we were trying to achieve.
It takes a lot of effort to ensure combo attacks work well. You have to make sure that the player always knows when they start, when they end, what stage they are at and what input is required to perform the desired sequence of strokes. Otherwise, a long series of actions produces an unpleasant feeling - the player starts to count how many attacks they performed, as well as to notice unpleasant pauses between attacks. We called this effect "Metronome" and immediately started to work on solutions. After a while, we came up with an interesting interface feature - the "combo helper". This system helped players navigate combo attacks, showing each element the player performed during the fight while displaying the corresponding icons in a row just as the skills are activated. In the end, we were able to achieve the best results by changing the duration of attacks and the time the client took to receive commands for the next strike.
We accelerated basic attacks and made the last strikes in the series significantly slower. In the beginning, each strike by the Paladin took about one second, but now the longest final strike takes as much as 1.5 seconds, while the fastest basic attack is executed in just 450 milliseconds. Commands for the next attack could be given much faster, and the process became much more comfortable for players, since it was no longer necessary to have long pauses between every hit. In the end, we achieved a result that allowed us to drop the previously created combo helper as there was no need for it anymore.
As we continued to work on the combo system, it became clear that combos for ranged classes looked very weird both from a visual perspective and from a common-sense point-of-view. Really, why not just launch the desired attack on the enemy without having to use some other abilities before it? We decided not to force the combo ideology on the ranged classes, and instead used alternative attributes of action combat like rechargeable skills, aimed shots and other mechanics. For example, the Archer uses 3 types of arrows, which you can switch between by clicking the right mouse button. To fire the selected type of arrow, you need to use a chargeable skill by holding down the left mouse button – causing the character to draw their bow. This skill contains 3 different types of shots, and the shot type is determined by when the player releases the button. Thus, the Archer has as many as 9 skills on the two mouse buttons. In addition, combo attacks do not have to be bound exclusively to the mouse buttons. The Archer also has a Jump Shot that is similar to the well-known Rocket Jump, which can be executed by dashing backwards using the movement keys, and pressing the spacebar immediately afterward.
Another thing worth noting is that in games like God of War or Devil May Cry at an average difficulty level, various combos produce the same result, even if they give you a completely opposite impression. Other things being equal, the player progresses through the game at a speed that is not affected by the abilities he uses, even though some of them can be quite involved and difficult to execute, while others are short and simple strokes. Attempting to use something similar in our game caused the players to use only the combos that they liked visually or that happened all by themselves, which is exactly what tends to happen in action games. But, because of the long duration of MMO play vs. the relatively short time spent in an action or fight games, players can simply lose interest in combat.
Our analysis of the causes of this fatigue led us to an interesting conclusion: the player generally loses interest in combat around the 8-10 hour mark, which basically matches the time it takes to complete most action games. When it comes to these games, there's nothing wrong with the fact that the player eventually gets bored fighting the mobs, but for an MMO losing interest this early in the game would be fatal. Therefore, in Skyforge we made combos more hardcore than in common action games: the player must often decide what kind of combo he should use at the moment, and his decisions will greatly affect the outcome of the battle. Paladin's combos are now subjected to a strict specialization: Seal of Light is beneficial if it hits two or three enemies in front of the character, Punishing Bolt inflicts maximum damage to a single target and Divine Scourge helps you deal with a large number of enemies.
But action combat does not just come down to what particular methods are used to control a class. It's an ideology that the entire game should be based around. Sometimes this ideology brings into question things that seem to lie at the very foundation of the MMORPG genre. For example, at some point, we realized that the classical role of healer in a group scenario does not suit us. Usually all the healer does is "push" the tank's health bar in the direction opposite to the one the enemy is pushing it, and spends most of the time looking at the interface. All of which does not fit in with the basic ideas of dynamic, and reactive, action combat. Also, the very existence of the healer role creates a large number of problems in a game. The healer needs to understand which characters he should be healing, and for that, we need certain protective characteristics – mostly for tanks. Healers also produce a twofold increase over the base healing efficiency other characters possess without a healer and with more protection it makes it even harder to inflict significant damage to the character. Over time, the healer is able to restore more and more health. And since the designer cannot always rely on a healer being present in the given scenario, it becomes a balancing issue, especially in PvP.
PvE also suffers from the presence of a healer. The above mentioned twofold increase in efficiency separates the tank from other roles in the group, but the tank does not really feel this effect. Tanking often comes down to a binary situation: either the tank and the healer have enough tools at their disposal to out heal the damage output from the boss, or they don't. If not, the boss is impossible to kill. If they do, then we have another problem caused by healers – the potentially infinite endurance of the group in a fight against the boss. With infinite endurance, you can have an arbitrarily small damage output and still defeat the enemy. It will just take more time. To counteract infinite endurance in PvE, developers often implement strange mechanics such as an "enrage", when after a certain time causes the boss to start dealing much more damage, making it impossible for the healers to compensate. Without these mechanics, the first kills of bosses are usually carried out by groups with a composition comprised largely of healers, and the fights subsequently last a long time.
These are some of the reasons why we decided to leave the role of healer out of Skyforge. Of course, the ability to heal is still there – we have simply removed the class role devoted exclusively to this mechanic. Instead, we expanded the support role, which is sort of a combat director who will be an indispensable member of any group. In combat, support makes important decisions that affect the outcome of the battle. They can help team members perform a variety of tasks at the right time, protecting allies and weakening opponents, providing offensive bonuses while creating additional points of interest on the battlefield.
Ultimately, only support decides what should be used at any given time. Thanks to their actions, the group is able to find success together against encounters too impossible to tackle as lone individuals. For example, one of our support classes, the Lightbinder, has numerous abilities with which to aid his group and change the outcome of a battle. This includes Sacred Barrier, which makes the whole group invincible for a few seconds. Likewise, Golden Sphere will place all enemies that it passes through into a line. Wanderer’s Relic will place an item on the ground that any ally can use to instantly teleport them to the Lightbinder's position. The Lightbinder can also teleport to any previously placed relic by using the ability again. It is also worth noting that the abilities of some of the support classes allows them to focus on directly supporting their allies in lieu of engaging the enemy directly. Thus, the Lightbinder's basic attacks can be used on an ally, and instead of inflicting damage, they will increase an ally's damage output.
To make sure that over the course of development we retain a sensible view of things and have a clear sight of what players expect from us, in all our experiments with the combat system we’ve actively used UX-testing (User Experience). For that, we have a special UX-laboratory, to which we invite a wide variety of players: those who are barely familiar with games, experienced MMO gamers, fans of shooters, console players - in other words, we try to get as much varied feedback as possible.
We seat our ‘guinea’ players at a special table, connect various biometric sensors, set up an eye-tracker and let them play a section of the game we are interested in gathering feedback for. In the end, we get a video that shows where on screen the player was focused at any given moment, their pulse and other indicators, which we then use to reconstruct the emotional structure of the fight and decide whether we got what we wanted and, if not, what changes are needed. Often the results of UX-testing help resolve disputes in which developers from both sides of an issue or idea have come to an impasse. That was the case, for example, with the "context actions" - hints displayed as class skill icons which appear in battle under specific conditions and suggest to the player certain abilities they should use. Some developers felt that context actions were extremely important for the game and must be as visible as possible, while others were skeptical, believing that there's no point in using them as skilled players could be expected to learn these actions easily.
UX-testing showed that inexperienced players who are the target audience of context actions do not pay attention to them, and hardcore gamers ignore them for obvious reasons. As a result, we greatly reduced the number of context actions, keeping them only for the most important abilities and where they could be considered convenient for the player, as well as making them more visible.
Can a newbie use this class's combos in action? Does the player find the ability panel and resource bar distracting? Is this mob's ability noticeable? Is its purpose clear? Our experiments in UX-lab were a great help in answering these and other similar questions.
Creating an enjoyable combat system for an MMO is not a trivial task. We've come a long way and while creating classes for this sort of combat: we went through dozens of different approaches, conducted hundreds of playtests, ran into a lot of pitfalls, spent many hours in meetings, disputed furiously, brandished toy swords and maces, worked in our spare time – all so we could be proud of our creation. After all, we know no other way of producing something we consider good.
In future articles we will continue to tell you about the combat system in Skyforge, but for now, I must bow out. We hope you will like the combat in Skyforge as much as we do!
