Game development method, game development device, program product, and electronic device

Abstract

The present disclosure provides a game development method, a game development device, a program product and an electronic device, and relates to the technical field of game development. The method comprises the following steps: obtaining game development requirement information in a natural language form; constructing a task topology graph with atomic operations as nodes and containing node dependency relationships by analyzing the game development requirement information; controlling a game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from a game trunk project, obtaining to-be-verified information, and verifying the to-be-verified information; the to-be-verified information comprises intermediate products generated by executing the atomic operations; if the to-be-verified information passes the verification, updating the game trunk project according to incremental information corresponding to the intermediate products. The present disclosure provides a game development automation scheme, realizes bottom-layer control and closed-loop management of the automation process, and improves the efficiency and safety of game development and production.

Description

Technical Field

[0001] This disclosure relates to the field of game development technology, and more specifically, to game development methods, game development apparatus, program products, and electronic devices. Background Technology

[0002] With the rapid development of the gaming industry, the scale of game development projects is increasing daily. For example, a typical AAA game development team usually consists of hundreds or even thousands of members, covering dozens of sub-fields such as concept art, 3D modeling, level design, technical art, client-side logic development, server-side architecture, and quality assurance. Therefore, how to improve the efficiency and security of game development and production is an urgent problem to be solved by the industry. Summary of the Invention

[0003] This disclosure provides game development methods, game development apparatus, program products, and electronic devices to at least partially improve the efficiency and security of game development and production.

[0004] According to a first aspect of this disclosure, a game development method is provided, the method comprising: acquiring game development requirement information in natural language form; constructing a task topology graph with atomic operations as nodes and including node dependencies by parsing the game development requirement information; controlling a game engine to execute the atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, obtaining information to be verified, and verifying the information to be verified; the information to be verified includes intermediate products generated by executing the atomic operations; if the information to be verified passes verification, updating the main game project according to the incremental information corresponding to the intermediate products.

[0005] According to a second aspect of this disclosure, a game development apparatus is provided, the apparatus comprising: a requirement information acquisition module configured to acquire game development requirement information in natural language form; a task topology graph construction module configured to construct a task topology graph with atomic operations as nodes and including node dependencies by parsing the game development requirement information; a sandbox verification module configured to control a game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the game backbone project, obtain information to be verified, and verify the information to be verified; the information to be verified includes intermediate products generated by executing the atomic operations; and a game backbone project update module configured to update the game backbone project according to incremental information corresponding to the intermediate products if the information to be verified passes verification.

[0006] According to a third aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method of the first aspect described above and possible implementations thereof.

[0007] According to a fourth aspect of this disclosure, an electronic device is provided, comprising: a processor and a memory, the memory being used to store executable instructions of the processor; the processor being configured to implement the method of the first aspect described above and possible implementations thereof via executing the executable instructions.

[0008] The technical solution disclosed herein has the following beneficial effects: This paper presents an automated game development solution that parses natural language requirements into an executable task topology graph and progressively updates the game project within a strictly secure, isolated, and verified environment. This achieves low-level control and closed-loop management of the automated game development process. On one hand, it acquires game development requirements in natural language form and constructs a task topology graph with atomic operations as nodes and node dependencies by parsing this information. This transforms ambiguous, unstructured natural language requirements into a structured, executable, and logically clear atomic operation topology, laying the foundation for automated execution and solving the problem that traditional scripting solutions cannot handle dynamic, unstructured requirements. On the other hand, within a sandbox isolated from the main game project, the game engine is controlled to execute the atomic operations corresponding to the task topology graph. This obtains and verifies information containing intermediate products. Only after successful verification is the incremental information corresponding to the intermediate products merged and updated into the main game project. This ensures that potentially risky operations in the game development project (such as code compilation and asset modification) are performed within a controlled sandbox environment, guaranteeing the security and stability of the main game project. This achieves a stable, reliable, and automated game development closed loop that requires no human intervention, improving the efficiency and security of industrialized game production. Attached Figure Description

[0009] Figure 1 A flowchart illustrating a game development method according to one embodiment of this disclosure is shown; Figure 2 This diagram illustrates an HSN processing flow according to one embodiment of the present disclosure. Figure 3 This diagram illustrates an AEL processing flow according to one embodiment of the present disclosure. Figure 4 This diagram illustrates a method architecture in one embodiment of the present disclosure. Figure 5 This diagram illustrates an interactive flow in one embodiment of the present disclosure. Figure 6 This diagram illustrates a case flow diagram of one embodiment of the present disclosure; Figure 7 This diagram illustrates a case flow diagram of one embodiment of the present disclosure; Figure 8 This diagram illustrates a case flow diagram of one embodiment of the present disclosure; Figure 9 A schematic diagram of a game development apparatus according to one embodiment of the present disclosure is shown; Figure 10 A schematic diagram of an electronic device according to one embodiment of the present disclosure is shown. Detailed Implementation

[0010] Exemplary embodiments of this disclosure will be described more fully below with reference to the accompanying drawings.

[0011] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full description of the technical solutions of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted in implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0012] With the rapid development of the gaming industry, games have evolved from early 2D pixel games to today's AAA (3A) games, which feature complex physics simulations, massive amounts of high-definition art assets, and extensive narrative branches. In particular, in recent years, the popularity of massively multiplayer online role-playing games (MMORPGs), survival open-world crafting (SOC) games, and the metaverse platform has led to an exponential increase in the complexity of game development projects.

[0013] The modern game industrial pipeline is a highly coupled, multi-disciplinary collaborative system. A typical AAA game development team usually comprises hundreds or even thousands of members, covering dozens of sub-fields such as concept art, 3D modeling, level design, technical art (TA), client programming, server architecture, and quality assurance (QA). Within this massive pipeline, the following three efficiency bottlenecks exist: Asset Pipeline Bottleneck: In open-world games, tens of thousands of static meshes, skeletal meshes, high-resolution textures, and materials need to be created. While traditional procedural content generation (PCG) techniques, such as Houdini, alleviate the pressure of asset generation to some extent, their rules are highly hard-coded, lacking semantic understanding of gameplay logic, and require a high learning curve.

[0014] Logic Pipeline Bottleneck: The underlying logic and gameplay systems of a game (such as combat state machines, skill systems, and network synchronization mechanisms) are typically written in strongly typed languages ​​like C++ or C#. This code not only needs to handle complex business logic but must also strictly adhere to the lifecycle and memory management specifications of game engines (such as Unreal Engine and Unity). Any minor pointer error or state machine deadlock can cause the entire game client to crash.

[0015] Verification and Testing Bottleneck (QA Pipeline Bottleneck): The interactive state space of a game is almost infinite. Traditional automated testing typically only covers the preset linear path (Happy Path), failing to exhaust the player's free exploration in the open world. Manual testing is costly, and when faced with frequent iterations of Daily Builds, it is often difficult to perform full regression testing, resulting in a large number of hidden bugs (such as memory leaks, physics clipping, and infinite loops) entering the online version.

[0016] To address the challenges of automating game development, the industry has explored various approaches for many years, resulting in the following mainstream technical solutions: 1. Automated pipelines based on traditional macro scripts and continuous integration (CI / CD). This approach deploys continuous integration tools such as Jenkins, TeamCity, or GitLab CI, combined with pre-defined Python, Shell, or Lua scripts, to perform automated packaging, asset compliance checks (e.g., checking texture resolution and model face count compliance), and simple unit tests during nightly builds. However, this solution is a typical open-loop control system. The scripts can only strictly execute pre-defined logic and are completely unable to handle dynamic and unstructured development needs. Furthermore, it lacks dynamic reasoning and self-healing capabilities. If unexpected errors occur during execution (e.g., a newly introduced plugin causing compilation failure), the script can only passively stop and send an alert email to the developer; the system itself lacks self-healing and dynamic reasoning capabilities.

[0017] 2. Copilot code / asset generation plugins based on pure LLM (Large Language Model). Examples include GitHub Copilot, Cursor, and AI-assisted plugins for various game engines. Developers install the plugin in their IDE or game engine editor, input their natural language requirements via a dialog box, and the LLM performs inference in the cloud, returning a code snippet or generating a texture map. Developers then manually copy and paste or apply this to their project. However, the LLM only sees the static text context (Source Code Context) and does not understand the game engine's underlying runtime state (such as memory fragmentation rate, the current frame's rendering pipeline state, and the physics collision tree), leading to contextual fragmentation and runtime blind spots in its inference results. Furthermore, the code generated by the LLM often contains undefined variables, incompatible API calls, or lifecycle errors, making it difficult to compile directly in complex project contexts. Secondary review, compilation debugging, and logic verification by human experts are required, meaning true automated development cannot be achieved and still requires significant human resources.

[0018] 3. Traditional game AI based on Behavior Trees (BRTs) or Finite State Machines (FSMs). These are classic techniques used to control the behavior of Non-Player Characters (NPCs) within games. They construct logic trees through hard-coded condition nodes and action nodes. However, this approach is limited to in-game character control and cannot be applied back to the game development process itself. Furthermore, when faced with open-domain development tasks brought about by natural language, the state space of BRTs or FSMs tends to "explode," making it impossible to exhaustively enumerate all development branches and exception handling logic.

[0019] 4. Node graph systems based on Procedural Generation (PCG). For example, the PCG framework built into Houdini Engine or UE5 (Unreal Engine 5) automatically generates terrain, vegetation, and city layouts by connecting various mathematical and geometric processing nodes according to predefined rules (such as noise functions and density distributions). However, PCG systems can only handle mathematical rules and cannot understand game semantics. For instance, PCG can be used to generate forests in a game, but it's difficult to generate objects that meet specific semantic requirements (such as enemy camps that fit stealth gameplay, have visual guidance, and have a performance overhead of no more than 2 milliseconds). PCG systems can only generate static assets and cannot generate the accompanying C++ underlying logic code, network synchronization mechanisms, and UI interfaces, thus failing to form a complete game functionality loop.

[0020] In view of one or more of the above-mentioned problems, this disclosure provides a game development method. Figure 1 An exemplary process for game development is shown, including the following steps: S110, obtain game development requirements information in natural language form; S120 constructs a task topology graph with atomic operations as nodes and node dependencies by parsing game development requirements information; S130, in a sandbox isolated from the main game project, controls the game engine to execute atomic operations corresponding to the task topology graph, obtains the information to be verified, and verifies the information to be verified; the information to be verified includes intermediate products generated by executing atomic operations; S140: If the verification information passes, the game backbone project is updated based on the incremental information corresponding to the intermediate product.

[0021] Based on the above method, an automated game development solution is provided. This solution parses natural language requirements into an executable task topology graph and progressively updates the game project within a strictly secure, isolated, and verified environment, achieving low-level control and closed-loop management of the automated game development process. On one hand, it acquires game development requirements in natural language form and constructs a task topology graph with atomic operations as nodes and node dependencies by parsing this information. This transforms fuzzy, unstructured natural language requirements into a structured, executable, and logically clear atomic operation topology, laying the foundation for automated execution and solving the problem that traditional scripting solutions cannot handle dynamic, unstructured requirements. On the other hand, in a sandbox isolated from the main game project, the game engine is controlled to execute the atomic operations corresponding to the task topology graph, obtaining and verifying information containing intermediate products. Only after successful verification is the incremental information corresponding to the intermediate products merged and updated into the main game project. This ensures that potentially risky operations in the game development project (such as code compilation and asset modification) are performed within a controlled sandbox environment, guaranteeing the security and stability of the main game project. This truly realizes a stable, reliable, and automated game development closed loop that requires no human intervention, improving the efficiency and security of industrialized game production.

