Program development methods, program development systems, computing devices and media

Abstract

This specification provides a program development method, a program development system, a computing device, and a medium. The program development method includes: obtaining the program architecture of a target program, the program architecture including functional modules and a control module, wherein the functional code in the functional module has a calling dependency with the control module; responding to a decoupling instruction sent by the front end for the target function, determining the target functional code, and removing the calling dependency of the target functional code; encapsulating the target functional code after the dependency is removed into an independently deployed target component, and configuring a proxy access layer for the target component; registering the proxy access layer with the control module so that the control module routes to the proxy access layer, and the proxy access layer schedules the target component. This method can decouple the functions in the original program architecture while ensuring the stable operation of the original architecture, thereby improving the optimization efficiency of the original architecture.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of program development technology, and in particular to program development methods, program development systems, computing devices and media. Background Technology

[0002] As digital cultural products operate for longer periods, the program code within them gradually accumulates, and the coupling between codes with different functions increases accordingly. This leads to problems such as extended development cycles for new features and difficulties in maintenance.

[0003] Current software development methods mainly involve refactoring existing architectures. However, for long-term digital cultural products on the market today, refactoring existing architectures (such as directly replacing the engine or resetting the project) is extremely costly and can lead to the suspension of project operations, affecting user experience.

[0004] Therefore, existing program development methods cannot efficiently develop and maintain the performance of existing digital cultural products while ensuring the stable operation of the project. Summary of the Invention

[0005] In view of the above, embodiments of this specification provide a program development method. One or more embodiments of this specification also relate to a program development system, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a program development method is provided, applied to the backend of a program development system, comprising: Obtain the program architecture of the target program, which includes functional modules and control modules. There are calling dependencies between the functional code in the functional modules and the control modules. In response to the decoupling instructions sent by the front end for the target function, determine the target function code and remove the calling dependencies of the target function code; The target functional code after dependency removal is encapsulated into an independently deployable target component, and a proxy access layer is configured for the target component; Register the proxy access layer with the control module so that the control module routes to the proxy access layer and the proxy access layer schedules the target component.

[0007] According to a second aspect of the embodiments of this specification, another program development method is provided, applied to the front end of a program development system, including: Send a decoupling instruction for the target function so that the backend executes any of the methods described above.

[0008] According to a third aspect of the embodiments of this specification, a program development system is provided, including a front-end and a back-end; The front end is configured to send decoupling commands for the target function; The backend is configured as follows: Obtain the program architecture of the target program, which includes functional modules and control modules. There are calling dependencies between the functional code in the functional modules and the control modules. In response to the decoupling instruction, identify the target functional code and remove the calling dependencies of the target functional code; The target functional code after dependency removal is encapsulated into an independently deployable target component, and a proxy access layer is configured for the target component; Register the proxy access layer with the control module so that the control module routes to the proxy access layer and the proxy access layer schedules the target component.

[0009] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which implement the steps of the above method when executed by the processor.

[0010] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0011] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0012] This specification provides a program development method according to one embodiment, applied to the backend of a program development system, including: The system obtains the target program's architecture, which includes functional modules and control modules. Functional code within the functional modules has call dependencies with the control module. Responding to decoupling instructions sent from the front end for the target function, it identifies the target functional code and removes its call dependencies. The decoupled target functional code is then encapsulated into an independently deployable target component, and a proxy access layer is configured for this component. The proxy access layer is registered with the control module, enabling the control module to route to it and the proxy access layer to schedule the target component. Based on the developers' actual needs, the system can individually extract and independently optimize high-value (urgently needing resolution) or high-performance bottleneck functions from the functional modules without requiring a global, high-risk rewrite or engine replacement. This ensures the target program's continued stable operation without excessive additional costs, allowing for independent upgrades and iterations. It reduces the coupling of the target program's architecture, lowers the learning curve for new team members, significantly improves the efficiency of new feature development and maintenance, and reduces technical debt in subsequent feature iterations. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a program development method provided in one embodiment of this specification; Figure 2 This is a flowchart of another program development method provided in one embodiment of this specification; Figure 3 This is a schematic diagram of the structure of a program development system provided in one embodiment of this specification; Figure 4 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0014] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0016] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0017] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0018] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0019] Code coupling: Code coupling refers to the interdependence between different functional modules or code segments, such that modifying or replacing one part will affect the others. For example, a module responsible for calculating damage might directly call another module responsible for UI display, making it impossible to independently modify the damage algorithm.

[0020] Program architecture: Program architecture refers to the high-level structure and organization of a software system. It defines the main components of the system, the relationships between these components, and how they collaborate to achieve system functions. For example, the architecture of a game server might include a login module, a combat module, a matchmaking module, etc.

[0021] Components: Components are independently deployable and replaceable functional units in a software system. They encapsulate specific data and functions and provide clear interfaces to collaborate with other parts. A component performs only one specific function or business domain. For example, a "collision component" can perform a collision process between different objects and obtain the collision result. Another example is that in an e-commerce system, "user authentication," "product display," and "order processing" should be divided into different components.

[0022] Frontend: The frontend is the program architecture management interface or development tool interface used by developers, operations and maintenance personnel, for sending decoupling commands, monitoring runtime status, and managing components. Examples include plugin interfaces in integrated development environments, standalone web management consoles, or command-line tools.

[0023] Backend: The backend is the program part responsible for core business logic processing, data storage, and supporting the program architecture. Examples include game server programs and data processing service engines.

[0024] Computing devices: Computing devices are computer systems designed to perform one or more specific tasks. Compared to personal mainframes, they are weaker in performance but have significant advantages in terms of size and power consumption. They are commonly used in various electronic and mechanical control systems.

[0025] Currently, classic products in the digital cultural product industry with a lifecycle exceeding 15 years generally face pressure to iterate their technical architecture. 82% of projects with an operational cycle of over ten years exhibit architectural decay issues, specifically manifested as code coupling exceeding 60%, full compilation taking over 60 minutes, and core functionality reuse rate below 20%. The main pain points are as follows: Code and technical debt: Most digital cultural products that have been operating for more than 10 years have a "code swamp". For example, a product project once had a 300% extension in the development cycle of new gameplay due to the high coupling of the script system.

[0026] Low reusability: In an early version of a product project, the same execution logic had 5 different implementations, increasing maintenance costs by 40%.

[0027] For digital cultural products operating in the current market for the long term, the cost of directly replacing the engine or resetting the project is too high (including maintaining the technical continuity of the original user ecosystem, dealing with historical technical debt, and ensuring cross-platform version compatibility). Therefore, it is necessary to design development methods that do not affect the online experience, do not add too much extra cost, and can optimize the code architecture.

[0028] Therefore, this specification provides a program development method, and also relates to a program development system, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0029] See Figure 1 , Figure 1 This specification illustrates a flowchart of a program development method according to an embodiment, applied to the backend of a program development system, comprising the following specific steps: Step 102: Obtain the program architecture of the target program. The program architecture includes functional modules and control modules. There are calling dependencies between the functional code in the functional modules and the control modules.

[0030] The embodiments in this specification apply to scenarios involving incremental refactoring and performance optimization of applications. For example, upgrading and optimizing the functionality of a digital cultural product project that has been operating for many years.

[0031] The target program is an application that requires incremental refactoring. For example, a server program for a massively multiplayer online role-playing game.

[0032] Program architecture refers to the structure and organization of a software system. It defines the various components (components, modules, services, etc.) of an application (target program), the relationships between these components (such as calls, dependencies, and data flows), and how these components collaborate to meet specific functional and non-functional requirements (such as performance, security, and scalability). For example, the program architecture of a game might include functional modules such as a "combat system module," an "economic system module," and a "social system module."

