Live broadcast interactive game role management system based on cross-platform Token verification

By using a cross-platform token verification mechanism and live streaming platform bullet screen data transmission, cross-platform game character management was achieved, solving the problems of platform fragmentation and data synchronization delay, and improving user experience and business potential.

CN121668689APending Publication Date: 2026-03-17BAIXU TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511819381.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-04
Publication Date
2026-03-17

AI Technical Summary

Technical Problem

Existing game character management systems suffer from platform fragmentation, difficulty in cross-platform character use, data synchronization delays, and poor consistency. Viewers cannot deeply participate in the streamer's game, and the gameplay depth of traditional bullet screen games is limited.

Method used

A live interactive game character management system based on cross-platform token verification is adopted. It realizes cross-platform character data synchronization through token generation, verification module, bullet screen processing module, character management module and data synchronization module. It uses the bullet screen of the live platform as a data transmission channel, and combines the token verification mechanism to ensure the uniqueness and security of the character.

Benefits of technology

It has achieved seamless synchronization of character data across platforms, lowered the barrier to entry for the game, improved data consistency and system reliability, optimized user experience, expanded the user base, and opened up new business models.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121668689A_ABST
    Figure CN121668689A_ABST
Patent Text Reader

Abstract

The invention discloses a live broadcast interactive game role management system based on cross-platform Token verification, and belongs to the technical field of network games. Comprising a Token verification module, a bullet screen processing module, a role management module, a data synchronization module, a game logic module and a platform interface module. Through an innovative Token verification mechanism, seamless synchronization of role data among three different platforms including a WeChat applet / chattering applet playing method, a live broadcast platform and a game client is realized; a live broadcast platform bullet screen is used as a data transmission channel, and an interaction mode of adding an applet role into any live broadcast room game match is realized; by establishing a real-time data synchronization system among multiple platforms, role states are ensured to be kept consistent in all platforms; a traditional anchor unilateral game is converted into an interactive game mode in which audiences can participate, the technical problems that in the prior art, platforms are split, roles are difficult to manage, and the real-time performance is poor are solved, and the game participation threshold is lowered.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network games, in particular to a live interactive game character management system based on cross-platform Token verification, and more particularly to a technical scheme for realizing cross-platform character participation in games by using a live platform bullet screen system. BACKGROUND

[0002] With the rapid development of the network live broadcast industry, live game content has become one of the mainstream live broadcast types. In the traditional live game mode, the host plays the game, and the audience can only watch and send bullet screens for limited interaction, and cannot substantially participate in the game.

[0003] The existing game character management system usually adopts a single platform mode, and the player needs to log in through a specific game client, and the character data is only stored in the game server. This mode has several obvious shortcomings: first, the user needs to create and manage the character on a specific platform, and needs to input the account and password to join the game; second, in the existing bullet screen game, the player inputs a specific bullet screen instruction such as "red / blue, 1, 2, join" in the live room to join the game, but the game account triggered by this way is only bound to the current live platform, for example, the account character of the Douyin platform can only be used in the Douyin platform, and cannot be joined in the Kuaishou platform, the instruction only triggers the function switch of the platform, and cannot carry the unique identity information that can be parsed, resulting in that the character information cannot be managed outside the live platform, and the live platform is subject to its own inability to carry the complete game character, backpack and other page of the game, resulting in that the depth of the bullet screen game play at the present stage is very limited; finally, whether it is a traditional game or an existing bullet screen game, the character data is bound to the platform, and cannot be used across platforms.

[0004] In addition, the existing live platform mainly provides a watching function, and the audience cannot directly participate in the game of the host, and although some platforms provide simple interactive functions such as voting and rewarding, they lack a deep game participation mechanism, and the game experience of the audience and the host is relatively independent. In terms of cross-platform data synchronization, the existing technology mainly focuses on the cross-platform login of the account system, and lacks a cross-platform real-time synchronization solution for game character data, and there are usually delays and consistency problems in data synchronization.

[0005] Therefore, there is an urgent need for a technical scheme that can realize cross-platform character management, reduce the game participation threshold, and ensure real-time data synchronization, to solve the problems in the prior art. SUMMARY

[0006] The present application aims to provide a live interactive game character management system based on cross-platform Token verification, which aims to solve the technical problems of platform fragmentation, character management difficulty and poor real-time performance in the prior art.

[0007] The application provides a live interactive game character management system based on cross-platform Token verification, comprising:

[0008] A Token verification module is configured to receive user character information, generate a Token containing an encrypted character identifier, verify the validity of the received Token, and mark the Token as used after verification;

[0009] A barrage processing module is in communication with the Token verification module and is configured to listen to barrage information of a live platform, identify Token-formatted content from the barrage information, and send the identified Token to the Token verification module for verification;

[0010] A character management module is in communication with the Token verification module and is configured to respond to the verification result of the Token verification module, obtain character data associated with the Token, and load the obtained character data into a game;

[0011] A data synchronization module is in communication with the character management module and is configured to receive character data change information generated during a game process and synchronize the character data change information to multiple platforms;

[0012] A game logic module is in communication with the character management module and the data synchronization module and is configured to control character behavior and interaction in a game process, calculate game settlement data, and provide character data change information to the data synchronization module.

[0013] Preferably, the Token verification module comprises a Token generation unit, a Token verification unit, and a character information extraction unit. The Token generation unit is configured to receive unique identifier information of a user character, generate a variable-length string in combination with a timestamp and a random factor, or concatenate character attribute information with a timestamp and perform SHA256 encryption, take a specific number of bits of the encrypted result as a Token, and record the association between the generated Token and the character in a database. The Token verification unit is configured to verify the legality of the Token format, query the database to confirm the existence and validity of the Token, and mark the Token as used after verification. The character information extraction unit is configured to extract unique identifier information of a character from a verified Token and obtain complete character data according to the unique identifier information.

[0014] Preferably, the barrage processing module comprises a barrage acquisition unit, a Token recognition unit and a user association unit. The barrage acquisition unit is configured to establish a communication connection with a barrage server of a live streaming platform and receive barrage information of a specific live streaming room. The Token recognition unit is configured to preprocess the barrage content to remove blank characters, detect whether the barrage content meets the Token format requirements, and extract Token information meeting the requirements. The user association unit is configured to record user information of a Token sender and establish an association relationship among users, Tokens and game characters.

[0015] Preferably, the Token recognition unit recognizes Tokens in the following manner: detecting whether the length of the barrage content meets a preset Token length range, detecting whether the character composition of the barrage content only contains letters, numbers or preset special symbols, and performing format standardization processing on the content meeting the conditions.

[0016] Preferably, the data synchronization module comprises a data change listening unit, a data updating unit and a change notification unit. The data change listening unit is configured to listen to character data change events generated in a game process and convert the data change events into a standard data structure. The data updating unit is configured to receive change information in the standard data structure and update character data in a database. The change notification unit is configured to generate a data change notification and push the data change notification to a related platform.

[0017] Preferably, the data change events listened to by the data change listening unit include character attribute change events, character equipment change events, character virtual asset change events and character game progress change events.

[0018] Preferably, the game logic module comprises a character loading unit, a battle control unit and a reward calculation unit. The character loading unit is configured to generate a character entity in a game scene based on character data provided by the character management module, and apply character attributes and equipment effects. The battle control unit is configured to control automatic battle behaviors of characters, and process interactions among characters and between characters and a game environment. The reward calculation unit is configured to calculate virtual assets obtained by characters in a game process, and generate character data change information in game settlement.

[0019] Preferably, the interactions controlled by the battle control unit include character attacks on monsters and obtaining gold coins, character death and dropping part of obtained gold coins, character picking up gold coins in a scene, and team cooperation among characters.

[0020] As preferred, a platform interface module is further included, in communication connection with the barrage processing module and the data synchronization module, configured to provide a unified interface for communication with multiple live streaming platforms, adapt data formats of different live streaming platforms, forward barrage information in a standard format to the barrage processing module, and forward change notifications from the data synchronization module to corresponding platforms.

[0021] As preferred, the role management module further includes a role creation unit, an equipment management unit, and an attribute calculation unit. The role creation unit is configured to receive a request for creating a role from a user via a WeChat mini-program or a Douyin mini-game, generate initial data of the role, and save the role data to a database. The equipment management unit is configured to maintain role equipment information, process equipment acquisition, upgrade, and wearing operations, and calculate the influence of equipment on role attributes. The attribute calculation unit is configured to calculate comprehensive attribute values of the role based on basic attributes of the role and effects of equipment, and trigger a data change event when the attributes of the role change.