[0022] The following describes, in conjunction with one or more embodiments and related accompanying drawings, [the following is a description of...]. Figure 1 Each step is explained in detail.

[0023] refer to Figure 1 In step S110, game development requirements information in natural language form is obtained.

[0024] Game development requirements, expressed in natural language, can be instructions and descriptions from game planners, artists, designers, and other developers, conveyed through everyday text or voice, outlining their intentions to create, modify, or adjust game content. This information does not adhere to specific programming syntax or script formats but is presented in natural language, easily understood and expressed by humans. For example, game development requirements could be, "Generate an abandoned medieval village at world coordinates (1000, 2000, 0)," or "Create a mage's Meteor spell; meteors will fall from the sky, causing area damage." The system can receive game development requirements input by developers in natural language via a pre-defined interface, serving as the starting point for subsequent automated processing. This interface can be integrated into intelligent agents or game engines used for game development, or it can exist as a standalone application or network service.

[0025] Continue to refer to Figure 1 In step S120, by parsing the game development requirements information, a task topology graph is constructed with atomic operations as nodes and containing node dependencies.

[0026] Traditional AI code generation is typically linear, meaning the model outputs a long string of code or script. This is prone to problems like context forgetting and logical breaks when dealing with AAA game development tasks involving hundreds of steps. The embodiments disclosed in this paper abstract complex development tasks into dynamically combinable, self-growing topologies.

[0027] In this context, an atomic operation is an indivisible, minimal unit of execution defined and encapsulated by the authoritative execution layer when operating on a game engine or game project. Each atomic operation corresponds to a specific and explicit game development action, such as "loading a static mesh asset from a specified path," "instantiating an Actor at a specified coordinate position in the scene," "setting a vector parameter value for a specified material instance," or "compiling a C++ code snippet." Atomic operations can be mapped to the application programming interface of the game engine's underlying C++ core, providing a safe and controlled calling method for upper layers through encapsulation by the authoritative execution layer. The task topology graph is a structured representation of the sequence of atomic operations. It uses an atomic operation or a set of atomic operations as a node and includes node dependencies. Node dependencies define the execution order and preconditions between atomic operation nodes in the task topology graph, which can be represented as edges in the task topology graph. A node depending on another node means that the subsequent node begins execution only after the preceding node has successfully executed and produced the expected result. Dependencies ensure the logical correctness and completeness of the task execution flow.

[0028] By parsing the obtained natural language requirements, the complex development intentions they contain are broken down into a series of ordered atomic operations. The dependencies between these atomic operations are then described using a topological structure, ultimately forming a structured task topology graph. For example, the task topology graph can be a Directed Acyclic Graph (DAG), where directed edges represent dependencies between atomic operations.

[0029] In one implementation, the above-mentioned method of constructing a task topology graph with atomic operations as nodes and including node dependencies by parsing game development requirements information includes the following steps: The semantic parsing model is used to parse game development requirements information into a directed acyclic graph; Logical consistency checks are performed on directed acyclic graphs. The logical consistency check is used to verify whether the execution result of the preceding node in the directed acyclic graph provides at least some of the resources required by the subsequent node, and whether the preconditions of the subsequent node are covered by the post-effects of the preceding node. The task topology is determined based on the directed acyclic graph that has passed the logical consistency check.

[0030] The semantic parsing model can be a pre-trained deep learning model. Its role is to understand and parse game development requirements in natural language form, transforming the unstructured development intentions contained therein into a structured directed acyclic graph composed of nodes and edges. The training data for the semantic parsing model can include massive amounts of game engineering source code, blueprint logic, game design documents, and corresponding natural language descriptions, enabling the semantic parsing model to learn the mapping ability from semantic intentions to development operation sequences. For example, for the game development requirement of "generating an enemy camp with patrolling AI," the semantic parsing model can parse it into a series of atomic operation nodes such as "loading building assets," "procedurally placing buildings," "generating navigation mesh," "generating AI characters," and "setting patrol paths," and initially construct the dependencies between these nodes, such as "generating navigation mesh" depending on the completion of "procedurally placing buildings."

[0031] Logical consistency verification is performed after the semantic parsing model generates the initial directed acyclic graph (DAG). It verifies the logical executability of the DAG to ensure that the execution sequence defined in the DAG is logically consistent and implementable within the logical context of game development. The logical consistency verification process mainly includes two aspects: First, verifying whether the execution result (i.e., post-effect) of the preceding node provides at least some of the resources required for the execution of the subsequent node. For example, a node that "instantiates a torch Actor in the scene" results in the existence of a torch object in the scene, providing the necessary resource for the subsequent node "attaches a flame particle effect component to the torch Actor." If a "attach flame effect" node exists in the graph, but none of its preceding nodes result in "the existence of a torch Actor," the logical consistency verification fails. Second, verifying whether all the preconditions of each node are completely covered by the union of the post-effects of all its ancestor nodes. For example, the preconditions of the "baking navigation mesh" node include "the existence of a static mesh in the scene" and "the static mesh has generated a collider." Therefore, in a directed acyclic graph (DAG), the set of execution results of all ancestor nodes on paths pointing to the "Baking Navigation Grid" node should completely contain both conditions. If the semantic parsing model misinterprets this and attempts to execute the "Baking Navigation Grid" node before the "Import Building Model" node, the logical consistency check will find that the set of preconditions cannot be covered by the set of post-effects of the ancestor nodes, thus determining that the DAG fails the logical consistency check. This ensures the logical accuracy of the DAG.

