Game scenario editing method and system

Abstract

The application provides a game plot editing method and system. The method comprises the following steps: generating plot graph structure data by creating plot nodes and establishing connections between the plot nodes; converting the plot graph structure data into standard plot data in a preset format; simulating the execution of the standard plot data and generating a plot coverage report for counting the number of times each plot node in the execution path is reached; verifying the standard plot data according to the plot coverage report, and generating executable plot data files after verification. By defining an engine-independent standardized plot data format, combining directed graph visual editing, automatic logic verification based on graph algorithms, and real-time preview and breakpoint debugging with a built-in lightweight simulator, the application realizes cross-engine reuse of plots, automatic detection of logic errors in the editing stage, and rapid debugging independent of game engines.

Description

Technical Field

[0001] This invention relates to the field of game plot editing technology, and in particular to a method and system for editing game plots. Background Technology

[0002] As narrative and role-playing games demand increasing complexity in their storylines, story editing and management have become core aspects of game development. Current game story editing primarily employs two methods: one is text- or table-based editing, where designers write dialogue text, branching conditions, and event triggering logic in documents or spreadsheets, which are then manually converted into executable code or configuration files by programmers; the other is based on story editing plugins built into specific game engines, where the story is edited in a node graph format within the engine editor.

[0003] However, the aforementioned existing technologies have the following drawbacks: First, the plot data format is deeply bound to a specific game engine, making plot data unusable across engines and resulting in high costs for cross-engine migration. Second, existing editing methods lack automated logic verification mechanisms during the editing phase; logical problems such as circular dependencies, isolated nodes, incorrect variable references, and condition conflicts in the plot can only be discovered during game runtime, leading to late detection and high repair costs. Third, plot debugging requires starting a complete game engine runtime environment, and each modification requires repackaging and running to verify the effect, resulting in a long debugging cycle. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a method and system for editing game plots, which improves plot editing efficiency and cross-engine reusability while ensuring the correctness of plot logic.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a method for editing game plot, comprising: By creating story nodes and establishing connections between them, story graph structure data is generated; Convert the plot diagram structure data into standard plot data in a preset format; Simulate the execution of the standard plot data and generate a plot coverage report that counts the number of times each plot node is reached in the execution path; The standard plot data is verified based on the plot coverage report, and an executable plot data file is generated after successful verification.

[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is: a game plot editing system, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0007] The beneficial effects of this invention are as follows: By converting the plot graph structure data into standard plot data in a preset format, the plot data no longer depends on the proprietary format of any specific game engine, achieving seamless cross-engine reuse of plot data. By simulating the execution of standard plot data and generating a plot coverage report, plot logic can be verified during the editing stage, allowing logical errors to be detected and reducing error repair costs. Simultaneously, the simulation execution is independent of the game engine, enabling rapid verification and debugging of the plot without starting a complete game engine runtime environment, thus improving plot editing efficiency. Attached Figure Description

[0008] Figure 1 A flowchart illustrating a method for editing game storylines according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the specific steps of a game story editing method according to an embodiment of the present invention. Figure 3 A flowchart illustrating the creation of a story project and the definition of variables in an embodiment of the present invention; Figure 4 This is a flowchart of a visual editing plot node diagram according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the configuration node attributes and logic in an embodiment of the present invention; Figure 6 This is a flowchart illustrating the real-time preview and debugging of the plot in an embodiment of the present invention; Figure 7 This is a flowchart illustrating the export of plot data files according to an embodiment of the present invention; Figure 8 This is a flowchart illustrating the integration of this invention into the game engine runtime, as described in an embodiment of the invention. Figure 9 This is a flowchart illustrating the in-game execution of storyline and feedback collection in an embodiment of the present invention; Figure 10 This is a schematic diagram of a game story editing system according to an embodiment of the present invention. Detailed Implementation

[0009] Definitions:

[0010] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0011] In existing technologies, game story editing is mainly applied to the development of narrative games and role-playing games. With the rapid development of the game industry, players' demands for the complexity and branching of game storylines are constantly increasing, making story editing and management a core aspect of game development. Traditional story editing methods mainly fall into two categories: one is a manual editing method based on text or tables, where designers write dialogues and branching logic in documents, which are then manually converted into executable code by the game engine by programmers; the other is a visual editing method based on specific game engine built-in plugins, where the story is edited in the form of a node graph within the engine editor. These methods suffer from problems in practical applications, such as deep binding of story data to the engine preventing cross-platform reuse, lack of automated logic verification during the editing stage, and inefficiency due to reliance on a complete game engine environment for debugging.

