A method, system, device, and medium for game data processing based on real-time interaction across multiple terminals.

Abstract

This application relates to a game data processing method, system, device, and medium based on real-time interaction across multiple terminals. The method includes: responding to a game start signal; generating and initializing a story state machine containing scene node data objects and non-player character attribute datasets through structured parsing of module configuration files; acquiring a character attribute dataset submitted by the player's terminal; establishing a mapping relationship between the terminal identification code and the dataset to generate a character binding record; responding to a turn start signal; acquiring an interaction type identifier and invoking the corresponding preset instruction; and calculating an interaction result dataset based on the preset instruction, used to instruct player terminal actions and / or update the story state machine. This method automates and standardizes the processing of tabletop role-playing game (RPG) data, ensures data synchronization and consistency across multiple terminals, improves data processing efficiency and interaction fairness, and optimizes the RPG experience.

Description

Technical Field

[0001] This invention belongs to the field of computer information processing technology, and in particular relates to a game data processing method, system, device and medium based on real-time interaction of multiple terminals. Background Technology

[0002] In offline complex narrative strategy simulation activities (such as tabletop role-playing games TRPGs, commonly known as tabletop role-playing games), the game process relies heavily on a host managing the character data, plot progress, combat calculations, and various temporary states of multiple players simultaneously. Due to the large number of participants and the complex rule system, the organizer (host) needs to bear extremely high data maintenance and synchronization pressure.

[0003] Currently, moderators typically use paper records, local spreadsheets, or general instant messaging tools to assist in management. While these methods can accomplish data recording to some extent, they are essentially still manual information processing modes. For example, when a player character loses health or acquires temporary madness symptoms due to a story event, the moderator needs to manually modify the local record and then verbally or via chat software to inform the player, while other players may not be aware of this change in real time. When calculating the order of actions in combat, the moderator must compare all player characters' agility stats with preset enemy data one by one, manually sort them, and then inform the entire team. These operations are not only time-consuming but also prone to disrupting the game's rhythm due to omissions or delays in information transmission, and may even cause disputes among players. These problems not only affect the game experience but also limit the commercial development of tabletop role-playing games. Summary of the Invention

[0004] Therefore, it is necessary to provide a game data processing method, system, device, and medium based on multi-terminal real-time interaction to address the aforementioned technical problems. This method can improve the efficiency, accuracy, and synchronization consistency of data processing in complex multiplayer game scenarios, thereby enhancing the gaming experience for both the host and the players.

[0005] In a first aspect, this application provides a game data processing method based on real-time interaction across multiple terminals. This method can be applied to a server, which communicates with multiple terminals, including a host terminal and player terminals. The method includes:

[0006] In response to the game start signal, the obtained module configuration file is parsed in a structured manner to generate a story state machine that includes scene node data objects and non-player character attribute datasets, and the story state machine is initialized to the starting scene node;

[0007] Obtain the game character attribute dataset submitted by the player's terminal, establish a mapping relationship between the player's terminal identification code and the game character attribute dataset, and generate a character binding record;

[0008] In response to the start of the round signal, obtain the interaction type identifier sent by the host terminal, and invoke the corresponding preset instruction based on the interaction type indicated by the interaction type identifier;

[0009] Based on preset instructions, interactive operations are performed on the game character attribute dataset and / or non-player character attribute dataset to obtain an interactive result dataset; wherein, the interactive result dataset is used to instruct the player terminal to perform corresponding actions and / or update the story state machine.

[0010] Secondly, this application also provides a game data processing system based on real-time interaction across multiple terminals, used to implement the game data processing method based on real-time interaction across multiple terminals provided above. The system includes:

[0011] The module parsing module is used to perform structured parsing on the obtained module configuration file, generate a story state machine including scene node data objects and non-player character attribute datasets, and initialize the story state machine to the starting scene node;

[0012] The character binding module is used to obtain the game character attribute dataset submitted by the player's terminal, establish a mapping relationship between the player's terminal identification code and the game character attribute dataset, and generate a character binding record.

[0013] The instruction routing module is used to obtain the interaction type identifier sent by the host terminal and call the corresponding preset instruction based on the interaction category indicated by the interaction type identifier.

[0014] The interactive calculation module is used to perform interactive calculations on the game character attribute dataset and / or non-player character attribute dataset based on preset instructions to obtain an interactive result dataset; wherein, the interactive result dataset is used to instruct the player terminal to perform corresponding actions and / or update the plot state machine.

[0015] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the game data processing method based on real-time interaction of multiple terminals provided above.

[0016] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the game data processing method based on real-time interaction across multiple terminals provided above.

[0017] The aforementioned game data processing method, system, device, and medium based on multi-terminal real-time interaction, upon receiving the game start signal, performs structured parsing of the module configuration file, constructs a narrative state machine containing scene nodes and non-player character data, and locates the starting scene. Simultaneously, it acquires the character attribute datasets submitted by each player's terminal and generates character records by binding them with terminal identification codes. Then, in each round, it responds to the interaction type identifier issued by the host's terminal and calls the corresponding instruction, performing unified calculations on the character attribute data and scene-related non-player character data to generate an interaction result dataset that can be used to instruct player terminals to perform actions and trigger updates to the narrative state machine. This solution uses a server as the data processing hub to replace manual recording and verbal synchronization, enabling scene synchronization, character state management, and round interaction judgment between multiple terminals to be centrally executed and automatically distributed by the central logic. This significantly reduces processing delays and state inconsistencies caused by manual transcription, comparison, and information transmission, while maintaining the coherence of complex narrative progression and greatly improving the efficiency of process advancement and the accuracy of information synchronization in multi-player board games or real-world interactive scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a game data processing method based on real-time interaction across multiple terminals, provided as an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram of the structure of a game data processing system based on real-time interaction across multiple terminals, provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0022] First, a brief introduction to the terms used in the embodiments of this application will be given.

[0023] Tabletop role-playing games (TRPGs) are a type of collaborative narrative activity, either offline or online, involving one organizer and multiple participants. In a typical process, the organizer (usually called the KP or DM) constructs a fictional world and storyline based on a pre-written or self-designed narrative framework. Each participant creates and assumes a role within this fictional world. The progress of the activity depends on the organizer's description of the scene, the participants' declarations of their character actions, and the organizer's judgment of the outcomes of these actions according to rules. This process involves the generation and flow of a large amount of character attribute data, non-player character data, random event judgments, and scene transition information, traditionally relying heavily on human memory, paper records, and verbal synchronization.

[0024] Adventure modules are the core narrative carriers of tabletop role-playing games. Essentially, they are standardized resource packs containing complete world-building, story background, plot lines, scene descriptions, non-player character (NPC) information, and rule constraints. Their role is to provide a unified narrative framework and interaction basis for tabletop role-playing games. The host advances the game by loading and interpreting the module content, and players create characters based on the module settings and participate in the narrative interaction. The degree of structuring of the module directly affects the smoothness and immersion of the tabletop role-playing process.

[0025] The interaction type identifier is a command identifier sent by the host terminal to the server to define the nature of the current round of interaction. It is used to distinguish different interaction scenarios such as combat interaction and non-combat interaction (such as dialogue, reconnaissance, listening, etc.). This identifier is the core basis for the server to call the corresponding preset instructions and data operation logic. By clarifying the interaction type, the data processing rules under different scenarios can be accurately matched, ensuring the standardization and pertinence of data operation during the interaction process.

[0026] Based on the above definitions, the implementation environment of a game data processing method based on real-time multi-terminal interaction provided in this application is described. Indicatively, this implementation environment includes terminals and servers. The terminals include a host terminal and at least one player terminal. The host terminal is typically a personal computer or laptop computer running client software, a mini-program, or a web application accessible via a browser with global management permissions. It can be used to load module configuration files, initiate game processes, issue interactive commands, and view the status of each player. The player terminal is typically a smartphone or tablet computer, running a mobile application for character creation, data viewing, receiving push messages, and submitting interactive feedback. The server can be an independent physical server, a cloud server, or a server cluster consisting of multiple servers. It establishes a full-duplex communication connection with each terminal via a network and is used to perform module parsing, story state machine maintenance, character data storage, interactive computation processing, and message distribution and broadcasting. This application does not limit the specific hardware configuration and networking form of the server.

