Leaderboard and Achievement System programming

Design goals

? Support for large users
? Multi-leaderboard Support

Scenario I (not described)

Unified leaderboard/Achievement system. Leaderboards and achievement systems for a wide range of games. Many game platforms provide the corresponding API.

Programme II

The game has a single built-in leaderboard. API design recommendations refer to the approach of the way, follow-up can be easily upgraded to plan one.

Bottleneck 1: Sort calculation requirements

Ask the puzzle reason: the leaderboard, need to be sorted, if the constant sorting, the computing resources will be exhausted. If the complete sequence is timed, the player will not be able to instantly see their rankings, especially for players who have entered the rankings without a good incentive. It is possible to optimize the sorting algorithm in case of subsequent necessity.

Solution: Different Refresh Rates
Month, week, day, half day, five minutes;
1 minutes + trigger + evaluation (fake real-time):
Trigger 1: When a player requests to view the leaderboard
Trigger 2: Pending data queue up to set upper limit (usually 1000)
Evaluation: Data that goes beyond the thermal display range is reflected in the evaluation, giving a rough ranking
Note: The evaluation system is used on the leaderboard for all refresh rates.

Bottleneck 2: Big Data

Problem reason: Big Data
If a lot of roles are really involved in sorting, assuming that role 100,000 is registered, then sorting the data for level 100,000, regardless of the computing power, the disk's IO bottleneck and memory size bottlenecks directly result in a single order that takes longer than a second, and if the sorting period setting is too short, it becomes in a constant sort. The result is a depletion of compute resources and IO resources.

Solution: Reduce sorting data
The first 100 or 200 is usually viewed on the design requirements, so the evaluation system is out of range. Players in the case outside of 200, this time, you can use simple evaluation data to give him a ranking. How to better design evaluation system, follow-up introduction.

Bottleneck 3: Resource contention (compute resources/Memory Resources/io Resources)

Problem cause: Multitasking operating system
The computing requirements assigned by the operating system to each process/thread are configurable. In order to avoid one it becomes excessive consumption. Of course, we don't have to set the priority of the process under normal circumstances.

Solution: Single Process
Use a separate process to deliver this service. Use memory data to avoid disk IO.

Bottleneck 4: Frequent submissions

Cause of the problem: program implementation
The game code, after the player leaderboard depends on the value changes, immediately commits, resulting in a number of invalid data submissions.

Solution: Regular submission + lower limit setting
When the player does not view the leaderboard request, the game server is submitted to the leaderboard server on a regular basis (5 minutes), and the lower limit data is compared before submission, before the lower limit is entered into the submission packet (* Note: This submission packet can be packaged, not a small packet sent in a small package). When a role views the leaderboard request, the commit action is triggered and a sort operation is performed on the leaderboard server.


Realize the point of attention

1) CPU consumption
Using a separate process to achieve the leaderboard, a half-day leaderboard can share a process. The 1 minute + triggered list can take a single process.

2) Reduced computational data
After the online character submits the data, and the last comparison of the leaderboard, if it is less than the value, then discard directly. If you enter the list, press this data into the pending queue.

3) Evaluation System
is beyond the 200 (setpoint) List range, exactly how many rankings, not real data, but based on the predetermined ranking range required value, the scope of the valuation. For example, 1000 need 1000 points, 2000 need 2000 points, if the player is 1500 points, then directly estimated to 1500, rather than with other characters in the real sort, maybe we actually do not have a role between the 1000~1500, his rank should be 1000, It might even be 800.
This evaluation system, it is best to build a learning model, can be automatic dynamic update.

4) About multithreading
Leaderboard this process, do not use multithreading to achieve, because the number of connections generated by the socket is small, from our own game server. So it is possible to use the Select model directly under Windows.

Review

Server system design, as far as possible simplification, single. This brings the benefits of a small size of the entire program, small code, bug fixes, maintenance upgrades and other work has become simple and easy to control.

Leaderboards and achievement systems, with a high general universality, are implemented as far as possible with the design of the scheme one in human resources and time permitting.

The sorting algorithm is excellent, it is very effective to improve the sorting speed. It is suggested that the combination of jumping comparison method + lower limit comparison culling method be adopted. Instead of just using the bubbling method.

Other

If you do not understand, or find the error, you can qq:447483932 contact, or e-mail. If there are better suggestions or ideas also welcome to communicate in a timely manner.

Leaderboard and Achievement System programming