[0012] To at least address the aforementioned issues, this invention provides a method for editing game storylines, which converts the storyline structure data generated by visual editing into an engine-independent standard format, simulates execution, generates a coverage report for verification, and outputs an executable storyline data file after successful verification.

[0013] This approach enables seamless reuse of story data across engines, automatically detects plot logic errors during the editing stage, and supports rapid debugging independent of the game engine, thereby improving the efficiency and logical correctness of story editing.

[0014] The following describes in detail a method for editing game storylines according to the present invention. Please refer to [link / reference]. Figure 1 as well as Figure 2 The method 100 includes steps 101 to 104: Before step 101, the process includes: obtaining user-defined global plot variables, which contain variable names, data types, and initial values; performing a validity check on the global plot variables, which includes checking whether the variable names have naming conflicts, whether the data types are valid, and whether the initial values ​​match the data types; if the checks pass, generating a variable type definition file containing the global plot variables and initializing a blank plot graph; otherwise, outputting an error message.

[0015] Specifically, combined Figure 3 In the development of large-scale role-playing games, designers need to define global variables that affect the game's plot, such as the player's affinity with a character or the acquisition status of a key item. Designers enter the variable name "goodness" in the story editor, with an integer data type and an initial value of 0. The system automatically checks if the variable name is already in use and if the data type and initial value match. If the variable definition is valid, the system creates the project directory structure, generates project configuration files and variable definition files, and initializes a blank story map.

[0016] This approach ensures that plot variables are defined correctly and without conflict, laying a data foundation for the correct execution of subsequent plot logic.

[0017] Step 101: Generate story graph structure data by creating story nodes and establishing connections between them, including: Step 1011: Create a story node in the blank story graph and add the story node to the node set. The node types of the story node include dialogue node, selection node, condition node, event node, jump node and random node. The story node includes independent input port type and output port type.

[0018] Specifically, combined Figure 4 Designers create story nodes by dragging and dropping on a visual editing canvas. The system supports six core node types: dialogue nodes display character dialogue text; selection nodes present player options and generate branches; conditional nodes determine the jump direction based on variable expressions; event nodes trigger game event commands, such as playing cutscenes or triggering combat; jump nodes jump to a specified story location, enabling the reuse of story segments; and random nodes allocate subsequent paths according to probability, increasing the randomness and replayability of the story. Each node has a clearly defined input and output port. For example, a dialogue node has only one input port and one output port, a selection node has one input port and multiple output ports, with each output port corresponding to an option, and a random node has multiple output ports allocated according to preset probabilities.

[0019] In this way, abstract plot logic is transformed into an intuitive node diagram structure. The six node types cover various scenarios commonly encountered in plot editing, making it easier for planners to conduct visual plot design and editing.

[0020] Step 1012: When a request to establish a connection between two story nodes is detected, obtain the output port type of the connection start node and the input port type of the connection end node, and determine whether the connection is allowed based on the preset port type compatibility matrix. If they are incompatible, the connection will fail to be established and a prompt message will be output.

[0021] Specifically, when a planner attempts to connect the output port of a dialog node to the input port of another condition node, the system reads the output port type of the dialog node and the input port type of the condition node, and queries the port type compatibility matrix. If the output port type of the dialog node is "text" while the input port type of the condition node requires "boolean value", it is determined to be incompatible, the system refuses to establish the connection and displays a prompt message.

[0022] In this way, incorrect connections due to type mismatch can be prevented during the editing stage, ensuring the structural correctness of the story diagram.

[0023] Step 1013: After the connection is successfully established, add the connection to the edge set, traverse the established story nodes and edges, and check whether there is a loop path that starts from any story node, passes through several edges, and returns to the story node itself. If it exists, cancel the connection and output a prompt that a loop path exists.

[0024] Specifically, when a planner connects a branch of a selected node to a preceding node, the system starts from the origin of that connection and uses a depth-first search (DFS) algorithm to traverse all nodes and edges. If a path is found that starts from a node, traverses several edges, and returns to that node, it is considered a circular dependency. For example, if a path goes from node A to node B, then to node C, and then back from node C to node A, the system will detect this loop, immediately cancel the connection, and display the message "Circular path detected."

[0025] In this way, the generation of circular dependencies is prevented in real time during the connection process, thus avoiding the plot from falling into an infinite loop.

[0026] Step 1014: After all story nodes have been created and connected, the set of nodes and the set of edges are encapsulated into story graph structure data.