[0033] A functional module is a collection of code within a target program responsible for performing specific business functions. For example, a functional module could be a "combat damage calculation module," which includes a collection of code used to calculate the final damage values ​​of a character's attacks, defenses, critical hits, etc.; another example is a "item trading module," which includes a collection of code used to handle the transfer of item ownership, price calculation, and the saving of transaction records.

[0034] A control module is a collection of code within a target program responsible for business process control, decision-making, and state management. For example, a control module could be a "task flow controller," which includes code for determining task acceptance conditions, advancing task steps, determining task completion, and distributing rewards. Another example is a "dungeon gameplay controller," which includes code for managing the opening, progress, and settlement states of dungeons, as well as scheduling scene resources and monster behavior based on the state.

[0035] Function code is a code segment that performs a single function. For example, function code could be the code corresponding to a function that calculates the damage of a player character's skills.

[0036] A dependency is a relationship where a control module needs to execute a target function of a functional module, and must call the code corresponding to the target function in the functional module. For example, in the "Battle Flow Control Module" of the game server, to execute the target function of "Calculate Skill Damage", its code contains a call statement of damage value = damage calculation formula, which directly calls the damage calculation formula function in the "Skill Damage Calculation Module".

[0037] Optionally, one way to obtain the program architecture of the target program is to scan the source code using static code analysis tools to generate a module dependency graph. For example, tools such as Understand or Source Insight can be used to analyze the code structure. Another way to obtain the program architecture of the target program is to collect call chain data between modules through dynamic tracing technology during program runtime. For example, application performance management (APM) tools or distributed tracing systems can be used. The embodiments in this specification do not limit this approach.

[0038] For example, the target program is a game server. Static analysis revealed that its "Combat System" module (control module) directly calls the "Damage Calculation Formula" (function code). This dependency means that any modification to the skill damage calculation formula requires recompiling and re-deploying the entire combat system module.

[0039] Step 102 lays the foundation for subsequent decoupling instructions for the target function, determining the target function code, and removing the calling dependencies of the target function code by obtaining the program architecture of the target program.

[0040] Step 104: In response to the decoupling instruction sent by the front end for the target function, determine the target function code and remove the calling dependency of the target function code.

[0041] The target function is a business capability that requires independent optimization or maintenance. For example, the target function could be the "damage calculation" function in the combat system of a large game program.

[0042] Decoupling commands are triggered by developers or operations personnel through the front end, instructing the system to initiate a decoupling and refactoring process for a specified target function. For example, clicking the "Componentize the critical hit damage calculation function" button in the management backend.

[0043] The target function code is the code segment corresponding to the target function identified from the functional modules based on the decoupling instructions. For example, the algorithm function corresponding to the "critical hit damage calculation" function and its directly dependent auxiliary functions.

[0044] Optionally, in response to a decoupling instruction sent by the front end for a target function, one way to determine the target function code is to search for the target function code in a preset function-code mapping table based on the function identifier specified in the instruction. For example, the front end sends the instruction {“target”:“crit_damage_calc”}, and the back end searches for the corresponding target function code based on this instruction. Another approach is to perform dependency analysis on the code of the functional modules to automatically identify code clusters strongly related to the specified function. For example, graph analysis algorithms can be used to find the code block most closely related to the “critical hit damage” function call. This specification does not limit the implementation of this approach.

[0045] Optionally, remove the call dependencies of the target function code, including: Based on the call dependencies between the target function code and the control module, identify and decouple the call points of the target function code; Based on the call points of the decoupled target function code, a call isolation layer is generated and injected to remove the call dependencies of the target function code.

[0046] A dependency relationship is the execution logic of a control module referencing and executing a specific function in the target function code to complete its business process. For example, in the "Battle Flow Controller" of a game server, there is code that must be executed: "Damage Calculator (a function related to attack power and defense power)". This indicates that there is a dependency relationship between the control module and the "Damage Calculator".

[0047] A call point is the location within the control module where code calls the code that invokes the target function. For example, the code location of the damage calculator in the example above is a call point.

[0048] Optionally, based on the call dependencies between the target function code and the control module, one way to identify and decouple the call points of the target function code is to use static code analysis tools to scan the source code of the control module, find all function call symbols pointing to the target function code, and mark them as points to be decoupled. Another way to identify and decouple the call points of the target function code based on the call dependencies between the target function code and the control module is to perform dynamic tracing during program runtime, record all call stacks of the target function code during the actual execution of the control module, and use the call stack information to reverse locate the call points in the source code. Yet another way to identify and decouple the call points of the target function code based on the call dependencies between the target function code and the control module is to mark cross-module call instructions in the generated intermediate code or binary file during the code compilation or building phase through instrumentation or compiler plugins. This specification does not limit the scope of this method in the embodiments.

[0049] The call isolation layer is a pure interface abstract class located between the control module and the target function code. Its purpose is to inherit and redefine the original direct call relationship, and it does not contain the business implementation logic of either party. For example, a Java interface named "Damage Calculation Interface" declares the method signature (parameters and return type) of the calculation method.

[0050] Optionally, one way to generate and implant a call isolation layer based on the call points of the decoupled target function code is to create a corresponding interface method definition for each identified call point and modify the code of that call point to call this new interface method. Another way is to generate a global, unified adapter interface that covers all methods that need to be called in the target function code and uniformly replaces all scattered call points with calls to this adapter interface. Yet another way is to use aspect-oriented programming (AOP) to automatically implant proxy logic at the call points; this proxy logic is the dynamic implementation of the call isolation layer. For example, first define an aspect and declare an advice containing proxy logic within that aspect; the join points matched by this advice are all the decoupled call points. During program compilation or loading, the proxy logic is woven into each matching call point using a weaver. After weaving, the woven proxy logic becomes a dynamic instance of the call isolation layer at runtime. When the control module reaches the original call point, this instance will take over the call request, thereby severing the original direct call dependency. This specification does not limit this aspect in the embodiments.

[0051] For example, a damage calculation interface is defined as a call isolation layer between the game server's "combat system" (control module) and "damage calculation formula" (target function code). The system replaces all direct calls to the calculation function within the combat system with calls to the damage isolation proxy. At this point, the damage isolation proxy object is merely a temporary stub that records the call parameters and returns a fixed value of 0. By establishing this isolation layer, the combat system's direct dependency on the specific details of the damage calculation implementation is immediately eliminated, structurally preparing for the subsequent independent deployment of this calculation logic as a component and the configuration of a proxy layer with actual communication capabilities.

[0052] Step 104 involves responding to the decoupling instructions sent by the front end for the target function, identifying the target function code, and removing the calling dependencies of the target function code. This lays the foundation for subsequently encapsulating the target function code after the dependencies are removed into an independently deployed target component.

[0053] Step 106: Encapsulate the target functional code after dependency removal into an independently deployable target component, and configure a proxy access layer for the target component.

[0054] Dependency removal means that the control module's direct access to the target function code has been cut off.

[0055] Independent deployment means that the target component is compiled, packaged, and run in a separate process, container, or server, with its own resource space. For example, the target functionality code can be packaged into a container image.

[0056] A target component is a software unit that can run independently and provide services, formed by encapsulating the target functional code after dependency removal. For example, a target component called damage calculation.

[0057] The proxy access layer acts as a communication intermediary between the control module and the target component. Running within the control module's environment, it is responsible for translating the control module's business calls into network requests to the target component and handling communication logic such as protocol conversion and load balancing. For example, a proxy library deployed within a game server (host program) that implements a damage calculation proxy interface and communicates with a remote damage calculation service component via HTTP.

[0058] Optionally, the target functionality code after dependency removal can be encapsulated into a separately deployed target component, including: Define the contract protocol based on the target function code after dependency removal; Based on the contractual agreement, generate independently deployable target components.

