Metacosm player behavior off-line hosting method and system
By constructing predefined behavior tree and decision tree models and training online data from real players, virtual characters can operate autonomously in the metaverse, solving the problem of the lack of dynamic response in virtual character behavior and improving the realism and stickiness of the game experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- XIAMEN UNIV
- Filing Date
- 2026-04-15
- Publication Date
- 2026-05-12
AI Technical Summary
In existing metaverse games, when real players go offline, the virtual characters lack dynamic responses, resulting in a dull gaming experience and poor player engagement.
By constructing a predefined behavior tree and using decision tree models to train online data from real players, a player decision-making behavior model is generated. The virtual character then dynamically reacts to environmental changes and plot developments, achieving autonomous operation.
It enhances the engagement of real players with the metaverse game, allows the game's storyline to progress naturally, and improves the accuracy and realism of virtual character behavior.
Smart Images

Figure CN122020409A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method and system for offline hosting of metaverse player behavior. Background Technology
[0002] In the related technologies of metaverse games, after a real player goes offline, the behavior of a virtual character (i.e., a Non-Player Character, or NPC) is determined by a preset strategy to simulate the behavior of a real player, thus achieving game hosting for the real player.
[0003] Currently, some metaverse games are experienced by real players using fragmented time. Because the related technology uses preset strategies to determine behavior, the decision-making is rigid and cannot be changed according to external factors such as changes in the surrounding environment or plot development. This lack of realism makes it easy for real players to feel bored and uninterested after experiencing the game, resulting in poor player engagement with metaverse games. Summary of the Invention
[0004] This application provides a method and system for offline hosting of metaverse player behavior, which enables virtual characters to make dynamic reactions based on external factors such as changes in the surrounding environment or the development of the plot, thereby enhancing the stickiness of real players to metaverse games.
[0005] The first aspect of this application provides a metaverse player behavior offline management method, wherein the predefined behavior tree includes a state machine, decision nodes, and operation nodes, and the method includes: Retrieve online data of real players from a predefined behavior tree. The online data of real players includes... The decision node stores environmental variables, external conditions, decision behaviors, and a unique ID; Using environmental variables and external conditions as feature datasets and decision-making behavior as label datasets, a sample dataset is generated, where each sample data corresponds to a unique ID. The sample dataset is input into the decision tree model, which includes a training method module and a tree structure module. The training method module calculates the information entropy or information entropy gain of each feature in the feature dataset based on the recursive splitting algorithm. Based on the information entropy or information entropy gain, the splitting features are determined and corresponding splitting conditions are generated. The sample dataset is recursively divided into subsets according to the splitting conditions until the splitting stopping condition is met. The node data generated during the splitting process is stored in the tree structure module to construct the player decision behavior model. During the model prediction phase, the state machine responds to offline messages from real players in the metaverse and sends notifications to the decision nodes. After receiving the notification, the decision node obtains the current environmental variables and external conditions through the injected data collection interface instance and sends them to the player decision behavior model. The player decision behavior model outputs the predicted behavior and returns it to the decision node of the behavior tree. The decision node selects the operation node corresponding to the predicted behavior based on a pre-defined mapping table of behavior and operation nodes. In response to the selection of decision nodes, operation nodes control the virtual characters in the metaverse to perform behaviors in order to complete the offline hosting of real player behaviors.
[0006] In some embodiments, the definition of the predefined behavior tree includes the definition of the training data collection phase, which includes: Define a state machine to control the state transitions of real players and send notifications of state transitions to decision nodes; Define decision nodes; upon receiving notifications, obtain environment variables, external conditions, and commands from real players through the injected data collection interface instance; and The function invokes an externally passed conditional callback function, performs logical checks on the data obtained from the data collection interface instance based on the business rules it carries, and determines whether the obtained data meets the conditions for triggering the specified behavior; and Data is collected synchronously from training data collection objects and stored, and decision-making behaviors and unique IDs are generated and stored based on logical judgments; and When the conditions for triggering the execution of the specified behavior are met, the operation node is selected according to the preset behavior-operation node mapping table and a unique ID is sent to the operation node; Define operation nodes, respond to the selection of decision nodes, control the execution of virtual characters in the metaverse, and establish and store the association record between the behavior and the unique ID.
[0007] In some embodiments, decision behavior, environmental variables, external conditions, and unique IDs are stored in a local temporary JSON file for later retrieval during decision tree model training.
[0008] In some embodiments, the process of defining a decision tree model includes: Define the decision tree model class structure, which includes a tree structure module, a feature list module, a training method module, and a prediction method module; The feature list module is used to extract and store the feature names and values of each feature in the feature dataset. The prediction method module is used to obtain the current environmental variables and external conditions of the metaverse and call the tree traversal algorithm to calculate the prediction behavior during the model prediction stage.
[0009] In some embodiments, the information entropy or information entropy gain of each feature in the feature dataset is calculated based on a recursive splitting algorithm. Splitting features are determined based on the information entropy or information entropy gain, and corresponding splitting conditions are generated. The sample dataset is recursively divided into subsets according to the splitting conditions until the splitting stopping condition is met, including: a. Extract the feature value of each feature in the feature dataset, calculate the information entropy of each feature in the current node based on the feature value, or extract the label value of the label category in the label dataset under the condition of the features of the feature dataset, and calculate the information entropy gain of each feature in the current node based on the label value; b. Determine the splitting feature of the current node based on the information entropy or information entropy gain of each feature, and generate splitting conditions based on the splitting feature; c. Divide the sample dataset into two subsets according to the splitting condition, repeat steps a to c until the splitting stopping condition is met, generate leaf nodes, and complete the recursive construction of branch directions that meet or do not meet the splitting condition.
[0010] In some embodiments, the node data generated during the splitting process is stored in a tree structure module to construct a player decision-making behavior model, including: The information entropy or information entropy gain of the features in the splitting process, the splitting conditions, and the branching direction are stored in the corresponding nodes of the tree structure module to construct the player decision-making behavior model.
[0011] In some embodiments, determining the splitting feature of the current node based on the information entropy or information entropy gain of each feature includes: The feature with the lowest information entropy or the highest information entropy gain is identified as the splitting feature of the current node; or Each feature is used as a virtual splitting feature to perform virtual splitting, and left and right child nodes are generated; Calculate the information entropy gain of all possible splitting methods for the left and right child nodes respectively, and determine the maximum information entropy gain as the potential gain for the left and right nodes respectively. The left potential gain, right potential gain, and information entropy gain are input into a preset global evaluation function to obtain the global score of each feature, and the feature with the highest score is determined as the splitting feature of the current node.
[0012] In some embodiments, the method further includes: The new environmental variables and external conditions are input into the player's decision-making behavior model to determine the target leaf node into which the new environmental variables and external conditions fall. Determine whether the Gini impurity of the target leaf node has changed; If no changes occur, no partial reconstruction of the player decision-making behavior model will be performed; If a change occurs, the target leaf node is determined as the new current node. The sample dataset falling into the target leaf node, along with the new environmental variables and external conditions, are used as training data. Splitting begins from the new current node until the splitting stop condition is met, thus completing the local reconstruction of the player's decision-making behavior model.
[0013] In some embodiments, the splitting stop condition is: during the splitting process, the information entropy gain of the current node after splitting is lower than a preset gain value.
[0014] The second aspect of this application provides a metaverse player behavior offline hosting system, the system including a server and a client; The server retrieves online data of real players from a predefined behavior tree. This online data includes environmental variables, external conditions, decision-making behaviors, and unique IDs stored in the decision nodes; and... Using environmental variables and external conditions as feature datasets and decision-making behaviors as label datasets, a sample dataset is generated, where each sample data corresponds to a unique ID; and The sample dataset is input into the decision tree model, which includes a training method module and a tree structure module. The training method module calculates the information entropy or information entropy gain of each feature in the feature dataset based on a recursive splitting algorithm. Based on the information entropy or information entropy gain, it determines the splitting features and generates corresponding splitting conditions. The sample dataset is recursively divided into subsets according to the splitting conditions until the splitting stopping condition is met. The node data generated during the splitting process is stored in the tree structure module, thus constructing the player's decision behavior model. During the model prediction phase, the state machine responds to offline messages from real players in the metaverse, sending notifications to the decision nodes; and After receiving the notification, the decision node obtains the current environmental variables and external conditions through the injected data collection interface instance and sends them to the player decision behavior model. The player decision behavior model outputs the predicted behavior and returns it to the decision node of the behavior tree; and The decision node selects the operation node corresponding to the predicted behavior based on a pre-defined mapping table of behavior and operation nodes. The client responds to the selection of decision nodes, and the operation nodes control the virtual characters in the metaverse to perform behaviors, thereby completing the offline hosting of real player behaviors. Understandably, the offline hosting method and system for metaverse player behavior provided in this application, through the online data of real players stored in a predefined behavior tree, provides rich training samples for the training of the decision tree model, improving the accuracy of the decision behavior model of the player decision behavior model built based on the decision tree model. Compared with the preset strategy determining behavior, using the player decision behavior model to input the current environmental variables and external conditions of the metaverse and output predicted behavior to determine the behavior of virtual characters, allows virtual characters to make dynamic reactions based on external factors such as changes in the surrounding environment or the development of the plot, enabling autonomous operation in the metaverse like real players, allowing the game plot to advance naturally, thereby enhancing the stickiness of real players to the metaverse game. Attached Figure Description
[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0016] Figure 1 This is a schematic diagram of the structure of the Metaverse Real Player Behavior Offline Hosting System provided in an embodiment of this application; Figure 2 A flowchart illustrating the offline hosting method for real-person player behavior in the metaverse provided in this application embodiment; Figure 3 A schematic diagram illustrating an application scenario of the Metaverse Real-Person Player Behavior Offline Hosting Method provided in this application embodiment; Figure 4 This is a schematic diagram illustrating another application scenario of the Metaverse Real-Person Player Behavior Offline Hosting Method provided in the embodiments of this application; Figure 5 A flowchart illustrating the offline hosting method for real-person player behavior in the metaverse provided in this application embodiment; Figure 6 This is a schematic diagram of the decision tree model training process provided in an embodiment of this application.
[0017] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0018] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.
[0019] The terms “first”, “second”, etc. used in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.
[0020] The relevant technologies will be further elaborated below.
[0021] After users log off across multiple platforms (PC, mobile, web, mini-programs, etc.), player data is managed by NPCs. AI utilizes large models to determine the behavior of AI players. Currently, player engagement in most cultural and tourism metaverses is poor; after the experience, players often feel bored and disengaged, and users only engage in the activity during fragmented time. With AI-managed systems, the AI autonomously determines its behavior within the metaverse, performing actions similar to humans. This can be reflected in business needs, such as automatically watering and fertilizing plants and harvesting fruit, providing players with a sense of accomplishment. Players can log in at any time to check their achievements, increasing the connection between players and the metaverse and enriching the content for the intelligent islanders. Currently, most AI-managed systems on the market are strategy-based, not truly AI, randomly executing specific actions.
[0022] The technical solution of this application and how the technical solution of this application solves the technical problem are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.
[0023] Please see Figure 1 , Figure 1 This application provides a schematic diagram of the structure of a metaverse player behavior offline hosting system 100, which includes a server 10 and a client 20. The logic processing modules for the player decision behavior model, the state machine of the predefined behavior tree, decision nodes, and operation nodes are deployed on the server 10, and the execution modules for the operation nodes of the behavior tree are deployed on the client 20. The metaverse player behavior offline hosting method provided in this application is applied to the metaverse player behavior offline hosting system 100.
[0024] Please see Figures 1 to 3 , Figure 2 This is a flowchart illustrating the offline hosting method for metaverse player behavior provided in this application. The executing entity of this offline hosting method can be an offline hosting system. Steps S210 to S250 are executed on the server side, and step S260 is executed on the client side. Figure 2 As shown, this offline hosting method may include the following steps: Step S210: Obtain the online data of real players in the predefined behavior tree. The online data of real players includes: environmental variables, external conditions, decision behaviors, and unique IDs stored in the decision node.
[0025] Specifically, environmental variables describe the objective background state of the metaverse, including timestamps, in-game time, location information (floor, room, street, etc.), item information (clothing, props, etc.), and character information (gender, identity, attire, social network, etc.). These environmental variables provide the overall context in which behavior occurs. External conditions specifically refer to those immediate, dynamic variables that can directly trigger or change decision-making behavior, mainly referring to state IDs (such as internal character states like hunger, fatigue, and busyness). Decision-making behavior includes actions such as entering a house to avoid rain, crouching, and standing up.
[0026] After obtaining the environmental variables, external conditions, decision-making behavior, and unique ID, the acquired data can be preprocessed. Preprocessing includes the following steps: A. Loading data: Convert the data into a dictionary list format, which is easy to manipulate in Python.
[0027] B. Data Cleaning: Check the data for missing or outlier values. Missing data may need to be filled (e.g., using the mean, median, or previous value), while outliers need to be excluded or corrected. If non-numerical data is present, it also needs to be coded.
[0028] C. Data Format Conversion: Since most machine learning libraries in Python (such as Scikit-learn) require numerical matrices as input, it is necessary to convert data in dictionary list format to a suitable numerical array or data frame format.
[0029] D. Standardization / Normalization: Standardize or normalize the data. Although decision trees do not depend on the scale of features, this step can be useful in some cases to improve overall performance or address certain specific problems. E. Feature selection: Correlation analysis or other statistical methods can be used to select the most relevant features from the data to avoid redundant data and improve model performance.
[0030] F. Integrated Feature and Result Processing: This approach combines feature and label datasets for joint processing, simplifying the data loading and processing workflow. Data cleaning, transformation, and matching are completed in a single operation.
[0031] G. Flexible Data Structures and Automated Preprocessing: Use data dictionaries or similar flexible structures to facilitate subsequent feature extraction, combination, and processing. Reduce manual intervention by writing automated scripts to perform preprocessing during data loading.
[0032] H. Intelligent Feature Selection: Select the most representative features through intelligent algorithms (such as feature importance assessment), reduce unnecessary feature inputs, and optimize the model training process.
[0033] Understandably, traditional decision tree training methods typically involve step-by-step data processing, with each step relatively independent. Feature and label datasets are processed separately, often requiring multiple data loading and transformation operations. They lack flexible data structures, with data often existing in tabular form, making direct manipulation inflexible, especially for data preprocessing, transformation, and feature extraction, necessitating frequent calls to external tools or libraries. Since it involves inputting the entire dataset into the model, traditional training methods typically input all data directly into the decision tree model without fine-grained feature selection, easily leading to high model complexity and low efficiency. This application, however, preprocesses the data through steps A to H, reducing unnecessary manual operations and making the feature selection, data preprocessing, and model training processes smoother and more efficient.
[0034] Step S220: Using environmental variables and external conditions as feature datasets and decision behavior as label datasets, generate a sample dataset, where each sample data corresponds to a unique ID. Input the sample dataset into the decision tree model. The decision tree model includes a training method module and a tree structure module. The training method module calculates the information entropy or information entropy gain of each feature in the feature dataset based on a recursive splitting algorithm. Based on the information entropy or information entropy gain, determine the splitting features and generate corresponding splitting conditions. Based on the splitting conditions, recursively divide the sample dataset into subsets until the splitting stopping condition is met. Store the node data generated during the splitting process in the tree structure module to construct the player decision behavior model.
[0035] Specifically, decision trees are the base learners in random forests.
[0036] Step S230: During the model prediction phase, the state machine responds to the offline messages from real players in the metaverse and sends notifications to the decision nodes.
[0037] Specifically, such as Figure 3 As shown, a behavior tree is a computational model used to implement complex dynamic decision-making and control flow. A behavior tree consists of a state machine, decision nodes, and operation nodes.
[0038] Step S240: After receiving the notification, the decision node obtains the current environmental variables and external conditions through the injected data collection interface instance and sends them to the player decision behavior model. The player decision behavior model outputs the predicted behavior and returns it to the decision node of the behavior tree.
[0039] Specifically, the predefined behavior tree also includes a DataCollectInterface instance, which is used for the behavior tree to communicate with the outside world.
[0040] Step S250: The decision node selects the operation node corresponding to the predicted behavior according to the preset behavior-operation node mapping table.
[0041] Specifically, the behavior tree has multiple operation nodes, each performing a specific behavior. For example, the behavior-operation node mapping table includes the following: The action "go indoors to avoid the rain" corresponds to operation node A; The action "watering" corresponds to operation node B; Behavior "Dialogue" → Corresponding operation node C.
[0042] Step S260: In response to the selection of the decision node, the operation node controls the virtual character in the metaverse to perform behavior in order to complete the offline hosting of the behavior of the real-person virtual character.
[0043] Understandably, in the above technical solution, the predefined behavior tree can store online data of real players during operation. This online data provides rich training samples for the decision tree model, improving the accuracy of the player decision behavior model built upon it. Compared to pre-defined strategies determining behavior, using a player decision behavior model to input the current environmental variables and external conditions of the metaverse and output predicted behavior to determine the behavior of virtual characters allows them to dynamically react to changes in the surrounding environment or plot developments, enabling autonomous operation within the metaverse like real players. This allows the game's plot to progress naturally, thereby enhancing real players' engagement with the metaverse game.
[0044] In some embodiments, such as Figures 4 to 5 As shown, the behavior tree is defined on the server side using C++ code, including defining the role of the behavior tree in the training data collection phase and the player decision behavior model prediction phase. The process of defining the behavior tree includes the following steps: Step S110: Define a state machine to control the state switching of real players and send notifications of state switching to decision nodes during the training data collection phase; and to control the state switching of behavior and send notifications of state switching to decision nodes during the player decision behavior model prediction phase.
[0045] Specifically, the state machine is defined to play the role of trigger and recorder during the training data collection phase. For example, when a real player switches from "standing" to "walking", the state machine immediately sends a notification to the decision node.
[0046] During the model prediction phase, the state machine acts as a loop initiator. For example, when the operation node reports "watering behavior completed", the state machine will switch its role from "working" back to "idle" and actively notify the decision node: "The state is now idle, please decide what to do next."
[0047] Step S120: Define a decision node, which, during the training data collection phase, upon receiving a notification, obtains environment variables, external conditions, and instructions from real players through an injected data collection interface instance; calls an externally passed condition callback function to perform logical judgment on the data obtained by the data collection interface instance according to the business rules it carries, determining whether the obtained data meets the conditions for triggering the execution of a specified behavior; synchronously collects and stores the obtained data through a training data collection object; generates and stores a decision behavior and a unique ID based on the logical judgment; and when the conditions for triggering the execution of a specified behavior are met, selects an operation node according to a preset behavior-operation node mapping table and sends the unique ID to the operation node.
[0048] Define a decision node, which, during the prediction phase of the player decision behavior model, after receiving a notification, obtains the current environmental variables and external conditions and sends them to the player decision behavior model, receives the predicted behavior returned by the model, and stores the obtained and received data.
[0049] Specifically, business rules refer to a set of criteria based on domain knowledge that guide conditional judgment logic; they define what decision-making behavior should occur under what input conditions. The condition callback function is called the `condition` callback function. The training data collection object is a `TrainDataCollect` object. For example... Figure 4 As shown, the decision node receives instructions from real players, environmental variables, and external conditions.
[0050] For example, the decision node obtains the real player's instruction to "go inside to avoid the rain", the environmental variable is "raining", and the external condition is "the virtual character is hungry". Based on the business rule (on a rainy day, a hungry virtual character can go inside), it determines that the obtained data meets the rule and generates the decision behavior of "go inside to avoid the rain".
[0051] Decision-making behavior, environmental variables, external conditions, and unique IDs can be stored in a temporary local JSON file on the server, which can then be retrieved during the training of the decision tree model. It can be understood that the JSON file stores data on a daily basis for easy retrieval during decision tree model training.
[0052] Understandably, the data stored by the decision node during the training phase is used for model training, and the data stored during the prediction phase is used for model optimization. Step S130: Define an operation node, which, in response to the selection of the decision node, controls the virtual character in the metaverse to perform actions during the training data collection phase or the player decision behavior model prediction phase, and establishes and stores the association record between the action and the unique ID.
[0053] It is understandable that the data stored in the operation nodes is used for subsequent evaluation of the rationality of the model's behavior or for incremental learning of the model.
[0054] Specifically, each decision node performs a specific action. For example, decision node A executes the action of going inside to avoid the rain and stores this action.
[0055] The operation node performs storage actions through the data collection interface instance. The stored data can be stored in a temporary local JSON file on the client, so that the server-side decision tree model can call it from the client's JSON file during training.
[0056] Understandably, after the client's operation node has been running for a period of time, it creates multiple JSON files based on the operation node. After the client uploads the JSON files to the server via the WebSocket protocol, the JSON files can be automatically deleted to reduce storage space usage and avoid duplicate data uploads.
[0057] Understandably, this application encapsulates a predefined behavior tree and deploys it on both the server and client sides. It collects environmental variables and external conditions through the behavior tree's data collection interface instance, and then trains the model using the collected data to obtain a player decision-making behavior model, which is then deployed on the server. This allows the player decision-making behavior model and behavior tree to truly manipulate the metaverse like a real person. These behaviors are specific to, but not limited to, business logic (friend gatherings, friend interactions, handling emergencies, random events, daily tasks, etc.). The richness of these extended functionalities depends on the richness of the specific business logic requirements; that is, the richness of the character's operable behaviors in the metaverse determines the richness of the behavior tree. The player decision-making behavior model will automatically decide which behavior tree interface to call.
[0058] In some embodiments, the definition process of a decision tree model includes: defining a decision tree model class structure, which includes a tree structure module, a feature list module, a training method module, and a prediction method module. The feature list module is used to extract and store the feature names and values of each feature in the feature dataset. The prediction method module is used, during the model prediction phase, to obtain the current environmental variables and external conditions of the metaverse and call a tree traversal algorithm to calculate the predicted behavior.
[0059] Specifically, the decision tree model class structure is `DecisionTree`, which includes a tree structure module `tree`, a feature list module `feature_names`, a training method module `train(train_data, result_data)`, and a prediction method module `predict(sample)`.
[0060] Understandably, defining a flexible decision tree model class structure facilitates the management and operation of the decision tree model's training process. The tree structure module and feature list module within the class structure can store data attributes during training, while the training method module and prediction method module can call the training algorithm and prediction algorithm, respectively.
[0061] The feature dataset includes multiple features, each with a corresponding feature name. Feature names help to intuitively understand the meaning of each node in the tree structure. For example, the feature dataset includes timestamps, in-game time, action execution time, location information (including floor, room, street, location name, etc.), item information (including clothing, usable item IDs, quest reward items, etc.), and character information (including gender, identity, clothing, social network, etc.).
[0062] Understandably, the `feature_names` module is introduced to maintain consistency between feature names and indices. This allows the decision tree model to understand and manipulate features by name when processing data, rather than relying on simple indexes. This not only aids in debugging the decision tree model but also facilitates the interpretation of the final player decision behavior model.
[0063] In some embodiments, the training method module in step S220 calculates the information entropy or information entropy gain of each feature in the feature dataset based on a recursive splitting algorithm, determines the splitting features based on the information entropy or information entropy gain and generates corresponding splitting conditions, and recursively divides the sample dataset into subsets according to the splitting conditions until the splitting stopping condition is met, including the following steps: a. Extract the feature value of each feature in the feature dataset, and calculate the information entropy of each feature in the current node based on the feature value; or, given the features in the feature dataset, extract the label value of each label category in the label dataset, and calculate the information entropy gain of each feature in the current node based on the label value.
[0064] Specifically, the feature dataset includes multiple different features, and the label dataset includes multiple different label categories. For example... Figure 6As shown, the decision tree model splits into multiple nodes during training, including parent nodes, child nodes, and leaf nodes. For example, the sample dataset is split at the parent node, and the left and right subsets after the split move to the left and right branches respectively, moving to child node 1 for further splitting and leaf node 1 for calculating prediction behavior.
[0065] The formula for calculating the information entropy of each feature is: (1), where, The information entropy of a certain feature in a given node. This represents the probability that the i-th value of a given feature appears in this node. For example, if the feature is weather and the i-th feature is rain, then... This can represent the probability of the feature "rain" occurring in that node.
[0066] Information entropy is an metric that measures the disorder of a sample dataset. The more disordered the sample dataset, the higher the information entropy value. By calculating the information entropy of each feature, we can determine how much order that feature brings when used as a splitting feature to divide the sample dataset. The lower the information entropy, the better the sample dataset can be separated.
[0067] The formula for calculating the information entropy gain of each feature is as follows:
[0068]
[0069] It can be understood that the variables in the information entropy formula can be features or label categories, which differs from formula (1) and formula (2). This represents the probability of the i-th label value in a given label category appearing in a certain node, given the features in the feature dataset. For example, if the label category is "whether to take shelter from the rain", the label value can be "have taken shelter from the rain" or "have not taken shelter from the rain". It can represent the probability of having already taken shelter from the rain when assuming a certain feature is the splitting feature. The information entropy represents the label category corresponding to a given feature in a node.
[0070] H(current node) represents the information entropy of the label category in the current node to be split, H(branch) represents the information entropy of the label category in a subset (i.e., child node) after splitting from the current node, and P(branch) represents the proportion of the number of samples in the subset to the number of samples in the parent node. It can be understood that the larger the information entropy gain, the more beneficial the feature is for splitting the sample size.
[0071] It is understandable that the information entropy gain calculated in the end is the information entropy gain of the given feature. By repeatedly specifying the feature as the given feature and performing the calculation, the information entropy gain of each feature can be obtained.
[0072] b. Determine the splitting features of the current node based on the information entropy or information entropy gain of each feature, and generate splitting conditions.
[0073] Specifically, the feature with the lowest information entropy can be determined as the splitting feature of the current node, the feature with the highest information entropy gain can be determined as the splitting feature of the current node, or a global greedy strategy can be used to determine the splitting feature, and the corresponding splitting conditions can be generated based on the splitting feature of the current node.
[0074] The steps for determining the splitting feature using a global greedy strategy are as follows: 1) Perform virtual splitting on each feature as a virtual splitting feature, and generate left and right child nodes. 2) Calculate the information entropy gain for all possible splitting methods of the left and right child nodes, and determine the maximum information entropy gain as the left potential gain and right potential gain respectively. 3) Input the left potential gain, right potential gain, and information entropy gain into a preset global evaluation function to obtain the global score for each feature, and determine the feature with the highest score as the splitting feature of the current node.
[0075] c. Divide the sample dataset into two subsets according to the splitting condition, repeat steps a to c until the splitting stopping condition is met, generate leaf nodes, and complete the recursive construction of branch directions that meet or do not meet the splitting condition.
[0076] Specifically, the splitting stopping conditions include feature splitting being complete, reaching the maximum depth of the decision tree, reaching the minimum number of leaf nodes, or the information entropy gain after the current node split being lower than a preset gain value. The predicted behavior to be output by the leaf node is calculated based on the label dataset in the sample dataset of the leaf node. The predicted behavior can be the label value with the largest proportion.
[0077] It is understood that this application not only calculates the information entropy of each feature in each node, but can also be extended to calculate the information entropy gain of each feature.
[0078] In some embodiments, node data includes the information entropy or information entropy gain of features, splitting conditions, and branching directions. That is, the information entropy or information entropy gain of features during the splitting process, splitting conditions, and branching directions are stored in the corresponding nodes of the tree structure module as attributes of the corresponding nodes to construct a player decision-making behavior model.
[0079] Understandably, traditional decision trees typically do not explicitly record the splitting quality (such as information entropy gain or reduction) of nodes during generation, making subsequent optimizations (such as pruning or model tuning) lack a basis. This application, however, stores the structure formed by all decision paths during the splitting process through a tree structure module, explicitly recording the information entropy or information entropy gain of features, splitting conditions, and branch directions. By recording splitting quality (such as entropy or information entropy gain) and sample distribution, the improved nodes are not merely simple splitting points but also become key nodes for model debugging and analysis. Adjusting the generation order of left and right subtrees based on sample distribution improves tree generation efficiency under large-scale data. By recording and displaying detailed information at nodes, such as entropy changes and sample category distribution, the generation and decision-making processes of the decision tree become more transparent and interpretable, facilitating debugging and model optimization.
[0080] In some embodiments, the player decision-making behavior model can be further optimized. The optimization steps are performed on the server side and include the following steps: Step S410: Obtain new environmental variables and external conditions to input into the player decision-making behavior model, and determine the target leaf node into which the new environmental variables and external conditions fall.
[0081] Step S420: Determine whether the class purity of the label dataset of the target leaf node has changed.
[0082] Step S430: If no changes occur, no local reconstruction of the player decision-making behavior model is performed.
[0083] Step S440: If a change occurs, the target leaf node is determined as the new current node. The sample dataset falling into the target leaf node, along with the new environmental variables and external conditions, are used as training data. Splitting begins from the new current node until the splitting stop condition is met, thus completing the local reconstruction of the player decision-making behavior model.
[0084] The splitting process employs a dynamic pruning strategy: if the information entropy gain of the current node after splitting is determined to be lower than a preset gain value, the current node is marked as a leaf node, and the splitting is terminated.
[0085] Understandably, this embodiment introduces incremental learning. When new environmental variables and external conditions arrive, it determines which part of the tree they fall into and performs incremental updates or re-splitting in that local area as needed. For nodes that need adjustment, this application can reconstruct part of the tree structure through local pruning or splitting, rather than completely rebuilding the entire tree.
[0086] Understandably, traditional decision tree algorithms, such as ID3, C4.5, and CART, typically employ a locally greedy strategy during tree construction. This approach involves selecting the optimal feature at the current node for splitting, but this split only considers the local optimum of the current node, neglecting the global effect. A locally optimal split does not guarantee a globally optimal overall tree structure. Therefore, traditional methods are prone to generating suboptimal decision trees, especially with complex data distributions. Traditional decision tree training is static; once built, it cannot handle new data. Adding new samples usually requires rebuilding the entire tree, incurring additional computational costs. Traditional decision tree algorithms typically do not prune in real-time during construction, potentially generating overly deep or overfitted tree structures, which are only corrected through subsequent pruning. Traditional methods generally set a fixed maximum depth or minimum number of samples per node; these conditions are static and stop recursion once reached. However, these conditions do not always effectively control model complexity, potentially leading to underfitting or overfitting.
[0087] This application addresses these issues by employing global optimization, incremental learning, and dynamic pruning strategies. By comprehensively considering the splitting effects at multiple levels, it ensures that the decision tree achieves not only local optima but also global optima.
[0088] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0089] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A method for offline management of player behavior in a metaverse, characterized in that, The predefined behavior tree includes a state machine, decision nodes, and operation nodes. The methods include: Retrieve online data of real players from a predefined behavior tree. The online data of real players includes... The decision node stores environmental variables, external conditions, decision behaviors, and a unique ID; Using environmental variables and external conditions as feature datasets and decision-making behavior as label datasets, a sample dataset is generated, where each sample data corresponds to a unique ID. The sample dataset is input into the decision tree model, which includes a training method module and a tree structure module. The training method module calculates the information entropy or information entropy gain of each feature in the feature dataset based on the recursive splitting algorithm. Based on the information entropy or information entropy gain, the splitting features are determined and corresponding splitting conditions are generated. The sample dataset is recursively divided into subsets according to the splitting conditions until the splitting stopping condition is met. The node data generated during the splitting process is stored in the tree structure module to construct the player decision behavior model. During the model prediction phase, the state machine responds to offline messages from real players in the metaverse and sends notifications to the decision nodes. After receiving the notification, the decision node obtains the current environmental variables and external conditions through the injected data collection interface instance and sends them to the player decision behavior model. The player decision behavior model outputs the predicted behavior and returns it to the decision node of the behavior tree. The decision node selects the operation node corresponding to the predicted behavior based on a pre-defined mapping table of behavior and operation nodes. In response to the selection of decision nodes, operation nodes control the virtual characters in the metaverse to perform behaviors in order to complete the offline hosting of real player behaviors.
2. The method according to claim 1, characterized in that, The definition of the predefined behavior tree includes the definition of the training data collection phase, which includes: Define a state machine to control the state transitions of real players and send notifications of state transitions to decision nodes; Define decision nodes; upon receiving notifications, obtain environment variables, external conditions, and commands from real players through the injected data collection interface instance; and The system invokes an externally passed conditional callback function, performs logical checks on the data obtained from the data collection interface instance based on the business rules it carries, and determines whether the obtained data meets the conditions for triggering the specified action; and The acquired data is collected synchronously through the training data collection object and stored, and decision-making behavior and unique ID are generated and stored according to the logical judgment; and When the conditions for triggering the execution of the specified behavior are met, the operation node is selected according to the preset behavior-operation node mapping table and a unique ID is sent to the operation node; Define operation nodes, respond to the selection of decision nodes, control the execution of virtual characters in the metaverse, and establish and store the association record between the behavior and the unique ID.
3. The method according to claim 2, characterized in that, Decision-making behavior, environmental variables, external conditions, and unique IDs are stored in a local temporary JSON file for later retrieval during decision tree model training.
4. The method according to claim 1, characterized in that, The definition process of the decision tree model includes: Define the decision tree model class structure, which includes the tree structure module, the feature list module, the training method module, and the prediction method module; The feature list module is used to extract and store the feature names and feature values of each feature in the feature dataset; the prediction method module is used to obtain the current environmental variables and external conditions of the metaverse and call the tree traversal algorithm to calculate the prediction behavior during the model prediction stage.
5. The method according to claim 1, characterized in that, The recursive splitting algorithm calculates the information entropy or information entropy gain of each feature in the feature dataset, determines the splitting features based on the information entropy or information entropy gain and generates corresponding splitting conditions, and recursively divides the sample dataset into subsets according to the splitting conditions until the splitting stopping condition is met, including: a. Extract the feature value of each feature in the feature dataset, calculate the information entropy of each feature in the current node based on the feature value, or extract the label value of the label category in the label dataset under the condition of the features of the feature dataset, and calculate the information entropy gain of each feature in the current node based on the label value; b. Determine the splitting feature of the current node based on the information entropy or information entropy gain of each feature, and generate splitting conditions based on the splitting feature; c. Divide the sample dataset into two subsets according to the splitting condition, repeat steps a to c until the splitting stopping condition is met, generate leaf nodes, and complete the recursive construction of branch directions that meet or do not meet the splitting condition.
6. The method according to claim 5, characterized in that, The process of storing node data generated during the splitting process in a tree structure module to construct a player decision-making behavior model includes: The information entropy or information entropy gain of the features in the splitting process, the splitting conditions, and the branching direction are stored in the corresponding nodes of the tree structure module to construct the player decision-making behavior model.
7. The method according to claim 5, characterized in that, The process of determining the splitting feature of the current node based on the information entropy or information entropy gain of each feature includes: The feature with the lowest information entropy or the highest information entropy gain is identified as the splitting feature of the current node; or Each feature is used as a virtual splitting feature to perform virtual splitting, and left and right child nodes are generated; Calculate the information entropy gain of all possible splitting methods for the left and right child nodes respectively, and determine the maximum information entropy gain as the potential gain for the left and right nodes respectively. The left potential gain, right potential gain, and information entropy gain are input into a preset global evaluation function to obtain the global score of each feature, and the feature with the highest score is determined as the splitting feature of the current node.
8. The method according to claim 6, characterized in that, The method also includes: The new environmental variables and external conditions are input into the player's decision-making behavior model to determine the target leaf node into which the new environmental variables and external conditions fall. Determine whether the Gini impurity of the target leaf node has changed; If no changes occur, no partial reconstruction of the player decision-making behavior model will be performed; If a change occurs, the target leaf node is determined as the new current node. The sample dataset falling into the target leaf node, along with the new environmental variables and external conditions, are used as training data. Splitting begins from the new current node until the splitting stop condition is met, thus completing the local reconstruction of the player's decision-making behavior model.
9. The method according to claim 6 or 8, characterized in that, The splitting stop condition is: during the splitting process, the information entropy gain of the current node after splitting is lower than the preset gain value.
10. A metaverse player behavior offline hosting system, characterized in that, The system includes a server and a client; The server is used to obtain online data of real players in a predefined behavior tree. The online data of real players includes environmental variables, external conditions, decision behaviors, and unique IDs stored in the decision nodes. as well as Using environmental variables and external conditions as feature datasets and decision-making behavior as label datasets, a sample dataset is generated, where each sample data corresponds to a unique ID. as well as The sample dataset is input into the decision tree model, which includes a training method module and a tree structure module. The training method module calculates the information entropy or information entropy gain of each feature in the feature dataset based on the recursive splitting algorithm. Based on the information entropy or information entropy gain, the splitting features are determined and corresponding splitting conditions are generated. The sample dataset is recursively divided into subsets according to the splitting conditions until the splitting stopping condition is met. The node data generated during the splitting process is stored in the tree structure module to construct the player decision behavior model. as well as During the model prediction phase, the state machine responds to offline messages from real players in the metaverse and sends notifications to the decision nodes. as well as After receiving the notification, the decision node obtains the current environmental variables and external conditions through the injected data collection interface instance and sends them to the player decision behavior model. The player decision behavior model outputs the predicted behavior and returns it to the decision node of the behavior tree. as well as The decision node selects the operation node corresponding to the predicted behavior based on a pre-defined mapping table of behavior and operation nodes. The client responds to the selection of decision nodes, and the operation nodes control the virtual characters in the metaverse to perform behaviors, thereby completing the offline hosting of real player behaviors.