Re:Build - FAQ 2

Table of Contents

 

1. Rank System Changes Pt. 1 (Click here)
2. Rank System Changes Pt. 2 (Click here)
3. New Content: Borutos Kapas & Astral Tower Closed Quarters (Click here)
4. FAQ (Click here)
5. Compatibility Issues & Solutions (Click here)
6. FAQ 2

 

Greetings, Saviors!

Today we’re following up on the previous [Re:Build] FAQ post with a few more questions received from players after the release of the first announcements. We will also include a few comments on feedback from test-server kTOS players, to give you a better idea of the current concerns surrounding this update and the direction in which it continues to be developed.
 

---

Q. What principles have framed your balance decisions so far?

We’re taking class balance into a different direction now, compared to when we first started developing [Re:Build]. Here’s how.

Our initial ideas for balance:

We wanted to ensure that every class maintained its own unique value and distinctive characteristics, no matter what build you chose. In our idea, this meant leveling out all skills to the same “height”. The standard we used for that was the current Rank 6, not simply because it’s between Ranks 1 and 10, but because we wanted to avoid having skill-based classes overperform basic attack ones, and skill factors in Rank 6 correspond to that middle ground we were looking for.

More specifically, skills higher than Rank 6 were dialed down, while those below it were boosted to Rank 6 standards. We then deleted a few skills that ended up too powerful even after the numeric adjustments, like Armor Break, a support skill in the damage-oriented Musketeer class.

On the other hand, we added new skills to classes where we considered the current skill set insufficient to its role in the game. Paraclitus Time, for instance, was introduced to the Chaplain repertoire to reinforce its identity as a close-range basic attack class.

The problem:

Once the update was brought over to the kTOS test server, the main issue was that all skills in general felt like they had been excessively scaled down: an overall nerf. This was because of multiple reasons.

First, high-rank classes – once the main damage dealers – felt significantly weaker after the factors were leveled out, which in turn amplified how the surge in low-rank class factors was perceived. On the other hand, low-rank dealer classes, who due to Rank limitations were making more use of their buffs and debuffs, suddenly saw a decrease in buff/debuff utility when their skill factors increased.

Finally, our excessive focus on making each individual class reach maximum performance took a severe toll on the overall tempo of combat. We largely failed to consider practical aspects like skill cooldown, overheat, buff/debuff duration, and skill range, which made combat situations feel that much more frustrating.

Our current direction:

We’ve now turned our balancing plans around. Instead of basing balance around a uniform standard of performance, we want to focus on individual value. What we’re aiming for is a balancing system that allows classes to manifest their unique identity without threatening raw performance.

Skill factors will of course be adapted to exhibit similar degrees of performance, but instead of trying to make up for the shortcomings of their effects, we want to emphasize their advantages. If, in this process, we’re unable to provide players with skills that are more satisfying than the ones they have now, we’ll have no choice but to bring back skills from the “delete” pile.

A specific example:

Running Shot, for instance, is a skill that players like for how it allows them to shoot while running (as the name implies). This skill was set to be deleted since it didn’t fit in with the concept of the Quarrel Shooter class, but because it is such a unique and beloved feature of the Archer tree, we decided to instead transfer it to the skill set of the Archer class by merging it with Swift Step.

We won’t be integrating Running Shot in its entirety, of course, since the performance would still be out of proportion, but we are carrying over its basic function. This is only one example of how we can keep skill factors in check with the overall balance but still make use of a skill’s best traits.

Q. Skills feel so impractical in this update. Is this Tree of Basic Attacks now?

The fact that skill-based classes felt a decrease in skill usability after the test server update is not related to us having based the new balance changes around the results of basic attack Rank 6 classes. It was never our intention to slow down the overall combat tempo for skill-heavy fighters.

We did perform several adjustments to skill cooltime and overheat since then, but the full process is not yet complete. With TOS being not just an MO but an MMO, however, we do expect the system where players need to go back to town for potions in order to maintain a good level of field efficacy to remain valid.

Q. How come only some classes have skills that connect with other classes? It feels as if you’re forcing certain builds onto players.

We do have a lot more skill combinations prepared for follow-up patches. We want to keep introducing them as quickly as possible.

Q. The monsters don’t seem any weaker, so it feels like you dialed down everyone’s combat abilities.