[0027] Based on the above definitions and implementation environment, the application scenarios of this application's embodiments are described. The game data processing method based on multi-terminal real-time interaction provided in this application embodiment is mainly applied to scenarios requiring multi-person collaborative participation and relying on real-time data management, such as tabletop role-playing games (TRPGs), offline board games, or real-world interactive simulations. It is particularly suitable for offline interactive activities like tabletop role-playing games (RPGs) with complex plot lines, multi-character data interaction, and dynamic process progression. In the offline RPG game scenario, the host can complete adventure module loading, character data review, sending interaction type commands, and controlling the plot flow through the host terminal. Players can perform operations such as character creation and submission, receiving plot information, and responding to interaction commands through mobile player terminals. The server acts as the core hub, completing data processing tasks such as module data structure parsing, multi-terminal data synchronization, interactive calculations, and plot state machine updates. In addition, this solution can be extended to multi-person collaborative strategy simulation activities that require cross-terminal data exchange and automated process control between organizers and participants. Through real-time interaction across multiple terminals and standardized data processing, it effectively solves problems such as untimely data synchronization, low processing efficiency, and cumbersome control processes in traditional scenarios, significantly improving the smoothness of activity progress, the consistency of data interaction, and the immersive experience of participants.

[0028] This is merely an illustrative example; the game data processing method based on real-time interaction across multiple terminals provided in this application embodiment can also be applied to other application scenarios. This is only an example and does not limit the specific application scenarios.

[0029] In one exemplary embodiment, such as Figure 1 As shown, a game data processing method based on real-time interaction across multiple terminals is provided. This embodiment illustrates the application of this method to a terminal in the aforementioned implementation environment. It is understood that this method can also be applied to a server, or to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps 101 to 104:

[0030] Step 101: In response to the game start signal, perform structured parsing on the obtained module configuration file to generate a story state machine including scene node data objects and non-player character attribute datasets, and initialize the story state machine to the starting scene node.

[0031] Specifically, this method can obtain a module configuration file pre-uploaded by the host through a communication link established with the host's terminal. This module configuration file contains the world view description, plot outline, scene information, basic data of non-player characters, and rule constraints required for the tabletop role-playing activity. Its data format is compatible with common text formats, markup language formats, or custom structured formats. For example, to achieve standardized processing and subsequent calling of module data, this method adopts a structured parsing strategy based on syntax parsing and semantic mapping. It identifies key information fields in the module configuration file through a preset parsing rule base, decomposes scene-related information into scene node data objects containing scene identifiers, scene description text, scene association conditions, and scene interactive elements, and extracts and integrates non-player character-related information into a non-player character attribute dataset containing basic character attributes, behavioral logic parameters, and interaction response thresholds. This constructs a plot state machine with scene nodes as the core, containing node jump logic and data association relationships. After the plot state machine is constructed, the method can initialize the plot state machine to the corresponding starting scene node according to the preset starting plot node identifier in the module configuration file, providing a digital basic framework for the orderly advancement of the game plot. For example, this structured parsing process can realize the structured transformation of unstructured text information by integrating natural language processing technology, ensuring the integrity and accuracy of the parsing results, and avoiding information omissions or errors caused by manual parsing.

[0032] Step 102: Obtain the game character attribute dataset submitted by the player's terminal, establish a mapping relationship between the player's terminal identification code and the game character attribute dataset, and generate a character binding record.

[0033] Specifically, after a player creates a character (vehicle card) through their player terminal, the terminal encrypts and uploads a game character attribute dataset containing information such as character attribute parameters and skill configurations to the server. Furthermore, upon receiving this dataset, this technical solution verifies the data format for compliance, ensuring that the data fields match the preset character data template. It then obtains the unique terminal identification code of the player terminal that sent the dataset and establishes a one-to-one correspondence between the terminal identification code and the game character attribute dataset using a hash mapping algorithm. This generates a character binding record and stores it in the server's character data management database. Further, this character binding record is synchronized to the host's terminal for card review. The host receives the review result from the terminal. If the review is successful, the character binding record is marked as valid. If the review fails, the server sends feedback to the corresponding player terminal. The player corrects the error, resubmits, and repeats the data reception and binding process. This process achieves precise association between the player terminal and character data, providing an identity identification basis for subsequent multi-terminal data interaction and targeted synchronization.

[0034] Step 103: In response to the round start signal, obtain the interaction type identifier sent by the host terminal, and call the corresponding preset instruction based on the interaction category indicated by the interaction type identifier.

[0035] Specifically, when a game round ends, the host sends a round start signal through the host terminal. This signal contains an interaction type identifier corresponding to the current round. This identifier is set by the host based on the needs of the module's plot progression and the player's interaction in the previous round. After receiving the round start signal, this technical solution parses the interaction type identifier and determines the interaction category indicated by the identifier by querying a preset instruction mapping table. Then, it calls preset instructions pre-stored on the server that correspond to the interaction category. The preset instructions are a set of standardized data processing logic and operation rules based on different interaction scenarios (such as combat interaction and non-combat interaction). For example, if the interaction type identifier indicates combat interaction, the method calls preset instructions that include logic such as initiative value calculation and combat process control. If the identifier indicates non-combat interaction (such as reconnaissance or dialogue), it calls preset instructions that include logic such as skill judgment and plot response, ensuring the relevance and standardization of data processing under different interaction scenarios.

[0036] Step 104: Perform interactive operations on the game character attribute dataset and / or non-player character attribute dataset based on preset instructions to obtain an interactive result dataset; wherein, the interactive result dataset is used to instruct the player terminal to perform corresponding actions and / or update the story state machine.

[0037] Specifically, after invoking the corresponding preset instruction, this method retrieves the corresponding game character attribute dataset from the character data management library according to the instruction's computational logic. If the interaction scenario involves non-player characters, it also retrieves the non-player character attribute dataset from the story state machine. Following the computational rules and parameter weights set in the preset instruction, the method performs logical operations and data fusion processing on the relevant datasets to obtain an interaction result dataset containing interaction results, character data update information, and story progression instructions. Specifically, the computation process can employ algorithms such as weighted summation, logical judgment, and rule matching. For example, in a combat interaction scenario, damage values ​​and survival status are calculated based on the attribute parameters of both characters. In a non-combat interaction scenario, the success rate of the interaction is determined by combining character skill values ​​and story constraints. This interaction result dataset is then pushed to the corresponding player terminal and host terminal. The player terminal executes corresponding actions such as character status display and interaction result prompts based on the dataset. Simultaneously, the method updates the current scene node of the story state machine according to the story progression instructions within the dataset, achieving automated synchronous progression of the story.

[0038] The aforementioned game data processing method based on real-time interaction across multiple terminals performs structured parsing of the module configuration file upon receiving the game start signal. It constructs a narrative state machine containing scene nodes and non-player character data and locates the starting scene. Simultaneously, it acquires the character attribute datasets submitted by each player's terminal and binds them with terminal identification codes to generate character records. Then, in each round, it responds to the interaction type identifier issued by the host's terminal, calling the corresponding instruction. It performs unified calculations on the character attribute data and the scene-related non-player character data to generate an interaction result dataset that can both instruct player terminals to perform actions and trigger updates to the narrative state machine. This solution uses a server as the data processing hub, replacing manual recording and verbal synchronization. Scene synchronization, character state management, and round interaction judgment between multiple terminals are all centrally executed and automatically distributed by the central logic. This significantly reduces processing delays and state inconsistencies caused by manual transcription, comparison, and information transmission. While maintaining the coherence of complex narrative progression, it greatly improves the efficiency of process advancement and the accuracy of information synchronization in multi-player board games or real-world interactive scenarios.

[0039] In one embodiment, the process includes obtaining a game character attribute dataset submitted by the player's terminal, establishing a mapping relationship between the player's terminal identification code and the game character attribute dataset, and generating a character binding record, including:

[0040] Extract the preset world view description text, era background tags, occupation rarity constraint parameters, and attribute mutual exclusion rule set from the module configuration file.