[0022] The present application realizes seamless synchronization of role data among three different platforms of WeChat mini-programs / Douyin mini-games, live streaming platforms, and game clients through an innovative Token verification mechanism; realizes an innovative interactive mode of joining a game session in any live streaming room by a role of a mini-program through the ingenious use of the live streaming platform barrage comment function as a data transmission channel; ensures consistency of the state of the role in all platforms through the establishment of a real-time data synchronization system among multiple platforms; and changes the traditional one-sided game of anchors into an interactive game mode in which audiences can participate.

[0023] The present application has the following beneficial effects:

[0024] Lower technical threshold: users do not need to install complex clients and can participate in the game through simple barrages, greatly reducing the participation threshold.

[0025] Improve data consistency: through a unified data synchronization mechanism, ensure real-time consistency of multi-platform data, and improve user experience.

[0026] Enhance system reliability: the Token verification mechanism provides secure cross-platform identity verification, ensuring the uniqueness and security of the role.

[0027] Optimize user experience: through a unified role management architecture, users can manage roles in mini-programs and participate in games in live streaming platforms, experiencing a coherent and smooth experience.

[0028] Expand the user base: lower the participation threshold, attract more audiences to participate in the game, and increase user stickiness.

[0029] Innovative business model: combine the innovative mode of live streaming and games to open up new profit channels.

[0030] Token length is configurable: support different length Token generation strategy, enhance system flexibility, avoid being competitors through changing bit number to avoid patent. BRIEF DESCRIPTION OF DRAWINGS

[0031] Figure 1 For the system architecture schematic diagram of the application;

[0032] Figure 2 For the structure schematic diagram of Token verification module in the application;

[0033] Figure 3 For the structure schematic diagram of the barrage processing module in the application;

[0034] Figure 4 For the structure schematic diagram of the data synchronization module in the application;

[0035] Figure 5 For the structure schematic diagram of the game logic module in the application;

[0036] Figure 6 For the structure schematic diagram of the role management module in the application;

[0037] Figure 7 For the workflow diagram of the system of the application;

[0038] Figure 8 For the Token generation and verification flow chart in the application;

[0039] Figure 9 For the game participation flow chart in the application. DETAILED DESCRIPTION

[0040] Please refer to Figures 1-9 , the application will be further described in detail below in conjunction with the drawings and examples. These drawings are only used to explain the application and not to limit the application.

[0041] Referring to Figure 1 , the live interactive game role management system based on cross-platform Token verification provided by the application includes Token verification module 1, barrage processing module 2, role management module 3, data synchronization module 4, game logic module 5 and platform interface module 6, each module is connected through communication to form a complete system architecture.

[0042] The working principle of the system is that a user creates a game character through a WeChat mini-program or a Douyin mini-game, generates a unique Token associated with the character, and then sends a barrage message containing the Token in a live broadcast room of a live broadcast platform. The game client listens to the barrage in the live broadcast room, identifies the Token information and verifies its validity, and after verification, loads the corresponding character into the game, enabling the player to participate in the game session in the live broadcast room. After the game ends, the system calculates the rewards obtained by the character and synchronously updates the data to each platform, ensuring that the user can see the latest character status and asset information on any platform.

[0043] Reference Figure 2 The Token verification module 1 is the core component of the system, mainly responsible for Token generation and verification. The Token verification module 1 includes a Token generation unit 11, a Token verification unit 12, and a character information extraction unit 13.

[0044] The Token generation unit 11 is responsible for receiving the unique identification information of the user's character and generating a Token containing the encrypted character identification. The present application provides two Token generation methods to enhance the flexibility and security of the system:

[0045] The first generation method: Token generation based on random factors

[0046] This method combines time stamps and random factors to generate variable-length strings. In practical applications, the Token length can be configured to be 8 bits, 16 bits, 24 bits, or 32 bits, etc. of different lengths according to security requirements. For example, a 16-bit Token is "mqj6xegdxlao3e6b", which has strong randomness and uniqueness.

[0047] The Token generation logic structure of this method is as follows: after obtaining the unique identification of the character, combine the current time stamp and the randomly generated string, generate the Token string through the hybrid encoding algorithm, and format the result to the specified length. After generating the Token, the system will record the association between the Token and the character in the database, and mark the state of the Token as valid.

[0048] The second generation method: Token generation based on SHA256 encryption

[0049] This method concatenates the character attribute information and the time stamp and then performs SHA256 encryption, taking a specific number of encrypted results as Token information. This method makes the Token generation logic more robust and enables it to be checked afterwards.