[0059] A contract protocol is a file that describes the service capabilities, interface forms, data formats, and behavioral constraints provided by a target component. For example, a Java interface file that defines the signatures of all public methods.

[0060] Optionally, one way to define a contract protocol based on the target functional code after dependency decoupling is to perform static analysis on the target functional code, automatically extract its public function signatures, parameters, and return types, and generate an initial contract draft. Another way to define a contract protocol based on the target functional code after dependency decoupling is to provide an interactive contract definition tool to guide developers to manually define and improve service interfaces, data types, and constraints according to the code functionality. Yet another way to define a contract protocol based on the target functional code after dependency decoupling is to reference existing industry or enterprise standard interface specifications, adapt the target functional code to that specification, and use it as its contract protocol. This specification does not limit the scope of the embodiments described herein.

[0061] Optionally, one way to generate an independently deployable target component according to the contract agreement is to use the contract agreement as input, generate server-side framework code using a code generation tool, embed the target functional code as the core implementation within it, and finally package it into an executable file. Another way to generate an independently deployable target component according to the contract agreement is to submit the contract agreement and the target functional code together to a serverless computing platform, where the platform automatically generates scalable, event-driven function services according to the agreement. Yet another way to generate an independently deployable target component according to the contract agreement is to deploy the contract agreement as a configuration manifest, along with the container image of the target functional code, to a container orchestration platform, where the platform exposes the service according to the agreement. This specification does not limit the scope of this embodiment.

[0062] Optionally, after encapsulating the target functionality code after dependency removal into a separately deployed target component, the following may also be included: By using reflection to optimize the target function code, the values ​​of the target component's attributes during runtime can be discovered, facilitating rapid problem localization. Reflection allows the target program to obtain its own structural information (such as classes, methods, and fields) in real time during runtime and adjust its behavior based on this information.

[0063] Optionally, a proxy access layer is configured for the target component, including: Design a communication protocol based on the contractual agreement of the target component; Configure a proxy access layer for the target component according to the communication protocol.

[0064] A communication protocol is a set of rules designed based on contractual agreements for network interaction between the proxy access layer of the control module and the target component. It may include transport protocols, serialization formats, connection management, security mechanisms, and error handling conventions. For example, it might specify the use of HTTP / 2 as the transport layer and JSON as the serialization format.

[0065] Optionally, one approach to designing a communication protocol based on the contract protocol of the target component is to specify the underlying network transmission and data encoding standards on top of the contract protocol. Another approach is to select a remote procedure call framework that matches the contract protocol model and determine its specific configuration. Yet another approach is to define an asynchronous communication mode based on a message queue, including message topics, formats, routing keys, and delivery guarantees. The embodiments in this specification do not limit this approach.

[0066] Optionally, one way to configure a proxy access layer for the target component according to the communication protocol is to generate client stub code according to the communication protocol and integrate this code into the control module as its proxy access layer. Another way to configure a proxy access layer for the target component according to the communication protocol is to configure a general network proxy configuration file so that it forwards requests from the control module to the target component according to the communication protocol. Yet another way to configure a proxy access layer for the target component according to the communication protocol is to deploy a sidecar proxy for the target component in a service mesh architecture and configure traffic rules to comply with the communication protocol. This specification does not limit the embodiments in this way.

[0067] For example, the "real-time damage calculation" function includes a damage calculation function (used to calculate the original damage value based on basic attributes such as attack power and defense power), a critical hit damage determination function (used to determine whether a critical hit is triggered based on the critical hit rate and critical hit damage coefficient and calculate the damage after a critical hit), and a damage fluctuation adjustment function (used to apply a random fluctuation range to the final damage to increase the variability of combat). The backend packages the three functions of "real-time damage calculation" and their dependent libraries into an independent microservice and deploys it in a container orchestration platform cluster. At the same time, within the combat system module of the game server, a damage calculation service proxy class is automatically generated. This class calls the remote microservice through Remote Procedure Call (RPC).

[0068] Step 106 encapsulates the target functional code after dependency removal into an independently deployable target component and configures a proxy access layer for the target component. This provides a data foundation for subsequently registering the proxy access layer with the control module, enabling the control module to route to the proxy access layer and for the proxy access layer to schedule the target component.

[0069] Step 108: Register the proxy access layer with the control module so that the control module routes to the proxy access layer and the proxy access layer schedules the target component.

[0070] Optionally, registering the proxy access layer to the control module includes: Determine the injection information for the proxy access layer, and register the proxy access layer to the control module based on the injection information.

[0071] Injection information describes the configuration data required to integrate and connect the proxy access layer to the control module. For example, injection information may include: the class name or identifier of the proxy access layer instance, its key name in the dependency injection container, the endpoint address for service discovery, or its corresponding configuration file name and path.

[0072] Optionally, one way to determine the injection information of the proxy access layer is to extract the connection and configuration parameters required by the proxy access layer from the deployment description or contract agreement generated for the target component. Another way to determine the injection information of the proxy access layer is to receive user input from the front end, where the user input specifies the specific access method and parameters of the proxy access layer. Yet another way to determine the injection information of the proxy access layer is to automatically deduce the injection information of the proxy access layer based on preset naming rules or environment variables.

[0073] Optionally, one way to register the proxy access layer to the call chain of the control module based on the injection information is to instantiate the proxy access layer using the injection information and register it in the container when the dependency injection container of the control module starts. Another way to register the proxy access layer to the call chain of the control module based on the injection information is to modify the configuration file of the control module runtime, write the injection information into the configuration items, so that the control module can read and load the proxy access layer during initialization. Yet another way to register the proxy access layer to the call chain of the control module based on the injection information is to dynamically load the implementation class of the proxy access layer according to the injection information and replace the original call stubs during the runtime of the control module through dynamic code loading or reflection mechanisms. This specification does not limit this approach.

[0074] For example, when the game server starts, an instance of DamageServiceProxy is registered with the service discovery center, and the combat system module is configured so that all requests for damage calculation are sent through this proxy instance. When the combat system needs to calculate damage, it calls the IDamageCalculatorProxy interface through this proxy. The request is received by DamageServiceProxy and forwarded to the backend Damage-Calculation-Service component for execution, and the result is returned along the same path.

[0075] Step 108 registers the proxy access layer with the control module, enabling the control module to route to the proxy access layer and have the proxy access layer schedule the target component. This allows the control module's calls to the target component to change from a tightly coupled method based on direct function calls to an asynchronous and loosely coupled method through the proxy access layer, without modifying the core business logic of the control module. This achieves physical decoupling and independent deployment of business logic and functional implementation while ensuring the stability of the control module.

[0076] In the embodiments of this specification, the program architecture of the target program is obtained. The program architecture includes functional modules and control modules, and there is a call dependency between the functional code in the functional modules and the control module. In response to the decoupling instruction sent by the front end for the target function, the target functional code is determined and the call dependency of the target functional code is removed. The target functional code after the dependency is removed is encapsulated into an independently deployed target component, and a proxy access layer is configured for the target component. The proxy access layer is registered with the control module so that the control module routes to the proxy access layer, and the proxy access layer schedules the target component. It can separate and optimize target functions with high value (urgently needing to be solved) or high performance bottlenecks from the functional modules one by one according to the actual needs of the developers, without performing a global, high-risk rewrite or engine replacement. This ensures that the target function can be independently upgraded and iterated without increasing the additional cost of the target program's continuous and stable operation, reduces the coupling degree of the target program's program architecture, reduces the learning curve for new team members, significantly improves the efficiency of developing new functions for the target program and the efficiency of maintaining the target program, and reduces the technical debt of subsequent function iterations.