[0032] For example, a High-level Skill Network (HSN) is constructed, which incorporates a semantic parsing model finely tuned from massive amounts of game engineering code and blueprint logic. This is used to construct the task topology map. Specifically, a game development requirement (such as generating an enemy camp with patrolling AI and destructible bunkers) is denoted as... L Define a high-level skill as... K , containing a set of nodes V (Representing executable atomic operations or sub-skills) and a set of directed edges. E (Represents the order of execution dependencies). Semantic parsing model The goal is to find a mapping function f : L → G ( V , E This results in a directed acyclic graph. G Able to cover L All the intended requirements. To ensure the generated directed acyclic graph... G Logically executable, HSN introduces a pre-condition-based approach (denoted as...). ) and post-effects (denoted as The rigorous logical calculus of .

[0033] For directed acyclic graphs G Any two nodes in v a , v b V If there exists a directed edge ( v a , v b ) E Then the following conditions must be met: (1) in, Represents a node v b The set of resources required for execution. Ancestors( v b ) represents a directed acyclic graph G All ranked in v b The previous set of ancestor nodes. The left half of the above formula represents the node. v a The execution result (post-effect) must provide at least a portion of the nodes. v b Required resources. The right half represents the node.v b All preconditions for execution A condition must be completely covered by the union of the post-effects of all its ancestor nodes; that is, the union of the post-effects must contain the precondition. .

[0034] Assumption v b It is a Bake NavMesh, and its prerequisites are... It is {a static mesh exists, and colliders have been generated}. In a directed acyclic graph. G In the middle, ranked v b The preceding ancestor nodes should contain both the "placement building model" and the "generated physical collision bounding box". If the semantic parsing model misjudges and sets the "baked navigation mesh" before the "placement building model", HSN's logic calculation game engine will immediately detect the invalid set inclusion relationship, thus blocking this error during the topology generation stage and requiring the semantic parsing model to re-plan the directed acyclic graph.

[0035] In one implementation, determining the task topology graph based on the directed acyclic graph that has passed logical consistency verification includes the following steps: If multiple directed acyclic graphs (DAGs) pass the logical consistency check, then determine the execution cost of each DAG and construct a task topology graph based on the DAG with the optimal execution cost.

[0036] For the same game development requirement, the semantic parsing model may generate multiple logically valid directed acyclic graphs (DAGs) with different execution paths and efficiencies. For example, generating a village containing multiple buildings can be done by generating all buildings first and then laying them out uniformly, or by generating and laying out each building individually. In a multi-threaded game engine environment, different task graph topologies have vastly different impacts on peak memory usage, CPU and GPU resource utilization, and overall execution time. Therefore, this implementation introduces execution cost value to quantify and evaluate the execution cost of different task topologies.

[0037] In one implementation, the execution cost can be determined based on the computational cost and execution time of the directed acyclic graph. For example, the computational cost and execution time of the directed acyclic graph can be calculated, and the two indicators can be combined by weighting to obtain the execution cost.

[0038] In one implementation, the execution cost of a directed acyclic graph (DAG) can be determined based on one or more of the following metrics: computational cost, which is the sum of the basic computing power and input / output time overhead required to execute all nodes in the topology graph; context switching penalty, which measures the pipeline stall cost caused by frequent switching between adjacent operations in the topology graph between different threads of the game engine (such as logic threads and rendering threads); redundancy penalty, which penalizes overly complex graph structures containing unnecessary operations by using information such as the in-degree variance of nodes in the graph, in order to suppress the generation of useless steps in large models; and parallelism reward, which rewards independent branches in the graph that can be executed simultaneously. The more branches and the wider the graph, the better the topology can make full use of multi-threaded concurrency and the higher the execution efficiency. By solving the problem of minimizing the execution cost, the system selects the optimal solution from multiple DAGs and constructs the final task topology graph based on the optimal DAG. This ensures that the game development task is not only logically correct, but also achieves optimal performance in terms of memory usage, execution time, and resource utilization, avoiding the problem that artificial intelligence-generated solutions are feasible but inefficient, and further enhancing the practical value of automated production.

[0039] For example, an energy function is constructed to calculate the execution cost, as shown below: (2) Among them, E( G ) represents a directed acyclic graph. G The execution value, λ , ρ , η These are weighting coefficients. Calculate the cost item. Indicates the execution node Basic computing power and memory overhead (e.g., I / O time for loading 8K textures). Context switching penalty. This represents the cost of state transitions between adjacent operations. In a game engine, if a node... u Executed in the Physical Thread, while the node... v When executed on the render thread, cross-thread synchronization can cause the pipeline to stop. Specifically designed to penalize such frequent cross-thread calls. Redundancy penalty. To penalize overly complex graph structures and suppress the generation of useless operations in large models, the Shannon entropy or the variance of node in-degree and out-degree is utilized. Parallelism reward. This is used to reward directed acyclic graphs (DAGs) with high parallelism. If the width (i.e., the number of independent branches that can be executed simultaneously) of a DAG is large, it indicates that the topology highly supports multi-threaded concurrent execution, thereby encouraging agents to generate parallelizable development pipelines.

[0040] The agent integrates an optimization solver based on a combination of beam search and graph neural network (GNN) to find the optimal solution in a vast topological space. (3) in, It is the optimal directed acyclic graph, which can be used as a task topology graph, or a task topology graph can be further constructed based on this directed acyclic graph.

[0041] In one implementation, the HSN processing flow can be referenced. Figure 2 As shown. First, enter the game development requirements. L Then, an initial set of DAGs is generated using a semantic parsing model: candidate graphs. G 1: Serial loading; candidate graph G 2: Parallel loading and baking; candidate graph G 3. Logical gaps exist. Next, the game engine will be logically verified to eliminate candidate graphs. G 3. The next step is to use the energy function E( G Evaluate the remaining candidate graphs: E( G 1) = High switching cost + Low parallelism reward; E( G 2) = Low switching cost + High parallelism reward. Solve for argminE( G According to the optimal candidate graph Construct a task topology graph.

[0042] Continue to refer to Figure 1 In step S130, the game engine is controlled to execute atomic operations corresponding to the task topology in a sandbox isolated from the main game project, to obtain the information to be verified, and to verify the information to be verified; the information to be verified includes intermediate products generated by executing atomic operations.

[0043] The game backbone refers to the main body of the game project currently under development and requiring stability. It can be a collection of all stable data and code in the current game development version. For example, the game backbone may include the following modules: a persistent storage module, containing various game project files stored on non-volatile storage media, such as game scene description files, art asset files like static meshes and skeletal meshes, source code files like C++ and shaders, and visual scripts and parameter files like blueprints and materials; a runtime memory state module, containing the complete game world runtime state loaded into memory and organized from the above files, such as all object instances in the scene graph, the collision tree and constraint system in the physics engine, the rendering dependency graph in the rendering thread, the navigation mesh data required by the navigation system, and state machine instances for various gameplay logic; and a metadata and consistency management module, containing an asset registry, object lifecycle management system, and version control metadata used by the game engine to maintain the integrity, uniqueness, and version information of the above data. The game backbone represents the production baseline in the game development process, and its stability is the core guarantee for the automated production pipeline of game development.

[0044] A sandbox, also known as a validation sandbox, is a temporary computing and simulation environment dynamically created in memory and completely isolated from the main game project. Atomic operations corresponding to the task topology graph and their intermediate products are first executed and temporarily stored in the sandbox. Intermediate products refer to various types of temporary results generated after executing atomic operations but not yet confirmed and incorporated into the main game project, such as a newly generated C++ source code file, a 3D model placed in a temporary scene, or a newly configured UI layout description data. Incremental information refers to the collection of all verified, safe, and valid modifications and additions in the sandbox environment relative to the main game project. It precisely describes which data needs to be added, modified, or deleted to update the main project from its current state to the target state.

[0045] In one implementation, an Authoritative Execution Layer (AEL) can be constructed. This AEL is a security control and execution module with the highest operational authority, built into the underlying C++ core of the game engine. It is used to operate the game engine and serves as the interaction interface between the agent and the game engine's underlying resources (such as memory, assets, and threads). The AEL is responsible for security review, authentication, scheduling, and final execution of all operation instructions from the upper layer, ensuring that operations do not compromise the stability and data integrity of the game engine's underlying structure. The AEL can control the game engine to execute atomic operations corresponding to the task topology graph within a sandbox isolated from the main game project, obtain the information to be verified, and verify that information.

[0046] In one implementation, controlling the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project includes the following steps: Mark the first memory page occupied by the game's main project as read-only; When an atomic operation to write or modify data is required, the data in the first memory page that the atomic operation needs to modify is copied to a new memory page, the atomic operation is performed in the new memory page, and the incremental information is saved.

[0047] Specifically, the data in the current state of the game's main project occupies several memory pages in physical memory; these pages are called the first memory pages. At the initial creation of the sandbox, the authoritative execution layer does not immediately perform a massive physical copy of the data. Instead, it uses the operating system's virtual memory management interface to mark all the first memory pages occupied by the game's main project as read-only. At this time, the sandbox environment shares the same physical memory data as the main project, resulting in low sandbox creation overhead. When an atomic operation performed in the sandbox requires writing to or modifying an object for the first time (e.g., modifying the coordinates of a building model), this operation triggers a write-protection exception on the first memory page containing the target object. The authoritative execution layer catches this exception and then allocates a new physical memory page for the page that triggered the exception. It copies the original data from the first memory page to the new memory page and maps the corresponding virtual address of the sandbox environment to this new memory page in the page table. Afterward, all data write and modification operations are performed on this new memory page. Thus, modifications in the sandbox are recorded as newly added memory pages, and this newly added data constitutes incremental information. This approach ensures complete logical isolation of the sandbox, while the physical memory overhead is only proportional to the amount of data modified. It provides an efficient underlying environment for high-frequency trial and error and verification, ensuring the security of the game's main project while also taking performance into account.

[0048] For example, the system may include a Progressive Loading & Auto-Verification (PLAV) module. When an agent is ready to execute a subgraph or node of the task topology, PLAV does not allow it to directly modify the main state of the game. S main Instead of a traditional sandbox, it clones a sandbox in memory within a short time (usually a few milliseconds to tens of milliseconds), which can be called a verification sandbox. To avoid copying tens of gigabytes of game project memory, PLAV uses incremental snapshots (DeltaSnapshot), as shown in the following formula: (4) At its core, PLAV utilizes the operating system's virtual memory page table remapping technology. (Main trunk state) S main The memory pages are marked as read-only. When the agent is in the sandbox... S box When an attempt is made to write to or modify an asset, a copy-on-write (COW) page fault is triggered. The system allocates a new memory page only for the first memory page that needs to be modified. The new memory page can be used to store incremental information Δ. S agent This mechanism results in low overhead for sandbox creation, allowing agents to conduct high-frequency trial and error.

[0049] In one implementation, controlling the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project includes the following steps: The receiving agent issues operation instructions based on the task topology diagram to perform atomic operations. The operation instructions include an encrypted handle formed by encrypting the memory address of the target object. The target object is a game object related to the operation instructions, and the memory address of the target object is located in the agent's dedicated memory pool. The handle authentication table is used to verify the legitimacy of the encrypted handle in order to determine the lifecycle status of the target object; If the validity check passes, the game engine will be controlled to perform atomic operations within the sandbox.

[0050] The agent is the intelligent core driving the entire automated production process. It can be one or more specially fine-tuned large language models or multimodal models, responsible for receiving the task topology diagram and generating and issuing specific operation instructions according to the order and logic in the diagram. The target object refers to the specific game object existing in the game engine that the agent wants to access or modify through the operation instructions, such as a static mesh component, a light actor, or a material instance. The agent-specific memory pool is a memory area specifically allocated in the game engine's memory by the authoritative execution layer. Game objects created by the agent through the authoritative execution layer have their underlying C++ object memory allocated in this area, physically isolated from the game engine's core memory area to prevent erroneous operations by the agent from contaminating the game engine's core. The encrypted handle is a unique, unforgeable identifier generated by the authoritative execution layer for the object during creation and returned to the agent. All subsequent operations by the agent specify the target object by providing this handle, instead of directly holding or using the original C++ pointer.

[0051] Specifically, the encrypted handle is calculated using a secure hash algorithm, taking into account factors such as the target object's real memory address, the unique identifier of the current agent session, the high-precision timestamp of the object's creation, and a game engine-level random salt value. This allows the handle to not only hide the real memory address but also bind the session creation time, preventing replay attacks and the ABA problem (where a variable's value is modified and then reverted to its original value). The handle authentication table is a crucial data structure maintained internally by the authoritative execution layer, recording the mapping relationship between all currently active encrypted handles created by agents and their real memory addresses, session identifiers, and timestamps.

[0052] When the authoritative execution layer receives an operation instruction, it parses the encrypted handle, extracts the various factors it contains, and then queries the handle authentication table for multi-dimensional legality verification: First, existence verification checks if the handle is in the active registry of the handle authentication table. If the object has been garbage collected by the game engine, the handle will be automatically unregistered, and the search will fail, indicating that the target object's lifecycle has ended. Second, session permission verification ensures that the parsed session identifier completely matches the session of the agent currently making the request, preventing unauthorized access across agents. Finally, ABA defense verification compares timestamps to ensure that the target memory address has not been reused by subsequently created objects, preventing operations on the wrong object. When all verifications pass, the authoritative execution layer restores the handle to a real C++ pointer and performs atomic operations in a secure sandbox context. This mechanism adds security checks to agent operations at the memory and pointer levels, preventing game engine crashes caused by dangling pointers, null pointers, and unauthorized access.

[0053] In one implementation, the above-mentioned verification of the validity of the encrypted handle using a handle authentication table includes the following steps: Parse the encrypted handle to obtain the target memory address, session identifier, and timestamp; Query the handle authentication table to determine whether the target memory address has been marked as destroyed by the game engine's garbage collection mechanism, determine whether the target memory address has been reused based on the timestamp, and determine whether the session identifier matches the agent; If the target memory address is not marked as destroyed or reused, and the session identifier matches the agent, then the legality check is considered successful.

[0054] For example, the authoritative execution layer first decrypts or parses the encrypted handle, extracting several core pieces of information embedded when the handle was generated: the original target memory address, the session identifier of the agent that created the object, and the creation timestamp. Next, it queries the handle authentication table using the target memory address or the handle itself as an index. The authentication process includes three parallel or sequential checks: First, it checks the game engine's garbage collection system to determine if the object corresponding to the target memory address has been marked as "pending destruction" or "destroyed." If so, the object no longer exists, and authentication fails. Second, it compares the timestamp in the handle with the creation timestamp of the last time the memory address was allocated to an object, currently recorded in the handle authentication table. If they don't match, it means the memory address was reclaimed and allocated to a new object after the original object was destroyed, exhibiting an ABA problem, and authentication fails. Third, it compares the session identifier in the handle with the session identifier of the agent currently executing the task. If they don't match, it means an agent is attempting to operate on an object created by another agent, constituting unauthorized behavior, and authentication fails. If all three checks above pass, the handle is deemed legitimate and valid, and the instruction proceeds to the subsequent security assessment and execution phase. This multi-layered verification mechanism accurately identifies and intercepts various risks arising from object lifecycle termination, memory reuse, and permission errors.

[0055] In one implementation, before executing an atomic operation, a security check is performed on the atomic operation based on the current state of the operating environment and a security boundary assessment function used to evaluate the security level of the atomic operation. If both the security check and the validity check pass, the game engine is controlled to execute the atomic operation.

[0056] The runtime environment of an atomic operation, also known as the game development environment, can be a controlled context built at the game engine's underlying layer for the execution of agent instructions. This context encompasses the real-time underlying state of the game engine when the atomic operation is executed, such as memory allocation layout, the running state and lock holding status of each thread, and the lifecycle markers of relevant game objects. Since the same atomic operation may produce different effects at different times and in different states, a safety check is performed on the atomic operation based on the current state of the runtime environment; that is, the safety of performing the atomic operation in the current state is assessed.

[0057] Safety boundary assessment functions can quantify the safety level of atomic operations. For example, a safety boundary assessment function takes the current state of the atomic operation's runtime environment and the atomic operation to be executed as input. By analyzing the distance of the atomic operation from the safety boundary in multiple dimensions such as memory access, thread synchronization, and object lifecycle, it outputs quantitative results such as a safety value. The safety boundary is a safety constraint set for the normal operation of a game engine. It can be represented by a quantified safety threshold. If the safety value output by the safety boundary assessment function is greater than the safety threshold, it means that executing the atomic operation in the current state satisfies the safety boundary and passes the safety check.

[0058] In one implementation, the computational dimensions of the safety boundary assessment function include, but are not limited to: memory boundary detection, verifying whether the memory range requested for reading and writing by the atomic operation falls entirely within the agent's dedicated memory pool to prevent it from accessing the game engine's core memory out of bounds; deadlock loop detection, by constructing a resource wait graph to detect whether the thread lock requested by this atomic operation will form a circular wait with other locks already held in the current system, thereby causing a deadlock; and lifecycle assertion, checking whether all objects involved in the atomic operation are in a lifecycle phase that can be safely accessed.

[0059] In one implementation, a deterministic state transition function can be introduced into the security check. This function defines how the state of the runtime environment should evolve after performing an atomic operation in a safe state. The security check process can be formalized as a restricted Markov decision process, and the state transition equation can be expressed as follows: when the safety value calculated by the safety boundary evaluation function is greater than a preset multidimensional safety threshold, the state of the runtime environment is allowed to change according to the deterministic state transition function; otherwise, the state of the runtime environment remains unchanged, the atomic operation is intercepted and a precise C++-level exception object (containing error type and stack information) is thrown, rather than causing the game engine process to crash directly.

[0060] Once an atomic operation instruction passes both handle authentication (legality check) and state security boundary assessment (security check), the authoritative execution layer finally schedules and executes the atomic operation in the sandbox, further enhancing the system's security and stability.

[0061] For example, AEL defines each atomic development operation of the game engine (such as instantiating an object, modifying a material parameter, or compiling a piece of logic) as a Constrained Markov Decision Process (CMDP). The underlying state space of the runtime environment for atomic operations is defined as follows: Each of the states It contains all memory snapshots, thread states, and asset registry entries for the current game engine. The set of atomic operations that an agent can invoke is defined as follows. For any given time status Operations issued by the intelligent agent Traditional game engine state transitions are fragile. In the middle, once illegal, This is the state of collapse. AEL introduces a deterministic state transition function. and multidimensional security boundary evaluation function The state transition equation for AEL is strictly defined as follows: (5) in, This is an indicator function; its value is 1 when the condition within the parentheses is met, and 0 otherwise. The multidimensional security thresholds set for the system; It is a safety boundary assessment function that pre-computes data before atomic operations actually access the game engine's core memory. Its computational dimensions include: memory boundary detection and verification. Does the requested memory read / write range fall entirely within the agent's dedicated memory pool? Deadlock and loop detection, using directed graph detection. Will it cause a circular dependency on thread locks? Lifecycle assertion, check. Has the object being operated on been marked as PendingKill?

[0062] The above formula mathematically guarantees the monotonic stability of the system. This stability is guaranteed if and only if the safety assessment function outputs a safe value... Greater than the safety threshold When the indicator function is 1, the state transition will occur (i.e., If operation There is any risk that could cause the game engine to crash (i.e.) When the indicator function is 0, the second half of the formula takes effect, and the system will maintain its original state (i.e., Meanwhile, AEL will intercept the atomic operation and throw a precise C++-level exception object (containing the error type and stack information) to the higher-level agent, instead of causing the game engine process to crash directly.

[0063] AEL introduces an Agent-specific Memory Pool (AMP) and a Handle Authentication Table (HAT). When an agent requests to create a game asset or object, AEL allocates memory for it in the AMP, but does not return a raw C++ pointer. Instead, AEL generates a unique, unforgeable encrypted handle using a cryptographic algorithm. : (6) in, It is the actual physical memory address of the object in AMP. It is a unique identifier for the current agent session, preventing unauthorized access between different agents. It is the timestamp when the object was created (accurate to the nanosecond level) to prevent the ABA problem (that is, the same memory address is freed and then reassigned to a new object, causing the old handle to be misidentified). It is a random salt value generated when the game engine starts. This indicates a bitwise XOR operation. This represents a secure hash algorithm. The generated 64-bit integer encrypted handle. This encrypted handle is returned to the agent. The agent needs to provide this handle in all subsequent operations. Before execution, AEL performs reverse parsing and strict authentication via HAT: (7) During the HAT_Lookup process, AEL performs the following verifications: existence verification, which checks whether the handle is in HAT's active registry. If the object has been garbage collected, HAT will automatically unregister the handle, in which case the lookup will fail and throw an Object_Destroyed_Exception; permission verification, the parsed SessionID must match the agent that initiated the request to prevent cross-domain tampering; ABA defense: verifying timestamp matching to ensure that the memory address has not been reused. Only after all authentications are passed will AEL restore the handle to a real C++ pointer and perform operations in a safe context. This mechanism physically isolates the agent from the game engine's core memory.

[0064] Figure 3The diagram illustrates the AEL processing flow. First, the agent initiates an operation request: Action(H_obj, Params); then, it enters the lock-free instruction queue. Next, HAT handle parsing and multi-dimensional authentication are performed. If authentication fails (e.g., the object has been destroyed, there is unauthorized access, or an ABA problem exists), an interception operation is performed, throwing an AEL_Security_Exception. If authentication succeeds, the real pointer is obtained, and security checks are performed. Furthermore, if the security check fails (e.g., there is a risk of memory overflow or deadlock), the state maintenance function is triggered. t+1 =s t If the security check passes, the operation is executed during the game engine's security frame phase, manipulating the agent's dedicated memory pool and successfully updating the game engine state. t+1 In cases of authentication failure or insecurity assessment, feedback is provided to the agent for reflection.

[0065] Game engines are highly concurrent. For example, UE5 has Game Thread (processing logic), Render Thread (handling rendering instructions), RHI Thread (communicating with the GPU), etc. If an agent's instructions are executed in the wrong thread, or if they conflict with the game engine's own logic, it will lead to a catastrophic data race. To avoid this concurrency disaster, AEL implements an instruction scheduling system based on lock-free programming and fine-grained spinlocks. In one implementation, when controlling the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, the method further includes the following steps: Monitor the safe execution window in the main loop thread of the game engine; When a safe execution window is detected and the atomic operation involves cross-thread shared resources, exclusive access to the shared resources is acquired through a fine-grained spinlock, and the exclusive access is released after the operation is completed.

[0066] The safe execution window refers to a predefined, specific phase within the main loop of each frame of the game engine, suitable for executing external modification instructions. Examples include a safe phase after physics simulation calculations are completed, before rendering instructions are submitted to the rendered image, or before garbage collection begins. The authoritative execution layer continuously monitors the game engine's main loop, and only when the game engine thread state falls within these predefined safe execution windows will it consume instructions from the agent's instruction queue and begin processing them.

[0067] The instruction queue is implemented using a lock-free circular buffer based on compare-and-swap primitives. Agents can add instructions to the queue without blocking, without affecting the game engine's main loop. When an instruction enters the execution phase, if the object to be modified is a cross-thread shared asset (e.g., a material instance being read by a rendering thread), the authoritative execution layer uses fine-grained spin locks to ensure data safety. Spin locks are associated with objects, not global locks, providing fine-grained characteristics. Before executing a modification, the system spins and waits, continuously attempting to acquire the lock on the target object. Once acquired, it exclusively gains access, safely completing the data modification within the critical section, and then immediately releases the lock. During the spin wait, CPU instructions can be paused, reducing power consumption. Through this combination of lock-free queues, a safe execution window, and fine-grained spin locks, the authoritative execution layer efficiently solves the concurrency scheduling problem in a multi-threaded environment. This ensures both the smooth operation of the game engine itself and the safe and orderly execution of agent commands, preventing underlying crashes caused by concurrency.

[0068] For example, the instruction queue issued by the intelligent agent is defined as follows: Q agent In order not to block the normal operation of the game engine, Q agent It is implemented using a lock-free ring buffer based on the CAS (Compare-And-Swap) primitive. The main loop frame time of the game engine is Δ. t AEL does not execute immediately upon receiving a command; instead, it introduces a Safe Execution Window (SEW). AEL consumes commands during specific safe phases (e.g., after physics simulation calculations are complete and before rendering commands are submitted to the Render Graph) within the game engine's Tick() function for each frame. Q agent The mathematical scheduling condition can be expressed as: (8) Among them, the security window set .

[0069] When executing specific instructions, if it is necessary to modify assets shared across threads (such as modifying a material that is being read by a rendering thread), AEL uses a spinlock mechanism, as shown in the following pseudocode: / / AEL underlying spinlock pseudocode example void AEL_ModifySharedAsset(uint64_t handle, AssetData newData) { void realPtr = HAT_Lookup(handle); std::atomic_flag assetLock = GetAssetLock(realPtr); / / Spinning and waiting until exclusive modification rights to the asset are acquired. while (assetLock->test_and_set(std::memory_order_acquire)) { / / Briefly retreat to prevent CPU from overheating due to idling. _mm_pause(); } / / Critical Section: Safely Modifying Assets ApplyDataToAsset(realPtr, newData); / / Release lock assetLock->clear(std::memory_order_release); } Through strict thread scheduling and spinlock mechanisms, AEL eliminates the underlying concurrency crash problem caused by agent operations.

[0070] In one implementation, the intermediate products include at least one of the following: code files, game scenes, and game logic information. The verification of the information to be verified includes at least one of the following methods: An abstract syntax tree is generated from the code file, and a static syntax compilation check is performed on the abstract syntax tree. Perform collision detection on scene components in the game scene; Perform reachability detection on the graph structure of game logic information.

[0071] The above methods clarify the specific technical means adopted in the verification phase for different types of intermediate products. For example, for intermediate products such as C++ code files or blueprint nodes generated by the agent, the underlying compiler frontend (such as Clang or MSVC) is invoked to parse them and generate the corresponding abstract syntax tree. Subsequently, the abstract syntax tree is traversed to check for syntax and semantic errors such as undefined variables, type mismatches, and lifecycle violations. If erroneous nodes exist in the abstract syntax tree, a weighted calculation is performed based on the severity of the error to form a compile-time loss assessment. For intermediate products such as generated game scenes, the underlying physics engine is invoked, and precise collision detection algorithms such as GJK (Gilbert-Johnson-Kerty algorithm) are used to calculate the intersection volume between all newly added or modified collider-type scene components in the game scene. If the colliders of two objects (such as two houses) overlap and the intersection volume is greater than zero, a physical clipping penalty is triggered. For game logic information, such as newly generated task flows, NPC behavior state machines, or AI pathfinding networks, they are abstracted into graph structures, and reachability matrices or pathfinding algorithms in graph theory are used to test whether key logical paths are reachable. For example, on a generated AI pathfinding network, test whether the AI ​​character can find a path to the destination from a preset starting point; or in a task state machine, test whether all task states can be reached from the initial state. If the graph structure is found to be unreachable, the verification of the game logic information is deemed unsuccessful.

[0072] In one implementation, the information to be verified also includes time-consuming and memory-consuming parameters of simulating the execution of the code file in a sandbox. The verification of the information to be verified further includes the following methods: Check whether the time consumption and memory usage parameters meet the preset conditions.

[0073] The sandbox incorporates dynamic simulation testing to expose runtime performance and memory leak issues. For example, the authoritative execution layer launches a headless simulated game environment within the sandbox, allowing virtual game characters to run scenes containing newly generated code at high frequency or for extended periods. During this time, the system continuously collects runtime performance data, primarily including time-consuming parameters and memory usage parameters. Time-consuming parameters refer to the time spent executing or rendering logic per frame; a preset condition could be that the frame time must be below a certain threshold (e.g., 16.6 milliseconds to ensure a smooth 60 frames per second experience). Memory usage parameters focus on their trend throughout the simulation cycle. Specifically, the derivative of memory usage with respect to time is calculated to determine the presence of memory leaks. If the memory usage curve shows a monotonically increasing trend during simulation (i.e., the derivative is consistently greater than zero), it strongly indicates a memory leak in the generated code, meaning dynamically allocated memory is not being properly released. Runtime performance verification is considered successful only when the time-consuming parameter consistently remains below the performance threshold, and the memory usage parameter remains stable under prolonged stress testing with its derivative approaching zero. This allows for the early detection of memory leaks and performance bottlenecks that are likely to occur online, thus improving the stability of the final game product.

[0074] In one implementation, the information to be verified is verified using the following joint verification loss function: (9) (10) (11) (12) in, To jointly verify the loss function values; α , β , γ , These are the weighting coefficients. The static compilation loss function value. e This represents an illegal node in the abstract syntax tree. This is an illegal weight. The severity of illegality. Each illegal node is calculated by weighted summation of all illegal nodes in the abstract syntax tree. e Based on its type (such as an undeclared identifier or a type mismatch), there is a preset severity level Severity(e), which is multiplied by a weighting coefficient. The final sum is obtained. The more and more serious the syntax errors in the code, the better. The larger the value, the better. This is the value of the runtime performance penalty function. NIndicates the number of frames in the simulation. Indicates the first t Frame latency As a time threshold, is the weighting coefficient, and MemUsage is the memory usage parameter. It quantifies the dynamic runtime performance and memory health of the code, consisting of two parts: the first part is the frame latency penalty, which applies to the entire simulation run. N The time consumed in each frame Exceeding the target time threshold The first part (e.g., 16.6ms) is integrated to penalize performance issues that cause screen stuttering. The second part is a memory leak penalty, which calculates the derivative of memory usage (MemUsage) with respect to time t and multiplies it by a large weighting coefficient κ. If memory usage continues to rise during the simulation, resulting in a positive and large derivative, this term will increase sharply to strongly penalize memory leaks. The physical collision loss function value. i , j This represents a scene component with two different collider types in the game scene. V i For scene components i The collision space V j For scene components j The collision space. The physical validity of the game scene was quantified by traversing all different collision pairs in the game scene. i and j ), calculate the volumes of the two colliding bodies V i and V j The volume of the intersection (triple integral). If two objects overlap through a clipping mechanism, the volume of their intersection is greater than 0, and this volume is added to the total volume. In the middle. The more severe the clipping, the better. The larger the value, the better. This represents the reachability loss function value for game logic, indicating the loss function value used to perform reachability detection on the graph structure of game logic information. For example, it can be obtained by calculating the number of nodes that are unreachable from a given starting point. Weighting coefficients are used. α , β , γ , The joint validation loss function value is obtained by weighting the four loss function values ​​mentioned above, and then assigning weight coefficients to each sub-loss function. α , β , γ , The system can flexibly adjust the emphasis on different quality dimensions. For example, in projects with high performance requirements, the emphasis can be increased. β The weight of the joint validation loss function. If the final joint validation loss function value is less than the validation threshold, then the information to be validated is determined to have passed validation.

[0075] A more stringent acceptance threshold can be set. (If close to 0), when the joint validation loss function value At that point, the system considers the information to be verified to have passed verification and the incremental information to meet industrial-grade security standards.

[0076] Continue to refer to Figure 1 In step S140, if the information to be verified passes the verification, the game backbone project is updated based on the incremental information corresponding to the intermediate product.

[0077] For example, the authoritative execution layer securely applies the incremental information previously recorded in the sandbox—that is, the data representing all modifications and additions to the game project, stored in new memory pages via copy-on-write mechanism—to the main game project. This includes writing newly generated and verified asset files to disk, persisting the modified object state in memory to the corresponding asset registry, and updating relevant data structures within the game engine. This allows the main game project to atomically migrate from its old consistent state to a new consistent state containing the required new functionality. The merge process is atomic, ensuring that the main game project is not in an incomplete or inconsistent intermediate state. After a successful update, the sandbox environment and its associated temporary data can be destroyed, freeing up computing resources. The formula for PLAV to perform a Progressive Merge is as follows: (13) Persist the changes made in the sandbox to the main project's disk (e.g., save as a .uasset or .unity file).

[0078] In one implementation, the method further includes the following steps: If the verification of the information to be verified fails, the loss information in the verification process is extracted and a structured feedback vector is generated. The structured feedback vector is input to the agent to correct the task topology graph, and atomic operations are re-executed in the sandbox based on the corrected task topology graph.

[0079] For example, if This indicates that the agent has experienced hallucinations or made a mistake. PLAV encapsulates the multidimensional loss data collected in the sandbox into a high-dimensional structured feedback vector. ): (14) The above structured feedback vector The feedback is fed back to the agent. Upon receiving the feedback, the agent triggers its internal reflection mechanism. Based on the specific error coordinates or stack trace, it modifies the code (e.g., adding delete statements) or adjusts asset parameters (e.g., shifting the clipping model 50 units along the Z-axis), and then generates a corrected subgraph. Submit it to the sandbox for verification again.

[0080] This iterative approach gives the system autonomy, enabling it to continuously refine and improve the game project without human intervention until it reaches industrial-grade standards.

[0081] In one implementation, an intelligent agent native production system was constructed, which is divided into three layers from bottom to top: the bottom layer AEL, the middle layer PLAV, and the top layer HSN. Figure 4 The diagram illustrates the methodological architecture of the agent-native production system. First, requirement parsing is performed, specifically receiving game development requirements and performing semantic mapping. Then, topology optimization is carried out, specifically generating an initial Directed Acyclic Graph (DAG), performing pre- and post-logic checks, energy function evaluation, and constructing a task topology graph based on the optimal DAG. Next, each operation in the task topology graph is executed incrementally in a closed loop. A sandbox verification mechanism is employed, including triggering copy-on-write, performing multi-dimensional joint testing, and creating incremental snapshots. Joint loss is calculated through multi-dimensional joint testing; if verification passes, incremental state merging is performed. Then, it is checked whether the task topology graph has been completed. If so, asset persistence and version control system commit are triggered; otherwise, the current skill node is extracted. If the above verification fails, structured feedback information is generated, and the agent reflects, regenerating correction instructions. The current skill node is then extracted again. After extracting the current skill node, authentication interception is performed by the Agent Array (AEL), including HAT handle parsing, permission and lifecycle verification. If AEL verification fails, a security exception is thrown; if AEL verification passes, memory pool allocation is performed and execution is initiated.

[0082] Figure 5This illustrates the interaction flow (capable of microsecond-level interaction) between the game designer / developer, the intelligent agent (e.g., a multimodal large-scale intelligent agent), HSN, PLAV, AEL, and the game engine backbone layer when handling specific tasks. First, the game designer / developer inputs game development requirements: generate a mage skill with fire effects and no memory leaks. After receiving the game development requirements, the intelligent agent calls the semantic mapping function of HSN to request the generation of a Directed Acyclic Graph (DAG). HSN processes this information and returns a task topology graph: [Write C++ class] -> [Compile] -> [Attach effect]. Then, the nodes in the task topology graph are executed through a loop. Specifically, the intelligent agent sends atomic instructions to AEL: instantiate the effect Actor; AEL performs HAT handle authentication and security boundary assessment. In the event of authentication failure, AEL intercepts and throws a C++ exception (to protect the game engine from crashing), and the intelligent agent corrects the pointer logic. If authentication is successful, AEL executes within a secure frame window, requesting a sandbox environment from PLAV. PLAV triggers copy-on-write, cloning the incremental state. AEL allocates memory and instantiates the Actor within the sandbox. PLAV accelerates the process for 1000 frames for load testing, calculating the joint loss (with a focus on monitoring memory derivatives). If a memory leak is detected based on the joint loss, PLAV sends a rejection to the agent and returns a structured feedback vector. If the joint loss verification passes, PLAV incrementally merges the sandbox into the main branch. The game engine's main branch then confirms successful node execution and advances to the next step in the task topology graph. After completing all nodes in the task topology graph through a cyclical process, HSN reports task completion to the game designers / developers, confirming that resources have been securely stored, and reporting zero crashes and zero leaks.

[0083] The following four game development case studies further illustrate this implementation method. These case studies cover level construction, underlying C++ logic development, multi-platform UI adaptation, AI pathfinding and repair, and economic system balancing, demonstrating how AEL, HSN, and PLAV work together in this implementation method to achieve zero crashes and self-healing functionality.

[0084] Case 1: Automated construction of large open-world levels and self-healing of physical clipping.

[0085] Background: In open-world games, level artists need to manually place thousands of buildings, vegetation, and objects. Traditional AI generation tools often plant trees in rocks or cause severe overlap of the colliders of two buildings (clipping), which can cause players to get stuck in the game or trigger rigid body explosions in the physics engine.

[0086] refer to Figure 6As shown, the system executes the following complete process: The game designer inputs requirements into the system via voice or text: Generate an abandoned medieval village at world coordinates (1000, 2000, 0). The village must contain 5 dilapidated houses, a well in the center, and interactive weeds around it. A navigation mesh must be baked for AI pathfinding, and no buildings can clip through each other. Then, the HSN (Hardware Service Network) parses and generates a task topology map. Specifically, the agent's semantic parsing model decomposes the task into a Directed Acyclic Graph (DAG), determining the task topology map based on the optimal DAG, for example, including: LoadAssets (medieval building set) -> ProceduralPlacement (houses and well) -> FoliageGeneration (weeds) -> BakeNavMesh (navigation mesh). Next, the AEL (Automatic Asset Loader) asynchronously loads assets and returns handles. Specifically, when executing LoadAssets, AEL asynchronously loads high-precision models directly from the game engine's Package Manager using low-level C++ pointers. AEL does not expose raw pointers to the agent but returns an encrypted handle H_asset, completely avoiding memory fragmentation at the script layer. A similar mechanism is used for other nodes. Next, the agent calculates the coordinates and places the houses. The next step is for the PLAV sandbox to calculate physical collisions and intersection volumes. After the agent executes ProceduralPlacement, PLAV clones the incremental state of that region in the memory sandbox and calls the underlying physics engine (such as Havok or Chaos) for collision detection. The system calculates the intersection volume of each house's colliders. If clipping is detected (for example, the physics engine reports that the bounding boxes of house A and house B overlap by 30%, causing the integral value of the physics loss function L_physics to surge, far exceeding the safety threshold), the system will take action. The PLAV process extracts the clipping coordinates and minimum separation vector. For example, it encapsulates the precise 3D coordinates, normal direction, and overlap depth of the clipping into a feedback vector, which is then fed back to the agent for reflection and parameter readjustment. For instance, the agent's internal spatial geometry algorithm module, upon receiving the feedback, calculates the minimum translation vector (MTV) and automatically adjusts the transformation parameters of house B (translating it 150 Unreal Units along the X-axis), then re-invokes AEL to execute the placement. If there is no clipping, a weed and baking navigation mesh is generated, and the PLAV sandbox verifies the NPC pathfinding logic. If verification fails, the navigation mesh generation parameters are adjusted; if verification succeeds, the incremental data is merged into the main scene. For example, virtual NPCs are deployed to test pathfinding. Once it is confirmed that 100% of the target points are reached, the incremental data of the entire medieval village is safely and atomically merged into the main game scene.

[0087] Case 2: Writing C++ code for automated game combat logic and troubleshooting memory leaks.

[0088] Background: The development of combat skills is the most complex part of the game logic. AI-generated code is prone to lifecycle management errors. For example, it might generate an effect actor but forget to call `Destroy()` after the effect finishes playing, causing the object to remain in memory indefinitely (memory leak). When players frequently use skills, this leak can overwhelm the player's memory within minutes, causing the game to crash (OOM Crash).

[0089] refer to Figure 7 As shown, the system executes the following complete process: Combat Planning Requirements: Create a mage's 'Meteor' skill. The spell has a 1.2-second cast time; a meteor falls from the sky, causing an explosion damage area of ​​500 radius upon impact with the ground, and generating a continuous burning particle effect at the explosion site. This burning effect lasts for 5 seconds and must be completely destroyed. HSN generates C++ code logic, which can be broken down into CreateSkillClass (C++ skill framework) -> SetProjectileMovement (projectile logic) -> ImplementRadialDamage (area damage) -> SpawnVFX (generated effects). AEL uses secure compilation at the underlying level. Specifically, the agent generates the corresponding C++ class code. AEL calls the underlying Live Coding compiler to compile in an isolated environment. If a syntax error exists, L_compile reports an error, resulting in a rewrite. After successful compilation, PLAV sandbox instantiates dummies for high-frequency casting stress testing. For example, a virtual mage continuously casts the "Meteor" skill on the dummies at a very high frequency (e.g., 10 times per second) to simulate an extreme stress test environment, monitoring memory usage and calculating derivatives. If a memory leak occurs, the system captures undestroyed Actor stacks and Timer handles. For instance, at frame 5000 of the test, PLAV's memory monitoring module calculates the time derivative of memory usage (d("MemUsage")) / dt. The system finds that although the visual component of the burning effect (Particle System) disappears after 5 seconds, its underlying C++ Actor object is not properly destroyed (because the agent forgot to unbind the Timer handle, causing GC to fail to reclaim it), and memory usage exhibits a strictly monotonically increasing trend, exceeding the L_runtime limit. The AEL layer throws a MemoryLeak_Warning. PLAV packages the exact leaked C++ class name, the unreleased memory address, and the stack trace of the most time-consuming function and feeds it back to the agent for reflection and optimization. For example, after reflection, the agent added explicit GetWorld()->GetTimerManager().ClearTimer(...) and Destroy() logic to the EndPlay lifecycle function. Then, it tests again. If the memory curve is stable, it performs logical assertions to verify whether the range damage value is correct. If correct, it is safely merged into the main C++ project.

[0090] Case Study 3: Automated UI Generation and Multi-Resolution Responsive Over-Boundary Adaptation.

[0091] Background: Modern games need to be published on PCs, consoles, and mobile devices, with screen resolutions and aspect ratios varying widely (from 16:9 for 720p to 21:9 for ultrawide monitors, and 4:3 for iPads). AI-generated UI layouts often only work correctly at specific resolutions; once the resolution is switched, UI elements will severely overlap, stretch, or extend beyond the screen boundaries.

[0092] refer to Figure 8 As shown, the system executes the following complete process: UI designer requirements: Generate a player character attribute panel, displaying a 3D model of the character on the left and progress bars for health, mana, attack power, etc., on the right. It must perfectly adapt to 1080P, 2K, 4K, and 21:9 ultrawide screens, and UI elements must not overlap or extend beyond the screen boundaries. HSN generates the UI layout and anchor point configuration, breaking down the above requirements into CreateCanvasPanel -> Place3DModelRenderTexture -> GenerateProgressBars -> SetAnchorsAndOffsets (setting anchor points). The PLAV sandbox traverses 20 resolutions for virtual rendering, detecting screen space bounding box boundaries and overlaps. For example, after the agent generates the UI blueprint, the PLAV sandbox starts the UI automation testing module. The system automatically traverses 20 preset common resolutions and aspect ratios, rendering virtual camera footage. PLAV uses image recognition and boundary detection algorithms to calculate the absolute screen space bounding box of all UI controls (widgets). If an out-of-bounds / overlapping event is detected, the system extracts the ID of the out-of-bounds control and the difference in pixels exceeding the limit, feeding this information back to the agent for reflection. The system then modifies the absolute offset to a relative anchor point. For example, during testing at a 21:9 (3440×1440) resolution, the system found that the health bar on the right side exceeded the right edge of the screen. This was because the agent incorrectly used an absolute pixel offset relative to the screen center when setting the anchor point, resulting in an excessive offset on ultrawide screens and triggering an L_logic out-of-bounds exception. The system feeds back the ID of the out-of-bounds UI control, the current anchor point configuration, and the difference in pixels exceeding the limit to the agent. The agent recognizes the error in the absolute offset and automatically changes the anchor point of the health bar from "center" to "vertically centered on the right" and changes the size setting to a relative percentage (Relative Scale). It then checks again. If the check passes (e.g., the bounding boxes of all UI controls strictly fall within the screen's safe area and there is no overlap), the UI assets are incrementally merged.

[0093] Case 4: Dynamic Repair of Automated Level Navigation Mesh (NavMesh) Based on Reinforcement Learning.

[0094] Background: In live-op games, developers often add new dynamic obstacles (such as destructible roadblocks or crashing spaceships) to existing levels. This causes the original static navigation mesh to malfunction, resulting in NPCs crashing into walls or getting stuck while navigating, severely disrupting the player experience.

[0095] Level Design Requirements: In existing complex city levels, the original static navigation mesh has become ineffective due to the addition of numerous dynamic obstacles. The AI ​​needs to automatically detect ineffective areas and generate local dynamic navigation mesh (DynamicNavMesh) repair solutions to ensure the AI ​​can find a path under any circumstances with minimal computational overhead. HSN Analysis: Decomposed into AnalyzeNavMeshInvalidation -> GenerateLocalNavMesh -> TestPathfinding -> OptimizeNavMeshCost. The AI ​​calls the underlying API to analyze the position and bounding box of all newly added dynamic obstacles in the current scene, generating an initial local navigation mesh. PLAV instantiates 100 test AIs in the sandbox, randomly generating start and end points around the obstacles, and executes A... Pathfinding Algorithm. If the test AI encounters a narrow alley (half blocked by newly added vehicles), the pathfinding algorithm may deem the alley impassable due to the excessively large cell size of the navigation grid generated by the agent, causing the AI ​​to remain stationary. The reachability matrix test fails, and L_logic reports an error. PLAV feeds back the precise coordinates of the failed pathfinding and the physical width of the alley to the agent. The agent uses the built-in reinforcement learning fine-tuning module to dynamically reduce the cell size and agent radiius parameters of the navigation grid for that local area, regenerating a more precise local grid. In subsequent tests, all 100 AIs successfully bypassed the obstacles and reached the destination. Since the accuracy was only improved locally, the overall performance overhead was small, and the final navigation grid was merged into the main game project.

[0096] In summary, the implementation method disclosed herein overcomes the limitations of traditional AI-assisted development tools, such as their incompatibility with actual engineering environments, lack of underlying awareness, and susceptibility to project crashes. It achieves innovation and improvement in dimensions such as underlying architecture, logical evolution, and verification closed loop, as detailed below: By employing the C++ Authoritative Execution Layer (AEL), Agent-Specific Memory Pool (AMP), and Hacked Handle Authentication (HAT) mechanism, the security boundaries of AI are pushed down to the lowest level of the game engine (memory and thread level). The system can physically intercept wild pointers, out-of-bounds accesses, and deadlock instructions generated by agents, ensuring the stability of the game engine and the main project.

[0097] By using High-Level Skill Networks (HSNs), the system abandons fragile linear code generation and transforms natural language requirements into rigorous Directed Acyclic Graphs (DAGs). Combining logical calculations of preconditions and postconditions with path optimization using Energy Functional, the system can handle complex and large-scale development tasks with optimal concurrency efficiency.

[0098] Through a progressive loading and automatic verification mechanism (PLAV), the system introduces a high-speed memory sandbox based on copy-on-write (COW). Every line of code and every asset generated by the AI ​​undergoes rigorous testing using a multi-dimensional joint loss function, including compile-time performance, runtime memory derivatives, and 3D physical intersection volume, before being merged into the main branch. AI illusions are blocked in the sandbox and transformed into precise structured feedback vectors, guiding the agent to reflect and correct itself.

[0099] This disclosed implementation achieves a robust and autonomous intelligent agent-native automated production line. In actual large-scale game project development, adopting this implementation can replace a large amount of tedious manual asset assembly, basic logic writing, and regression testing, reducing development costs, shortening version iteration cycles, and avoiding problems such as underlying bugs caused by human or AI errors flowing into online versions.

[0100] This disclosure also provides a game development apparatus. (See reference...) Figure 9 As shown, the game development device 900 includes: The requirement information acquisition module 910 is configured to acquire game development requirement information in natural language form; The task topology graph construction module 920 is configured to construct a task topology graph with atomic operations as nodes and containing node dependencies by parsing the game development requirement information. The sandbox verification module 930 is configured to control the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, obtain information to be verified, and verify the information to be verified; the information to be verified includes intermediate products generated by executing the atomic operations; The game backbone update module 940 is configured to update the game backbone based on the incremental information corresponding to the intermediate product if the verification of the information to be verified passes.

[0101] In one implementation, controlling the game engine to execute atomic operations corresponding to the task topology graph within a sandbox isolated from the main game project includes: receiving an operation instruction issued by an agent according to the task topology graph for executing the atomic operation, the operation instruction containing an encrypted handle formed by encrypting the memory address of a target object; the target object being a game object associated with the operation instruction, the memory address of the target object being located in an agent-specific memory pool; verifying the validity of the encrypted handle using a handle authentication table to determine the lifecycle state of the target object; if the validity verification passes, controlling the game engine to execute the atomic operation within the sandbox.

[0102] In one implementation, the step of using a handle authentication table to verify the legitimacy of the encrypted handle includes: parsing the encrypted handle to obtain a target memory address, a session identifier, and a timestamp; querying the handle authentication table to determine whether the target memory address has been marked as destroyed by the game engine's garbage collection mechanism, determining whether the target memory address has been reused based on the timestamp, and determining whether the session identifier matches the agent; if the target memory address has not been marked as destroyed, has not been reused, and the session identifier matches the agent, then the legitimacy verification is deemed successful.

[0103] In one embodiment, the device is further configured to: before executing the atomic operation, perform a security check on the atomic operation based on the current state of the operating environment of the atomic operation and a security boundary assessment function used to assess the security level of the atomic operation; the step of controlling the game engine to execute the atomic operation if the legality check passes includes: if both the security check and the legality check pass, controlling the game engine to execute the atomic operation.

[0104] In one implementation, the step of constructing a task topology graph with atomic operations as nodes and node dependencies by parsing the game development requirement information includes: parsing the game development requirement information into a directed acyclic graph using a semantic parsing model; performing a logical consistency check on the directed acyclic graph, wherein the logical consistency check is used to verify whether the execution result of the preceding node in the directed acyclic graph provides at least some of the resources required by the subsequent node, and whether the preconditions of the subsequent node are covered by the post-effects of the preceding node; and determining the task topology graph based on the directed acyclic graph that has passed the logical consistency check.

[0105] In one implementation, determining the task topology graph based on the directed acyclic graph that has passed the logical consistency check includes: if there are multiple directed acyclic graphs that have passed the logical consistency check, determining the execution cost of each directed acyclic graph, and constructing the task topology graph based on the directed acyclic graph with the optimal execution cost.

[0106] In one implementation, controlling the game engine to execute atomic operations corresponding to the task topology in a sandbox isolated from the game backbone includes: marking a first memory page occupied by the game backbone as read-only; when an atomic operation requiring data writing or modification needs to be performed, copying the data in the first memory page that the atomic operation needs to modify to a new memory page, performing the atomic operation in the new memory page, and saving the incremental information.

[0107] In one implementation, the intermediate product includes at least one of the following: a code file, a game scene, and game logic information; the verification of the information to be verified includes at least one of the following methods: generating an abstract syntax tree based on the code file, performing static syntax compilation checks on the abstract syntax tree; performing collision detection on scene components in the game scene; and performing reachability detection on the graph structure of the game logic information.

[0108] In one implementation, the information to be verified further includes time consumption parameters and memory usage parameters for simulating the execution of the code file in the sandbox; the verification of the information to be verified further includes: detecting whether the time consumption parameters and the memory usage parameters meet preset conditions.

[0109] In one implementation, the information to be verified is verified using the following joint verification loss function: ; ; ; ; in, To jointly verify the loss function values; α , β , γ , These are the weighting coefficients; Here, 'e' represents the static compilation loss function value, and 'e' represents an illegal node in the abstract syntax tree. This is an illegal weight. The severity of illegality; This represents the runtime performance penalty function value, where N represents the number of frames in the simulation. Indicates the first t Frame latency As a time threshold, Here, MemUsage is the weighting coefficient, and MemUsage is the memory usage parameter. The physical collision loss function value. i , j This represents a scene component with two different collider types in the game scene. V i For scene components i The collision space V j For scene components j The collision space; The game logic reachability loss function value represents the loss function value for reaching the graph structure of the game logic information; if the joint verification loss function value is less than the verification threshold, then the verification of the information to be verified is determined to be successful.

[0110] In one embodiment, the device is further configured to: if the verification of the information to be verified fails, extract loss information during the verification process and generate a structured feedback vector; input the structured feedback vector to the agent to correct the task topology graph, and re-execute atomic operations in the sandbox based on the corrected task topology graph.

[0111] In one implementation, when controlling the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, the device is further configured to: monitor a safe execution window in the main loop thread of the game engine; when the safe execution window is detected and the atomic operation involves cross-thread shared resources, acquire exclusive access to the shared resources through a fine-grained spinlock, and release the exclusive access after the operation is completed.

[0112] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0113] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0114] This disclosure also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the method steps of various embodiments of this disclosure.

[0115] In one implementation, the computer program product can be a tangible product, such as a computer-readable storage medium storing a computer program. The readable storage medium can be based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, and includes, but is not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. For example, the computer program product can be a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0116] In one implementation, the computer program product can be an intangible product. For example, the computer program product can be a virtual digital product, such as an executable file or installation package containing a computer program.

[0117] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0118] Computer programs can be carried or transmitted via signals such as electrical, magnetic, optical, electromagnetic, and infrared rays. Electronic devices can convert the signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, to be executed by the processor of the electronic device) the method steps of various embodiments of this disclosure, such as... Figure 1 The method and steps.

