Game rankings are a very important function. Rankings are very important in stand-alone games and online games with weak connections. Today we will explain in detail the production plan of game rankings. There are four main points:
- Implementation of the core algorithm of the game ranking ranking algorithm;
- How to create a game ranking server;
- How the Unity client connects and requests ranking data;
- How Unity optimizes leaderboard UI performance;
Implementation of core algorithm for sorting game rankings
Sorting is a very important algorithm in game development, especially for massive amounts of data. An efficient sorting algorithm is the core and key. The same goes for the rankings. We need to sort the players in all the rankings in the server. Every time a player's data changes, it will trigger a sorting, and ultimately let us pull down the rankings from the leaderboard. The performance of the sorting algorithm is very critical. The mainstream sorting algorithms are very mature. For massive server data, the sorting algorithm also has core implementation modules. Here we are doing sorting based on redis, which provides an ordered list. The function internally implements the sorting of massive data. We only need to submit the data to the ordered collection of redis, and then redis will sort it for us, and we can pull the data at the top of the ranking to the client. The core algorithms for sorting the rankings are all implemented by redis, and we can just use them directly.
r redis adds a record : zadd table weight value, add a weighted data to the ordered set table, redis will sort based on this weight.
Redis obtains the ranking data : zrang table start stop, pulls the data from the [start, stop] segment from the ordered collection. There is also reverse sorting, etc., the principle is the same.
How to make a ranking server
With redis server helping us make the ranking kernel, why do we still have a ranking server? What if we don't directly let the client directly operate the redis server on our server? This is mainly due to several factors:
a; Each game partition may be different, so we use a ranking server to manage this concept;
b: The security situation of communication with the client is very complicated. We should not directly expose the core database to the client. For example, if the redis command is directly opened to the customer segment, if there is a plug-in that constantly initiates commands to refresh the rankings, our ranking service may be affected. If we have a server, we can block the IP address. Wait for the means to deal with it. If there is a plug-in that keeps sending some non-standard data without external server verification, this will also cause the rankings to be messed up.
c: If the sorting is affected by some performance, we can ask the sorting server to save the minimum score of the list. If the score is less than this minimum score, then the new scores will not need to participate in the ranking to solve the ranking performance problem.
d: What is stored in the redis ordered collection may be the unique UID that can represent the player. The client displays the rankings and may also need other data, such as user avatars, etc., so a server is needed to combine what the client needs based on the UID. data information.
Generally, when we make a game ranking server, we will write a server program ourselves. This server program serves as the client of redis-server to control the core operations of redis ordered collection. Let redis help complete the sorting core. Then the game ranking server will make strategies, such as the minimum weight mechanism. If the weight is lower than the current minimum weight, it will not be on the list. If it is not on the list, there will be no performance ranking overhead, etc.
The ranking server provides a protocol interface for the client to use. The client sends data to the ranking server according to the protocol. The ranking server checks and verifies the authenticity and security of the game data before updating it to the redis server.
How Unity optimizes leaderboard UI performance
How can Unity display a list with 200 ranking data so that its performance will be good? Let's first look at the information and data content displayed by a basic ranking list to briefly analyze it. This is the ranking list of a certain game, as shown in the figure:
Let's intercept a ranking record from the ranking list to analyze its UI composition. As shown below:
UI element composition:
1: Background UI node to display each item of data
2: UI node to display ranking numbers;
3: Display one or several UIs of the player's avatar, as well as masks, etc.;
4: Display the player’s level node;
5: Display the player’s nickname node;
6: Display the player's score node;
7: Display a player's gift button node,
From the above analysis, it takes 10 to 15 UI nodes to display each ranking record.
If I want to display 100 items of data in this ranking, then I need to create 1,500 UI nodes, which will definitely lead to poor performance. So how do we optimize a game leaderboard or a scrolling list of large amounts of data?
After analyzing possible problems, we generally consider optimizing from the following aspects:
a: Reduce the number of displayed UI nodes and improve rendering performance. For example, if there are 100 items of data, we can actually see only 10 items in the scrolling list, so we can do data paging to do dynamic data loading and display. For example, if 10 items are displayed on each page, we can do 30 items. In this way, dynamic loading can be achieved, and the number of UI nodes can be controlled.
b: Save drawcalls and try to allow these large numbers of UI nodes to be completed in one or a few drawcalls. For example, we put all the resources related to the rankings into an atlas , which increases the possibility of Uidrrawcall merging. At the same time, we make the rankings When designing, do not let the text label disrupt the drawcall batching. U GUI will optimize the text rendering batching , adjust the rendering order of the text without affecting the rendering effect, and render the text together to obtain the smallest drawcall. , In this way, when we organize the interface design, we should not let pictures cover the text. If a certain picture covers the text, then this text Label will not be able to participate in the batching of all texts, and this text Label It will also disrupt the batching of image rendering.
C: For UGUI, the rankings can be deployed under one root node, and the root node has a UGUI Canvas component to reduce a large amount of combined calculation overhead.