[0077] In one optional embodiment of this specification, before configuring the proxy access layer for the target component, the following is also included: Configure the simulation environment based on the simulation protocol of the target program; In the simulation environment, run the target component and obtain the simulation results of the target component; Configure a proxy access layer for the target component, including: If the simulation results meet the preset targets, configure a proxy access layer for the target component.

[0078] A simulation protocol is a communication contract and data format agreed upon between a target program and a target component for interaction in a simulated environment. For example, a simulation protocol defines how the simulation environment simulates a control module sending requests to a component, and how the component returns simulated responses. Its message structure is consistent with the real protocol, but may contain simulated data used for testing.

[0079] A simulation environment is a software environment used to test target components without affecting the operation of the target program. For example, a sandbox container containing a simulated database, simulated dependent services, and a lightweight runtime.

[0080] Optionally, one way to configure the simulation environment based on the target program's simulation protocol is to select a suitable simulation protocol, such as Hypertext Transfer Protocol (HTTP) or WebSocket, based on the target program's existing network protocols. Then, a simple simulation server (simulation environment) is implemented using a programming language (such as Python or Java). This simulation server is then integrated into the target program's program architecture, and the target program's running mode (online simulation mode and local simulation mode) is switched via configuration files or command-line parameters. Another way to configure the simulation environment based on the target program's simulation protocol is to directly load the simulation protocol and dynamically generate simulation stubs within the target program's test framework. For example, libraries such as Mockito (a mock object framework) can be used in the unit test framework to dynamically generate mock objects based on the interface. This specification does not limit this approach in the embodiments.

[0081] The simulation results are the output data and performance metrics generated by the target component after running in the simulation environment. For example, the average response time of the component in processing simulated requests, the CPU / memory usage rate, and the verification results of the correctness of the returned data.

[0082] The preset metrics are the performance, functional correctness, and stability thresholds that the simulation results must meet before the target component is officially connected to the system. For example, the average response time is required to be less than 50 milliseconds, the functional correctness (compared to the expected output) must reach 100%, and the peak memory usage must be less than 200MB.

[0083] For example, during the simulation verification of the "real-time damage calculation" component, the system generates 1000 simulated requests containing various boundary conditions (such as extremely high attack power and negative defense power) according to the damage calculation protocol. The simulation environment loads these requests and invokes the "real-time damage calculation" component. The simulation results show that all damage values ​​are calculated correctly, and the average processing time is 2 milliseconds, meeting the preset target of less than 5 milliseconds. Therefore, the system determines that the component meets the standard and configures a formal proxy access layer for it, connecting it to the real game server.

[0084] In the embodiments described in this specification, a simulation environment is configured based on the simulation protocol of the target program; in the simulation environment, the target component is run to obtain the simulation results of the target component; when the simulation results meet the preset indicators, a proxy access layer is configured for the target component. This enables full functional verification and performance stress testing of the newly decoupled component before it is officially run, ensuring the quality control of the reconstruction process and avoiding the risk of directly affecting the stability of the online system due to potential defects or substandard performance of the component. It also enables the complete operation of online logic in an environment away from the server, improving the local running stability of the target program.

[0085] In one optional embodiment of this specification, the simulation environment includes at least one of an online simulation environment and a local simulation environment; Based on the target program's simulation protocol, configure the simulation environment, including: According to the simulation protocol, an environment configuration file for the target program is generated, wherein the environment configuration file includes at least one of an online environment configuration file and a local environment configuration file; Configure the simulation environment for the target program based on the environment configuration file.

[0086] An online simulation environment is a test environment built on servers or clusters independent of the production environment, capable of simulating online service dependencies and data flows. For example, a Kubernetes test namespace dedicated to component integration testing, in which simulated databases and upstream and downstream services are deployed.

[0087] A local simulation environment is a lightweight simulation execution environment that runs on the developer's local computing device. Examples include an embedded simulation server launched in a local integration environment, or a target component and its simulation dependencies running in a local container using container technology.

[0088] An environment configuration file is a text file that defines the resources, service addresses, connection parameters, and startup configuration required for the mock environment. For example, a YAML file may contain the connection string for the mock database, the Uniform Resource Locator (URL) for the mock service endpoints, and the resource limits for the components.

[0089] The online environment configuration file is specifically designed for configuring and starting the online simulation environment. For example, a deployment manifest file named simulation-online.yaml.

[0090] The local environment configuration file is used to configure and start the local simulation environment. For example, an environment configuration file named docker-compose-sim-local.yml.

[0091] Optionally, one implementation for generating the target program's environment configuration file according to the simulation protocol is to parse the simulation protocol definition and automatically populate the corresponding environment configuration file using a configuration template engine. For example, the backend reads the interface definitions in the protocol and automatically generates an application.properties file containing all service endpoint placeholders. Another implementation is to provide a configuration file generation wizard that dynamically generates the corresponding environment configuration based on the user's selection of the simulation scenario (such as data volume and network latency). This specification does not limit the implementation in this way.

[0092] Optionally, one way to configure the simulation environment of the target program based on the environment configuration file is to call the corresponding orchestration tool (such as the container orchestration command-line tool Kubectl) to execute the configuration file and start the complete simulation environment. Another way is to read the environment configuration file through the target program's startup script and dynamically adjust its own connections and behaviors to adapt to the simulation environment. This specification does not limit this approach.

[0093] For example, the backend generates online environment configuration files and local environment configuration files according to the simulation protocol. When developers choose local testing, the backend executes the local environment configuration file to start a complete environment containing a simulated database and message queue locally, and then deploys the target component into it for testing.

[0094] In the embodiments described in this specification, an environment configuration file for the target program is generated according to a simulation protocol. This environment configuration file includes at least one of an online environment configuration file and a local environment configuration file. Based on the environment configuration file, the simulation environment for the target program is configured. This provides flexible and reproducible test environment setup capabilities, supporting the entire verification process from rapid local debugging to online integration testing, reducing environment preparation costs, and improving testing efficiency.

[0095] In one optional embodiment of this specification, after registering the proxy access layer to the control module, the method further includes: In response to scheduling instructions for the target component, monitor the target component's operating parameters: The runtime parameters are fed back to the front end.

[0096] A scheduling command is a command issued by the front end, instructing the back end to begin monitoring the operational status of a specific target component. For example, an administrator clicks the "Monitor Damage Calculation Service" button on the front end interface.

[0097] Optionally, in response to a scheduling instruction for the target component, one implementation for monitoring the target component's operating parameters can be to send a data collection instruction to a monitoring agent deployed on the target component via a proxy access layer, so that the monitoring agent monitors the target component's operating parameters. Another implementation can be that the performance monitoring system (e.g., the Tracy system) actively pulls or receives performance data pushes from the target component. This specification does not limit this approach in the embodiments.

[0098] Running parameters are metrics that reflect the running status of the target component, including but not limited to CPU utilization, memory usage, request processing latency, throughput, and error rate. For example, running parameters could be "CPU utilization: 45%", "request processing latency: 12 milliseconds", and "error rate: 0.1%".

[0099] Optionally, one way to feed back runtime parameters to the front end is to push the runtime parameters to the front end interface in real time for visualization via a WebSocket communication protocol. For example, the front end can draw a dynamic line chart to show changes in CPU and memory. Another approach is to store the runtime parameters in a time-series database, and the front end can retrieve and display historical and real-time data by querying the Application Programming Interface (API). This specification does not limit the implementation of this approach.

[0100] For example, the administrator issues monitoring commands to the "Matching Service" component on the front end. The back end accesses the component through its proxy layer, collects its container resource metrics and business metrics once per second, and pushes them to the front-end management panel in real time for display in the form of a dashboard.