[0119] Implementing the above methods and steps through computer programs achieves the following technical effects: It provides an automated game development solution that parses natural language requirements into an executable task topology graph and progressively updates the game project within a strictly secure, isolated, and verified environment, achieving low-level control and closed-loop management of the automated game development process. On one hand, it acquires game development requirement information in natural language form and constructs a task topology graph with atomic operations as nodes and node dependencies by parsing this information. This transforms fuzzy, unstructured natural language requirements into a structured, executable, and logically clear atomic operation topology, laying the foundation for automated execution and solving the problem that traditional scripting solutions cannot handle dynamic, unstructured requirements. On the other hand, in a sandbox isolated from the main game project, it controls the game engine to execute the atomic operations corresponding to the task topology graph, obtains and verifies information containing intermediate products, and only merges and updates the incremental information corresponding to the intermediate products into the main game project after successful verification. This ensures that potentially risky operations in the game development project (such as code compilation and asset modification) are performed within a controlled sandbox environment, guaranteeing the security and stability of the main game project. This achieves a stable, reliable, and automated game development closed loop that requires no human intervention, improving the efficiency and security of industrialized game production.

[0120] In one implementation, controlling the game engine to execute the atomic operation corresponding to the task topology map in a sandbox isolated from the main game project includes: receiving an operation instruction issued by an agent according to the task topology map for executing the atomic operation, the operation instruction containing an encrypted handle formed by encrypting the memory address of a target object; the target object is a game object related to the operation instruction, and the memory address of the target object is located in the agent's dedicated memory pool; using a handle authentication table to verify the validity of the encrypted handle to determine the lifecycle state of the target object; if the validity verification passes, controlling the game engine to execute the atomic operation in the sandbox.