[0041] Specifically, this method can extract several preset card review benchmark data from the loaded module configuration file. These benchmark data include at least the world view description text, era background tags, occupation rarity constraint parameters, and attribute mutual exclusion rule set. The world-building description text is generally a paragraph written in natural language that summarizes the basic settings of the fictional world on which the game adventure is based. For example, whether magic exists in the world, what stage of technology it is at, and the composition and relationships of different social classes. The era background tags are several keywords or classification marks abstracted from the world-building description, such as "Victorian era," "cyberpunk near future," or "medieval fantasy," used to quickly determine the era fit of the character's identity. The job rarity constraint parameter defines the allowed range of numerical strength for each job type in the module settings, such as the initial value upper limit of a job in a specific skill dimension, or the reasonable fluctuation range of a certain attribute. The attribute mutual exclusion rule set records the logical conflict relationship between multiple attribute value combinations in the form of conditional expressions. Typical rules are such as "if the character is a beggar, the wealth attribute value must not exceed the preset threshold" or "if the character has a noble title, the wandering skill value must not exceed the preset upper limit," unless there is a reasonable story background explanation.

[0042] Input the character identity description field and the world view description text from the game character attribute dataset into the semantic consistency evaluation model, and calculate the first compatibility score between the character identity description field and the world view description text.

[0043] For example, the semantic consistency evaluation model can employ a text matching network structure fine-tuned from a pre-trained language model. Its backbone network is pre-trained on a large-scale general corpus and can be supervisedly fine-tuned on a large amount of historical tabletop role-playing game (RPG) character cards paired with corresponding module worldview descriptions. This enables it to evaluate the semantic fit between a character description text and a worldview description text, particularly its ability to understand and analyze RPG slang. Specifically, the semantic consistency evaluation model converts the character identity description field and the worldview description text into high-dimensional semantic vectors, calculates the cosine similarity or Euclidean distance between the two semantic vectors, and outputs a first compatibility score within a preset range after passing through a normalized mapping function. A higher first compatibility score indicates a better match between the character's identity setting and the module's worldview; conversely, a lower score suggests a potential deviation from the module's overall tone.

[0044] Specifically, the semantic consistency evaluation model performs word segmentation and word embedding encoding on the input character identity description text sequence and worldview description text sequence, respectively, converting the two unstructured texts into two dense semantic vectors with fixed dimensions. Let the first semantic vector corresponding to the character identity description field be vector A, and the second semantic vector corresponding to the worldview description text be vector B. The model measures the semantic similarity between vectors A and B by calculating the cosine of the angle between them in the vector space. The smaller the angle, the closer the cosine value is to the preset upper limit, indicating a better match between the character identity setting and the module's worldview tone; conversely, the larger the angle, the closer the cosine value is to the preset lower limit, suggesting a potential risk that the character identity may deviate from the module's worldview. This step calculates the first compatibility score using the following formula, which is the final output value of the cosine similarity between vectors A and B after normalization mapping:

[0045]

[0046] in, The first compatibility score is configured to be a continuous or discrete value between a first preset lower limit and a first preset upper limit. For the first semantic vector A in the th... Component values ​​in each dimension; For the second semantic vector B in the th Component values ​​in each dimension; The total dimension of the first semantic vector A and the second semantic vector B is predetermined by the feature extraction network structure of the semantic consistency evaluation model. Through the above formula, this step transforms the fuzzy semantic matching process into a quantifiable and reproducible numerical calculation, ensuring the objectivity and consistency of the compatibility evaluation results.

[0047] Input the role identity description field and the era background label into the semantic consistency evaluation model to calculate the second compatibility score between the role identity description field and the era background label.

[0048] Similarly, the server inputs the character identity description field and the era background label into the same semantic consistency evaluation model or another sub-model specifically for label matching, and calculates a second compatibility score, which is used to measure the degree of matching between the character identity and the era background of the module.

[0049] The values ​​of each attribute field in the game character attribute dataset are compared with the profession rarity constraint parameters to generate a third compatibility score. The third compatibility score is used to characterize whether the overall strength of the game character attribute dataset exceeds the range of character strength allowed by the module configuration file.

[0050] Specifically, this method reads the selected job type identifier of the character, finds the corresponding attribute strength benchmark range from the job rarity constraint parameters, and compares the attribute values ​​submitted by the character with the upper and lower limits of the benchmark range. If all attribute values ​​fall within the benchmark range, the third compatibility score is set to the highest value; if any attribute value exceeds the upper limit of the benchmark range by a large margin, or falls below the lower limit of the benchmark range by a significant difference, the third compatibility score is reduced according to a preset deviation mapping function. The third compatibility score is essentially used to quantify whether the overall strength of the character attribute dataset exceeds the character strength range allowed by the module configuration file, preventing players from disrupting game balance by irrationally allocating attribute points.

[0051] For example, this method can read the selected job type identifier of the character, find the baseline upper limit value of each attribute field corresponding to that job type identifier from the job rarity constraint parameters, and denot it as... ,in This serves as the index identifier for the attribute field. For each attribute field participating in the comparison, the server calculates the current value of that attribute field. Its corresponding upper limit value The degree of deviation between attributes is considered. When the current value of one or more attribute fields exceeds its baseline upper limit, it indicates that the character's strength in that dimension exceeds the module's preset balance range. In this embodiment, the method can calculate the third compatibility score using the following formula, which comprehensively represents the deviation of each attribute field:

[0052]

[0053] in, This is the third compatibility score; The preset maximum score for third compatibility; For the game character attribute data set, the first The actual submitted values ​​for each attribute field; The parameters defined in the occupation rarity constraint parameters are related to the first... The baseline upper limit value corresponding to each attribute field; This is the deviation term, indicating that it only applies if the actual value... Exceeding the baseline upper limit Only the portion exceeding the limit will be included in the deduction calculation; In order to be with the first Each attribute field corresponds to a preset weight coefficient, which is used to characterize the relative importance of different attribute supermodels to the game balance; To account for the total number of attribute fields participating in the comparison, the above method can transform the abstract strength assessment into a weighted cumulative deduction calculation of the deviation of each attribute, so that the third compatibility score can accurately reflect the extent to which the character's value has broken through the module's preset strength constraint boundary, providing the host with an objective quantitative basis for card review.

[0054] The game character attribute dataset uses a conflict detection rule engine to identify whether there are any combinations of attribute values ​​that conflict with the character identity description field. When a conflict is detected, a conflict detection result is generated that includes the identifier of the conflicting attribute field and a description of the reason for the conflict.

[0055] For example, the attribute conflict detection rule engine has a built-in extensible rule base. Each rule in the rule base consists of an antecedent condition and a consequent conclusion. The antecedent condition describes specific keywords or phrases contained in the character identity description field, while the consequent conclusion defines the range of attribute values ​​that should not appear or should be restricted under that identity. The rule engine can use a pattern matching algorithm to scan the character identity description field. When it identifies an identity feature word that matches the antecedent condition of a rule, it activates the corresponding rule and compares and verifies the consequent conclusion of that rule with the values ​​of each attribute field submitted by the character. If the attribute value is found to fall within the restricted range defined by the consequent conclusion, a conflict is detected. The rule engine then generates a conflict detection result, which includes the identifier of the conflicting attribute field and a conflict reason description text generated based on the rule template. For example, if the character identity description is "a weak scholar" but the "strength value" in the attribute field is far beyond the reasonable range of a normal scholar, the rule engine will accurately detect the conflict and generate a conflict detection result containing the identifier of the conflicting attribute field (such as "strength value") and a conflict reason description (such as "the identity of a weak scholar contradicts the attribute of high strength value").

[0056] Based on the first compatibility score, the second compatibility score, the third compatibility score, and the conflict detection results, an audit prompt dataset is generated. The audit prompt dataset contains warning entries triggered when each compatibility score is lower than the corresponding preset threshold, as well as all conflict description entries recorded in the conflict detection results.