[0101] In the embodiments described in this specification, by responding to scheduling instructions for the target component, the operating parameters of the target component are monitored; and the operating parameters are fed back to the front end, which enables real-time monitoring of the decoupled target component, allowing development or operation and maintenance personnel to perceive the health status of the component in real time, providing data support for fault diagnosis and performance debugging, and improving the observability and maintainability of each component.

[0102] In one optional embodiment of this specification, after encapsulating the target functional code after dependency removal into an independently deployable target component, the method further includes: Generate the component configuration file for the target component and monitor the component configuration file; If an update to the component configuration file is detected, the updated component configuration file will be loaded into the application architecture.

[0103] Component configuration files are metadata files that describe the configurable properties, behavioral parameters, and management interfaces of the target component. For example, a JSON file might define the component's adjustable algorithm parameters, log levels, cache size, etc.

[0104] Optionally, one way to generate a component configuration file for the target component is to perform static analysis on the source code or compiled binary file of the target component, extract its configurable constants, annotations, or specific data structures, and automatically generate a configuration file template. Another way is to provide a configuration file editor that receives user input and generates a structured configuration file. This specification does not limit this approach.

[0105] Optionally, one way to monitor component configuration files is to use a file system monitoring tool to listen for change events in the directory where the component configuration files are located. Another way is to periodically check the last modification time of the configuration files through a configuration management service. This specification does not limit the scope of this approach.

[0106] An update to a component configuration file means that the file content of the component configuration file has been modified and saved. For example, an operations and maintenance personnel might modify a parameter value in the component configuration file and then save it.

[0107] The updated component configuration file is a new version of the component configuration file with changed content.

[0108] Optionally, one way to load the updated component configuration file into the program architecture is to send a signal to the target component or call its management interface to trigger a hot reload of the new configuration file. For example, sending a SIGHUP signal to the component process. Another approach is to distribute the new configuration parameters to the target component through a proxy access layer. This specification does not limit the implementation of this approach.

[0109] For example, the backend generates a component configuration file for the "anti-fraud detection" component. When the operations and maintenance personnel change the "sensitivity threshold" in the component configuration file from 0.8 to 0.9 and save it, the backend detects the file change and immediately issues the new configuration through the component's management interface. The component applies the new threshold without restarting.

[0110] In the embodiments of this specification, by generating a component configuration file for the target component and monitoring the component configuration file; when an update to the component configuration file is detected, the updated component configuration file is hot-loaded into the program architecture, which enables hot updating of component configuration. This allows the target program to quickly adjust component behavior without downtime, avoids the recompilation efficiency loss caused by changes in the component configuration file, and improves the flexibility and response speed of the target program in dealing with strategy changes and performing online optimization.

[0111] In one optional embodiment of this specification, after generating the component configuration file for the target component, the method further includes: Based on the component configuration file, construct the front-end interactive interface of the target component; Feedback is provided to the front-end interactive interface so that the front-end can configure the target component through the front-end interactive interface.

[0112] The front-end interactive interface is a graphical user interface automatically generated based on the metadata of the component configuration file, allowing users to interact with the components (view, configure, and manage). For example, a World Wide Web (Web) page contains forms, buttons, and charts.

[0113] Optionally, one way to construct the front-end interactive interface of the target component based on the component configuration file is to use a front-end user interface (UI) framework to dynamically render the corresponding forms and controls according to the JSON schema specification of the configuration file. For example, based on the parameter type (such as number, string, boolean), it can be rendered as an input box, drop-down list, or switch. Another approach is to provide a general-purpose interface rendering engine that parses the configuration file and generates the corresponding HTML interface. This specification does not limit this approach.

[0114] For example, the backend reads the configuration file of the "Sound Effects Service" component, which defines parameters such as "volume level" and "playback mode". Based on this configuration file, the backend automatically generates a web interface containing a slider (for volume) and a group of radio buttons, and sends it back to the frontend management backend.

[0115] This embodiment constructs a front-end interactive interface for the target component based on the component configuration file; the front-end interactive interface is then fed back to the front end, allowing the front end to configure the target component through the interface. This improves the development efficiency of the target program's interactive interface, automates and reduces coding in configuration management, lowers the technical threshold for configuring and managing components, improves operational efficiency, and enhances the consistency of component configuration operations.

[0116] In one optional embodiment of this specification, the component configuration file includes configuration parameters and control parameters, and the front-end interactive interface includes a first front-end interactive interface corresponding to the configuration file and a second front-end interactive interface corresponding to the target component. Based on the component configuration file, construct the front-end interactive interface of the target component, including: Based on the configuration parameters in the component configuration file, a first front-end interactive interface corresponding to the component configuration file is constructed so that the front end can update the data in the configuration file through the first front-end interactive interface; Based on the control parameters in the component configuration file, a second front-end interactive interface corresponding to the target component is constructed so that the front-end can manage the target component through the second front-end interactive interface.

[0117] Configuration parameters are numerical values ​​or options used to define and adjust the business behavior and functional characteristics of target components. Examples include algorithm coefficients, timeout periods, resource limits, and feature on / off switches.

[0118] Control parameters are configuration information describing the management instructions for the target component and their invocation methods. The configuration information defines how the front-end interface is constructed and sends control instructions. For example, a control parameter can be defined as {"action": "restart", "method": "POST", "endpoint": " / api / component / restart"}.

[0119] The first front-end interactive interface is a configuration management interface mainly used for displaying and editing configuration parameters. For example, a "Parameter Settings" page containing multiple tabs and forms.

[0120] The second front-end interactive interface is a console interface primarily used to send control commands and view the runtime status of components. For example, a "Service Control" panel containing start / stop buttons and status indicator lights.

[0121] Optionally, one way to construct the first front-end interactive interface corresponding to the component configuration file based on the configuration parameters in the component configuration file is to classify and group the configuration parameters, generate a configuration panel for each group, and generate corresponding UI controls and validation logic for each parameter according to its type and constraints. For example, numeric parameters generate input boxes with step and range validation, and enumeration parameters generate drop-down lists. This specification does not limit this approach.

[0122] For example, for a "database connection pool" component, its configuration parameters (such as maximum number of connections and minimum number of idle connections) are generated in a "connection pool configuration" page (first interface) for users to adjust; its control parameters (such as immediately reclaiming all connections and refreshing statistics) are generated in a "connection pool control" panel (second interface) for users to operate.

[0123] Optionally, one implementation of constructing a second front-end interactive interface corresponding to the target component based on the control parameters in the component configuration file can generate a clickable button or trigger area for each control command, and add a confirmation dialog box based on the side effects of the command (such as whether it is a dangerous operation). For example, the "Restart" button will pop up a confirmation prompt. This specification does not limit this aspect.

[0124] In the embodiments of this specification, a first front-end interactive interface corresponding to the component configuration file is constructed based on the configuration parameters in the component configuration file, so that the front end can update the data in the configuration file through the first front-end interactive interface; a second front-end interactive interface corresponding to the target component is constructed based on the control parameters in the component configuration file, so that the front end can manage the target component through the second front-end interactive interface. This can separate the "configuration" and "control" responsibilities of the component, provide users with an intuitive, safe and efficient management experience, reduce the risk of misoperation, and improve the development efficiency of complex interfaces in the UI system and combat system.

[0125] In one optional embodiment of this specification, after registering the proxy access layer to the control module, the method further includes: Generate a component manager corresponding to the target component on the control module, so that the front end can manage the lifecycle of the target component by scheduling the component manager through the control module.

[0126] The component manager is a program module used to manage the lifecycle and scheduling state of one or more target components. For example, the component manager is used to manage the starting and stopping of a "collision component".