[0050] The innovative encryption algorithm used in this method is as follows:

[0051] ,

[0052] Among them, is the character attribute information string, is the current timestamp, represents the string concatenation operation, is the SHA256 hash function, represents taking the th bit to the th bit of the encryption result as the final Token. and are determined according to the required Token length. For example, if a 16-bit Token is needed, then or and other intervals can be taken.

[0053] In the preferred embodiment of the present invention, the character attribute information includes the combination of character ID, character name and character level, and the timestamp is accurate to the millisecond level. After SHA256 encryption, the first 16 bits or the middle 16 bits of the encryption result are taken as the Token. The advantage of this method is that the Token contains the hash value of the character information, and the system can confirm the legitimacy of the Token by recalculating the hash value during subsequent verification, providing a dual verification mechanism.

[0054] For example, assume the character ID is "user_12345", the character name is "Brave Xiaoming", the character level is 10, and the current timestamp is "1704067200000". Then the concatenated string is "user_$$12345|Brave Xiaoming|10|1704067200000". Perform SHA256 encryption on this string to obtain the 64-bit hexadecimal hash value "a7f5d8c9e3b2f1a6d4c8e7b9f2a$5d8c3e6b1f4a7d9c2e5b8f1a4d7c0e3b6f9a2", and take the first 16 bits to get the Token "a7f5d8c9e3b2f1a6".

[0055] The two Token generation methods can be selected according to the specific application scenario. The first method has a fast generation speed and is suitable for high-concurrency scenarios; the second method has higher security and is suitable for scenarios with strict requirements for Token verification. The system supports specifying the Token generation method and length in the configuration file, achieving the configurability of the Token length, ensuring both security and preventing competitors from circumventing this patent by simply changing the Token number of bits.

[0056] The Token verification unit 12 is responsible for verifying the legality of the token's format, its existence, and its validity. The verification process includes checking if the token's length conforms to the system's configured length range, whether the characters are a valid combination of letters and numbers or preset special symbols such as hyphens and underscores, whether the token exists in the database, and whether it is in a valid state. If the verification passes, the token is marked as used, ensuring that each token can only be used once, preventing reuse and security risks.

[0057] For tokens generated using SHA256 encryption, the verification unit performs additional verification steps: extracting role attributes and generation timestamps from the role information associated with the token, re-performing the SHA256 encryption calculation, and comparing the calculation result with the token stored in the database. If the comparison matches, the token's legitimacy is further confirmed. This dual verification mechanism significantly improves system security and effectively prevents token forgery and tampering.

[0058] The character information extraction unit 13 is responsible for extracting the unique character identifier from the verified token and obtaining complete character data based on the identifier, including character level, attributes, equipment and other information.

[0059] Reference Figure 3 The bullet screen processing module 2 is responsible for monitoring bullet screen information on the live streaming platform and identifying tokens. This module includes a bullet screen acquisition unit 21, a token identification unit 22, and a user association unit 23.

[0060] The bullet screen acquisition unit 21 is responsible for establishing a communication connection with the bullet screen server of the live streaming platform and receiving bullet screen information from specific live streaming rooms. In one embodiment, this unit establishes a connection with the bullet screen server of the Bilibili live streaming platform via the WebSocket protocol to receive bullet screen messages in the live streaming room in real time. For different live streaming platforms, the system adopts corresponding protocols and authentication methods to ensure stable acquisition of bullet screen data.

[0061] The Token recognition unit 22 is responsible for preprocessing the bullet screen content, detecting whether it conforms to the Token format requirements, and extracting the compliant Token information. Specifically, this unit first removes whitespace characters from the bullet screen content, then checks whether the content length is within the system-configured Token length range, and whether the character composition meets the requirements.

[0062] In a preferred embodiment of the present invention, the judgment criteria for Token recognition are flexible: the length of the bullet screen needs to be between 8 and 32 bits, and the characters can be lowercase letters a-z, uppercase letters A-Z, numbers 0-9, or preset special symbols such as hyphen "-" and underscore "_". This judgment criteria not only ensures sufficient strictness to avoid misidentifying ordinary bullet screens as Tokens, but also provides sufficient flexibility to support different Token generation strategies while maintaining a good user experience.