[0121] In one implementation, the step of using a handle authentication table to verify the legitimacy of the encrypted handle includes: parsing the encrypted handle to obtain a target memory address, a session identifier, and a timestamp; querying the handle authentication table to determine whether the target memory address has been marked as destroyed by the game engine's garbage collection mechanism, determining whether the target memory address has been reused based on the timestamp, and determining whether the session identifier matches the agent; if the target memory address has not been marked as destroyed, has not been reused, and the session identifier matches the agent, then the legitimacy verification is deemed successful.

[0122] In one embodiment, the method further includes: before executing the atomic operation, performing a security check on the atomic operation based on the current state of the operating environment of the atomic operation and a security boundary assessment function used to evaluate the security level of the atomic operation; the step of controlling the game engine to execute the atomic operation if the legality check passes includes: if both the security check and the legality check pass, controlling the game engine to execute the atomic operation.

[0123] In one implementation, the step of constructing a task topology graph with atomic operations as nodes and node dependencies by parsing the game development requirement information includes: parsing the game development requirement information into a directed acyclic graph using a semantic parsing model; performing a logical consistency check on the directed acyclic graph, wherein the logical consistency check is used to verify whether the execution result of the preceding node in the directed acyclic graph provides at least some of the resources required by the subsequent node, and whether the preconditions of the subsequent node are covered by the post-effects of the preceding node; and determining the task topology graph based on the directed acyclic graph that has passed the logical consistency check.