[0127] Optionally, one implementation for generating a component manager corresponding to a target component on the control module can be to dynamically create and compile the source code of the component manager using code generation technology based on the type of the target component and the definition of the proxy access layer, and then load it into the runtime of the control module. For example, the manager class can be dynamically generated and compiled using a Java application programming interface. Another implementation can be to provide a general manager framework and instantiate manager instances for specific components through configuration files. For example, a general manager framework can be pre-defined in the control module, which defines the general logic, interfaces, and infrastructure required to manage the lifecycle of components. Then, a corresponding configuration file can be provided for each target component that needs to be managed. This configuration file describes the unique identifier of the target component, its proxy access layer connection endpoint, and resource restriction policies, etc. When the control module receives a management instruction, the manager framework reads and parses the above configuration file, creates a manager instance for the target component according to the description in the configuration file, and registers the manager instance in the internal management service bus or registry of the control module. This specification does not limit this embodiment.

[0128] The lifecycle is the runtime of a target component from startup, running, paused, to stopping. Managing the lifecycle includes triggering state transitions, monitoring the current state, and recovering from abnormal states.

[0129] Optionally, one implementation of the front-end managing the lifecycle of the target component through the control module and scheduling component manager is that the front-end sends a request to the control module to schedule a "collision component," and the control module forwards the request to the corresponding component manager for execution. Another implementation is to send lifecycle management instructions through a message queue, with the component manager subscribing to and executing them. This specification does not limit the implementation to these methods.

[0130] For example, a dedicated cross-server matchmaking manager is generated in the game server (control module) for the "cross-server matchmaking" component. When the administrator clicks "Restart Matchmaking Service" in the front end, the request is routed to the manager via the game server. The manager then sequentially performs the operations of stopping the old instance, starting the new instance, and verifying that the service is ready.

[0131] In the embodiments described in this specification, a component manager corresponding to the target component is generated on the control module, enabling the front end to manage the lifecycle of the target component through the control module's scheduling of the component manager. This achieves centralized and automated lifecycle management of the decoupled components, encapsulating complex operation and maintenance operations into simple interface commands, thereby improving the system's maintainability and reliability.

[0132] In one optional embodiment of this specification, removing the call dependency of the target function code includes at least one of the following: Replace the function calls to the target function code in the control module with interface calls to the proxy access layer; Remove direct references from the control module to the target function code; Extract access permissions to environmental resources in the target program from the target function code.

[0133] For example, replacing function calls to the target function code in the control module with interface calls to the proxy access layer involves: locating all calls to the target function code in the control module's source code and replacing those calls with calls to a predefined proxy interface. This proxy interface currently lacks a concrete implementation or is merely a simple log stub; the actual logic for communicating with independent components through the proxy access layer will be configured in subsequent steps.

[0134] For example, removing direct references from the control module to the target function code involves deleting direct references to header files, library files, or modules containing the target function code from the control module's compiler dependencies or module reference list. Simultaneously, ensure that all source code of the control module no longer contains direct uses of classes, functions, or variables in the target function code (i.e., these have been replaced with interface calls in the previous step).

[0135] For example, the access permissions to environmental resources in the target program are extracted from the target function code as follows: All operations in the target function code that directly access the program's global environmental resources are identified, such as reading the global configuration manager, writing to a shared log file, and calling platform-specific APIs. These operations are encapsulated into a set of explicit resource access interfaces, and the direct operations on resources in the function code are replaced with calls to these interfaces. The original direct access logic is moved to the implementation section of these interfaces, thereby severing the tight coupling between the function code and specific environmental resources in the code logic.

[0136] Optionally, in one optional embodiment of this specification, removing the call dependency of the target function code includes: isolating the target function code through an object-oriented mechanism to remove the call dependency of the target function code.

[0137] Object-oriented mechanisms utilize principles and techniques from object-oriented programming, such as encapsulation, inheritance, polymorphism, and dependency injection. For example, an object-oriented mechanism can encapsulate functional code in an independent class and abstract its behavior through an interface, so that the control module depends only on the interface rather than the specific implementation.

[0138] For example, the "payment verification" logic, which was originally scattered across multiple files, is extracted and encapsulated into a class named "Payment Validator," and a payment validator interface is defined. All related calls in the control module are then replaced with calls to this interface, thereby eliminating the dependency on the specific verification logic.

[0139] The embodiments in this specification enable preliminary decoupling at the code level in a standard and controllable manner, laying a solid foundation for subsequent physical isolation and proxy layer configuration, and ensuring the readability and maintainability of the refactoring process.

[0140] In one optional embodiment of this specification, after registering the proxy access layer to the control module, the method further includes: Monitor the performance parameters of the target program during runtime, and determine the functional code to be optimized based on the performance parameters; Send the code of the function to be optimized to the front end so that the front end can determine whether the code of the function to be optimized needs to be configured with a proxy access layer and register the proxy access layer with the control module.

[0141] Performance parameters are quantitative indicators that reflect the execution efficiency, resource consumption, and stability of a target program during its operation. Examples include the call frequency, average execution time, CPU cycle usage, and memory allocation rate of a specific function or module.

[0142] The code to be optimized refers to code segments identified, based on performance parameter analysis, as having performance bottlenecks, excessive resource consumption, or a significant negative impact on overall system performance. For example, the code to be optimized could be a "pathfinding algorithm" function that, according to performance profiling, accounts for more than 20% of the total time spent on the process.

[0143] Optionally, one way to monitor the performance parameters of a target program during runtime is to implant performance probes on the program's critical path or to use APM tools for non-intrusive sampling. For example, a Java Agent can be used in conjunction with an APM tool for tracing. Another approach is to collect data through the operating system's performance counters or performance analysis interfaces provided by the runtime. This specification does not limit this approach.

[0144] Optionally, one way to determine the code to be optimized based on performance parameters is to set a performance threshold and automatically alert and mark functions or modules that exceed the threshold. For example, the code corresponding to an interface with an average response time exceeding 100 milliseconds can be marked as needing optimization. Another approach is to use performance profiling tools to generate a flame graph, and manually or through algorithms identify the code corresponding to the widest "flame" in the graph. This specification does not limit this approach.

[0145] For example, when the backend monitors the performance parameters of the target program during runtime, it finds that the CPU utilization of the "scene loading" module consistently exceeds 70% during peak periods. Through analysis, it is located that the "texture merging" function in the target program has the longest execution time. Therefore, the backend identifies the "texture merging" function as the code to be optimized and pushes its information to the frontend management interface.

[0146] In the embodiments described in this specification, performance parameters of the target program during runtime are monitored, and the functional code to be optimized is determined based on these parameters. The functional code to be optimized is then sent to the front end, allowing the front end to determine whether the functional code needs to be configured with a proxy access layer and to register the proxy access layer with the control module. This approach proactively identifies performance bottlenecks in the target program and intelligently recommends candidate targets for decoupling and refactoring, assisting developers in formulating optimization strategies and thus efficiently further optimizing the target program.

[0147] In one optional embodiment of this specification, the target program includes a game program, the control module includes a game task flow control module, and the physically isolated components include game scene components and game object components. The method further includes: A state machine is constructed based on the calling relationships between the process control module, game scene components, and game object components. Inject the state machine into the flow control module so that the flow control module can call the game scene components and game object components through the proxy access layer based on the current state of the state machine.

[0148] Flow control modules (such as Missions) are modules in a game responsible for driving and managing the execution order and rules of specific gameplay or tasks. For example, a flow control module could be a "dungeon challenge flow controller" or a "main quest guide".

[0149] Game scene components (such as Cells) are independent components that encapsulate the logic and resources related to a specific game scene (such as a snowfield, desert, or instance room). For example, the "Snowfield Battlefield Scene Service" is responsible for weather simulation, terrain collision, and exclusive rules for that scene.