[0063] For example, for the bullet screen "mqj6xegdxlao3e6b", the system recognizes its length as 16 bits, and all characters are lowercase letters and numbers, which meets the Token format requirements, and extracts this string as a Token. For the bullet screen "user_abc-123-xyz", the system recognizes its length as 16 bits, including letters, numbers, and preset special symbols underscore and hyphen, which also meets the Token format requirements. However, for the bullet screen "大家好呀", the length is only 4 characters and contains Chinese characters, which does not meet the Token format and will not be recognized.

[0064] The user association unit 23 is responsible for recording the user information of the sent Token and establishing the association relationship between the user, Token, and game character. This enables the system to display the owner information of the character in the game interface, enhancing the user's sense of participation and social interaction. In one embodiment, the system will record information such as the user's live streaming platform ID, user nickname, and the time of sending the Token, and store it together with the character data.

[0065] Refer to Figure 6 , the character management module 3 is responsible for the creation, attribute management, and equipment management of game characters. This module includes a character creation unit 31, an equipment management unit 32, and an attribute calculation unit 33.

[0066] The character creation unit 31 receives the user's request to create a character on the WeChat mini-program or Douyin mini-game end, generates the initial character data, and saves it to the database. In one embodiment, the initial character includes basic attributes such as 1000 hit points of health, 15 attack power, 10 defense power, etc., and the user can improve these attributes through the game process.

[0067] The equipment management unit 32 is responsible for maintaining the character's equipment information, handling equipment acquisition, upgrade, and wearing operations, and calculating the impact of the equipment on the character's attributes. In one embodiment of the present invention, the equipment can be divided into categories such as weapons, armors, accessories, etc., and each type of equipment can provide different attribute bonuses. For example, a "Silver Moon Blade" weapon can provide an attribute bonus of +50 attack power and +15% critical strike rate.

[0068] Attribute calculation unit 33 calculates the character's comprehensive attribute value based on the character's basic attributes and equipment effects, and triggers a data change event when the character's attributes change. The attribute calculation adopts a method of superimposing basic attributes and equipment bonuses. The calculation logic structure is as follows: the character's final attack power equals the basic attack power plus the fixed attack power bonus provided by the equipment, and then multiplied by the percentage attack power bonus provided by the equipment.

[0069] In a specific example, if a character's base attack power is 100 points, and the equipment provides +20 attack power and a +15% attack power bonus, then the final attack power is calculated as the sum of 100 and 20, multiplied by the product of 1 and 15%, resulting in 135 points.

[0070] When a character's attributes change, the attribute calculation unit 33 will trigger a data change event, notifying the data synchronization module 4 to update the database and synchronize it to various platforms.

[0071] Reference Figure 4 The data synchronization module 4 is responsible for synchronizing character data changes that occur during gameplay. This module includes a data change monitoring unit 41, a data update unit 42, and a change notification unit 43.

[0072] The data change monitoring unit 41 is responsible for monitoring character data change events generated during the game process and converting them into standard data structures. The monitored data change events include, but are not limited to, character attribute change events, equipment change events, virtual asset change events, and game progress change events. In one embodiment, when a player character defeats a monster and obtains gold coins, the system generates an asset change event, recording the amount and time of the gold coin increase.

[0073] Data update unit 42 is responsible for receiving change information of the standard data structure and updating the role data in the database. To ensure data consistency, this unit adopts a transaction management mechanism to ensure that data update operations either all succeed or all fail, preventing data inconsistencies caused by partial updates.

[0074] The change notification unit 43 is responsible for generating data change notifications and pushing them to relevant platforms. In one embodiment of the present invention, when a character obtains new equipment in the game, the change notification unit 43 generates a notification containing equipment information and pushes it to a WeChat mini-program or Douyin mini-game, allowing users to view the new equipment obtained by their character in real time.

[0075] To ensure the real-time performance and reliability of data synchronization, data synchronization module 4 employs various optimization strategies. For high-frequency but unimportant data changes, such as character location changes, the system uses a timed batch synchronization strategy to reduce system load; for low-frequency but important data changes, such as equipment acquisition, the system uses an instant synchronization strategy to ensure the real-time performance of important data. Furthermore, the system implements a failure retry mechanism; when data synchronization fails, it automatically retryes multiple times until synchronization is successful or the maximum number of retries is reached.

[0076] Reference Figure 5 Game logic module 5 is responsible for controlling character behavior and interactions during the game process. This module includes a character loading unit 51, a combat control unit 52, and a reward calculation unit 53.