[0124] In one implementation, determining the task topology graph based on the directed acyclic graph that has passed the logical consistency check includes: if there are multiple directed acyclic graphs that have passed the logical consistency check, determining the execution cost of each directed acyclic graph, and constructing the task topology graph based on the directed acyclic graph with the optimal execution cost.

[0125] In one implementation, controlling the game engine to execute atomic operations corresponding to the task topology in a sandbox isolated from the game backbone includes: marking a first memory page occupied by the game backbone as read-only; when an atomic operation requiring data writing or modification needs to be performed, copying the data in the first memory page that the atomic operation needs to modify to a new memory page, performing the atomic operation in the new memory page, and saving the incremental information.

[0126] In one implementation, the intermediate product includes at least one of the following: a code file, a game scene, and game logic information; the verification of the information to be verified includes at least one of the following methods: generating an abstract syntax tree based on the code file, performing static syntax compilation checks on the abstract syntax tree; performing collision detection on scene components in the game scene; and performing reachability detection on the graph structure of the game logic information.

[0127] In one implementation, the information to be verified further includes time consumption parameters and memory usage parameters for simulating the execution of the code file in the sandbox; the verification of the information to be verified further includes: detecting whether the time consumption parameters and the memory usage parameters meet preset conditions.

[0128] In one implementation, the information to be verified is verified using the following joint verification loss function: ; ; ; ; in, To jointly verify the loss function values; α , β , γ , These are the weighting coefficients; Here, 'e' represents the static compilation loss function value, and 'e' represents an illegal node in the abstract syntax tree. This is an illegal weight. The severity of illegality; This represents the runtime performance penalty function value, where N represents the number of frames in the simulation. Indicates the first t Frame latency As a time threshold, Here, MemUsage is the weighting coefficient, and MemUsage is the memory usage parameter. The physical collision loss function value. i , j This represents a scene component with two different collider types in the game scene. V i For scene components i The collision space V j For scene components j The collision space; The game logic reachability loss function value represents the loss function value for reaching the graph structure of the game logic information; if the joint verification loss function value is less than the verification threshold, then the verification of the information to be verified is determined to be successful.