[0057] Specifically, this technical solution generates a review prompt dataset based on the calculated first compatibility score, second compatibility score, third compatibility score, and conflict detection results, according to a preset data format template. When any compatibility score is lower than the corresponding preset threshold, the corresponding warning item is automatically triggered. The warning item clearly indicates the type of low compatibility (such as incompatible worldview, mismatched historical background, or excessive strength) and specific related fields. At the same time, all conflict description items recorded in the conflict detection results are fully incorporated into the review prompt dataset to ensure that the host can clearly understand the problems existing in the role data.

[0058] The review prompt dataset and the game character attribute dataset are sent to the host terminal. The review prompt dataset is used to display warning entries on the host terminal indicating compatibility issues or attribute conflicts.

[0059] Specifically, the review prompt dataset and the original game character attribute dataset are sent together to the host's terminal. Upon receiving this data, the management interface on the host's terminal performs standard rendering of the game character attribute dataset and parses the content of the review prompt dataset. Furthermore, in the interface display, attribute fields with compatibility issues or attribute conflicts are highlighted with differentiated visual styles, such as using different colored borders, background highlights, or warning icons. When the host hovers the cursor over or clicks on these marked areas, the interface displays the corresponding warning entries and the specific reasons stated in the conflict description entries via a pop-up or sidebar. Based on these visual prompts, the host can quickly locate potential problems in the character settings and, combined with their understanding of the module's storyline, make a final review judgment, which may include: approval, rejection with modification requests, or ignoring warnings and approving. The server only executes the subsequent operations of establishing a mapping relationship between the terminal identification code and the game character attribute dataset and generating a character binding record after receiving the approval instruction from the host's terminal.

[0060] In this embodiment, the method combines semantic understanding technology, numerical compliance verification, and logical rule reasoning to achieve multi-dimensional automatic analysis and annotation of suspicious points in player-submitted character data while retaining the host's final discretion. Compared to the traditional manual card review method, this method significantly reduces the time required for the host to review character cards, reduces reliance on the host's rule memorization ability, and effectively avoids plot loopholes and balance issues exposed in the later stages of the game due to the disconnect between character settings and world view or internal contradictions in attributes. It also improves the data processing efficiency and consistency of card review results during the game preparation phase.

[0061] In one embodiment, an interaction type identifier sent by the host terminal is obtained, and a corresponding preset instruction is invoked based on the interaction category indicated by the interaction type identifier. It should be noted that in traditional offline role-playing games, participants typically use physical dice to roll them and verbally report the results. The host then judges the success or failure of a role's action based on this result and their own memory of the rules. This embodiment aims to assist the host in calculation and information synchronization, specifically including:

[0062] When the interaction type identifier indicates that the interaction category is non-combat interaction, the skill judgment instruction sent by the host terminal is obtained. The skill judgment instruction includes the terminal identification code of the target player's terminal, the skill dimension identifier to be judged, and the difficulty level modifier.

[0063] Non-combat interaction is the most frequent type of interaction in tabletop role-playing games. It covers a variety of player actions that do not directly involve armed conflict, such as persuasion, environmental reconnaissance, listening to sounds, knowledge recall, and stealthy movement. The common feature of these actions is that the host needs to initiate a skill judgment for a specific player character according to the needs of the plot, and the server replaces the human to complete the complete judgment chain from data extraction, random number generation to result output.

[0064] Specifically, when a player declares that their character will perform a non-combat action during gameplay, such as searching for a hidden door in an abandoned library, trying to eavesdrop on whispers at neighboring tables in a banquet hall, or persuading a suspicious guard, the host selects the corresponding skill assessment option on the host's terminal interface based on the current scenario. The host's terminal then generates a skill assessment instruction. This instruction's data structure includes the target player's terminal identifier, the skill dimension identifier to be assessed, and a difficulty level modifier. The skill dimension identifier indicates the character's ability dimension associated with this assessment, such as "reconnaissance," "listening," "communication," "climbing," or "occult knowledge." Furthermore, the difficulty level modifier reflects the objective impact of the current scenario on the success rate of the action. For example, a particularly harsh environment can be marked as "difficult" with a negative correction value, while a favorable environment can be marked as "easy" with a positive correction value.

[0065] Based on the terminal identification code of the target player's terminal, the system searches for the corresponding game character attribute dataset in the character binding record and extracts the skill dimension value corresponding to the skill dimension identifier from the game character attribute dataset.

[0066] Specifically, after receiving the skill determination instruction, the server parses the target player's terminal identification code and uses this code to search through the generated character binding records. It then locates the game character attribute dataset bound to that terminal and extracts the corresponding skill dimension value from the dataset based on the skill dimension identifier carried in the skill determination instruction. In the data structure, the skill dimension value is typically represented as a combination of a base ability value and several specialty modifiers. The base ability value comes from the attribute points allocated during character creation, while the specialty modifiers come from specific bonuses granted by the character's class or background. Combining these two values ​​yields the actual skill dimension value applied in this determination.

[0067] Using the current system timestamp, server hardware entropy source value, and current session identifier as a seed input, a first random value is generated through a cryptographically secure pseudo-random number generation function.

[0068] Specifically, this method can invoke a cryptographically secure pseudo-random number generation function built into the server side. This function employs a hash-based message authentication code algorithm or a certified deterministic random bit generator. Its seed input consists of a microsecond-precision portion of the current system timestamp, the server hardware entropy source value, and the current session identifier. The hardware entropy source value can be derived from a combination of sampling of the timestamp counter and a high-precision event timer within the server's central processing unit, ensuring the unpredictability of each seed input. Based on this mixed seed, the pseudo-random number generation function outputs a first random value uniformly distributed within a preset value range. This first random value can be used as a reference dice roll result provided by the server to the host, or as a built-in alternative judgment criterion within the system.

[0069] The skill dimension value and the first random value are input into the preset rule judgment function. The judgment result enumeration value is calculated by the rule judgment function, and the interactive result dataset is generated based on the judgment result enumeration value.

[0070] Specifically, the rule-based decision function is a pre-configured computational logic module based on the rule system corresponding to the module used in this game. In an exemplary implementation, the rule-based decision function first performs a weighted sum of the first random value and the skill dimension value to obtain a preliminary decision value. Then, it compares this preliminary decision value with the target threshold corresponding to the difficulty level modifier. The target threshold can be divided into multiple intervals, each corresponding to a different level of success or failure. For example, when the preliminary decision value is lower than the first threshold, the decision result is "major failure"; when the preliminary decision value is between the first and second thresholds, the decision result is "failure"; when the preliminary decision value is between the second and third thresholds, the decision result is "success"; and when the preliminary decision value is higher than the third threshold, the decision result is "major success". The rule-based decision function ultimately outputs an enumerated value representing the above-mentioned levels of decision results.

[0071] In another exemplary implementation, considering that offline role-playing games often retain the ritualistic feel and interactive fun of participants personally throwing physical dice, the server's processing focus in this embodiment can be replaced by calculating and pushing scene-related impact data, rather than directly outputting the final judgment conclusion. In this implementation, after receiving the skill judgment instruction, the server does not actively generate a first random value, but instead extracts and summarizes the environmental correction parameters related to the skill dimension recorded in the current scene node data object. For example, if the current scene is set as a "dim underground tomb," the server reads the "insufficient lighting" tag from the scene node's attribute label and, based on a preset environmental impact mapping table, adds a negative correction value to the "reconnaissance" skill; similarly, if a non-player character in the current scene is in an abnormal state of "being intoxicated," the server adds a negative correction value to the non-player character's resistance to the player's "talking" skill. The server performs algebraic calculations on correction parameters from multiple sources, including scene settings, non-player character states, and temporary status effects carried by the characters themselves, to generate a comprehensive scene impact correction value. This comprehensive scene impact correction value, along with the character skill dimensions and difficulty level modifiers involved in the judgment, is packaged into an interactive result dataset and pushed to the host's terminal. The host can see automatically summarized prompts on their terminal interface, such as "This reconnaissance judgment is reduced by two due to dim lighting" and "The target guard's resistance is reduced by one due to intoxication." The host, combining the actual dice rolls by the players, quickly calculates the final judgment result mentally and announces it verbally, or confirms it through the host's terminal and sends the final result back to the server to trigger subsequent story state machine updates.

[0072] In one embodiment, the interaction type identifier sent by the host terminal is obtained, and a corresponding preset instruction is invoked based on the interaction category indicated by the interaction type identifier, including:

[0073] When the interaction type identifier indicates that the interaction category is combat interaction, obtain the combat start command sent by the host terminal.

[0074] Obtain the current scene node from the story state machine, and determine the scope of participants in the current battle based on the non-player character attribute dataset associated with the current scene node and the game character attribute dataset corresponding to all player terminals that are active online.

[0075] For example, when a combat-triggered event occurs during the game, such as a conflict between a player character and a non-player character that cannot be resolved through non-combat means, or when the story description explicitly states that a pre-set combat encounter has occurred, the host can click a combat initiation control on the host terminal's interface. The host terminal then generates a combat initiation command and sends it to the server. Upon receiving the command, the server retrieves the current scene node from the story state machine maintained in memory. Each scene node data object in the story state machine is associated with a set of non-player character attribute datasets that are active or dormant in the current scene. This method reads the non-player character attribute datasets associated with the current scene node and marks all non-player character data objects as candidate participants in this combat.

[0076] Specifically, the server checks the connection status and session keep-alive signal of each player's terminal to determine all player terminals that are currently online and active. Based on the generated character binding records, the server obtains the game character attribute dataset corresponding to each of these player terminals and marks the game characters in the dataset as candidate participants in this battle. The server determines the scope of participants in the current battle by combining the above two types of candidate participants, ensuring that no character objects participating in the battle are missed or misjudged.

[0077] For each game character participating in the battle, extract the numerical field representing the action priority from the corresponding game character attribute dataset, and encapsulate the game character's character code, character name, and numerical field into a first sorting object, and push the first sorting object into the list container.

[0078] Specifically, after determining the scope of participants, the server performs data extraction and encapsulation operations for each game character within the scope. By traversing each game character within the scope, it extracts a numerical field representing action priority from its corresponding game character attribute dataset. In the module settings of different rule systems, this numerical field may be called "agility value," "reaction value," "first strike bonus," or similar names. In this embodiment, it can be abstracted as a single numerical variable used for sorting calculations. The server simultaneously extracts the game character's character code and character name, and encapsulates the character code, character name, and action priority numerical field into a first sorting object. This creates a key-value pair data entity in the server's memory, with the character code as the unique identifier key and the character name and action priority numerical value as attribute values. The encapsulated first sorting object is pushed into a pre-declared list container, which can be a dynamic array structure or a linked list structure in memory, used to temporarily store all objects to be sorted.

[0079] For each non-player character data object participating in the battle, extract the pre-defined numerical field representing the action priority from the non-player character attribute dataset, and encapsulate the non-player character code, character name, and numerical field of the non-player character data object into a second sorting object, and push the second sorting object into the list container.

[0080] Similarly, the server performs corresponding data extraction and encapsulation operations on each non-player character data object within the scope of the participants. By traversing each non-player character data object within the scope of the participants, it extracts the pre-defined numerical fields representing action priority from the non-player character attribute dataset. The action priority value of a non-player character is usually pre-set by the module designer when writing the module configuration file. Its value reflects the non-player character's reaction speed or combat prowess in the story setting. The server also extracts the non-player character code and character name from the non-player character data object, encapsulates these three pieces of data into a second sorting object, and pushes the second sorting object into the same list container. The first sorting object and the second sorting object are consistent in data structure, both containing at least an code field, a name field, and a numerical field, so that subsequent sorting calculations can uniformly handle player characters and non-player characters without distinguishing their source.

[0081] The pre-defined comparator function is called to sort all sorted objects in the list container. The comparator function sorts the objects in descending order based on the numerical values ​​of the fields representing action priorities, resulting in an ordered list of sorted objects.

[0082] Specifically, the comparator function is a callback function or inline logic block used to define the size relationship between objects. Its core operation rule is to read the numerical fields representing the action priority of the two objects to be compared and return the comparison result according to the numerical relationship. In this embodiment, the comparator function is configured to perform descending sorting, that is, the sorted object with the larger action priority value is arranged first in the sorting result, and the sorted object with the smaller action priority value is arranged last. For example, an efficient sorting algorithm can be used to sort the elements in the list container. This algorithm can be a mature implementation such as quicksort, mergesort, or heapsort. During the sorting process, the comparator function may encounter a situation where two or more sorted objects have the same action priority value. In this case, the comparator function can preset a secondary sorting strategy to break the tie. For example, the secondary sorting strategy can be based on the sorting pairs. The system determines the sorting order by the type field of the object, stipulating that sorted objects of player character type are placed before sorted objects of non-player character type when their values ​​are equal, thus giving player characters priority in the game experience. Another exemplary secondary sorting strategy is to call a pseudo-random number generation function to generate a supplementary random value for each sorted object with equal values, and determine the sorting order based on the size relationship of the supplementary random values, thereby simulating the randomness of resolving a tie by rolling physical dice. Finally, an ordered list of sorted objects is obtained from the list container, and the order of each element in the list corresponds to the order of actions of each party in this battle round.

[0083] An interactive result dataset is generated based on a sorted list of objects. The interactive result dataset includes a structured action order list data constructed from the sorted list of objects.

[0084] Specifically, this method iterates through the list of sorted objects, assigning each object an ascending sequence index number starting from a preset value. It then combines the character code, character name, action priority value, and sequence index number into a list entry. All list entries are arranged in ascending order of their sequence indices to form a structured action sequence list. This structured action sequence list serves as a core component of the interaction result dataset. Furthermore, the dataset may include a battle start indicator, the current round count, and optional battle scene description text. The server then broadcasts this interaction result dataset to the host terminal and all player terminals participating in the battle. Upon receiving the dataset, each terminal parses the structured action sequence list and renders it in its respective battle sequence display area. For example, player terminals can draw the avatar icons and name tags of each participating side from top to bottom according to the list order, and apply a highlighted border or dynamic cursor to the entry corresponding to the current action side to visually indicate which side's turn it is. In addition to displaying the same sequential list, the host terminal also provides a manual intervention control that allows dragging and dropping to adjust the order of list items. This allows the host to temporarily adjust the order of actions according to the actual plot. The adjusted list data will be broadcast again by the server as an updated version to all terminals to maintain the synchronization and consistency of the display across all terminals.

[0085] It's important to note that in traditional offline role-playing games, when the plot reaches a point of conflict, the facilitator needs to temporarily pause the narrative and require all participants to report their character's speed-related attributes one by one. Simultaneously, they must find the corresponding values ​​for all non-player characters involved in the current scene from the module manual, manually copy these values ​​onto paper, and sort them in descending order. The results are then read aloud to all participants sequentially. This process not only disrupts the flow of the plot but is also prone to errors in memorizing values ​​or omissions in sorting, especially when there are many participants, leading to confusion and disputes in subsequent battle rounds. This embodiment, through automatic data collection, encapsulation, and sorting calculations by the server, transforms the above manual operations into a standardized data processing workflow, significantly improving the efficiency and accuracy of the battle round initiation phase.

[0086] In one embodiment, the method also includes a plot progression and multi-terminal synchronization mechanism during scene switching. In traditional offline tabletop role-playing games, after a player character completes the exploration of a scene or triggers a specific plot condition, the host needs to consult the module manual or recall the plot outline to find the corresponding subsequent scene description paragraph. This information is then conveyed to all participants through oral reading or summarization. This not only carries the risk of jumping to the wrong plot branch due to the host's memory lapses, but also, when the new scene description text is long or contains multiple details that require player attention, oral communication is prone to omissions or misunderstandings between different players, thus affecting the consistency of subsequent action decisions. This embodiment transforms the scene switching operation into a server-driven, verifiable, multi-terminal synchronized data update transaction through centralized maintenance of the plot state machine by the server, automatic validity verification of scene jump paths, and structured broadcast distribution of scene description text. Specifically, this embodiment also includes the following steps:

[0087] In response to the scene switching command sent by the host terminal, the legality of the jump path from the current scene node identifier in the scene switching command to the target scene node identifier is verified according to the directed graph structure of scene nodes stored in the plot state machine.