[0027] Specifically, after the planners complete the creation of all plot nodes and connections, the system encapsulates all nodes and connections on the current canvas to generate complete plot graph structure data. This data records the unique identifier of each node, node type, input and output port information, and jump relationships between nodes.

[0028] In this way, the results of visual editing are transformed into structured data that can be processed later.

[0029] It also includes configuring the node attributes of each story node in the node set.

[0030] Specifically, select the target node to be configured, and configure the corresponding attributes according to the node type: when the node type is a dialogue node, edit the dialogue text and character information; when the node type is a selection node, configure the option text and branch jump logic; when the node type is a condition node, set the condition judgment expression; when the node type is an event node, configure the game event to be triggered; when the node type is a jump node, configure the target jump position; when the node type is a random node, configure the probability weight of each exit branch. After configuration, verify the completeness of the node configuration. If the configuration is invalid, prompt for missing fields or expression errors and require reconfiguration; if the configuration is valid, save the node attributes.

[0031] Specifically, combined Figure 5 The planner selects a story node on the canvas and fills in the corresponding content according to the node type. For example, for a selection node, the planner configures two options: "Accept Task" jumps to node A, and "Reject Task" jumps to node B. The system verifies whether the configuration is complete; if an option lacks a jump target, an error message is displayed. After all nodes are configured, the system saves the attribute configuration data for each node.

[0032] In this way, we can ensure that the business data of each story node is complete and meets the specifications of the node type.

[0033] Following step 1014, step 1015 is also included: obtaining a node set and an edge set from the plot graph structure data; traversing the plot nodes in the node set and the edges in the edge set, detecting whether there exists a loop path starting from any plot node, traversing several edges, and returning to the plot node itself; if so, marking a loop dependency error or warning based on the conditional reachability of the loop path; determining a starting plot node from the node set; starting from the starting plot node, traversing all plot nodes in the node set, marking all reachable plot nodes, and identifying unmarked plot nodes as isolated nodes and marking them as isolated nodes; obtaining plot nodes in the node set whose node type is condition node, and extracting the condition expression of the plot node... The referenced variable name is searched in the predefined global variable table. If not found, a variable reference error is marked. For multiple exit conditions of the same story node, mutual exclusion analysis is performed to check for branches where the value of the conditional expression is always false or branches where multiple conditional expressions can simultaneously be true. If such branches exist, a condition conflict error is marked. For random nodes, the sum of the probability weights of each exit branch is checked to ensure it is 100%. If the sum of the probability weights is not 100%, a configuration error is marked. Circular dependency errors, isolated node errors, variable reference errors, condition conflict errors, and random node configuration errors are categorized, and an error entry containing the error type, error location, and suggested repair solution is generated for each error. An error list is generated and output. For nodes that are structurally reachable but actually unreachable due to consistently false conditions, a warning level is marked, and the planner is notified with the message "Structurally reachable but semantically unreachable."

[0034] Specifically, the full verification in step 1015 complements the incremental interception in step 1013: step 1013 performs incremental interception when the user creates a new connection, and immediately cancels the connection and provides immediate feedback once a loop is found; while step 1015 performs full verification before converting or exporting plot data, covering scenarios such as importing old data, batch editing, or when incremental verification was not triggered in the previous step, and uniformly categorizes and outputs errors such as circular dependencies, isolated nodes, variable references, and condition conflicts.

[0035] Before the planners export the plot data, the system performs a comprehensive validation of the entire plot diagram. For example, if a plot segment contains a conditional node with exit conditions of "affinity ≥ 50" and "affinity < 50," these two conditions are mutually exclusive and cover all possibilities, so the validation passes. However, if another conditional node has exit conditions of "affinity ≥ 50" and "affinity ≥ 60," these two conditions overlap, and the system detects an ambiguous branch and marks it as a condition conflict error. If a conditional node's conditional expression references the undefined variable "affinity," the system marks it as a variable reference error. If the probability weights of the three exit branches of a random node are 30%, 30%, and 30% respectively, and the sum is less than 100%, the system marks it as a configuration error. If a node is not traversed by any starting node using the breadth-first search (BFS) algorithm, the system identifies it as an isolated / dead node and marks it as an error.

[0036] In this way, all logical problems are fully detected and highlighted before exporting, ensuring the logical correctness of the exported plot data.