[0077] Based on the character data provided by the character management module 3, the character loading unit 51 generates a character entity in the game scene and applies character attributes and equipment effects. In one embodiment of the present invention, when a player joins the game by sending a bullet screen containing a token, the character loading unit 51 generates a character entity associated with that token in the game scene and applies character attributes and equipment effects read from the database.

[0078] The combat control unit 52 is responsible for controlling the character's automatic combat behavior and handling interactions between characters and between characters and the game environment. In one embodiment of the invention, the character automatically attacks surrounding monsters, and the combat control unit 52 is responsible for calculating attack hits, damage calculations, and monster death logic. Interactions include the character attacking monsters and acquiring gold coins, the character dropping acquired gold coins upon death, the character picking up gold coins in the scene, and team cooperation between characters.

[0079] During the character's attack on the monster, the damage calculation uses the following innovative algorithm:

[0080] ,

[0081] in, The final damage value, This refers to the character's attack power attribute. This refers to the monster's defense attribute. This represents the character's critical hit rate (value range 0-1). This is the critical hit damage multiplier (usually 1.5-2.0). This formula incorporates a defense conversion factor of 0.7, making the damage reduction effect of defense more balanced and preventing high-defense monsters from being completely immune to damage. At the same time, the introduction of the critical hit mechanism increases the randomness and fun of combat.

[0082] In a specific example, if the character's attack power is 100 points, the monster's defense power is 30 points, the character's critical hit rate is 20%, and the critical hit damage multiplier is 1.5, then the damage caused by a normal attack is 100 minus 30 multiplied by 0.7, multiplied by 1, resulting in 79 points; the damage caused by a critical hit is 100 minus 30 multiplied by 0.7, multiplied by 1, plus the product of 20% multiplied by 1.5, resulting in approximately 102.7 points.

[0083] The reward calculation unit 53 is responsible for calculating the virtual assets acquired by the character during the game and generating character data change information at the game settlement. In this embodiment of the invention, the game duration is 15 minutes. After the game ends, the total amount of gold coins obtained by each character is calculated, and this data is synchronized to the server. The amount of gold coins dropped by monsters of different levels and types varies. For example, ordinary monsters drop 5-10 gold coins, elite monsters drop 20-30 gold coins, and boss monsters drop 100-200 gold coins.

[0084] In addition, the reward calculation unit 53 also calculates experience points based on the character's performance in the game. The logical structure is as follows: experience points equal the base experience points multiplied by 1 plus the performance bonus coefficient. The base experience points depend on the game duration and difficulty, while the performance bonus coefficient depends on the character's kill count, assist count, and death count. For example, if the base experience points are 100, and the character kills 10 monsters with each kill providing a 5% bonus, the final experience points gained are 100 multiplied by 1 plus 10 multiplied by 5%, resulting in 150 points.

[0085] Platform interface module 6 communicates with bullet screen processing module 2 and data synchronization module 4, providing a unified interface for communication with multiple live streaming platforms. This module is mainly responsible for adapting to the data formats of different live streaming platforms, forwarding standard format bullet screen information to bullet screen processing module 2, and receiving change notifications from data synchronization module 4 and forwarding them to the corresponding platforms.

[0086] In one embodiment of the present invention, the platform interface module 6 supports mainstream live streaming platforms such as Bilibili, Douyin, and Kuaishou. For each platform, the system has developed a corresponding adapter to convert the platform-specific data format into the system's internal standard format. For example, the bullet comment data format on the Bilibili platform is a JSON object, containing fields such as user ID, username, and bullet comment content; while the bullet comment format on the Douyin platform is different. The platform interface module 6 is responsible for identifying these different data formats, extracting key information, and converting them into the system's unified internal format.

[0087] Preferably, the platform interface module 6 also implements connection pool management, reusing and managing connections with various platforms to reduce the overhead of connection establishment and disconnection, and improve system performance. Simultaneously, this module also implements a reconnection mechanism, automatically attempting to re-establish the connection when the connection with a platform is lost, ensuring stable system operation.

[0088] The following is combined Figures 7-9 The working process of the system of the present invention will be described in detail.

[0089] First, users create game characters via WeChat mini-program or Douyin mini-games. When a user opens the "Lova Brawl" mini-program, the system automatically creates a default character for the new user, who can then view and customize the character's attributes. After the character data is saved to the server database, users can obtain equipment through gacha pulls to enhance their character's abilities.