[0088] Specifically, at any point in the game, when the host determines that the game needs to advance to a new scene based on the plot development, the host invokes the scene switching function on the host terminal's interface. The host terminal sends a scene switching command to the server. The data structure of this command carries at least a target scene node identifier. This target scene node identifier is a unique string or numeric code assigned to each scene node in the module configuration file, used to uniquely locate a specific scene node in the plot state machine. After receiving the scene switching command, the target scene node identifier is first parsed from the command. Simultaneously, the server reads the current scene node identifier from the plot state machine maintained in memory. The plot state machine maintains a current scene node pointer representing the current plot position of the game during game initialization and after each scene switch; the value of this pointer is the current scene node identifier. The directed graph structure of the scene nodes is constructed during the parsing of the module configuration file at the beginning of the game. It is stored in the server's memory in the form of an adjacency list or adjacency matrix, recording a list of identifiers of one or more subsequent scene nodes that each scene node can legally jump to. For example, the specific execution process of the legality check is as follows: The server uses the current scene node identifier as an index to search for the set of legal subsequent node identifiers corresponding to the node in the adjacency list or adjacency matrix, and then determines whether the target scene node identifier is included in the set of legal subsequent node identifiers. If the target scene node identifier exists in the set, the jump path is determined to have passed the legality check; if the target scene node identifier does not exist in the set, the jump path is determined to have failed the legality check.

[0089] For example, when a jump path fails the validity check, the server returns a validation failure response to the host's terminal. This response may include a list of valid subsequent nodes for the current scene node and a summary of the corresponding scene name, for the host to refer to and reselect the correct target scene. In another exemplary implementation, the module configuration file may preset some special global jump tags, such as "Return to Previous Scene" or "Jump to Ending Summary Scene." These tags are mapped to special edges in a directed graph structure, allowing jumps from any node. The server individually identifies and allows these special tags during validation.

[0090] When the jump path passes the validity check, the current scene node of the plot state machine is updated to the target scene node identifier, and the scene description text data packet is extracted from the scene node data object corresponding to the target scene node identifier.

[0091] Specifically, after the jump path passes the validity check, this method updates the current scene node of the story state machine to the target scene node identifier. This involves modifying the value of the current scene node pointer stored in memory to point to the node data object corresponding to the new scene, thus migrating the game story's state on the server side to the new scene. The method then extracts the scene description text data packet from the scene node data object corresponding to the target scene node identifier. The scene node data object is a composite data structure built in memory by the server when parsing the module configuration file. The scene description text data packet field stores all descriptive text content that the host should read or display to the players in that scene. This descriptive text content can be plain text or structured text containing rich text tags, such as bolding, paragraph marks, or embedded tags bound to background music switching commands. For example, during the extraction of the scene description text data packet, the server can also perform real-time rendering of dynamic variables based on the global context data of the current game session. For example, the scene description text may contain placeholders such as "the current game time is XX" or "the current weather is XX". The server reads the current virtual game timestamp and weather status variable from the global context data area, replaces the placeholders with specific values ​​or text, and generates the final scene description text data package.

[0092] The scene description text data packet is sent to all online player terminals. The scene description text data packet is used to instruct each player terminal to clear the current story display area and render the scene information corresponding to the target scene node identifier.

[0093] Specifically, since scene transitions signify the overall advancement of the game's plot, all participants need to be aware of the new scene's information. Therefore, a broadcast method is used instead of a targeted push method. After receiving the scene description text data packet, the player's terminal, based on the operation instruction carried in the message header of the data packet, first performs an operation to clear the current plot display area. For example, the plot display area is a text box or view container on the player's terminal user interface specifically used to display the host's narration text, environmental descriptions, and event descriptions. The clearing operation removes all previously displayed historical content from this area. Subsequently, the player's terminal parses the message body of the scene description text data packet and renders the scene description text content contained therein into the cleared plot display area. The rendering process may include font style application, paragraph formatting, and triggering the switching of associated background images or environmental sound effects. If the scene description text data packet carries tags associated with multimedia resources, the player's terminal can also simultaneously request the server to download the corresponding background image or audio file to create an audiovisual environment that matches the atmosphere of the new scene.

[0094] Furthermore, in addition to being sent to the player's terminal, the scene description text data packet is also sent to the host's terminal. After receiving the data packet, the host's terminal displays the complete new scene description text on the story management interface of the host's terminal. It can also simultaneously display the preset hidden information under the scene node, the detailed data cards of non-player characters, and possible story branch options. This auxiliary information, which is only for the host to view, is not included in the broadcast data packet sent to the player's terminal. Thus, while achieving scene synchronization across all terminals, the host's exclusive information permissions are maintained.

[0095] In one embodiment, the method also includes the targeted distribution and ownership record management functions for virtual items. In traditional offline role-playing games, when the host bestows an item upon a player's character during the storyline, it is usually announced verbally. The player then needs to record the item's name and brief attributes in the blank space on their character card or on a sticky note. As the game progresses for a considerable time, players often forget that they have obtained a certain item or lose the sticky note recording the item, making it impossible to trace key storyline items when needed later. Furthermore, if the host wants to show players the beautiful illustrations or detailed background descriptions of items, they usually need to temporarily search for images on their mobile device or consult the setting book, interrupting the coherent narrative. This embodiment solves the above problems by using a server-side structured storage of item data, persistent recording of ownership relationships, and a targeted push mechanism to transform item distribution into a complete data flow and interface update process. This embodiment also includes the following steps:

[0096] In response to the item distribution command sent by the host's terminal, the item code of the item to be distributed and the terminal identification code of the target player's terminal are parsed from the item distribution command.

[0097] Specifically, the server continuously monitors the instruction transmission channel of the host's terminal. When it captures an item distribution instruction with an item distribution feature, it immediately initiates a response process. The item distribution instruction is a control command generated by the host based on the needs of the tabletop role-playing game's storyline. The host inputs the information of the item to be distributed through a preset operation interface on the host's terminal, and the target player makes a selection. The core data it carries includes the unique item code of the item to be distributed (this code is a unique identifier assigned by the server to all preset items and is pre-stored in the item definition table) and the terminal identification code of the target player's terminal (this identification code is a unique device identifier assigned when the player's terminal connects to the server and is used to accurately locate the player's identity). This technical solution extracts the above two types of key data through a dedicated instruction parsing algorithm to ensure that the item can be accurately associated with the target item resource and the target recipient, avoiding problems such as incorrect distribution targets or item information mismatch.

[0098] Based on the item code of the item to be distributed, the corresponding item attribute data structure is retrieved from the item definition table. The item attribute data structure contains at least the item name, item description text, and static resource locator of the item image.

[0099] Specifically, based on the parsed item codes to be distributed, the system accesses a pre-built item definition table on the server. This item definition table is a structured database constructed by the server during system initialization by importing item resource data from module configuration files and general item data preset by the administrator. It uses a key-value pair storage method of "item code - attribute structure" to enable fast retrieval of item information. This technical solution retrieves the corresponding item attribute data structure through precise matching query of item codes. This structure is a standardized encapsulation of the core information of the item, including at least the item name, item description text for describing the item's function and background story, and a static resource locator pointing to the item image file in the server's static resource storage node. The purpose of obtaining this structure is to provide complete and standardized data support for the subsequent display of item information on player terminals, ensuring that the display of item information on different terminals remains consistent.

[0100] Establish a link between the item code of the item to be distributed and the game character attribute dataset corresponding to the target player's terminal, and persistently store the link in the player's inventory data table.

[0101] Specifically, based on the target player's terminal identification code, the corresponding game character attribute dataset (the core data of the character uploaded to the server after the player completes the vehicle card and passes the review) is queried in the character binding record database. A relationship is created between the code of the item to be distributed and the game character attribute dataset, forming a related record containing the character code, terminal identification code, item code, distribution timestamp, and distribution trigger plot node. The core purpose of this step is to establish the ownership binding relationship between the item and the character, clarifying the ownership of the item. Then, through data persistence technology, this related record is written to the player's backpack data table (this data table is used to store the item holding information of all player characters, supporting real-time operations of adding, deleting, modifying, and querying), realizing the permanent storage of the item ownership relationship. At the same time, the version number of the player's backpack data is updated synchronously, providing a data traceability basis for subsequent item interaction and status query, and ensuring the consistency and traceability of item data.