[0037] In step 1015, it is detected whether there is a loop path that starts from any plot node, traverses several edges, and returns to the plot node itself. If such a loop path exists, a loop dependency error is marked. Specifically, the detected loop path is obtained, and the condition nodes on the loop path are identified. It is determined whether the value of the branch condition pointing to the loop direction of the exit condition of the condition node is always false. If the value of the branch condition pointing to the loop direction is always false, the loop path is marked as a conditionally unreachable loop and a warning level is set, and the corresponding prompt message is output. If the expression of the branch condition pointing to the loop direction contains a preset runtime dynamic variable, the detected loop path is marked as an error level, and the corresponding prompt message is output.

[0038] Specifically, when the system detects a loop path, such as a loop where node A passes through condition node B and returns to node A, the system further analyzes the conditional expression pointing to the loop direction from condition node B. If the conditional expression is always false, such as "false" or "0 equals 1," the system determines that the loop will never be entered in actual execution, and marks the loop as a warning, indicating to the planner that the loop path is unreachable due to the condition always being false. If the conditional expression depends on runtime dynamic variables, such as "player level >= 10," and cannot be statically determined during the editing phase, the system marks the loop as an error, indicating to the planner that the loop path needs attention. For other situations, including loop paths without conditional nodes (i.e., unconditional loops consisting entirely of non-conditional nodes), or loop direction conditional expressions whose values ​​cannot be determined during the editing phase and do not contain runtime dynamic variables (e.g., depending on intermediate variables generated during the execution of other story nodes), since it cannot be proven that the loop is necessarily unreachable in actual execution, the system also marks the loop as an error, requiring the planner to manually review and handle the loop path.

[0039] In this way, a deep semantic analysis of the loop path is performed to distinguish between structural loops that truly need repair and unreachable loops caused by constant conditions.

[0040] Step 102: Convert the plot diagram structure data into standard plot data in a preset format.

[0041] Specifically, the process involves: obtaining a node set and an edge set from the plot graph structure data; encapsulating the node set and edge set into a graph structure definition in a preset format; traversing each plot node in the node set, reading the corresponding node attribute configuration data according to the node type of the plot node, and encapsulating the node attribute configuration data into a node attribute set in a preset format; obtaining a predefined global variable table and a local variable table, and encapsulating the global variable table and the local variable table into a variable table definition in a preset format; obtaining a preset localized text index, which contains text key-value pairs categorized by language; combining the graph structure definition, the node attribute set, the variable table definition, and the localized text index into a data object in a preset format, writing a version number field into the data object, performing a serialization operation on the data object, and generating standard plot data in a preset format.

[0042] Specifically, the system converts the verified story graph structure data into the SPDF standard format. A dialogue node records its unique identifier and node type in the graph structure definition, its dialogue text key and character information in the node attribute set, and stores the dialogue text content in both Chinese and English in the localized text index. Dialogue text is not directly written to node attributes; instead, it references the localized text index via text keys, thus decoupling the story logic from the multilingual text. A version number field is included in the generated SPDF data to support backward compatibility and version migration. If encryption is enabled, the serialized data can be encrypted for protection.

[0043] In this way, story data no longer depends on the proprietary format of a specific game engine. The same SPDF data file can be seamlessly migrated to different game engines for use, while also supporting unified management of multilingual storylines.

[0044] Step 103: Simulate the execution of the standard plot data and generate a plot coverage report that statistically analyzes the number of times each plot node is reached in the execution path, including: Step 1031: Obtain the node set from the graph structure definition of the standard plot data, initialize the virtual variable context and node execution stack, determine the starting plot node as the current plot node from the node set, push the current plot node onto the node execution stack, and read the corresponding node attribute configuration data according to the node type of the current plot node.

[0045] Specifically, combined Figure 6 After the planners start the story simulator, the system initializes the running state of all story variables, starting execution from the story's initial node. It reads the corresponding attribute configuration data based on the current node's type; for example, dialogue nodes read dialogue text keys, selection nodes read the option list, conditional nodes read conditional expressions, and random nodes read the probability weights of each exit branch. When the simulator starts, the preview panel indicates that it is currently in logic verification mode.

[0046] In this way, the system can parse the story data and prepare for execution without starting the game engine.

[0047] Step 10321: When the current story node is a dialogue node, retrieve the dialogue text from the localized text index and render the dialogue text to the preview panel. After the current node finishes execution, pop the currently executed node from the node execution stack, push the determined next story node onto the node execution stack, and use the node at the top of the node execution stack as the new current story node. Subsequent steps for determining the next story node are the same as this step.

[0048] Specifically, when the simulation executes to a dialog node, the system searches for the corresponding dialog text content from the localized text index according to the dialog text key of the node and the currently selected language, and displays the text in the preview panel. For example, if the dialog text key configured for the node is "greeting_001" and the current language is Chinese, the system searches the Chinese sub-table in the localized text index for the text "Hello!" corresponding to the key, and displays the text on the preview panel In this way, planners can preview the display content of dialog nodes without starting the game.