[0129] In one embodiment, the method further includes: if the verification of the information to be verified fails, extracting loss information during the verification process and generating a structured feedback vector; inputting the structured feedback vector into the agent to correct the task topology graph, and re-executing atomic operations in the sandbox based on the corrected task topology graph.

[0130] In one implementation, when controlling the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, the method further includes: monitoring a safe execution window in the main loop thread of the game engine; when the safe execution window is detected and the atomic operation involves cross-thread shared resources, acquiring exclusive access to the shared resources through a fine-grained spinlock, and releasing the exclusive access after the operation is completed.

[0131] This disclosure also provides an electronic device, which can be any one of the aforementioned terminals and servers. The electronic device includes a processor and a memory, the memory storing executable instructions of the processor; the processor is configured to implement the method steps of various embodiments of this disclosure by executing the executable instructions.

[0132] The following is for reference. Figure 10 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 10 The electronic device 1000 shown is merely an example and should not be construed as limiting the functionality or scope of this disclosure.

[0133] like Figure 10 As shown, the electronic device 1000 may include: a processor 1010, a memory 1020, a bus 1030, an I / O (input / output) interface 1040, and a network adapter 1050.

[0134] The memory 1020 may include volatile memory, such as RAM 1021 and cache unit 1022, and may also include non-volatile memory, such as ROM 1023. The memory 1020 may also include one or more program modules 1024, such program modules 1024 including, but not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 1024 may include the modules described above.

[0135] The processor 1010 may include one or more processing units, such as an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor, and / or an NPU (Neural-Network Processing Unit).

[0136] The processor 1010 can execute executable instructions stored in the memory 1020 to implement the method steps of various embodiments of this disclosure, such as... Figure 1 The method and steps.

[0137] Implementing the above method steps using processor 1010 achieves the following technical effects: It provides an automated game development solution that parses natural language requirements into an executable task topology graph and progressively updates the game project within a strictly secure, isolated, and verified environment, achieving low-level control and closed-loop management of the automated game development process. On one hand, it acquires game development requirement information in natural language form and constructs a task topology graph with atomic operations as nodes and node dependencies by parsing this information. This transforms fuzzy, unstructured natural language requirements into a structured, executable, and logically clear atomic operation topology, laying the foundation for automated execution and solving the problem that traditional scripting solutions cannot handle dynamic, unstructured requirements. On the other hand, in a sandbox isolated from the main game project, it controls the game engine to execute the atomic operations corresponding to the task topology graph, obtains and verifies information containing intermediate products, and only merges and updates the incremental information corresponding to the intermediate products into the main game project after successful verification. This ensures that potentially risky operations in the game development project (such as code compilation and asset modification) are performed within a controlled sandbox environment, guaranteeing the security and stability of the main game project. This achieves a stable, reliable, and automated game development closed loop that requires no human intervention, improving the efficiency and security of industrialized game production.