[0150] Game object components are independent components that encapsulate the behavioral logic and data of specific types of game objects (such as non-player characters (NPCs), monsters, and treasure chests). For example, the "intelligent NPC behavior service" is responsible for NPC dialogue, pathfinding, and combat.

[0151] The call relationship refers to the logical sequence dependency of the flow control module when it needs to call different game scene or game object functions at different nodes to advance the process. For example, the "entering the instance" stage requires calling the loading interface of the "instance scene" component, and the "triggering the BOSS battle" stage requires calling the generation and activation interface of the "BOSS monster" component.

[0152] A state machine is a mathematical model used to represent the transitions of a process control module between a finite number of states, where state transitions are usually triggered by events, and each state can be associated with a specific action that needs to be performed.

[0153] Optionally, one implementation of the state machine based on the calling relationships between the flow control module, game scene components, and game object components can be to define each key step of the flow as a state, define the transition conditions between steps as events, and encapsulate the component interfaces that each state needs to call as actions to be performed when "entering the state". For example, using a state machine library, the states can be defined as: Idle → Start Event → Load Scene → Scene Loading Complete Event → Generate Enemy. This specification does not limit this implementation.

[0154] Optionally, one way to inject a state machine into the process control module is to use the state machine instance as the core driving engine of the process control module, with the state machine taking over the process's execution logic. For example, the main logic of the refactored process control module becomes "receive an event → drive the state machine → execute the action output by the state machine (call the proxy layer)". Another approach is to design the state machine as a pluggable plugin and integrate it into the process control module through configuration. This specification does not limit the implementation of this approach.

[0155] In one optional embodiment of this specification, the target program is a game program, the control module is a skill control system in the game, and the physically isolated components include skill components and status effect components.

[0156] The skill control system is a program responsible for managing the decision-making logic of skill release, including processes, conditions, global cooldowns, and target selection. For example, it determines whether the player meets the conditions for releasing "Fireball" (mana points, presence of enemies within range) and decides when the skill takes effect and its initial target.

[0157] Skill components are functional components that encapsulate specific skills and numerical calculation logic. For example, the "Fireball component" is responsible for calculating the fireball's trajectory, collision detection, and the direct damage and ignition probability upon impact.

[0158] Status effect components are functional components that encapsulate the logic for applying, refreshing, taking effect, and removing persistent statuses (Buffs / Debuffs). For example, the "Ignite effect component" is responsible for managing the duration of Ignite, the damage calculation per tick, and the mutual exclusion or stacking rules that may exist with other effects (such as the "Frost" effect).

[0159] In the embodiments described in this specification, the above-described scheme physically isolates and decouples the skill control process from the specific implementation of skills and status effects. This significantly improves the reusability of skill and status effect components, reduces the writing of repetitive code, and facilitates unified management and adjustment of these components, enhancing game balance and playability. Furthermore, it allows game designers to independently adjust or add skill effects without modifying or even recompiling the core combat control system, improving the flexibility and efficiency of game content iteration.

[0160] For example, for a "escort character A" task, the constructed state machine includes states such as waiting to start, moving, encountering combat, and completing the task. When the state machine is in the moving state, the flow control module calls the "NPC movement" component through the proxy layer; when it transitions to the encountering combat state, it calls the "monster spawning" component and the "combat scene" component.

[0161] In the embodiments described in this specification, a state machine is constructed based on the calling relationships between the flow control module, game scene components, and game object components. This state machine is then injected into the flow control module, enabling the module to call the game scene components and game object components through a proxy access layer based on the current state of the state machine. This achieves a high degree of separation between the flow logic and the specific scene / object implementation, decoupling gameplay logic from scene entities. This reduces the need for repeatedly developing gameplay logic solutions for different scenes, allowing gameplay design to be developed and reused independently of specific content, thus improving the efficiency of game content production and the scalability of the system.

[0162] In one optional embodiment of this specification, the target program includes multiple rendering tasks, and the program development method further includes: rendering the multiple rendering tasks in the target program using multi-threaded rendering technology, specifically including: Obtain the rendering flow of multiple rendering tasks in the target program; Analyze the rendering process and determine parallel rendering tasks based on the analysis results; Render the parallel rendering task.

[0163] A rendering task is an independent computational unit with defined inputs and outputs that is executed within the graphics rendering pipeline to generate a final frame of image. Examples include calculating vertex transformations for all objects in a scene, calculating shadow maps for specific light sources, and performing blurring post-processing on the rendered target.

[0164] Parallel rendering tasks are those that have no data dependencies on each other or whose dependencies can be efficiently synchronized, and therefore can be simultaneously scheduled to be executed on different computing units (such as CPU threads or GPU computing queues). For example, "shadow calculation for light source A" and "shadow calculation for light source B" are usually independent and can be performed in parallel; "background skybox rendering" and "opacity object rendering" can also be performed in parallel with proper barrier settings because they are written to different rendering buffers and depths.

[0165] Optionally, the rendering process can be analyzed, and based on the analysis results, one approach to implementing parallel rendering tasks is to construct a directed acyclic graph (DAG) of the rendering tasks, where nodes represent tasks and edges represent data dependencies between tasks (e.g., task B requires the output of task A as texture input). By analyzing this graph, the set of nodes with zero in-degree or no path connection between them is identified as candidate tasks that can be executed in parallel. For example, if the analysis reveals that there are no dependent edges between the "shadow map generation" task and the "depth pre-rendering" task, they can be identified as parallel rendering tasks.

[0166] Analyzing the rendering process, another way to implement parallel rendering tasks is to analyze the binding state of rendering resources. Rendering tasks that use completely independent, non-overlapping rendering resources (such as framebuffers, textures, and constant buffers) are identified as parallelizable tasks. For example, if task 1 uses only rendering target A and texture set X, while task 2 uses only rendering target B and texture set Y, then they can be determined to be parallelizable.

[0167] Analyzing the rendering process, another approach to implementing parallel rendering tasks is determined based on the analysis results: heuristic analysis based on historical execution data. Performance profiling tools are used to collect the execution time and resource access patterns of each task in multi-frame rendering. Machine learning models are then used to predict the parallelism potential and benefits between tasks, and parallel strategies are determined accordingly. For example, if backend analysis reveals that "particle system update" and "ambient occlusion calculation" rarely compete for the same resource and have stable execution times in historical data, they can be identified as a stable pair of parallel rendering tasks.

[0168] In the embodiments of this specification, by obtaining the rendering flow of multiple rendering tasks in the target program, analyzing the rendering flow, determining parallel rendering tasks based on the analysis results, and rendering the parallel rendering tasks, it is possible to identify rendering tasks that can be processed in parallel, thereby allocating the rendering tasks to different threads for processing, improving rendering efficiency, ensuring synchronization and coordination between different threads, and avoiding rendering errors and data inconsistencies.

[0169] Indicatively, Figure 2 This specification illustrates a flowchart of another program development method provided in one embodiment, applied to the front end of a program development system, including: Step 202: Send a decoupling instruction for the target function so that the backend executes any of the above-described program development methods.

[0170] In the embodiments of this specification, by sending decoupling instructions for the target function, the backend executes any of the above-mentioned program development methods. This enables the target functions with high value (urgently needing to be solved) or high performance bottlenecks in the target program to be separated from the functional modules and optimized independently according to the actual needs of the developers, without the need for a global, high-risk rewrite or engine replacement. This ensures that the target function can be independently upgraded and iterated while maintaining the continuous and stable operation of the target program without increasing excessive additional costs. It also reduces the coupling degree of the target program's program architecture, reduces the learning curve for new team members, significantly improves the efficiency of developing new functions for the target program and the efficiency of maintaining the target program, and reduces the technical debt of subsequent function iterations.