[0049] Step 10322: when the current plot node is a selection node, acquire an option list from the node attribute configuration data, render the option list to a preview panel, acquire a selection result after the user's simulated selection, and determine a next plot node according to the selection result.

[0050] Specifically, when the simulation executes to a selection node, the system reads the option list of the node from the node attribute configuration data, for example, option A "Accept the task" and option B "Refuse the task", renders these two options in the preview panel for planners to make simulated selections. After the planner clicks to select an option, the system determines the next plot node to be executed according to the branch jump information corresponding to the option.

[0051] In this way, planners can fully verify the trend of branch plots in the simulator.

[0052] Step 10323: when the current plot node is a condition node, acquire a conditional expression from the node attribute configuration data, evaluate the conditional expression to obtain an evaluation result, and determine a next plot node according to the evaluation result.

[0053] Specifically, when the simulation executes to a condition node, the system reads the conditional expression from the node attribute configuration data, for example, "favorability >= 50", the system reads the current value of the favorability variable from the current virtual variable context, and evaluates the conditional expression. If the evaluation result is true, it jumps to the branch node where the condition is true; if it is false, it jumps to the branch node where the condition is false.

[0054] In this way, planners can test the trend of conditional branches under different variable values.

[0055] Step 10324: When the current story node is an event node, retrieve the command name and parameter configuration from the node attribute configuration data, and obtain the current trigger timing. Record the command name, parameter configuration, and trigger timing in a preset event trigger log, and display the command name and parameters in a preset log style in the preview panel. After the log recording is completed, the event node is considered executed, and the process continues to the next node without interrupting the story flow.

[0056] Specifically, when the simulation reaches an event node, the system reads the event command name, such as "play_cutscene," and parameter configurations, such as the cutscene identifier "opening_scene," from the node's attribute configuration data. The system also records the time when the node is reached as the trigger point, records this information in the event trigger log, and displays it in the preview panel as "Engine Event: Playing cutscene opening_scene" with the prefix "Engine Event." After logging is complete, the event node is considered executed, and the process continues to the next node without interrupting the story flow.

[0057] In this way, even without starting the game engine, designers can understand when and what game events will be triggered by event nodes.

[0058] Step 10325: When the current story node is a jump node, obtain the target jump position from the node attribute configuration data, and determine the story node corresponding to the target jump position as the next story node.

[0059] Specifically, when the simulation reaches a jump node, the system reads the target jump position configured for that node from the node attribute configuration data, such as jumping to the start node of a chapter or a specific plot node. The system directly determines the plot node corresponding to the target jump position as the next node to be executed, realizing the reuse of plot segments and the organization of complex plot structures.

[0060] In this way, planners can flexibly organize non-linear plot structures and avoid repeatedly editing the same plot segments.

[0061] Step 10326: When the current plot node is a random node, obtain the probability weight of each exit branch from the node attribute configuration data, randomly select an exit branch according to the probability weight, determine the plot node corresponding to the selected exit branch as the next plot node, and record the result of this random selection.

[0062] Specifically, when the simulation reaches a random node, the system reads the probability weights of each exit branch configured for that node from the node's attribute configuration data. For example, branch A has a probability of 30%, and branch B has a probability of 70%. The system randomly selects the next story node to execute based on these probability weights and records the result of this random selection in the simulation log. Designers can observe the different paths taken by the various random branches generated during multiple executions in the simulator to verify whether the random logic meets design expectations.

[0063] In this way, the system supports storyline designs with randomness and replayability, and designers can verify in the simulator whether the distribution of random probabilities meets expectations.

[0064] Step 1033: When a breakpoint is set on the current story node, execution is paused, and the values ​​of the input variables, output variables, and evaluated conditional expressions of the current story node are displayed in the preview panel; while paused, when a preset single-step execution instruction is received, the next story node of the current story node is executed and then paused again.

[0065] Specifically, combined Figure 6 Designers can set breakpoint markers for specific plot nodes in the editor. When the simulation reaches that node, the system automatically pauses and displays the input and output variable values ​​for the current node in the preview panel, as well as the evaluation result of the conditional expression if it is a conditional node. After the designer clicks the single-step execution button, the system executes the next node after the current node and then pauses again, making it easy to track the plot execution flow node by node.

[0066] In this way, planners can fine-tune the plot logic and quickly locate the problem.