As mentioned earlier, our plans are not to lower, but to raise overall performance equally. We did intend for monsters to feel a little tougher, but we've been adjusting their difficulty to more reasonable levels. We initially increased monster abilities because, after [Re:Build], you will be able to change your class build much more freely according to your intentions (growth, farming, hunting, etc.), which means there is less of a need to balance out fields in a way that allows support-heavy classes to clear quests solo.

We felt that having monsters blow up at the slightest contact with a skill was diluting the meaning of character growth and putting a damper on the challenge aspect of the game. With [Re:Build], we wanted to make sure that players were required to invest in their build, equipment and attributes to a certain degree to achieve a smoother field experience.

That doesn’t mean, however, that we’re pushing players into party play at all times. There are features you can enjoy solo and others where you need a party: those two are meant to be somewhat separate categories. We’ve already strengthened this distinction in features like instanced dungeons and the Challenge Mode, but we want to continue doing that for these and other elements of the game as well.

Q. Historically, Hackapells used a one-handed sword and a pistol. That seems more in tune with the Scout tree, doesn’t it? Why were they put under Swordsman?

Historic accuracy is of course important but, when it comes to allocating class trees, fitting our existing resources into the new system successfully comes first, from the viewpoint of utility. We hope you understand. For now, our priority is to stabilize things from the perspective of playability, and only then will we consider polishing up the game lore.

As for equipment preferences, Scout classes use mostly pistols and daggers; one-handed swords are a Swordsman trait. If we were to move Hackapells to the Scout tree for historical accuracy, they would probably gain a few pistol skills, but they would be forced to enhance and transcend two different weapons.

Not only that, a class majoring in one-handed swords within the Scout tree would see very few new equipment items catered to their particular strengths, putting Hackapells in a position similar to the one they have now in the Archer tree.

Q. You said you were going to reallocate the classes based on equipment compatibility, but no class in the Swordsman tree is properly compatible with mounted combat using a one-handed sword and a shield.

We realize that there are a few gaps left in terms of compatibility. To be frank, this is mostly due to problems in the processing of animation data that we failed to solve completely. We are in the process of making all one-handed sword skills and classes compatible with mounted combat.

Creating all the resources necessary for one-handed sword skill and class compatibility is going to take some time, so for Hackapells, for example, we expect to balance out these gaps with other improvements (overheat, skill factors, etc.) until the problem is solved. Then, as we work out the remaining compatibility issues, we will continue to gradually adjust the balance to common rules.

Q. Weren’t Squires a type of knight apprentice? Why are they in the Scout tree?

Squires may have been known as knight apprentices in the past, but that wasn’t always the case. Our Squire class is based on the traditional supportive role of historical squires, which is why we allocated them to the Scout tree. All skills in the class – apart from Deadly Combo, which focuses on self-protection – are geared towards that concept.

We do feel that our Squire still falls a little short of what we intended, however, so we want to continue tweaking it to better fit our ideas. We want the Squire to offer on-site equipment maintenance, while also providing a decent amount of field/hunting support.

Q. Having a fixed number of advancements means that, even when you expand the maximum level, we won’t be able to learn new skills. What are your plans?

We introduced attribute level limitations according to character level precisely because of this. Once the maximum level is expanded, slowly we’ll start to add new attributes, and rather than creating new skills from the feedback we receive, we’re going to strengthen existing skills instead. That is, basically, our plan.

These new attributes and level restrictions will also allow us to introduce more radical skill modifications. For instance, we could have an attribute that makes Meteor drop weaker but multiple meteors on the enemy.

In a previous dev blog post we also toyed with the idea of a Master Circle, a system which was slightly revised to fit the [Re:Build] plans but is still valid. If in the future we consider that simply adding new attributes doesn’t inject enough novelty into the game, we may adapt the concept of a Master Circle.

Q. Having jumps consume Stamina is too inconvenient.

We’ve talked about this in the Rank System Changes Pt. 2 post. Basically, within the category of “resources to manage during combat”, we want skill use to consume SP while movement consumes Stamina. We won’t limit movement itself, but we did increase the consumption of Stamina on jumps, which in combat situations give you the advantage of evading certain attacks, canceling skills, etc.

Q. What about the Homunculus, have you forgotten about it?

We are currently focused on developing the first stage of improvements for the [Re:Build] update. We do want to get to the Homunculus eventually, but because of its complicated structure we may have to adjust very basic aspects of it to fit with our current vision for TOS, which will take time.

