TOP

LOG IN

DEVELOPER'S BLOG

[EDITED] Update on the Optimization Process

By STAFF_Ines

Dec 30th, 2016

Greetings, Saviors!

This is TypeBPenguin, the programmer in charge of optimization for TOS.

Firstly, I would like to apologize for not giving you an update on how things have been going in a while, and for the delay in the optimization update.

We needed some time to reconsider the optimization process for there were certain stability issues. These issues have been dealt with since then and, with that success, different aspects of the optimization process have improved as a result.

In this quest for optimization, we set out one goal: make the game run without a hitch even with 100 players on the screen!

Now, as some of you might already know, this is not an easy task. But we set our goal high and we will dedicate our time and effort to realize it.

Also, we have set up a specialized test environment. As you can see from the screenshots below, 100 player characters are moving about, casting skills, jumping and doing all kinds of activities. This would be an ideal environment to test the optimization.

 

Optimization Process

The first and foremost thing to solve were the client stability issues from the previous optimization process.

During the numerous tests, certain side effects from the previous optimization process have been found and, regrettably, for the sake of stability, we had to forgo some improvements.

However, through other optimization processes, we were able to obtain both stability and improved performance.

1. Our resource management system has been improved by applying resource background loading and data pull. What we have achieved was a reduction in the time wasted on resource loading.

The graph below compares performances before and after the resource management system application.

The unit is ms/frame and the red graph indicates the before, while the purple graph indicates the after.

The test environment for both is the same as the one shown in the screenshots above. Please look at the number of spikes and duration.

Through the application of these measures, we were able to obtain the best of both worlds and have the benefits from the previous process along with the huge reduction from resource loading.

 

2. We created a separate thread to process articles, models and other ingame factors to reduce processing time.

Most of the total processing time is spent on updating models when 100 characters are on one screen.

When characters cast skills, naturally a number of particles are created. Consequently, more time is needed to process the particle effects.

Here, we thought of a way to process them in different threads.

 

3. We reduced rendering time and draw call numbers by improving the rendering pipeline.

We have improved the Character Depth MRT process and other unnecessary rendering processes that we weren’t able to do last time.

 

The graph above was obtained in a test environment and based on the results from replays where certain features were locked. There might be a margin of discrepancy in the actual gameplay environment.

Also, we must be prepared to deal with unexpected side effects like last time.

Therefore, we took some time testing and re-testing to find possible issues so that this optimization process will perform without major problems.

Likewise, we did have to sacrifice some performance to ensure better stability, but the ultimate goal was to provide our users with a safe and sound gameplay experience.

 

Ingame Test

The graph below is based not on replay scenarios but rather the actual ingame environment like the screenshots above.

The red graph indicates the before, the blue graph the after. The first graph is recorded when loading 100 characters doing various activities. The second graph is taken after the character loading and doing various activities.

We can clearly see certain significant improvements in the overall processing speed and reduction in frame drops.

 

 

Closing Words

Aside from the processes we have mentioned above, we are also working on improving inefficient algorithm structures and other tasks to reduce even 1ms for our users. We will keep on striving to improve the optimization process.

As always, thank you for playing and loving our game :D


UPDATE:

We thought we'd add in a few words on the general timeline for the new optimization measures after seeing your feedback on this post.

One part of the processes described here has already been implemented in kTOS and we hope to apply it to iTOS as early as next week (January 3, 2017). Keep an eye on the weekly patch notes for more on that.

Other processes still need some fine tuning before we can bring them into the game, so we'll keep working on those and hopefully we can let you in on more updates in a near future.