[0067] Step 1034: When a preset variable modification instruction is received, the value of the variable corresponding to the name of the variable is updated to the value of the modified variable, and the next plot node is executed.

[0068] Specifically, while the game is paused, developers can manually modify the value of a variable, such as changing the value of the "affinity" variable from 30 to 80, and then continue execution. The system will then continue simulating execution according to the modified variable value, thereby verifying the branching paths of the story under different variable values. In this way, various branching scenarios can be quickly tested without having to start from the beginning again.

[0069] Step 1035: Repeat the above steps until there are no more plot nodes or the preset end plot node is reached. Record the branch paths of the plot nodes passed through in each simulation and the number of times each plot node is reached. After the simulation ends, count the number of times each plot node is reached and the number of times each branch path is reached. Generate a plot coverage report based on the number of times the plot nodes are reached. The plot coverage report includes the ratio of reachable plot nodes to all plot nodes, a list of unreachable plot nodes, and a list of branches of unreachable nodes.

[0070] Specifically, the system starts from the initial node and executes each node sequentially, recording the path of each node visited and the direction of each option branch. For example, for a storyline containing 3 dialogue nodes and 2 choice nodes, after simulation, a coverage report is generated showing a total of 5 nodes, of which 4 nodes were reached and 1 node was not reached, resulting in a node coverage rate of 80%. The unreached node may be a node of a hidden branch. Designers supplement the test of this branch path based on the list of unreached nodes until all nodes and branches are verified. For random nodes, the system records the actual number of times each branch is reached during multiple simulations, helping designers verify whether the probability configuration meets expectations. After the simulation ends, the system generates a complete storyline execution path test report.

[0071] In this way, quantitative coverage data ensures that all branching paths in the story have been validated, avoiding any omissions in testing.

[0072] Step 104: Verify the standard plot data according to the plot coverage report. After successful verification, generate an executable plot data file.

[0073] Specifically, the process involves obtaining a list of unreached plot nodes and a list of unreached node branches from the plot coverage report; when both the list of unreached plot nodes and the list of unreached node branches are empty, the verification is considered successful; after successful verification, an integrity check is performed on the standard plot data, and an executable plot data file is generated after successful verification.

[0074] Specifically, combined Figure 7 Before exporting the plot data file, the system performs a global check. If there are logical or configuration errors in the plot, a complete list of errors is displayed and the export process is terminated. If the plot graph integrity check passes, the node plot graphs are converted to the SPDF standard format, the complete plot data is serialized, and finally, the plot data file is generated and saved to the user-specified storage path.

[0075] This method ensures that the final exported story data file is logically fully validated, reducing online issues caused by insufficient testing.

[0076] Step 104 is followed by generating a version hash identifier for the executable story data file; when the story data file is actually executed, the version hash identifier of the locally cached story data file is compared with the latest version hash identifier in the remote storage. If the comparison result is inconsistent, the locally cached story data file is updated according to the story data file with the latest version hash identifier in the remote storage, and the story data file with the latest version hash identifier is re-executed.

[0077] Specifically, combined Figure 8 and Figure 9 The runtime plugin is installed in the target game project, configuring the story data file reading path, initializing the in-game story interpreter instance, and loading the external SPDF format story data file. This runtime plugin implements a unified runtime abstract interface, including dialogue display, option presentation, event dispatch, and variable read / write interfaces. If the data file is valid, it fully parses the story graph nodes and flow structure, registering custom story command mappings for the project: the game project maps abstract command names to engine-side callback functions through a command registry configuration file. For example, "play_cutscene" maps to Unity's Timeline playback interface in Unity and to UE's Sequencer playback interface in Unreal Engine. The parsed story data is cached in runtime memory, marking the story runtime system as ready and available.

[0078] After the game's business side initiates a story execution request, the system locates the story's starting execution node based on the unique story ID. It reads all configuration data for the current node and, depending on the node type, calls the corresponding runtime abstract interface to execute the node logic: for a dialogue node, it calls the dialogue display interface; for a selection node, it calls the option presentation interface; for a conditional node, it calls the variable read / write interface to read global game variables and complete conditional logic calculations; and for an event node, it looks up the instruction name in a table and calls the corresponding engine callback function. After execution, game variables are updated, and the story node execution log is recorded. The process then jumps to the next story node until the story ends. The player's progress in this story is persistently saved, and the story completion event is reported to the upper-level business.

[0079] The system generates a unique version hash for each exported executable story data file. When the game starts, the runtime interpreter compares the version hash of the locally cached story data file with the latest version hash on the remote server. If they do not match, for example, the remote version hash is "v002" while the local cache is "v001", incremental update data is fetched from the remote server, the local cache is updated, and the story data is reloaded.