[0171] Corresponding to the above method embodiments, this application also provides a program development system. Figure 3 A schematic diagram of the structure of a program development system according to an embodiment of this application is shown. Figure 3 As shown, the system includes: front-end 302 and back-end 304; Front-end 302 is configured to send decoupling instructions for the target function; The backend 304 is configured to obtain the program architecture of the target program. The program architecture includes functional modules and control modules. There are calling dependencies between the functional code in the functional modules and the control modules. In response to the decoupling instruction, identify the target functional code and remove the calling dependencies of the target functional code; The target functional code after dependency removal is encapsulated into an independently deployable target component, and a proxy access layer is configured for the target component; Register the proxy access layer with the control module so that the control module routes to the proxy access layer and the proxy access layer schedules the target component. The front-end 302 is also configured to provide feedback on the inference results.

[0172] The program development system provided in this application obtains the program architecture of the target program, which includes functional modules and control modules. The functional code within the functional modules has a calling dependency with the control module. Responding to decoupling instructions sent by the front end for the target function, the system identifies the target functional code and removes its calling dependencies. The system then encapsulates the decoupled target functional code into an independently deployable target component and configures a proxy access layer for the target component. The proxy access layer is registered with the control module, enabling the control module to route to the proxy access layer, which then schedules the target component. This system allows for the independent extraction and optimization of high-value (urgently needing solutions) or high-performance bottleneck functions from the functional modules based on the actual needs of developers, without requiring a global, high-risk rewrite or engine replacement. This ensures the target program can be independently upgraded and iterated without incurring excessive additional costs, while maintaining its continuous and stable operation. It also reduces the coupling of the target program's architecture, lowers the learning curve for new team members, significantly improves the efficiency of developing new features and maintaining the target program, and reduces the technical debt for subsequent feature iterations.

[0173] The above is an illustrative scheme of a program development system according to this embodiment. It should be noted that the technical solution of this program development system and the technical solution of the above-described program development method belong to the same concept. Details not described in detail in the technical solution of the program development system can be found in the description of the technical solution of the above-described program development method. Furthermore, the components in the system embodiment should be understood as functional modules necessary to implement each step of the program flow or each step of the method; these functional modules are not actual functional divisions or separations. The system claims defined by such a set of functional modules should be understood as a functional module architecture that primarily implements the solution through the computer program described in the specification, and not as a physical system that primarily implements the solution through hardware.

[0174] Figure 4 A structural block diagram of a computing device according to one embodiment of this specification is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0175] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0176] In one embodiment of this specification, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0177] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 400 can also be a mobile or stationary server.

[0178] The memory 410 is used to store computer programs / instructions, and the processor 420 is used to execute the following computer programs / instructions, which, when executed by the processor, implement the steps of the above-described program development method.

[0179] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described program development method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described program development method.

[0180] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described program development method.

[0181] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the above-described program development method belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described program development method.

[0182] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described program development method.

[0183] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the above-described program development method belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-described program development method.

[0184] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0185] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0186] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0187] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0188] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A program development method, characterized in that, Backend applications used in software development systems include: Obtain the program architecture of the target program, which includes functional modules and control modules, wherein the functional code in the functional modules has a calling dependency with the control modules; In response to a decoupling instruction sent by the front end for a target function, the target function code is identified, and the calling dependency of the target function code is removed; The target function code after dependency removal is encapsulated into an independently deployable target component, and a proxy access layer is configured for the target component; The proxy access layer is registered with the control module so that the control module routes to the proxy access layer and the proxy access layer schedules the target component.

2. The method according to claim 1, characterized in that, Before configuring the proxy access layer for the target component, the method further includes: Configure the simulation environment based on the simulation protocol of the target program; In the simulation environment, the target component is run to obtain the simulation results of the target component; Configuring a proxy access layer for the target component includes: If the simulation results meet the preset targets, a proxy access layer is configured for the target component.

3. The method according to claim 2, characterized in that, The simulation environment includes at least one of an online simulation environment and a local simulation environment; The simulation protocol based on the target program configures the simulation environment, including: According to the simulation protocol, an environment configuration file for the target program is generated, wherein the environment configuration file includes at least one of an online environment configuration file and a local environment configuration file; Based on the environment configuration file, configure the simulation environment of the target program.

4. The method according to claim 2, characterized in that, After registering the proxy access layer to the control module, the method further includes: In response to a scheduling instruction for the target component, monitor the operating parameters of the target component; The operating parameters are fed back to the front end.

5. The method according to claim 1, characterized in that, After encapsulating the target functional code, after de-dependency removal, into a separately deployable target component, the following is also included: Generate a component configuration file for the target component and monitor the component configuration file; If an update to the component configuration file is detected, the updated component configuration file will be loaded into the program architecture.

6. The method according to claim 5, characterized in that, After generating the component configuration file for the target component, the following is also included: Based on the component configuration file, construct the front-end interactive interface of the target component; The front-end interactive interface is fed back to the front-end so that the front-end can configure the target component through the front-end interactive interface.

7. The method according to claim 6, characterized in that, The component configuration file includes configuration parameters and control parameters, and the front-end interactive interface includes a first front-end interactive interface corresponding to the configuration file and a second front-end interactive interface corresponding to the target component. The step of constructing the front-end interactive interface of the target component based on the component configuration file includes: Based on the configuration parameters in the component configuration file, a first front-end interactive interface corresponding to the component configuration file is constructed so that the front-end can update the data in the configuration file through the first front-end interactive interface; Based on the control parameters in the component configuration file, a second front-end interactive interface corresponding to the target component is constructed so that the front-end can manage the target component through the second front-end interactive interface.

8. The method according to claim 1, characterized in that, After registering the proxy access layer to the control module, the method further includes: A component manager corresponding to the target component is generated on the control module, so that the front end can schedule the component manager to manage the lifecycle of the target component through the control module.

9. The method according to claim 1, characterized in that, The removal of the call dependency of the target function code includes at least one of the following: Replace the function calls to the target function code in the control module with interface calls to the proxy access layer; Remove the direct references from the control module to the target function code; Extract the access permissions to environmental resources in the target program from the target function code.

10. The method according to claim 1, characterized in that, After registering the proxy access layer to the control module, the method further includes: Monitor the performance parameters of the target program during runtime, and determine the functional code to be optimized based on the performance parameters; The code for the function to be optimized is sent to the front end, so that the front end can determine whether the code for the function to be optimized needs to be configured with a proxy access layer and register the proxy access layer with the control module.

11. The method according to claim 1, characterized in that, The target program includes a game program, the control module includes a game task flow control module, the physically isolated components include game scene components and game object components, and the method further includes: A state machine is constructed based on the calling relationships between the process control module, the game scene components, and the game object components. The state machine is injected into the flow control module so that the flow control module can call the game scene component and game object component through the proxy access layer according to the current state of the state machine.

12. A program development method, characterized in that, The front-end used in software development systems includes: Send a decoupling instruction for the target function so that the backend performs the method described in any one of claims 1-11.

13. A program development system, characterized in that, Including front-end and back-end; The front end is configured to send decoupling instructions for the target function; The backend is configured as follows: Obtain the program architecture of the target program, which includes functional modules and control modules, wherein the functional code in the functional modules has a calling dependency with the control modules; In response to the decoupling instruction, the target function code is determined, and the call dependency of the target function code is removed; The target function code after dependency removal is encapsulated into an independently deployable target component, and a proxy access layer is configured for the target component; The proxy access layer is registered with the control module so that the control module routes to the proxy access layer and the proxy access layer schedules the target component.

14. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, It stores a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 12.

16. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 12.

Images