[0102] Generate a backpack update push message containing item attribute data structure, and send the backpack update push message to the target player's terminal. The backpack update push message is used to update the display status of the target player's local backpack interface.

[0103] Specifically, the retrieved item attribute data structure is integrated with core information (such as distribution time and associated character name) from related records. This information is then encapsulated into a standardized message format that the terminal can parse to generate a backpack update push message. This message contains a built-in terminal interface update trigger command. This technical solution encrypts and sends this message to the target player's terminal via a targeted communication link. The purpose of this step is to synchronize the item distribution results to the player's terminal in real time. After receiving the message, the player's terminal automatically calls the local interface rendering module according to the built-in command, clears the cached data of the backpack interface, loads the new item information, obtains and displays the item image through a static resource locator, and simultaneously displays the item name and description text. This allows players to immediately know the item distribution results and view item details. This process achieves a complete closed loop for item distribution, from server data processing to terminal visualization, improving the efficiency of item distribution and ensuring a better information acquisition experience for players through standardized data display. It also enhances the immersiveness and smoothness of item interaction during role-playing games.

[0104] In one embodiment, the method also realizes the transfer and synchronization of ownership of virtual items between players. In offline role-playing games, players frequently transfer, gift, lend, or exchange items. For example, a character might give a picked-up weapon to a teammate who is more skilled at using it, or share healing potions with an injured companion. Traditionally, this is accomplished only through verbal declarations between players and manual alterations on paper character cards. This not only easily leads to disputes over item ownership due to asynchronous records, but also makes it difficult to verify if one party forgets the transfer in subsequent games. In this embodiment, after establishing the association record between the item code to be distributed and the game character attribute dataset corresponding to the target player's terminal, the method further includes:

[0105] Obtain the item transfer request instruction sent by the first player's terminal, and parse the item code of the item to be transferred and the terminal identification code of the target second player's terminal from the item transfer request instruction.

[0106] Specifically, after establishing the association record between the items to be distributed and the target player character, the system continuously monitors the command transmission channels of all online player terminals. The item transfer request command sent by the first player terminal is generated after the player initiates an item transfer operation on their own terminal's inventory interface based on the needs of the tabletop role-playing storyline or the cooperation agreement between players. This command carries the item code of the item to be transferred (i.e., the unique identifier of the item to be transferred in the server, derived from the item data already bound in the player's inventory) and the terminal identification code of the target second player terminal (i.e., the unique device identifier corresponding to the player terminal receiving the item, generated by the first player after selecting the target player through the terminal interface). This technical solution extracts the above key data through the command parsing module. The core purpose is to clarify the initiator, target item, and receiver of the item transfer, providing a basis for subsequent transfer legality verification and data updates.

[0107] The player's inventory data table is queried based on the item code of the item to be transferred to obtain the current associated character code of the item to be transferred, and it is verified whether the current associated character code matches the character code in the game character attribute dataset corresponding to the first player's terminal.

[0108] Specifically, based on the parsed item code to be transferred, the system accesses the player inventory data table (created during system initialization to persistently store item ownership association records for all characters; each record contains core fields such as character code, item code, and holding time) in the server. The system accurately queries the current associated character code corresponding to the item to be transferred using the item code. This code is the core identifier of the current ownership of the item to be transferred. Then, the current associated character code is compared with the character code in the game character attribute dataset corresponding to the first player's terminal (i.e., the unique identifier of the character initiating the item transfer, derived from the character binding record). The core purpose of this verification step is to confirm whether the first player is the legitimate owner of the item to be transferred, preventing the illegal transfer of other players' items and ensuring the security and accuracy of item ownership.

[0109] Once the verification is successful, the associated character code of the item to be transferred in the player's inventory data table will be changed from the character code corresponding to the first player's terminal to the character code corresponding to the second player's terminal.

[0110] Specifically, once the above consistency check passes, confirming that the first player has the transfer authority for the item to be transferred, this technical solution initiates the update process of the player's inventory data table. Through the data writing interface, the associated character code of the item to be transferred is changed from the original character code corresponding to the first player's terminal to the character code corresponding to the second player's terminal (this code is obtained by querying the character binding record through the terminal identification code of the second player's terminal). At the same time, the modification timestamp and operation log of the item association record are updated (recording the transfer initiator, recipient, and transfer time). Through server-side data updates, the legal transfer of item ownership is completed, ensuring that the item ownership data in the server is consistent with the actual transfer situation, and providing accurate data support for subsequent item queries and further interactions.

[0111] A message indicating the removal of an item is generated and sent to the first player's terminal. At the same time, a message indicating the addition of an item is generated, containing the attribute data structure of the item to be transferred, and sent to the second player's terminal.

[0112] Specifically, after updating the player's inventory data table, an item removal message is immediately generated. This message contains the code and name of the item to be transferred, informing the first player's terminal that the item transfer was successful and triggering a local interface update. Simultaneously, based on the code of the item to be transferred, the corresponding attribute data structure is retrieved from the item definition table and encapsulated to generate an item addition message. This message contains complete display information of the item (name, description, image static resource locator, etc.). Then, the item removal message is sent to the first player's terminal and the item addition message is sent to the second player's terminal via a targeted communication link. Upon receiving the message, the first player's terminal automatically hides the item in its inventory interface, while the second player's terminal adds the item to its inventory interface. The entire process achieves a complete closed loop for item transfer, from request initiation, legality verification, data update to terminal synchronization. This ensures the security and standardization of item transfer while improving the smoothness and user experience of item interaction between players during the tabletop role-playing game through real-time terminal message synchronization.

[0113] In summary, the game data processing method based on multi-terminal real-time interaction provided in this application establishes communication connections between the server, the host terminal, and the player terminal. It uses the structured parsing of module configuration files to generate and initialize the story state machine. It achieves precise character binding by establishing a mapping relationship between player terminal identification codes and character attribute datasets. It responds to the turn start signal and calls corresponding preset instructions based on the interaction type identifier. For non-combat interactions, it employs cryptographically secure random number generation using a multi-source seed hybrid method and quantification formulas to calculate skill judgment results. For combat interactions, it automatically filters participants and sorts them based on action priority values. It also supports scene-based processing. By switching between legality verification and multi-terminal scene information synchronization, targeted item distribution and legal transfer between players, and generating review prompts through multi-dimensional compatibility metric calculation and attribute conflict detection during character binding, a standardized data processing system covering the entire tabletop role-playing game process has been formed. This system enables structured management of module data, compliance verification of character data, automated calculation of interaction processes, real-time synchronization of information across multiple terminals, and standardized control of item circulation. It effectively improves the efficiency and accuracy of data processing in tabletop role-playing games, ensures the fairness and traceability of interaction results, simplifies the global control process for the host, and optimizes the player participation experience and the smoothness of character interaction.

[0114] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0115] Based on the same inventive concept, this application also provides a multi-terminal real-time interaction game data processing system 10 for implementing the above-mentioned multi-terminal real-time interaction game data processing method. The solution provided by this system is similar to the implementation scheme described in the above method. Therefore, the specific limitations of one or more embodiments of the multi-terminal real-time interaction game data processing system 10 provided below can be found in the limitations of the multi-terminal real-time interaction game data processing method above, and will not be repeated here.

[0116] In one exemplary embodiment, such as Figure 2As shown, a game data processing system 10 based on multi-terminal real-time interaction is provided to implement the game data processing method based on multi-terminal real-time interaction as described above. The system includes:

[0117] The module parsing module 11 is used to perform structured parsing on the obtained module configuration file, generate a story state machine including scene node data objects and non-player character attribute datasets, and initialize the story state machine to the starting scene node;

[0118] The character binding module 12 is used to obtain the game character attribute dataset submitted by the player's terminal, establish a mapping relationship between the player's terminal identification code and the game character attribute dataset, and generate a character binding record;

[0119] The instruction routing module 13 is used to obtain the interaction type identifier sent by the host terminal and call the corresponding preset instruction based on the interaction category indicated by the interaction type identifier.