[0080] In this way, the game can be updated dynamically and hot-update the storyline independently of the client version during operation. Modifications to the storyline by the operators will take effect without waiting for players to update the client.

[0081] As described above, this invention achieves seamless cross-engine reuse of story data by converting the story graph structure data generated through visual editing into engine-independent preset format standard story data. The same story data file can be directly executed in different game engines, reducing project migration costs by 80%. By simulating the execution of standard story data and generating story coverage reports, story logic can be automatically verified during the editing stage. This advances the discovery of logical problems such as circular dependencies, orphaned nodes, variable reference errors, and condition conflicts from game runtime to the editing stage, reducing the story logic error rate by 75%. The editor's built-in lightweight story simulator, independent of the game engine, supports breakpoint debugging, single-step execution, variable monitoring and modification, and story coverage analysis. Designers can start the simulation in seconds and complete a full walkthrough of a single storyline in minutes without launching the game engine, improving efficiency by more than 5 times compared to traditional packaged runtime debugging methods. Through a plug-in engine adaptation layer and a unified runtime abstraction interface, independent hot updates of story data are supported, making the update process imperceptible to players. In summary, this invention effectively solves the technical problems of existing game story editing tools, such as the inability to reuse story data across engines, the lack of automated logic verification during the editing stage, and the low efficiency caused by the reliance on a complete game engine environment for debugging, thereby improving the efficiency and logical correctness of story editing.

[0082] Please refer to Figure 10 An embodiment of the present invention provides a game plot editing system 200, including a memory 201, a processor 202, and a computer program stored in the memory and executable on the processor. When the processor 202 executes the computer program, it implements the various steps of a game plot editing method as described above.

[0083] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for editing game plot, characterized in that, include: By creating story nodes and establishing connections between them, story graph structure data is generated; Convert the plot diagram structure data into standard plot data in a preset format; Simulate the execution of the standard plot data and generate a plot coverage report that counts the number of times each plot node is reached in the execution path; The standard plot data is verified based on the plot coverage report, and an executable plot data file is generated after successful verification.

2. The method for editing game plot according to claim 1, characterized in that, By creating story nodes and establishing connections between them, story graph structure data is generated, which previously included: Retrieve user-defined global plot variables, which include variable name, data type, and initial value; Perform a validity check on the global plot variables. The validity check includes checking whether there are naming conflicts in the variable names, whether the data types are valid, and whether the initial values ​​match the data types. If the verification passes, a variable type definition file containing the global plot variables will be generated, and a blank plot graph will be initialized; otherwise, an error message will be output.

3. The method for editing game plot according to claim 2, characterized in that, By creating story nodes and establishing connections between them, story graph structure data is generated, including: Create plot nodes in the blank plot graph and add the plot nodes to the node set. The node types of the plot nodes include dialogue nodes, selection nodes, condition nodes, event nodes, jump nodes, and random nodes. The plot nodes include independent input port types and output port types. When a request to establish a connection between two story nodes is detected, the output port type of the connection start node and the input port type of the connection end node are obtained. The connection is then determined based on a preset port type compatibility matrix. If the connection is not compatible, the connection will fail and a prompt message will be output. Once the connection is successfully established, add the connection to the edge set, traverse the established story nodes and edges, and check if there is a loop path that starts from any story node, passes through several edges, and returns to the story node itself. If it exists, cancel the connection and output a prompt that a loop path exists. Once all story nodes have been created and connected, the set of nodes and the set of edges are encapsulated into story graph structure data.

4. The method for editing game plot according to claim 3, characterized in that, Before converting the story map structure data into standard story data in a preset format, the process also includes: Obtain the node set and edge set from the aforementioned plot graph structure data; Traverse the story nodes in the node set and the edges in the edge set, and check if there is a circular path that starts from any story node, goes through several edges, and returns to the story node itself. If it exists, mark a circular dependency error or warning according to the conditional reachability of the circular path. Determine the starting story node from the node set, start from the starting story node, traverse all story nodes in the node set, mark all reachable story nodes, and identify unmarked story nodes as isolated nodes and mark isolated node errors. Obtain the plot nodes of type condition node from the node set, extract the variable names referenced in the condition expression of the plot node, search for the variable names in the predefined global variable table, and mark the variable reference as incorrect if not found. Perform mutual exclusion analysis on multiple exit conditions for the same plot node, and check whether there are branches where the value of the conditional expression is always false or branches where the value of multiple conditional expressions can be true at the same time. If they exist, mark the condition conflict error. The circular dependency errors, orphaned node errors, variable reference errors, and condition conflict errors are categorized, and an error list is generated and output.