[0138] In one implementation, controlling the game engine to execute the atomic operation corresponding to the task topology map in a sandbox isolated from the main game project includes: receiving an operation instruction issued by an agent according to the task topology map for executing the atomic operation, the operation instruction containing an encrypted handle formed by encrypting the memory address of a target object; the target object is a game object related to the operation instruction, and the memory address of the target object is located in the agent's dedicated memory pool; using a handle authentication table to verify the validity of the encrypted handle to determine the lifecycle state of the target object; if the validity verification passes, controlling the game engine to execute the atomic operation in the sandbox.

[0139] In one implementation, the step of using a handle authentication table to verify the legitimacy of the encrypted handle includes: parsing the encrypted handle to obtain a target memory address, a session identifier, and a timestamp; querying the handle authentication table to determine whether the target memory address has been marked as destroyed by the game engine's garbage collection mechanism, determining whether the target memory address has been reused based on the timestamp, and determining whether the session identifier matches the agent; if the target memory address has not been marked as destroyed, has not been reused, and the session identifier matches the agent, then the legitimacy verification is deemed successful.

[0140] In one embodiment, the method further includes: before executing the atomic operation, performing a security check on the atomic operation based on the current state of the operating environment of the atomic operation and a security boundary assessment function used to evaluate the security level of the atomic operation; the step of controlling the game engine to execute the atomic operation if the legality check passes includes: if both the security check and the legality check pass, controlling the game engine to execute the atomic operation.

[0141] In one implementation, the step of constructing a task topology graph with atomic operations as nodes and node dependencies by parsing the game development requirement information includes: parsing the game development requirement information into a directed acyclic graph using a semantic parsing model; performing a logical consistency check on the directed acyclic graph, wherein the logical consistency check is used to verify whether the execution result of the preceding node in the directed acyclic graph provides at least some of the resources required by the subsequent node, and whether the preconditions of the subsequent node are covered by the post-effects of the preceding node; and determining the task topology graph based on the directed acyclic graph that has passed the logical consistency check.

[0142] In one implementation, determining the task topology graph based on the directed acyclic graph that has passed the logical consistency check includes: if there are multiple directed acyclic graphs that have passed the logical consistency check, determining the execution cost of each directed acyclic graph, and constructing the task topology graph based on the directed acyclic graph with the optimal execution cost.

[0143] In one implementation, controlling the game engine to execute atomic operations corresponding to the task topology in a sandbox isolated from the game backbone includes: marking a first memory page occupied by the game backbone as read-only; when an atomic operation requiring data writing or modification needs to be performed, copying the data in the first memory page that the atomic operation needs to modify to a new memory page, performing the atomic operation in the new memory page, and saving the incremental information.

[0144] In one implementation, the intermediate product includes at least one of the following: a code file, a game scene, and game logic information; the verification of the information to be verified includes at least one of the following methods: generating an abstract syntax tree based on the code file, performing static syntax compilation checks on the abstract syntax tree; performing collision detection on scene components in the game scene; and performing reachability detection on the graph structure of the game logic information.

[0145] In one implementation, the information to be verified further includes time consumption parameters and memory usage parameters for simulating the execution of the code file in the sandbox; the verification of the information to be verified further includes: detecting whether the time consumption parameters and the memory usage parameters meet preset conditions.

[0146] In one implementation, the information to be verified is verified using the following joint verification loss function: ; ; ; ; in, To jointly verify the loss function values; α , β , γ , These are the weighting coefficients; Here, 'e' represents the static compilation loss function value, and 'e' represents an illegal node in the abstract syntax tree. This is an illegal weight. The severity of illegality; This represents the runtime performance penalty function value, where N represents the number of frames in the simulation. Indicates the first t Frame latency As a time threshold, Here, MemUsage is the weighting coefficient, and MemUsage is the memory usage parameter. The physical collision loss function value. i , j This represents a scene component with two different collider types in the game scene. V i For scene components i The collision space V j For scene components j The collision space; The game logic reachability loss function value represents the loss function value for reaching the graph structure of the game logic information; if the joint verification loss function value is less than the verification threshold, then the verification of the information to be verified is determined to be successful.

[0147] In one embodiment, the method further includes: if the verification of the information to be verified fails, extracting loss information during the verification process and generating a structured feedback vector; inputting the structured feedback vector into the agent to correct the task topology graph, and re-executing atomic operations in the sandbox based on the corrected task topology graph.

[0148] In one implementation, when controlling the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, the method further includes: monitoring a safe execution window in the main loop thread of the game engine; when the safe execution window is detected and the atomic operation involves cross-thread shared resources, acquiring exclusive access to the shared resources through a fine-grained spinlock, and releasing the exclusive access after the operation is completed.

[0149] Bus 1030 is used to connect different components of electronic device 1000, and may include data bus, address bus and control bus.

[0150] Electronic device 1000 can communicate with one or more external devices 1100 (such as keyboard, mouse, external controller, etc.) through I / O interface 1040.

[0151] Electronic device 1000 can communicate with one or more networks via network adapter 1050. For example, network adapter 1050 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 1050 can communicate with other modules of electronic device 1000 via bus 1030.

[0152] In one embodiment, the electronic device 1000 further includes a display for displaying a graphical user interface.

[0153] although Figure 10 As not shown in the diagram, other hardware and / or software modules may also be configured in the electronic device 1000, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0154] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0155] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. A game development method, characterized in that, The method includes: Obtain game development requirements information in natural language format; By analyzing the game development requirements information, a task topology graph is constructed with atomic operations as nodes and including node dependencies. In a sandbox isolated from the main game project, the game engine is controlled to execute atomic operations corresponding to the task topology graph, obtain information to be verified, and verify the information to be verified; the information to be verified includes intermediate products generated by executing the atomic operations; If the information to be verified passes the verification, the game's main project is updated based on the incremental information corresponding to the intermediate product.

2. The method according to claim 1, characterized in that, The process of controlling the game engine to execute atomic operations corresponding to the task topology graph within a sandbox isolated from the main game project includes: The receiving agent issues an operation instruction to execute the atomic operation according to the task topology graph. The operation instruction includes an encrypted handle formed by encrypting the memory address of the target object. The target object is a game object related to the operation instruction, and the memory address of the target object is located in the agent's dedicated memory pool. The encryption handle is validated using a handle authentication table to determine the lifecycle status of the target object. If the validity check passes, the game engine is controlled to execute the atomic operation within the sandbox.

3. The method according to claim 2, characterized in that, The step of using a handle authentication table to verify the legitimacy of the encrypted handle includes: Parse the encrypted handle to obtain the target memory address, session identifier, and timestamp; The handle authentication table is queried to determine whether the target memory address has been marked as destroyed by the game engine's garbage collection mechanism, whether the target memory address has been reused based on the timestamp, and whether the session identifier matches the agent. If the target memory address is not marked as destroyed or reused, and the session identifier matches the agent, then the legality check is deemed to have passed.

4. The method according to claim 2, characterized in that, The method further includes: Before executing the atomic operation, the atomic operation is security verified based on the current state of the operating environment of the atomic operation and the security boundary assessment function used to evaluate the security level of the atomic operation. If the validity check passes, the game engine is controlled to execute the atomic operation, including: If the security check and the validity check pass, then control the game engine to execute the atomic operation.

5. The method according to claim 1, characterized in that, The process of constructing a task topology graph with atomic operations as nodes and node dependencies by parsing the game development requirements information includes: The game development requirements information is parsed into a directed acyclic graph using a semantic parsing model; The directed acyclic graph is subjected to a logical consistency check. The logical consistency check is used to check whether the execution result of the preceding node in the directed acyclic graph provides at least some of the resources required by the subsequent node, and whether the preconditions of the subsequent node are covered by the post-effects of the preceding node. The task topology is determined based on the directed acyclic graph that has passed the logical consistency check.

6. The method according to claim 5, characterized in that, Determining the task topology graph based on the directed acyclic graph that has passed logical consistency verification includes: If multiple directed acyclic graphs (DAGs) pass the logical consistency check, then the execution cost of each DAG is determined, and the task topology graph is constructed based on the DAG with the optimal execution cost.

7. The method according to claim 1, characterized in that, The process of controlling the game engine to execute atomic operations corresponding to the task topology graph within a sandbox isolated from the main game project includes: Mark the first memory page occupied by the game's main project as read-only; When an atomic operation to write or modify data is required, the data in the first memory page that the atomic operation needs to modify is copied to a new memory page, the atomic operation is performed in the new memory page, and the incremental information is saved.

8. The method according to claim 1, characterized in that, The intermediate products include at least one of the following: code files, game scenes, and game logic information; the verification of the information to be verified includes at least one of the following methods: An abstract syntax tree is generated based on the code file, and a static syntax compilation check is performed on the abstract syntax tree; Collision detection is performed on the scene components in the game scene; Reachability detection is performed on the graph structure of the game logic information.

9. The method according to claim 8, characterized in that, The information to be verified also includes the time consumption parameters and memory usage parameters of simulating the execution of the code file in the sandbox; The verification of the information to be verified also includes: Check whether the time consumption parameter and the memory usage parameter meet the preset conditions.

10. The method according to claim 9, characterized in that, The information to be verified is verified using the following joint verification loss function: ； ； ； ； in, To jointly verify the loss function values; α , β , γ , These are the weighting coefficients; The static compilation loss function value. e This represents an illegal node in the abstract syntax tree. This is an illegal weight. The severity of illegality; This is the value of the runtime performance penalty function. N Indicates the number of frames in the simulation. Indicates the first t Frame latency As a time threshold, Here, MemUsage is the weighting coefficient, and MemUsage is the memory usage parameter. The physical collision loss function value. i , j This represents a scene component with two different collider types in the game scene. V i For scene components i The collision space V j For scene components j The collision space; The game logic reachability loss function value represents the loss function value for reaching the graph structure of the game logic information. If the joint verification loss function value is less than the verification threshold, then the verification of the information to be verified is deemed successful.

11. The method according to claim 1, characterized in that, The method further includes: If the verification of the information to be verified fails, the loss information in the verification process is extracted and a structured feedback vector is generated. The structured feedback vector is input to the agent to correct the task topology graph, and atomic operations are re-executed in the sandbox based on the corrected task topology graph.

12. The method according to any one of claims 1 to 11, characterized in that, When controlling the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, the method further includes: Monitor the secure execution window in the main loop thread of the game engine; When the safe execution window is detected and the atomic operation involves cross-thread shared resources, exclusive access to the shared resources is acquired through a fine-grained spinlock, and the exclusive access is released after the operation is completed.

13. A game development apparatus, characterized in that, The device includes: The requirement information acquisition module is configured to acquire game development requirement information in natural language form; The task topology graph construction module is configured to construct a task topology graph with atomic operations as nodes and containing node dependencies by parsing the game development requirements information. The sandbox verification module is configured to control the game engine to execute atomic operations corresponding to the task topology graph in a sandbox isolated from the main game project, obtain information to be verified, and verify the information to be verified; the information to be verified includes intermediate products generated by executing the atomic operations; The game backbone update module is configured to update the game backbone based on the incremental information corresponding to the intermediate product if the verification of the information to be verified passes.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 12.

15. An electronic device, characterized in that, include: Processor and memory; The memory is used to store executable instructions of the processor; the processor is configured to implement the method of any one of claims 1 to 12 by executing the executable instructions.

Images