[0120] The interactive calculation module 14 is used to perform interactive calculations on the game character attribute dataset and / or the non-player character attribute dataset based on preset instructions to obtain an interactive result dataset; wherein, the interactive result dataset is used to instruct the player terminal to perform corresponding actions and / or update the plot state machine.

[0121] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of a game data processing method based on multi-terminal real-time interaction as described above.

[0122] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0123] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0124] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A game data processing method based on real-time interaction across multiple terminals, characterized in that, Applied to a server, the server being communicatively connected to multiple terminals, including a host terminal and player terminals, the method includes: In response to the game start signal, the obtained module configuration file is parsed in a structured manner to generate a story state machine including scene node data objects and non-player character attribute datasets, and the story state machine is initialized to the starting scene node; Obtain the game character attribute dataset submitted by the player's terminal, establish a mapping relationship between the player's terminal identification code and the game character attribute dataset, and generate a character binding record; In response to the round start signal, the system obtains the interaction type identifier sent by the host terminal and invokes the corresponding preset instruction based on the interaction type indicated by the interaction type identifier. Based on the preset instructions, interactive operations are performed on the game character attribute dataset and / or the non-player character attribute dataset to obtain an interactive result dataset; wherein, the interactive result dataset is used to instruct the player terminal to perform corresponding actions and / or update the story state machine.

2. The method according to claim 1, characterized in that, The process of obtaining the game character attribute dataset submitted by the player's terminal, establishing a mapping relationship between the player's terminal identification code and the game character attribute dataset, and generating a character binding record includes: Extract the preset world view description text, era background tags, occupation rarity constraint parameters, and attribute mutual exclusion rule set from the module configuration file; Input the character identity description field in the game character attribute dataset and the world view description text into the semantic consistency evaluation model, and calculate the first compatibility score between the character identity description field and the world view description text; Input the character identity description field and the era background label into the semantic consistency evaluation model to calculate the second compatibility score between the character identity description field and the era background label; The values ​​of each attribute field in the game character attribute dataset are compared with the profession rarity constraint parameters to generate a third compatibility score. The third compatibility score is used to characterize whether the overall strength of the game character attribute dataset exceeds the character strength range allowed by the module configuration file. The game character attribute dataset inputs the character identity description field and the numerical values ​​of each attribute field into the attribute conflict detection rule engine to identify whether there is a combination of attribute values ​​that conflict with the character identity description field, and generates a conflict detection result containing the conflict attribute field identifier and the conflict reason description when a conflict is detected. Based on the first compatibility score, the second compatibility score, the third compatibility score, and the conflict detection result, an audit prompt dataset is generated. The audit prompt dataset includes warning entries triggered when each compatibility score is lower than the corresponding preset threshold, as well as all conflict description entries recorded in the conflict detection result. The review prompt dataset and the game character attribute dataset are sent to the host terminal. The review prompt dataset is used to display warning entries on the host terminal indicating compatibility issues or attribute conflicts.

3. The method according to claim 1, characterized in that, The step of obtaining the interaction type identifier sent by the host terminal and invoking the corresponding preset instruction based on the interaction type category indicated by the interaction type identifier includes: When the interaction type identifier indicates that the interaction category is non-combat interaction, the skill judgment instruction sent by the host terminal is obtained. The skill judgment instruction includes the terminal identification code of the target player's terminal, the skill dimension identifier to be judged, and the difficulty level modifier. Based on the terminal identification code of the target player's terminal, the corresponding game character attribute dataset is searched in the character binding record, and the skill dimension value corresponding to the skill dimension identifier is extracted from the game character attribute dataset. Using the current system timestamp, server hardware entropy source value, and current session identifier as seed input, a first random value is generated through a cryptographically secure pseudo-random number generation function. The skill dimension value and the first random value are input into a preset rule judgment function. The judgment result enumeration value is calculated by the rule judgment function, and the interaction result dataset is generated based on the judgment result enumeration value.

4. The method according to claim 1, characterized in that, The step of obtaining the interaction type identifier sent by the host terminal and invoking the corresponding preset instruction based on the interaction type category indicated by the interaction type identifier includes: When the interaction type identifier indicates that the interaction category is combat interaction, the combat start command sent by the host terminal is obtained; Obtain the current scene node from the story state machine, and determine the scope of participants in the current battle based on the non-player character attribute dataset associated with the current scene node and the game character attribute dataset corresponding to all player terminals that are in an online active state. For each game character participating in the battle, extract the numerical field representing the action priority from the corresponding game character attribute dataset, and encapsulate the game character's character code, character name, and the numerical field into a first sorting object, and push the first sorting object into a list container. For each non-player character data object participating in the battle, extract its preset numerical field representing action priority from the non-player character attribute dataset, and encapsulate the non-player character code, character name and the numerical field of the non-player character data object into a second sorting object, and push the second sorting object into the list container; A pre-defined comparator function is invoked to perform sorting calculations on all sorted objects in the list container. The comparator function sorts the objects in descending order based on the numerical values ​​of the fields representing action priorities in each sorted object, resulting in an ordered list of sorted objects. The interaction result dataset is generated based on the sorted object list, and the interaction result dataset includes a structured action order list data constructed based on the sorted object list.

5. The method according to claim 1, characterized in that, The method further includes: In response to the scene switching command sent by the host terminal, the legality of the jump path from the current scene node identifier in the scene switching command to the target scene node identifier is verified according to the directed graph structure of scene nodes stored in the plot state machine. When the jump path passes the validity check, the current scene node of the plot state machine is updated to the target scene node identifier, and the scene description text data packet is extracted from the scene node data object corresponding to the target scene node identifier. The scene description text data packet is sent to all online player terminals. The scene description text data packet is used to instruct each player terminal to clear the current story display area and render the scene information corresponding to the target scene node identifier.

6. The method according to claim 1, characterized in that, The method further includes: In response to the prop distribution instruction sent by the host terminal, the prop code of the prop to be distributed and the terminal identification code of the target player's terminal are parsed from the prop distribution instruction. Based on the item code of the item to be distributed, the corresponding item attribute data structure is queried from the item definition table. The item attribute data structure includes at least the item name, item description text, and static resource locator of the item image. Establish an association record between the item code of the item to be distributed and the game character attribute dataset corresponding to the target player's terminal, and persistently store the association record in the player's inventory data table; Generate a backpack update push message containing the item attribute data structure, and send the backpack update push message to the target player's terminal. The backpack update push message is used to update the display status of the target player's local backpack interface.

7. The method according to claim 6, characterized in that, After establishing the association record between the item code of the item to be distributed and the game character attribute dataset corresponding to the target player's terminal, the method further includes: Obtain the item transfer request instruction sent by the first player's terminal, and parse the item code of the item to be transferred and the terminal identification code of the target second player's terminal from the item transfer request instruction; The player's inventory data table is queried according to the item code of the item to be transferred to obtain the current associated character code of the item to be transferred, and it is verified whether the current associated character code matches the character code of the game character attribute dataset corresponding to the first player's terminal. Once the verification is successful, the associated character code of the item to be transferred in the player's backpack data table will be changed from the character code corresponding to the first player terminal to the character code corresponding to the second player terminal. A message to remove an item is generated and sent to the first player's terminal. At the same time, a message to add an item containing the attribute data structure of the item to be transferred is generated and sent to the second player's terminal.

8. A game data processing system based on multi-terminal real-time interaction, used to implement the method according to any one of claims 1 to 7, characterized in that, The system includes: The module parsing module is used to perform structured parsing on the obtained module configuration file, generate a story state machine including scene node data objects and non-player character attribute datasets, and initialize the story state machine to the starting scene node; The character binding module is used to obtain the game character attribute dataset submitted by the player's terminal, establish a mapping relationship between the terminal identification code of the player's terminal and the game character attribute dataset, and generate a character binding record; The instruction routing module is used to obtain the interaction type identifier sent by the host terminal and call the corresponding preset instruction based on the interaction type category indicated by the interaction type identifier. An interactive calculation module is used to perform interactive calculations on the game character attribute dataset and / or the non-player character attribute dataset based on the preset instructions to obtain an interactive result dataset; wherein, the interactive result dataset is used to instruct the player terminal to perform corresponding actions and / or update the story state machine.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images