5. The method for editing game plot according to claim 1, characterized in that, Converting the plot diagram structure data into standard plot data in a preset format includes: Obtain the node set and edge set from the plot graph structure data, and encapsulate the node set and edge set into a graph structure definition in a preset format; Iterate through each story node in the node set, read the corresponding node attribute configuration data according to the node type of the story node, and encapsulate the node attribute configuration data into a node attribute set in a preset format; Obtain the predefined global variable table and local variable table, and encapsulate the global variable table and local variable table into a variable table definition in a preset format; Obtain a preset localized text index, which contains text key-value pairs categorized by language; The graph structure definition, the node attribute set, the variable table definition, and the localized text index are combined into a data object in a preset format. The data object is then serialized to generate standard plot data in the preset format.

6. The method for editing game plot according to claim 5, characterized in that, Simulate the execution of the standard plot data and generate a plot coverage report that statistically analyzes the number of times each plot node is reached in the execution path, including: Obtain a set of nodes from the graph structure definition of the standard plot data, and determine the starting plot node as the current plot node from the set of nodes; Read the corresponding node attribute configuration data based on the node type of the current story node; When the current story node is a dialogue node, the dialogue text is obtained from the localized text index and rendered to the preview panel. When the current story node is a selection node, the option list is obtained from the node attribute configuration data, the option list is rendered to the preview panel and the selection result after the user simulates the selection is obtained, and the next story node is determined based on the selection result; When the current plot node is a condition node, the condition expression is obtained from the node attribute configuration data, the condition expression is evaluated to obtain the evaluation result, and the next plot node is determined based on the evaluation result. When the current plot node is an event node, the instruction name and parameter configuration are obtained from the node attribute configuration data, and the current triggering time is obtained. The instruction name, parameter configuration and triggering time are recorded in the preset event triggering log, and the instruction name and parameters are displayed in the preview panel in the preset log style. When a breakpoint is set on the current story node, execution is paused, and the values ​​of the input variables, output variables, and evaluated conditional expressions of the current story node are displayed in the preview panel. When paused, upon receiving a preset single-step execution command, the program executes the next story node after the current story node and then pauses again. When a preset variable modification instruction is received, the value of the variable corresponding to the name of the variable is updated to the value of the modified variable, and the next plot node is executed. Repeat the above steps until there are no more plot nodes or the preset end plot node is reached, and record the branch paths of the plot nodes passed through in each simulation and the number of times each plot node is reached. After the simulation is completed, the number of times each plot node and each branch path is reached is counted. A plot coverage report is generated based on the number of times the plot nodes are reached. The plot coverage report includes the ratio of reachable plot nodes to all plot nodes, a list of unreachable plot nodes, and a list of unreachable node branches.

7. The method for editing game plot according to claim 4, characterized in that, Check if there exists a circular path that starts from any story node, traverses several edges, and returns to the story node itself. If it exists, mark it as a circular dependency error, including: Obtain the detected loop path and identify the condition nodes on the loop path; Determine whether the value of the branch condition pointing to the loop direction of the loop path is always false. If the value of the branch condition pointing to the loop direction is always false, mark the loop path as a conditional unreachable loop and a warning level, and output the corresponding prompt message. If the expression for the branch condition pointing to the loop direction contains a preset runtime dynamic variable, the detected loop path will be marked as an error level, and the corresponding prompt message will be output.

8. The method for editing game plot according to claim 1, characterized in that, The standard plot data is verified based on the plot coverage report. Upon successful verification, an executable plot data file is generated, including: Obtain the list of unreached plot nodes and the list of unreached node branches from the plot coverage report; The verification is successful when both the list of unreached story nodes and the list of unreached node branches are empty. After successful verification, an integrity check is performed on the standard plot data. Once the check is successful, an executable plot data file is generated.

9. A method for editing game plot according to claim 8, characterized in that, After generating the executable story data file, it also includes: Generate a version hash identifier for the executable story data file; When the plot data file is executed, the version hash identifier of the locally cached plot data file is compared with the latest version hash identifier in the remote storage. If the comparison result is inconsistent, the locally cached plot data file is updated according to the plot data file with the latest version hash identifier in the remote storage, and the plot data file with the latest version hash identifier is re-executed.

10. A game plot editing system, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of a game plot editing method according to any one of claims 1 to 9.

Images