[0090] Next, the user generates a game participation token in the mini-program. The user selects their current character and clicks the "Token" button to request the generation of a participation credential. The front-end sends the character ID to the server, which selects a token generation method based on its configuration, generates a unique token (8, 16, 24, or 32 characters in length), associates the token with the character, marks it as valid, and then returns the token to the mini-program front-end for display. The user then copies the token to prepare to participate in the game.

[0091] Then, users participate in the game on the live streaming platform. The streamer launches the game client on their computer, enters the live streaming platform's identification code to connect to the live stream, and the game client begins listening for live stream comments. Users send comments containing a token on the live streaming platform; the game client captures the token information and sends a token verification request to the server. The server verifies and cancels the token, marks it as used, returns the complete data of the associated character, and the game client generates the corresponding character in the game.

[0092] During gameplay, characters automatically move within the game environment, attacking monsters to earn gold coins. The system records the amount of gold coins earned by each character, and a settlement process occurs after 15 minutes of gameplay. The game client calculates the gold coins earned by each character and sends the settlement data to the server via API. The server then updates the character information in its database. Users can view the updated character status and rewards in the mini-program.

[0093] Finally, users can use coins to draw equipment in the mini-program, and the obtained equipment will be automatically added to the character's inventory. Users can choose to equip the equipment on their characters, and the equipment's attributes will be added to the character's attributes. After the character's attributes are improved, they will be automatically synchronized to the database, and the character will appear with stronger attributes the next time they participate in the game.

[0094] The working process of the present invention is further illustrated below through a specific embodiment:

[0095] User Xiaoming opens the WeChat mini-program "Lova Brawl" and creates a character named "Brave Xiaoming" with initial attributes of 1000 HP, 15 Attack, and 10 Defense. Xiaoming clicks the "Token" button, and the system generates a 16-bit token string "a7f5d8c9e3b2f1a6" using SHA256 encryption. This token is generated by concatenating Xiaoming's character information "user_12345|Brave Xiaoming|10" with the current timestamp, encrypting it using SHA256, and taking the first 16 bits of the encrypted result. Xiaoming copies this token and then opens the Bilibili live streaming platform, entering a live stream room where "Lova Brawl" is in progress.

[0096] The streamer has launched the game client and connected to the live stream room, and the game client is listening for live stream comments. Xiaoming sent a comment containing the token "a7f5d8c9e3b2f1a6" in the live stream room. The game client captured this comment, identified the token, and sent a verification request to the server.

[0097] The server verifies the token's validity and performs double verification: first, it checks if the token exists in the database and is valid; then, it recalculates the SHA256 hash value from the character information associated with the token, confirming that the calculated result matches the token. After successful verification, the server returns the data for the Xiaoming character. The game client generates the "Hero Xiaoming" character in the game scene. The character automatically attacks monsters in the scene, earning coins for each monster defeated. After 15 minutes, the game ends; Xiaoming's character has defeated 20 monsters and earned 150 coins.

[0098] The game client sends the settlement data to the server, which updates Xiaoming's character information in the database, increasing his gold coin count by 150. Xiaoming returns to the WeChat mini-program and finds that his character's gold coins have increased to 150. He decides to use these gold coins to draw a piece of equipment and luckily obtains a "Flaming Sword," which increases attack power by 25. Xiaoming equips the sword to his character, increasing his character's attack power to 40 points.

[0099] The next time Xiaoming participates in the game, his character will appear with higher attack power, be able to defeat monsters faster, and obtain more gold coin rewards.

[0100] This invention provides a live-stream interactive game character management system based on cross-platform token verification. Through an innovative token verification mechanism, it achieves unified management of character data across platforms. Utilizing live-stream platform comments as a data transmission channel lowers the barrier to entry for game participation, and a real-time data synchronization mechanism ensures data consistency across multiple platforms, creating a completely new live-stream interactive game experience. This system not only solves the problems of platform fragmentation, difficult character management, and poor real-time performance in existing technologies, but also provides new technological directions and business models for the live-stream gaming industry. In particular, the configurable token length feature gives the system greater flexibility and a wider range of protection, effectively preventing competitors from circumventing this patent by simply changing the number of token bits.

[0101] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of protection of the present invention.

Claims