We haven’t forgotten about it, however. We expect to have clearer details for an improved Homunculus early next year, at which point we will release more information about it through the dev blog (we want to get rid of the one-week lifespan, for example).

Q. Trot is such an important skill for the Cataphract as a mounted class. Why did you limit its duration?

While we do want to respect the identity of each class, we can’t do so at the expense of balance. Letting players expand their maximum speed indefinitely has unintended consequences in PvP that we cannot control.

On the other hand, we realize that limiting the skill’s duration feels like a drastic change to existing Cataphracts. In line with this, we now expect to alter the skill again, either by removing duration limits but cutting some of the performance, or by applying some other kind of penalty.

Q. When monsters use Barrier, the knockback is too harsh on close-range characters.

Just like other monster skills, Barrier was introduced as an obstacle to specific types of classes (in this case, close-range fighters) and a way to diversify otherwise boring field combat.

That said, we recognize that this variety can be overshadowed by inconvenience when too many monsters use the skill at once, so we’ve committed to making the following alterations:

1. Multiple monsters will not use the Barrier simultaneously.
2. Each monster will use Barrier only once.
3. Distance between monsters will be increased.

Q. Corsairs still need to enhance and transcend two different weapons, all because of one skill that requires a pistol. Isn’t this a little unfair?

Classes like the Scout, Corsair and Outlaw were all envisioned as hybrid dagger/pistol characters. They weren’t designed to use both weapons interchangeably, though. We see the Corsair not as a class that is forced to process both weapons, but one that can choose to specialize in either of them, becoming either a dagger-wielding Corsair or a pistol-wielding one.

The same can be said about skills that are compatible with both weapons. These skills feel and act differently depending on whether you are a dagger- or pistol-specialized Scout, for example, which allows you the freedom of choosing between two distinct roles – or styles – from within the same class. In other words, we don’t intend to burden these classes with mandatory dagger + pistol setups, we want them to distinguish themselves as either dagger or pistol majors.

Q. So classes in the Scout tree use one-handed sword + pistol/dagger setups, but the only skills in the entire tree that require a one-handed sword are the Corsair’s Double Weapon Assault and Hexen Dropper. Why not just turn pistols and daggers into main weapons?

As we mentioned before, Scout-tree classes are intended for pistols and daggers. Apart from a few cases where the concept of the class/skill requires it, they aren’t really meant to use one-handed swords. Similarly, as a group of classes that specializes in subweapons, they cannot equip shields. Instead, they have the most attack-heavy attributes (critical rate, attack speed) and rely on evasion to keep themselves safe. Turning pistols and daggers into main weapons is a different issue altogether.

We have to say, though: we do agree that using a one-handed sword does not suit these classes well. It would be hard to make them not equip a main weapon at all due to technical factors, but we will think of alternatives to make it work better in this context.

Q. If players have no control over their basic stats, won’t they feel forced into certain classes to match their desired stat build?

When we say we want classes to manifest their unique roles and identities, we aren’t just talking about their strong points; we want their weaknesses to show as well. From this point of view, when we give players 390+n stat points to customize at will, two problems occur.

1. You can invest stats to compensate for your classes’ disadvantages instead of amplifying its strengths, creating characters that pretty much have it all. This isn’t what we’re trying to do in TOS: we want people to play the classes, not the stats.

2. Players with vast knowledge on the games’ systems can take advantage of the stats to correct their character’s most crucial weaknesses. For those without the same knowledge, 390+ choices are too many, to the point where stat investments lose meaning.

In order to avoid these two problems while still protecting the role of character customization in TOS, in the future we want to gradually allow players to invest more stat points at will, besides those obtained through Statues of Goddess Zemyna and quests.

Q. The new UI is too inconvenient. You can’t tell a skill’s overheat unless you get at least one level of it, and the tooltips don’t tell you about mounting compatibility either.

Those are problems we are aware of and already working to improve.
 

---

As a final note, would just like to say that, as you can imagine, going over all the skills and features we’ve been receiving feedback on and reworking them into something satisfactory is going to take a good while, more than what we initially expected when we began developing [Re:Build].

We wish we had seen the need for this rework sooner, but we will take this as process to improve Tree of Savior in a way that is meaningful to all of us, and we are eager to continue applying your feedback and ideas into our development plans.

Thank you to all the players who have been discussing the [Re:Build] news and communicating with us; we really appreciate your attention and enthusiasm.