In-game red dot system design

In-game red dot system design

The original intention of the red dot system design is to remind users. Through the red dot paths constructed by the red dot system, players are guided from the outermost layer to the innermost layer.

Common application scenarios include: prompting players to have new emails, to complete new achievements, to complete a certain task, to upgrade, and so on. Usually the paths constructed by the red dot system are continuous.

Types of red dots

Red dots can be roughly divided into performance and logic.

In terms of performance

The red dot can be a simple red dot, or an exclamation point, text, animation effects, etc. that don't look like a red dot. In short, it is a reminder to the user.

The planning may be based on the priority of the prompt (after all, all emphasis means no emphasis), fun and functionality to arrange the performance of this "red dot".

The performance processing can be encapsulated by itself, or directly add a custom red dot performance on the corresponding interface, and then change the interface performance through callback or event after the macro data changes.

logically speaking

The two most basic states of the red dot are show and hide.
In addition, there are other information displays such as the number of red dots, etc.

Code

After analysis, it is actually found that the red dot structure is a tree structure, or a prefix tree. The code can refer to the link below.

Tree application (1) - Red dot system based on TrieTree (prefix tree)
【Game development practice】Teach you how to use lua in Unity to implement the red dot system

In addition, since the operation of the prefix tree will split the string, this will cause performance problems. In order to solve the problem of string cutting, the use of strings can be optimized. The following article uses RangeString (the encapsulation of string, which is more convenient to use as the key in the prefix tree field).

Red dot system based on prefix tree

In addition, when the leaf node of the prefix tree species changes data, the value of the parent node needs to be updated. Since a large number of child node refreshes will cause invalid refresh of the parent node, there are the following two strategies.

1. Add a storage dirty node pool. When the child node data changes, put its parent node into the dirty pool. Then the external Update triggers the update, and traverses the dirty node pool to let it query its own value.
2. Add a dirty mark on each node. When the child node data changes, mark all the nodes as dirty along the path of the parent node. After the update operation is triggered, the root node will query the nodes marked as dirty from top to bottom and update them.

The first strategy may take a few frames to perform the update operation. There is no performance cost and the processing is smoother in different frames. It's a little less timely, but it doesn't have much of an impact on normal gameplay either.
The second strategy can be triggered by Upate or manually. If you need to calculate more timely can be used.