1. A live interactive game character management system based on cross-platform Token authentication, characterized in that The application relates to a token verification method and device, and a token verification system. The token verification module is used for: Receiving user role information, and generating a token containing an encrypted role identifier; Verifying the validity of the received token, and marking the token as used after verification; The barrage processing module is in communication connection with the token verification module, and is used for: Listening to the barrage information of a live broadcast platform; Identifying the content conforming to the token format from the barrage information; Sending the identified token to the token verification module for verification; The role management module is in communication connection with the token verification module, and is used for: Obtaining role data associated with the token in response to the verification result of the token verification module; Loading the obtained role data into a game; The data synchronization module is in communication connection with the role management module, and is used for: Receiving role data change information generated in a game process; Synchronizing the role data change information to multiple platforms; The game logic module is in communication connection with the role management module and the data synchronization module, and is used for: Controlling the role behavior and interaction in a game process; Calculating game settlement data; Providing role data change information to the data synchronization module.

2. The system of claim 1, wherein The token verification module comprises: A token generation unit is used for: Receiving the unique identifier information of a user role; Generating a variable-length string by combining a timestamp and a random factor, or performing SHA256 encryption on the role attribute information and the timestamp after splicing, and taking specific bits of the encryption result as the token; Recording the association between the generated token and the role in a database; A token verification unit is used for: Verifying the legality of the token format; Querying the database to confirm the existence and validity state of the token; Marking the token as used after verification; A role information extraction unit is used for: Extracting the unique identifier information of a role from the verified token; Obtaining complete role data according to the unique identifier information of the role.

3. The system of claim 1, wherein The barrage processing module comprises: A barrage acquisition unit is used for: Establishing a communication connection with a barrage server of a live broadcast platform; Receiving barrage information of a specific live broadcast room; A token identification unit connected with the barrage acquisition unit is used for: Pretreating barrage content to remove blank characters; Detecting whether the barrage content meets the token format requirements; Extracting token information meeting the requirements; A user association unit connected with the token identification unit is used for: Recording the user information of a token sender; Establishing an association relationship among a user, a token and a game role.

4. The system of claim 3, wherein The token identification unit identifies the token in the following manner: Detecting whether the length of the barrage content meets the preset token length range; Detecting whether the character composition of the barrage content only contains letters and numbers or preset special symbols; Performing format standardization processing on the content meeting the conditions.

5. The system of claim 1, wherein The data synchronization module comprises: A data change listening unit is used for: Listening to role data change events generated in a game process; Converting the data change events into a standard data structure; The data updating unit is connected with the data change monitoring unit and is configured to: receive change information of the standard data structure; update role data in the database; The change notification unit is connected with the data updating unit and is configured to: generate a data change notification; push the data change notification to the relevant platform.

6. The system of claim 5, wherein The data change events monitored by the data change monitoring unit include: role attribute change events; role equipment change events; role virtual asset change events; role game progress change events.

7. The system of claim 1, wherein The game logic module includes: The role loading unit is configured to: generate a role entity in a game scene based on the role data provided by the role management module; apply role attributes and equipment effects; The battle control unit is connected with the role loading unit and is configured to: control the automatic battle behavior of the role; handle interactions between roles and between roles and the game environment; The reward calculation unit is connected with the battle control unit and is configured to: calculate virtual assets obtained by the role during the game; generate role data change information at the end of the game.

8. The system of claim 7, wherein The interactions controlled by the battle control unit include: the role attacking monsters and obtaining gold coins; the role dropping part of the obtained gold coins when it dies; the role picking up gold coins in the scene; team cooperation between roles.

9. The system of claim 1, wherein Further comprising: The platform interface module is communicatively connected with the barrage processing module and the data synchronization module and is configured to: provide a unified interface for communication with multiple live streaming platforms; adapt to different data formats of different live streaming platforms; forward barrage information in a standard format to the barrage processing module; receive change notifications from the data synchronization module and forward them to the corresponding platform.

10. The system of claim 1, wherein The role management module further includes: The role creation unit is configured to: receive user requests for creating roles in WeChat mini programs or Douyin mini game interfaces; generate initial role data; save role data to the database; The equipment management unit is configured to: maintain role equipment information; handle equipment acquisition, upgrade, and wearing operations; calculate the impact of equipment on role attributes; The attribute calculation unit is connected with the equipment management unit and is configured to: calculate the comprehensive attribute value of the role based on the role base attributes and equipment effects; trigger data change events when role attributes change.