Features of the development of mobile MMO RTS. Part 3

Content:

1. Performance Optimization and Target Devices
2. Text Drawing and Label Optimization
3. Virtual lists and camera movement

Performance Optimization and Target Devices

I know 3 things that never end: the universe, BMW repair and optimization.
You start to optimize at the design stage of the architecture. It seems that this process will stop after reaching the required performance on target devices. But this is a myth. After you add new functionality or graphical content to the build, performance deteriorates.

We analyzed statistics on all devices and selected those on which we will monitor performance at ~ 30fps. The bottom line is to identify the weakest devices from which many purchases are made.
')


To identify problem areas, use the native Unity profiler and xCode. We are constantly analyzing in order to identify shortcomings, assess the possibilities of their elimination and the benefits from this. After we prioritize tasks and work until we reach the desired performance.

When profiling, we pay attention to 4 aspects: memory allocation in each frame, performance peaks, frequency of method calls, and the most time-consuming parts of the code.

Let's look at examples.

Label optimization and text rendering

Let's take a look at how Unity works with text. All characters and glyphs are added by the system to a special texture that is in memory when requested for rendering. Then, using the exact texture coordinates, the symbols are drawn from this texture. For batching, it is desirable that all Label be in the same DrawCall. Watch out for this while building the UI.

We rewrote the text component in NGUI to suit our needs. As a result, received a noticeable increase in performance. Here is a list of optimizations and rework:

• Label is divided into several components. Basic - for drawing the actual text. Component effects - to add BB-code, shadows, strokes and other add-on process of constructing the text. If you need text with no effects, the base component wins. It does not contain text parsing code or additional fields for storing states. Also, the label is fully recalculated only in case of changes in the text, font size and its own rekta.
• Expanded list of supported BB codes.
• Implemented a policy of working with font sizes. Analyzed their use in the project and chose the most efficient sizes: 28, 36, 40. If the developer chooses the 25th size, the 28th one from the list will be used. The selected size will scale down to 25. This has significantly reduced the size of the texture under the font.
• Optimized the process of updating the texture while increasing its size. Previously, if a character was requested that did not fit into the texture, it was deleted. After that, all characters from the active labels in the UI were requested and a new one was built. Unused characters were simply removed from the texture, and it could not grow in size. In practice, when opening a new window with a different set of characters, the texture could be recreated. We added caching of used characters and their sizes to guarantee an increase in texture each time to the value of the next power of two. Pretty quickly, this texture was filled with all used characters and sizes. This turned out to be better than a permanent restructuring with a smaller texture.

Virtual lists and camera movement

There is a lot of data in our game. To display them, we have implemented virtual lists. They have a certain number of elements that display content. This number is determined by the size of the visible area of ​​the list and a few extra elements for reinsurance. When an element goes beyond the boundaries of the visible area, new data is defined for it, and it is rearranged in the list so that the user scrolls on to see it next. This approach allows not to create many objects and display as many data as you like.



We noticed that with the active use of data lists from users, FPS sank noticeably. The fact is that in Unity, changing the position of objects is a relatively expensive operation, given that the UI itself is a large number of GameObjects. To avoid changing the positions of a large number of elements, we decided to change the position of just one element - the camera. Roughly speaking, the form is displayed by two cameras. One for the list, the other for the rest of the UI. On the scroll area is a controller that handles camera movements and tells the list how it needs to be rearranged.



We can also create endless lists when data is loaded from the server by pages and dynamically added to the data source. The following query is executed when the user has only to see a fixed number of objects. This solution is convenient to use in ratings.

This is not very convenient when building a UI: you have to constantly monitor the layers of objects within one prefab, but after completing the toolkit, there were no problems with this. In addition to lists and other UI-elements, we use this approach with cameras for the sector, maps, previews of characters, troops and buildings.



Finishing work on the fourth article. See you later!

Other articles from the series:

• Part 1 ;
• Part 2 ;
• Part 4