A code reuse and management method in a game development process

Abstract

This invention relates to the field of game development technology, and more particularly to a method for code reuse and management during game development. The method first acquires viewpoint interaction information, including viewpoint position and interaction type, entered by the code editing terminal, and forwards it to the scene rendering system to update the game scene data. Then, it retrieves matching target rendering parameters, combines them with real-time scene data to generate a real-time view, and sends it to the code debugging terminal for display. Simultaneously, based on the timestamps and interaction types of debugging marker commands pre-entered by the test terminal, historical scene code data is extracted; in response to scene updates, a scene debugging widget is generated, and debugging replay data is constructed by combining historical data and sent to the code debugging terminal for display. This solution achieves multi-terminal data linkage, supports dynamic adjustment of rendering feedback based on viewpoint behavior, and can accurately reproduce abnormal scenes, significantly improving the collaborative editing efficiency and debugging accuracy of immersive game scenes.

Description

Technical Field

[0001] This invention relates to the field of game development technology, and in particular to a method for code reuse and management during game development. Background Technology

[0002] With the rapid development of virtual reality (VR), augmented reality (AR), and real-time graphics rendering technologies, the construction and interactive experience of immersive game scenes are becoming increasingly complex, placing higher demands on the efficiency of scene editing and debugging during game development. Traditional game scene editing methods rely heavily on static views and manual parameter adjustments, lacking the dynamic perception of developers' viewpoint behavior and real-time interactive intentions. This results in delayed editing feedback, cumbersome debugging processes, and difficulty in meeting the needs of rapid iteration for highly free, multi-view immersive content. Especially in multi-person collaborative development environments, different roles (such as scene designers, programmers, and test engineers) often use independent toolchains, leading to untimely information synchronization and a lack of a unified data linkage mechanism, which seriously affects development efficiency and collaboration accuracy.

[0003] While some game engines in the current technology support remote debugging and real-time preview, they typically only implement one-way data push and cannot intelligently trigger corresponding rendering parameter optimization or debugging data playback based on the user's viewpoint interaction behavior. Furthermore, during the problem reproduction and root cause analysis phases, the lack of a precise time-space alignment mechanism between the abnormal events marked by testers and the specific scene states makes it difficult to efficiently recreate erroneous scenes. Especially for rendering anomalies or logical errors caused by interaction behavior from a specific perspective, existing systems struggle to automatically associate viewpoint trajectory, interaction type, and historical scene code data, thus limiting the level of automation and intelligence in debugging.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a method for code reuse and management during game development. This method aims to solve the technical problems of existing technologies, which lack dynamic perception of developer viewpoint interaction behavior and multi-terminal data linkage mechanism, resulting in delayed feedback and asynchronous debugging information in immersive game scenes during collaborative editing, and difficulty in achieving accurate spatiotemporal alignment and automated reproduction of abnormal events and historical scene code data.

[0006] To achieve the above objectives, the present invention provides a method for code reuse and management during game development, the method comprising: The viewpoint interaction information entered through the viewpoint interaction interface of the code editing terminal is obtained, and the viewpoint interaction information is forwarded to the scene rendering system so that the scene rendering system updates the game scene data according to the viewpoint interaction information. The viewpoint interaction information includes viewpoint position and interaction type. Retrieve at least one target rendering parameter that matches the viewpoint position and the interaction type, generate real-time view data based on the target rendering parameters and real-time scene data, and send the real-time view data to the code debugging terminal so that the real-time view data can be displayed in real time through the debugging interface of the code debugging terminal; Historical scene code data is extracted based on the timestamp of the debugging mark instruction and the interaction type. The debugging mark instruction is an instruction entered on the test interface of the test terminal before the viewpoint interaction information is obtained. In response to data updates from the scene rendering system, a scene debugging widget is generated based on the scene update data. Debug playback data is generated based on the scene debugging widget and the historical scene code data. The debug playback data is then sent to the code debugging terminal to be displayed through the debugging interface.

[0007] Optionally, before generating debug playback data based on the scene debug widget and the historical scene code data, the method further includes: Acquire the timestamp of the debugging marker command entered through the test interface of the test terminal, as well as the viewpoint pose data of the scene rendering engine within a preset historical time period; The debugging clip parameters are determined based on the timestamp, the viewpoint pose data, and the interaction type. The historical scene code data is edited according to the aforementioned debugging and editing parameters to obtain the historical scene code data.

[0008] Optionally, the debug editing parameters include a target debug duration, and the process of determining the target debug duration includes: Identify the expected debugging duration matching the interaction type from the preset debugging duration mapping relationship set; Based on the viewpoint pose data, calculate the maximum continuous stable duration for which the viewpoint pose change deviation is less than a preset deviation threshold before the time point recorded by the marked timestamp, and use the maximum continuous stable duration as the viewpoint stable duration. If the ratio of the viewpoint stabilization time to the expected debugging time is greater than or equal to a preset percentage, then the expected debugging time is determined as the target debugging time. If the ratio of the viewpoint stabilization time to the expected debugging time is less than a preset percentage, the expected debugging time is corrected according to a correction coefficient, and the correction result is used as the target debugging time. The correction coefficient is an exponential function of the proportional deviation between the preset percentage and the ratio.

[0009] Optionally, the debugging clipping parameters further include a debugging start image frame, and the process of determining the debugging start image frame includes: The key time point is calculated based on the marked timestamp and the preset delay duration, wherein the preset delay duration is determined based on historical instruction input delay data; The starting point is moved forward based on the interaction type, where different interaction types have their own pre-configured starting point forward time. The difference between the key time point and the starting point is used as the debugging start time point, and the image frame that matches the debugging start time point is identified from the historical scene code data as the debugging start image frame.

[0010] Optionally, the historical scene code data includes error scene data, and the method further includes: Obtain supplementary viewpoint error scene data that matches the error scene data. Extract the three-dimensional skeleton point sequence of the target game object from the error scene data and the supplementary viewpoint error scene data respectively through key point detection. And obtain the four-dimensional spatiotemporal skeleton point sequence of the target game object by registering the three-dimensional skeleton point sequences from different viewpoints. Based on the four-dimensional spatiotemporal skeleton sequence, erroneous actions are decomposed and erroneous parameters are extracted to obtain the original erroneous parameters of at least one erroneous action, and a four-dimensional skeleton point update sequence is generated based on the correction results of the original erroneous parameters. When a repair animation request instruction is received through the error repair control in the debugging interface, the four-dimensional skeleton point update sequence is bound to the corresponding skeleton points of the pre-built three-dimensional model of the game object, and an error repair animation is generated based on the bound game object model and displayed through the debugging interface.

[0011] Optionally, the step of decomposing erroneous actions and extracting erroneous parameters based on the four-dimensional spatiotemporal skeleton sequence to obtain original erroneous parameters for at least one erroneous action, and generating a four-dimensional skeleton point update sequence based on the correction results of the original erroneous parameters, includes: The four-dimensional spatiotemporal skeleton point sequence is decomposed and identified using a spatiotemporal graph convolutional neural network to obtain at least one erroneous action to be identified and the original error parameters of the erroneous action to be identified. The key error actions in the error actions to be identified are identified by a classifier trained based on an error knowledge base, and the standard repair parameters corresponding to the key error actions are retrieved. The four-dimensional skeleton sequence is updated using a regression model based on the standard repair parameters and the original error parameters to obtain the four-dimensional skeleton point update sequence.

[0012] Optionally, before acquiring the viewpoint interaction information entered through the viewpoint interaction interface of the code editing terminal, the method further includes: In response to a connection request from a terminal, obtain the terminal's account login information, as well as the editing permission information and project authorization information that match the account login information; If the editing permission information includes scene editing permissions and the project authorization information matches any scene of the game project to be launched, the scene is determined as the authorized scene of the terminal, and the terminal is bound to the authorized scene; The binding relationship between the terminal and the authorized scene is sent to the scene rendering system, so that when the scene rendering system receives the viewpoint interaction information recorded by the terminal, it updates the game scene data of the authorized scene according to the viewpoint interaction information.

[0013] Optionally, the method further includes: Update the scene performance statistics widget based on the performance data of each game object in the scene update data; When the time data in the scene update data triggers the preset time condition of any scene node, or when a pause debugging command is received through the test interface, the real-time scene data at the current moment is obtained. The real-time scene data at the current moment and the scene performance statistics widget are used to generate scene node debugging data.

[0014] Optionally, the method further includes: The scene update data is sent to the scene rendering and display terminal in the venue so that the real-time scene rendering data can be displayed through the scene rendering and display terminal; Send the real-time view data and the debug playback data to at least one target cloud test platform webpage; Acquire fixed-view scene data collected by an image acquisition device based on a fixed viewpoint of the scene, and send the fixed-view scene data to the on-site test monitoring webpage.

[0015] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a code reuse and management program for game development, wherein when the code reuse and management program for game development is executed by a processor, it implements the steps of the code reuse and management method for game development as described above.

[0016] This invention provides a method for code reuse and management during game development. By integrating viewpoint interaction information from the code editing terminal with debugging marker commands from the testing terminal, the method enables collaborative editing and intelligent debugging of immersive game scenes across multiple devices. It can dynamically match rendering parameters based on viewpoint position and interaction type and generate debug views in real time, improving the intuitiveness and responsiveness of scene feedback. Simultaneously, by combining timestamps and interaction types to accurately extract historical scene code data and generating debug replay data containing context states using scene debugging widgets, it effectively supports the automatic reproduction and root cause analysis of abnormal behaviors. This significantly improves the efficiency and accuracy of problem localization in complex interactive scenarios, enhancing the synergy of multi-role collaborative development and overall development efficiency. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating an embodiment of the code reuse and management method in the game development process of the present invention; Figure 2 This is a flowchart illustrating the process of determining the target debugging time in another embodiment of the code reuse and management method in the game development process of the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0020] Reference Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the code reuse and management method in game development according to the present invention, which presents an embodiment of the code reuse and management method in game development according to the present invention.

[0021] In one embodiment, the code reuse and management method during game development includes: Step S100: Obtain the viewpoint interaction information entered through the viewpoint interaction interface of the code editing terminal, and forward the viewpoint interaction information to the scene rendering system so that the scene rendering system updates the game scene data based on the viewpoint interaction information. The viewpoint interaction information includes the viewpoint position and interaction type.

[0022] The code editing terminal can be a client device or software environment for scene designers to input viewpoint interaction information. It can provide an immersive editing interface, supporting users to operate and adjust the game scene from a first-person or free perspective. In this embodiment, the code editing terminal can be implemented through a locally running game engine editor or a remotely connected collaborative editing client. The viewpoint interaction interface can be a graphical user interface component in the code editing terminal used to receive user viewpoint movement and interaction input. It can be used to convert the user's head posture, controller operation, or keyboard and mouse commands into structured viewpoint interaction information. For example, the viewpoint interaction interface can capture six-DOF pose and interaction events based on a VR / ARSDK or game engine input system. The viewpoint interaction information can be a data structure describing the user's current observation position and the interaction actions performed in the code editing terminal. It can be used to drive the scene rendering system to dynamically update content and serve as the context for parameter matching and debugging playback. Furthermore, the viewpoint interaction information can include, but is not limited to, one or more of head tracking data, controller grab events, and ray click commands. In one exemplary embodiment, viewpoint interaction information can work in conjunction with the scene rendering system to trigger game scene data updates; and simultaneously work in conjunction with target rendering parameter matching logic to determine the real-time view generation strategy.

[0023] The viewpoint position can be the user's observation coordinates and orientation in the 3D game space, typically represented by a position vector and a rotation quaternion. It can be used to determine the rendering frustum range and the set of visible objects, influencing rendering decisions such as lighting and LOD. In one specific embodiment, the viewpoint position can be output in real time by a VR headset, AR device, or traditional camera controller. The interaction type can be an identifier for the type of operation performed by the user at a specific viewpoint. It can be used to distinguish different editing intentions (such as placing objects, modifying materials, triggering events) for parameter matching and anomaly classification. For example, the interaction type can include, but is not limited to, one or more of object selection, attribute modification, and logic triggering. The scene rendering system can be the core rendering module responsible for generating a visual image based on the current scene state and viewpoint information. It can be used to perform geometric processing, lighting calculations, post-processing, and other processes, outputting view data that conforms to the current context. Furthermore, the scene rendering system can receive viewpoint interaction information to update game scene data; simultaneously, it outputs scene update data for use in generating scene debugging widgets. Game scene data can be a collection of all static and dynamic elements constituting the virtual world, including models, materials, lighting, scripts, etc., and can be used as the basic data source for rendering and logical operations. In one specific embodiment, game scene data can be stored in a project resource library and loaded and instantiated on demand by the scene rendering system.

[0024] Acquiring viewpoint interaction information entered through the viewpoint interaction interface of the code editing terminal can be achieved by listening to the input event stream of the viewpoint interaction interface, parsing and structuring it into a data packet containing the viewpoint position and interaction type. Furthermore, this operation can directly subscribe to headset and controller events via the VR runtime API, or intercept camera movement and UI operation events in a traditional editor and map them to standard interaction types, thereby achieving digital capture of the user's editing intent. Forwarding the viewpoint interaction information to the scene rendering system can be done through an in-process message bus or network protocol to pass the structured viewpoint interaction information to the scene rendering system. For example, this operation can be passed in a single-machine multi-threaded architecture via shared memory or callback functions, or transmitted in a distributed collaborative environment via WebSocket or gRPC, thereby establishing a data channel between editing behavior and scene state updates. Updating game scene data based on the viewpoint interaction information can be achieved by parsing the viewpoint position and interaction type and executing the corresponding scene modification logic (such as object transformation and attribute assignment). In one exemplary embodiment, this operation can be implemented by directly modifying spatial attributes by calling the transformation interface of scene graph nodes, or by triggering a scripted editing command interpreter to execute a compound operation, thereby enabling immersive editing operations to have an immediate impact on the virtual world.

[0025] Step S200: Retrieve at least one target rendering parameter that matches the viewpoint position and interaction type, generate real-time view data based on the target rendering parameters and real-time scene data, and send the real-time view data to the code debugging terminal so that the real-time view data can be displayed in real time through the debugging interface of the code debugging terminal.

[0026] The target rendering parameters can be a set of rendering configuration items matched to a specific viewpoint position and interaction type. These parameters can be used to optimize visual performance or debug information presentation in specific interaction scenarios, such as enabling wireframe mode or highlighting colliders. In one specific embodiment, the target rendering parameters may include, but are not limited to, one or more of the following: debug shader configuration, geometry display mode, performance analysis overlay. Furthermore, the target rendering parameters can be retrieved driven by viewpoint interaction information and combined with real-time scene data to generate real-time view data. The real-time scene data can be a snapshot of the complete scene state used by the scene rendering system in the current frame, which can be used as the basic input for generating real-time view data. For example, the real-time scene data can be synchronously output by the scene rendering system after each frame update.

[0027] Real-time view data can be a composite image of the current frame and its metadata based on target rendering parameters and real-time scene data. This data can be used to provide visual feedback synchronized with editing actions in the code debugging terminal. In one exemplary embodiment, real-time view data can be encoded and transmitted after adding debugging information during the post-processing stage of the rendering pipeline. The code debugging terminal can be a client device or interface for test engineers or programmers to view real-time views and debug playbacks. It can be used to receive and display debugging data from a collaborative system, supporting problem analysis and verification. Furthermore, the code debugging terminal can subscribe to editing and testing event streams via a network connection. The debugging interface can be a visual panel within the code debugging terminal used to present real-time view data and debug playback data. It can be used to provide interactive playback control, status checks, and log association functions. In one specific embodiment, the debugging interface can be built on a web or native UI framework, integrating video playback and status tree browsing components.

[0028] Retrieving at least one target rendering parameter that matches the viewpoint position and interaction type can be done by querying a predefined rule table or a machine learning model, returning an applicable rendering configuration based on the current viewpoint position region and interaction type. For example, this operation can be achieved by parameter lookup based on a spatial partitioning and interaction type hash table, or by using a lightweight neural network to predict the optimal debug rendering mode based on viewpoint feature vectors, thereby enabling context-aware adaptive rendering strategies. Generating real-time view data based on the target rendering parameters and real-time scene data can be achieved by injecting the target rendering parameters into the rendering pipeline, performing a frame rendering in conjunction with the current scene state, and attaching metadata. In an exemplary embodiment, this operation can dynamically switch debug shaders and overlay auxiliary geometry in the main rendering path, or start a separate debug rendering channel, reusing scene data but applying a dedicated post-processing chain, thereby outputting visual feedback highly relevant to the editing context.

[0029] Sending real-time view data to the code debugging terminal can be achieved by compressing and encoding the rendering results and transmitting them over a network to the code debugging terminal's subscribed endpoint. Furthermore, this operation can be implemented via real-time video streaming using WebRTC or by pushing frame data and state tuples through a message queue, thereby achieving low-latency visual synchronization across multiple devices. Displaying the real-time view data in real-time through the debugging interface of the code debugging terminal can be achieved by decoding the received view data and rendering it in the viewport area of ​​the debugging interface. In one specific embodiment, this operation can be performed by drawing video frames using Canvas / WebGL in a web browser or displaying them using Direct3D / Vulkan texture mapping in a native application, thus providing synchronized scene observation capabilities for non-editing characters.

[0030] Step S300: Extract historical scene code data based on the timestamp and interaction type of the debugging mark instruction. The debugging mark instruction is an instruction entered on the test interface of the test terminal before the viewpoint interaction information is obtained.

[0031] The test terminal can be a client environment used by test engineers to execute game tests and input debug marker commands. It can be used to record abnormal events and their context during immersive testing. In one specific embodiment, the test terminal can run an executable version of the game and integrate a marker input plugin. The test interface can be an interactive control or shortcut area in the test terminal used to trigger debug marker commands. It can be used to allow testers to quickly record the marker timestamp and interaction type when an anomaly is discovered. For example, the test interface can be implemented through gamepad button mapping, voice commands, or floating screen buttons. Debug marker commands can be anomaly marking signals actively issued by testers during testing. They include timestamps and interaction types and can be used as an index for capturing historical scene code data to achieve accurate location of problem scenarios. Furthermore, the timestamp and interaction type of the debug marker command together determine the scope of historical scene code data capture. The timestamp can be the system time or game logic frame number when the debug marker command is input. It can be used to provide an alignment benchmark in the time dimension to ensure that historical scene code data corresponds accurately to abnormal events. In an exemplary embodiment, the timestamp can be obtained by the test terminal from the game clock or system clock at the moment the command is triggered.

[0032] Historical scene code data can be a complete sequence of scene states saved before and after the debugging mark command time point, which can be used to provide the original environmental data required for problem reproduction. For example, historical scene code data can be continuously recorded through a circular buffer or incremental snapshot mechanism, extracted based on the mark timestamp. Entering debugging mark commands through the test interface of the test terminal can involve listening to the mark trigger event on the test interface and recording the current timestamp and associated interaction type. In a specific embodiment, this operation can be triggered by a dedicated button on the controller and automatically associated with the most recent interaction type, or the interaction type can be manually selected in a UI pop-up window and the mark implementation confirmed, thereby achieving structured annotation of abnormal events. Extracting historical scene code data based on the mark timestamp and interaction type of the debugging mark command can be achieved by locating scene snapshots in the historical buffer based on the timestamp and filtering state fragments that match the interaction type. Furthermore, this operation can read the complete scene sequence by timestamp index from the circular frame buffer, or reconstruct the minimum state set before and after a specified interaction based on event logs, thereby achieving accurate data extraction under the dual constraints of time and behavior.

[0033] In step S400, in response to the data update of the scene rendering system, a scene debugging widget is generated based on the scene update data, and debugging playback data is generated based on the scene debugging widget and historical scene code data. The debugging playback data is then sent to the code debugging terminal to display the debugging playback data through the debugging interface.

[0034] Scene update data can be a record of state changes generated by the scene rendering system in response to viewpoint interaction information. This data can be used as input to generate scene debugging widgets, encapsulating differences before and after the update. In one specific embodiment, scene update data can be extracted using a scene dirty tagging mechanism or differential serialization technology. The scene debugging widget can be a data container encapsulating the context state of a specific scene update event. It can be used to save a complete environmental snapshot when an anomaly occurs, including camera pose, interaction actions, rendering configuration, etc. For example, the scene debugging widget can include, but is not limited to, one or more of camera state packets, interaction event logs, and resource reference lists. Furthermore, the scene debugging widget can be generated based on scene update data and fused with historical scene code data to generate debug playback data. Debug playback data can be a replayable debug session package generated by combining the scene debugging widget with historical scene code data. This can be used to support accurate reconstruction of abnormal behavior triggered by a specific interaction from a specific viewpoint in the debugging interface. In one exemplary embodiment, the debug playback data can include, but is not limited to, one or more of interaction trajectory playback streams, state reconstruction scripts, and multi-view synchronous recordings.

[0035] In response to data updates from the scene rendering system, a scene debugging widget is generated based on the scene update data. This can be achieved by packaging the current camera state, interaction context, and resource reference list into a widget after the scene update is complete. Furthermore, this operation can be implemented by serializing the scene graph subtree and associated script variables, or by exporting GPU resource handles and rendering state object snapshots, thereby solidifying the complete execution environment at the time of the exception. Debug playback data is generated based on the scene debugging widget and historical scene code data. This can be achieved by injecting the context state from the widget into the historical scene code data to construct a replayable debugging session. In a specific embodiment, this operation can synthesize an interactive event stream with a timeline and a scene state sequence, or generate a scripted playback instruction set to drive engine replay, thereby generating an exception reproduction package with spatiotemporal consistency.

[0036] Sending debug playback data to the code debugging terminal can be achieved by pushing packaged debug playback data to the code debugging terminal via file transfer or streaming protocols. For example, this operation can be uploaded to a central collaboration server for the code debugging terminal to retrieve, or directly pushed to a designated code debugging terminal via a P2P connection, thus enabling cross-terminal sharing of problem scenarios. Displaying debug playback data through the debugging interface can involve loading the debug playback data and providing playback, pause, and jump control functions within the debugging interface. In an exemplary embodiment, this operation can be implemented by rendering frame-by-frame and synchronously displaying the state tree in a dedicated playback viewport, or by visualizing interactive events and rendering exception markers on the timeline, thereby supporting developers in interactively analyzing the root causes of exceptions.

[0037] Taking the reproduction of rendering anomalies in multi-person collaborative development as an example, the code reuse and management method in the game development process of this embodiment can be as follows: A scene designer moves to a corner inside a building in a VR code editing terminal and performs a "material replacement" interaction. At this time, the programmer observes texture flickering in the real-time view in the code debugging terminal. Simultaneously, a test engineer triggers the same flickering when performing a "character walking" interaction at the same location in another test terminal, and immediately enters a debugging mark command through the test interface. Based on the timestamp of the mark and the "character walking" interaction type, the system extracts a data fragment containing the lighting probe state and material instance at that location from the historical buffer; at the same time, the scene rendering system generates a scene debugging widget containing new material references and camera poses after responding to the material replacement in the code editing terminal. The two are merged to generate debugging playback data, allowing the developer to accurately replay the rendering process of that corner under the walking interaction in the debugging interface, and quickly locate the material sampling error caused by the lighting probe update delay.

[0038] In one embodiment, before generating debug playback data based on the scene debug widget and historical scene code data, the method further includes: Acquire the timestamp of the debugging marker command entered through the test interface of the test terminal, as well as the viewpoint pose data of the scene rendering engine within a preset historical time period.

[0039] The preset historical time period can be a fixed-length window extending forward or backward from the timestamp of the debugging marker instruction, used to limit the scope of viewpoint pose data collection. In this embodiment, the preset historical time period can constrain the boundaries of historical data backtracking, balancing editing accuracy and system overhead. For example, the preset historical time period can be set by system configuration items or by the user in the test interface, usually in seconds or frames. The scene rendering engine can be the core runtime module responsible for performing the visualization rendering of the game scene. Furthermore, the scene rendering engine can provide a continuous stream of viewpoint pose data as a spatial dimension basis for the editing context. In an exemplary embodiment, the scene rendering engine can output viewpoint pose data for use in the calculation of debugging editing parameters; its state updates also constitute part of the historical scene code data. The viewpoint pose data can be a sequence of user-observed poses continuously recorded by the scene rendering engine within the preset historical time period, including six degrees of freedom information such as position and rotation. In a specific embodiment, the viewpoint pose data can provide a spatial behavioral trajectory for identifying viewpoint areas and movement patterns related to anomalies. Furthermore, the viewpoint pose data, along with the timestamp and interaction type, can be input into the debugging editing parameter determination logic. For example, viewpoint pose data may include, but is not limited to, one or more of the following: head tracking trajectory, camera path log, and handle pointing sequence.

[0040] Obtaining the timestamp of the debug marker command entered through the test interface of the test terminal can be achieved by extracting the attached time identifier from the entered debug marker command. Alternatively, this operation can be implemented by directly reading the time field in the debug marker command structure, or by obtaining a high-precision timestamp synchronized from the system clock based on the command reception time, thus providing a time anchor for subsequent editing. Obtaining the viewpoint pose data of the scene rendering engine within a preset historical time period can be achieved by querying the pose buffer maintained by the scene rendering engine and extracting continuous pose records centered on the timestamp and covering the preset historical time period. Alternatively, this operation can be implemented by reading pose snapshots from a circular buffer queue indexed by time range, or by replaying and reconstructing the viewpoint trajectory within a specified time period through an event tracing mechanism, thereby constructing a spatial behavior context before and after the anomaly occurred.

[0041] The debugging clip parameters are determined based on the timestamp, viewpoint pose data, and interaction type.

[0042] The debugging editing parameters can be a set of data editing control parameters dynamically generated based on marked timestamps, viewpoint pose data, and interaction types. In this embodiment, the debugging editing parameters can guide the precise trimming of the original historical scene code data with spatiotemporal semantic awareness, preserving the relevant context of the issue. For example, the debugging editing parameters may include, but are not limited to, time window boundaries, spatial areas of interest, and interaction semantic filters. Furthermore, the debugging editing parameters can drive the editing processing of historical scene code data; their generation depends on the joint analysis of viewpoint pose data, marked timestamps, and interaction types. Determining the debugging editing parameters based on marked timestamps, viewpoint pose data, and interaction types can be achieved by fusing time anchors, spatial trajectories, and interaction semantics to calculate historical data filtering rules for editing. Furthermore, this operation can be implemented by identifying key observation areas based on viewpoint pose clustering and expanding the time window in combination with interaction types, or by using a rule engine to match predefined abnormal pattern templates and output corresponding editing parameter configurations, thereby enabling the generation of intelligent editing strategies with spatiotemporal-behavior triple alignment.

[0043] The historical scene code data is edited based on the debugging and editing parameters to obtain the historical scene code data.

[0044] Based on the debugging editing parameters, historical scene code data is edited to obtain historical scene code data. This can be achieved by applying temporal, spatial, and semantic constraints from the debugging editing parameters, filtering the original historical scene code data, and outputting simplified, effective segments. Furthermore, this operation can be implemented by extracting frame sequences by time window and retaining only the state of scene objects within the neighborhood of the viewpoint's pose trajectory, or by activating the state backtracking of specific subsystems (such as physics or animation) based on interaction type while ignoring irrelevant module data. This eliminates redundant irrelevant states and retains contextual data highly relevant to anomalies.

[0045] Taking the accurate reproduction of viewpoint-related lighting anomalies as an example, the code reuse and management method in the game development process of this embodiment can be as follows: When a test engineer performs a "door opening" interaction at a corner of a corridor during VR testing, they find that the character model suddenly turns black and immediately enters a debugging marker command through the test interface. The system obtains the timestamp of the marker command and traces back the viewpoint posture data recorded by the scene rendering engine within a preset historical time period (such as 5 seconds before and after), and finds that the user was quickly moving from a bright area to a shadow area before the anomaly occurred. Combined with the "door opening" interaction type, the system determines the debugging clipping parameters: the time window is [t-3s, t+2s], the spatial focus area is a sphere with a radius of 3 meters around the door frame, and the interaction semantic filter enables the lighting and material subsystem. Based on this, after clipping the original historical scene code data, only the key states that affect the lighting calculation within this spatiotemporal range (such as probe position, light source on / off state, and material reflectivity) are retained. This streamlined data is then integrated with the scene debugging widget to generate debug playback data, allowing programmers to focus on analyzing the coupling between the lighting probe update delay and the door opening animation triggering timing in the code debugging terminal, avoiding interference from irrelevant scene elements.

[0046] In one embodiment, the debug editing parameters include a target debug duration, and the process of determining the target debug duration includes: Identify the expected debugging duration matching the interaction type from the preset debugging duration mapping relationship set; Based on the viewpoint attitude data, calculate the maximum continuous stable duration when the viewpoint attitude change deviation is less than a preset deviation threshold before the time point recorded by the timestamp, and use the maximum continuous stable duration as the viewpoint stability duration. If the ratio of the viewpoint stabilization time to the expected debugging time is greater than or equal to the preset ratio, then the expected debugging time will be determined as the target debugging time. If the ratio of the viewpoint stabilization time to the expected debugging time is less than the preset percentage, the expected debugging time is corrected according to the correction coefficient, and the correction result is used as the target debugging time. The correction coefficient is an exponential function of the proportional deviation between the preset percentage and the ratio.

[0047] The target debugging duration can be the length of a time window used to guide the editing of historical scene code data, determined after dual calibration of interaction type and viewpoint stability. The target debugging duration can be used to dynamically adapt to the effective context interval under different interaction scenarios, avoiding redundancy or missing information. In this embodiment, the target debugging duration, as a core component of the debugging editing parameters, is determined by the expected debugging duration, viewpoint stability duration, and correction coefficient. The preset debugging duration mapping set can be a data structure storing the mapping rules between interaction types and their corresponding baseline debugging durations. The preset debugging duration mapping set can be used to provide initial time window suggestions based on interaction semantics, reflecting the typical observation duration required for different types of operations. Furthermore, the preset debugging duration mapping set can be generated through historical debugging log clustering analysis or expert experience configuration, and stored in key-value pair format. For example, the preset debugging duration mapping set can include, but is not limited to, one or more of the following: script trigger class mapping table, physical interaction class mapping table, and UI operation class mapping table.

[0048] The expected debugging duration can be a baseline debugging time length that matches the current interaction type, retrieved from a preset debugging duration mapping set. The expected debugging duration can be used as an initial reference value for calculating the target debugging duration. In an exemplary embodiment, the expected debugging duration can be obtained by querying the preset debugging duration mapping set based on the interaction type as the key. The preset deviation threshold can be an upper limit of pose change tolerance used to determine whether the viewpoint pose is in a "stable" state. The preset deviation threshold can be used to define the criteria for determining continuous stable periods, filtering out high-frequency jitter or minor drift. In a specific embodiment, the preset deviation threshold can be set by system configuration, typically based on device accuracy and human eye perception thresholds.

[0049] The maximum continuous stable duration can be the longest continuous period in the time series prior to the marked timestamp where the viewpoint pose change deviation is consistently less than a preset deviation threshold. The maximum continuous stable duration can be used to quantify the user's ability to maintain an effective observation state before an anomaly occurs. Furthermore, the maximum continuous stable duration can be identified by traversing viewpoint pose data using a sliding window or state machine to determine the longest subsequence that satisfies the stability condition. The viewpoint stable duration can be the maximum continuous stable duration adopted for calculating the ratio with the duration. The viewpoint stable duration can be used as a core indicator to measure the stability of user behavior and participate in the dynamic adjustment of the target debugging duration. In this embodiment, the viewpoint stable duration and the expected debugging duration are used together to calculate the ratio, determining whether to enable the correction mechanism. The preset percentage can be the minimum acceptable percentage threshold of the viewpoint stable duration relative to the expected debugging duration. The preset percentage can be used to control the decision boundary for whether to directly adopt the expected debugging duration. For example, the preset percentage can be configured by the system policy, typically taking an empirical value between 0.6 and 0.8.

[0050] The ratio can be the numerical proportion of the viewpoint stabilization time to the expected debugging time. The ratio can be used as a quantitative basis for judging whether the stability of user behavior meets the baseline debugging requirements. In one specific embodiment, the ratio can be calculated in real time through division. The ratio deviation can be the absolute value of the difference between the preset percentage and the actual ratio, i.e. The proportional deviation can be used to reflect the degree of instability and serves as input for calculating the correction coefficient. Furthermore, the proportional deviation is calculated as the absolute value of the difference between a preset percentage and a ratio. The correction coefficient can be a scaling factor generated by an exponential function based on the proportional deviation, used to compress the expected debugging time. The correction coefficient can be used to achieve non-linear attenuation of debugging time under unstable conditions, suppressing invalid data truncation. In an exemplary embodiment, the correction coefficient can be defined as a negative power of the proportional deviation multiplier from the natural exponent base e, containing a constant that adjusts the attenuation rate, i.e. , where e is the natural constant and k is a configurable decay rate constant used to adjust the correction magnitude. The exponential function can be used to accelerate the increase of the correction magnitude as stability decreases, thereby enhancing the duration compression of highly unstable scenarios.

[0051] Identifying the expected debugging duration matching the interaction type from the preset debugging duration mapping set can be achieved by performing a lookup operation in the preset debugging duration mapping set using the current interaction type as the key. Furthermore, this operation can be performed using a hash table for O(1) time complexity key-value lookup, or by backtracking the parent class mapping item through the interaction type hierarchical inheritance mechanism, thereby obtaining the baseline debugging time that conforms to the semantics of the current operation. Based on the viewpoint posture data, calculating the maximum continuous stable duration where the viewpoint posture change deviation is less than the preset deviation threshold before the time point recorded by the marked timestamp can be achieved by traversing the viewpoint posture data backward from the marked timestamp and counting the longest consecutive time period where the posture change deviation is less than the preset deviation threshold. Furthermore, this operation can use a two-pointer sliding window algorithm to solve for the longest stable subsequence in linear time, or convert the posture change into angular velocity and linear velocity, compare them with the threshold respectively, and then take the intersection to determine stability, thereby quantifying the effective observation duration of the user before the anomaly occurs.

[0052] Using the maximum continuous stable duration as the viewpoint stable duration can be achieved by assigning the calculated maximum continuous stable duration to the viewpoint stable duration variable. Furthermore, this operation can be implemented by directly referencing the calculation result pointer or by copying the value and attaching time unit metadata, thus achieving standardized output of the stability index. Determining whether the ratio of the viewpoint stable duration to the expected debugging duration is greater than or equal to a preset percentage can be achieved by calculating the ratio and comparing it with the preset percentage. Furthermore, this operation can be performed directly using floating-point comparison instructions or by introducing a small tolerance ε to avoid misjudgments caused by floating-point precision errors, thus determining whether to enable the duration correction logic. If the ratio is greater than or equal to the preset percentage, the expected debugging duration is determined as the target debugging duration. This can be achieved by directly assigning the expected debugging duration as the target debugging duration when the condition is met. Furthermore, this operation can be performed by directly redirecting pointers to avoid data copying or by recording decision logs for subsequent analysis, thus preserving the original semantically driven debugging window. If the ratio is less than the preset percentage, the expected debugging time is adjusted according to the correction coefficient. This can be done by calculating the correction coefficient and multiplying it by the expected debugging time to obtain the corrected time. Furthermore, this operation can apply the clamp function to ensure that the corrected time is not lower than the minimum allowable value, or apply a smoothing filter to the correction coefficient to prevent abrupt changes, thereby dynamically compressing the debugging window to adapt to unstable observation behavior.

[0053] Using the corrected result as the target debugging duration can be achieved by assigning the corrected value as the target debugging duration. Furthermore, this operation can be encapsulated as a duration object with a source tag, or implemented by synchronously updating the time window field in the debugging clip parameters, thus finalizing the adaptive duration. The correction coefficient is calculated as an exponential function of the proportional deviation between the preset percentage and the ratio. This can be achieved by first calculating the proportional deviation as equal to the preset percentage minus the ratio (since the ratio is less than the preset percentage), and then substituting this into the exponential function exp(-k × deviation). Further, this operation can use a lookup table to accelerate the exponential function calculation, or introduce a configurable attenuation factor k to adapt to different project requirements, thereby achieving non-linear correction with lower stability and stronger compression.

[0054] Taking the reproduction of animation glitches triggered during rapid movement as an example, the code reuse and management method in the game development process of this embodiment can be as follows: when a test engineer discovers that the character's arm is penetrating the model during a "pick up an item" interaction while running at high speed, they immediately record a debugging marker command. The system identifies the interaction type as "pick up an item" and finds the expected debugging time to be 4 seconds from the preset debugging time mapping set. Subsequently, the viewpoint posture data in the 5 seconds before the marked timestamp is analyzed, and it is found that the user is in a high-speed movement state for most of the time, only entering a relatively stable state in the last 0.9 seconds (posture change is below the threshold). The calculated viewpoint stability time is 0.9 seconds, and the ratio = 0.9 / 4 = 0.225, which is far lower than the preset ratio of 0.7. The system calculates the ratio deviation = 0.7 - 0.225 = 0.475, substitutes it into the exponential function exp(-2 × 0.475) ≈ 0.387, and the corrected target debugging time = 4 × 0.387 ≈ 1.55 seconds. The shortened window focuses on keyframes before and after the picking action, avoiding the inclusion of a large number of irrelevant rendering states during high-speed movement, allowing animators to accurately check the alignment of the skeleton rigging and collider at the moment of stable picking.

[0055] In one embodiment, the debugging clipping parameters further include debugging the starting image frame, and the process of determining the starting image frame includes: Key time points are calculated based on the marked timestamp and the preset delay duration, where the preset delay duration is determined based on historical instruction input delay data; The key time point is a time marker that more closely approximates the actual anomaly trigger time, obtained by subtracting a preset delay duration from the marked timestamp. It is used to correct for marking delays caused by human reaction or system response, thus approximating the actual occurrence of the problem. In this embodiment, the key time point can be obtained through arithmetic operations between the marked timestamp and the preset delay duration. The preset delay duration can be a configuration parameter reflecting the average time delay from when a tester perceives an anomaly to when they input a debugging marking command, and can be used to compensate for the lag in marking behavior relative to the actual occurrence of the anomaly. For example, the preset delay duration can include, but is not limited to, one or more of visual reaction delay, operation confirmation delay, and system input delay. Furthermore, the preset delay duration can be determined based on historical command input delay data. This process can involve statistical analysis of historical command input delay data (such as taking the mean, median, or quantiles) to generate a configuration value representing a typical delay. In an exemplary embodiment, this statistical analysis can calculate the mean delay by grouping by interaction type, generating a type-specific preset delay duration; or it can use a sliding window to dynamically update recent delay statistics to adapt to different tester habits, thereby achieving quantitative modeling of human or system marking delays.

[0056] Historical command input delay data can be a historical dataset recording the time deviation between past debugging marker commands and their corresponding actual anomaly events, which can be used to provide empirical evidence for setting the preset delay duration. In one specific embodiment, historical command input delay data can be collected and stored through labeled test logs or controlled experiments. The operation of calculating the key time point based on the marker timestamp and the preset delay duration can be performed by performing an arithmetic operation that the key time point equals the marker timestamp minus the preset delay duration. Furthermore, this operation can be achieved by performing integer subtraction in the frame sequence number field to maintain alignment with the rendered frame, or by rounding to the nearest valid frame timestamp after calculation in the continuous time domain, thereby reversing the marker time to a point closer to the actual time of the anomaly.

[0057] The starting point is moved forward based on the interaction type, where different interaction types have their own pre-configured starting point forward time. The start point advance duration can be a pre-configured time offset based on the interaction type, used to further advance the debugging start time. This ensures that the playback includes the necessary pre-observation or preparation context for a specific interaction. For example, the start point advance duration may include, but is not limited to, the pickup guide duration, animation preparation duration, and UI navigation pre-processing duration. In one specific embodiment, the start point advance duration can be obtained by interaction type matching and, together with key time points, determine the debugging start time. Matching the start point advance duration based on the interaction type can be done by using the current interaction type as the key to look up the corresponding start point advance duration in a pre-configured mapping table. Furthermore, this operation can be implemented by using the interaction type inheritance hierarchy to trace back the parent class configuration item, or by combining dynamic interpolation based on interaction complexity to obtain the advance duration, thereby introducing an interaction semantic-driven context expansion mechanism.

[0058] The difference between the critical time point and the starting point is used as the debugging start time point, and the image frame that matches the debugging start time point is identified from the historical scene code data as the debugging start image frame.

[0059] The debugging start time point can be the final debug playback start time obtained by subtracting the start point's forward shift from the key time point. It can be used to determine the optimal playback start point after comprehensively considering tag delay and interaction semantics. In this embodiment, the debugging start time point can be calculated using the difference between the key time point and the start point's forward shift. Using the difference between the key time point and the start point's forward shift as the debugging start time point can be achieved by performing the operation that the debugging start time point equals the key time point minus the start point's forward shift. Furthermore, this operation can prevent the start point from exceeding the buffer limit by applying minimum time boundary constraints, or by performing frame alignment processing on the result to ensure the existence of image frames, thereby completing double time correction and determining the final playback start point. The debugging start image frame can be a specific image frame in the debug playback data that serves as the playback start point. Corresponding to the debugging start time point determined after double time correction, it can be used to ensure that playback begins from the starting point of a behavioral sequence that fully covers the cause of the anomaly, improving the traceability of the causal chain. In an exemplary embodiment, the debugging start image frame can be located in the historical scene code data from the debugging start time point and serves as a key component of the debug clip parameters.

[0060] The operation of identifying the image frame matching the debugging start time point from historical scene code data as the debugging start image frame can be achieved by searching for the most valid image frame closest to the debugging start time point in the time index of the historical scene code data. Furthermore, this operation can be implemented by using binary search to quickly locate the frame in an ordered frame list, or by selecting the frame corresponding to the largest frame timestamp less than or equal to that time point if an exact match does not exist. This transforms an abstract time point into a concrete, playable visual starting point.

[0061] Taking the accurate reproduction of UI button clicks causing interface crashes as an example, the code reuse and management method in the game development process of this embodiment can be as follows: The test engineer sees that the pop-up button is unresponsive in VR and presses the mark key 0.8 seconds later. The system records the mark timestamp as T. Based on historical instruction input delay data (average 0.75 seconds), the preset delay duration is set to 0.75 seconds, and the critical time point is calculated to be T-0.75s, which is close to the actual click failure time. The interaction type is "UI button click", and the time to move forward from the starting point is 1.2 seconds (which must include the button appearance and user gaze process). Debug starting time point = (T-0.75)-1.2 = T-1.95s. The system locates the image frame corresponding to T-1.95s from the historical scene code data as the debugging starting image frame, so that the playback starts from when the pop-up window just appears and the user begins to gaze at the button, fully presenting the entire process from UI rendering, focus acquisition to click failure, helping programmers find that it is caused by the focus management script not being properly activated under specific lighting conditions.

[0062] In one embodiment, the historical scenario code data includes error scenario data, and the method further includes: Obtain supplementary viewpoint error scene data for matching error scene data. Extract the 3D skeleton point sequence of the target game object from the error scene data and the supplementary viewpoint error scene data through key point detection. Then, obtain the 4D spatiotemporal skeleton point sequence of the target game object by registering the 3D skeleton point sequences from different viewpoints. Based on the four-dimensional spatiotemporal skeleton sequence, erroneous actions are decomposed and erroneous parameters are extracted to obtain the original erroneous parameters of at least one erroneous action, and a four-dimensional skeleton point update sequence is generated based on the correction results of the original erroneous parameters. When a repair animation request instruction is received through the error repair control in the debugging interface, the four-dimensional skeleton point update sequence is bound to the corresponding skeleton points of the pre-built three-dimensional model of the game object, and an error repair animation is generated based on the bound game object model and displayed through the debugging interface.

[0063] The error scene data can be a specific scene state fragment containing abnormal behavior associated with debugging marker instructions in historical scene code data. It can be used as the primary perspective input source for error analysis, recording the original environment and character state when the problem occurred. In an exemplary embodiment, the error scene data can be used together with supplementary perspective error scene data for multi-view skeleton reconstruction. Supplementary perspective error scene data can be additional scene records that are temporally and semantically aligned with the error scene data but from different viewing angles. It can be used to compensate for the lack of motion information caused by occlusion or viewpoint limitations in the primary perspective, improving the completeness of skeleton reconstruction. Furthermore, supplementary perspective error scene data can be obtained through preset auxiliary cameras, multi-view recording by a playback system, or synchronous acquisition by a distributed test terminal. For example, supplementary perspective error scene data can include, but is not limited to, one or more of the following: lateral observation stream, top-down monitoring perspective, and third-person following perspective.

[0064] The target game object can be a drivable character or a skeletal entity exhibiting abnormal animation behavior in an error scene, serving as the core carrier for skeletal point extraction and error analysis. In one specific embodiment, the target game object can be automatically identified by debug marker commands or object references in scene debug widgets. The 3D skeletal point sequence can be a set of temporal positions of each joint of the target game object in 3D space estimated from single-view video or depth data using a keypoint detection algorithm. It can be used to characterize the character's motion trajectory from a specific viewpoint, providing basic input for multi-view fusion. Furthermore, the 3D skeletal point sequence can be inferred from the rendered frames using deep learning-based pose estimation algorithms (such as VIBE, MotionBERT) or traditional CV methods. The 4D spatiotemporal skeletal point sequence can be a unified, continuous, and unambiguous character motion trajectory generated by spatiotemporal registration of multi-view 3D skeletal point sequences. It can be used to provide complete and consistent motion representation, supporting high-precision error decomposition and parameter extraction. In this embodiment, the 4D spatiotemporal skeletal point sequence can be used as input for error motion decomposition; its correction result generates a 4D skeletal point update sequence. For example, a four-dimensional spatiotemporal skeleton point sequence may include, but is not limited to, joint trajectory tensors, temporal skeleton graphs, motion manifold embeddings, etc.

[0065] Erroneous actions can be abnormal motion units identified in the four-dimensional spatiotemporal skeletal point sequence that violate animation specifications or physical constraints. These can be used to define specific behavioral segments requiring repair, such as clipping, jitter, or sliding. In one specific embodiment, erroneous actions may include, but are not limited to, one or more of the following: joint rotation exceeding limits, foot slippage, and failed IK solver poses. Original error parameters can be low-level animation or physical parameters describing the cause of the erroneous action, such as incorrect rotation angles, displacement offsets, and weight assignments. These can be used as the direct target of the correction logic, determining the basis for generating the repair strategy. Furthermore, the original error parameters can be extracted through inverse dynamics analysis or parameter regression of the four-dimensional spatiotemporal skeletal point sequence. The four-dimensional skeletal point update sequence can be a new skeletal motion trajectory that conforms to animation specifications, generated based on the correction of the original error parameters. This sequence can be used to drive the game object model to generate visually correct repair animations. In this embodiment, the four-dimensional skeletal point update sequence can be bound to the skeletal points of the game object's three-dimensional model to generate error repair animations. For example, the four-dimensional skeletal point update sequence may include, but is not limited to, smoothed joint trajectories, physical constraint projection sequences, and style-preserving correction flows.

[0066] The bug fix control can be an interactive component in the debug interface used to trigger a bug fix animation generation request, allowing developers to actively initiate a visual verification process. Furthermore, the bug fix control can be integrated into the animation fix panel of the debug interface as a button, slider, or shortcut. The bug fix animation request command can be a signal issued by the user through the bug fix control, requesting the generation and display of a bug fix animation, and can be used to activate the binding and rendering process of the four-dimensional skeletal point update sequence to the animation model. In an exemplary embodiment, the bug fix animation request command can be captured by a UI event listener and forwarded to the animation generation module. The game object 3D model can be a pre-built target character digital asset with a complete skeletal hierarchy and skinning weights, which can be used as a binding carrier for the four-dimensional skeletal point update sequence to achieve animation visualization. Furthermore, the game object 3D model can be loaded from the project resource library and includes meshes, materials, skeletal structures, and animation controllers.

[0067] Error-fixing animations can be visual animations generated by a 3D model of a game object bound to a four-dimensional skeletal point update sequence. They can be used to intuitively demonstrate the corrected action effects and support developers in verifying the effectiveness of the fix. In one specific embodiment, the error-fixing animation can be rendered in real-time through a standard animation playback pipeline and presented in the debugging interface. Obtaining supplementary viewpoint error scene data matching the error scene data can be achieved by retrieving or synchronously acquiring scene records from other viewpoints at the same time based on the timestamp and spatial context of the error scene data. Furthermore, this operation can be achieved by pulling auxiliary viewpoint streams from a multi-camera recording system in time alignment, or by automatically matching nearest-neighbor auxiliary observation points using spatial metadata in the scene debugging widget, thereby expanding the observation dimensions and overcoming the insufficiency of information from a single viewpoint.

[0068] By extracting the 3D skeletal point sequence of the target game object from error scene data and supplementary viewpoint error scene data through keypoint detection, a 3D human / character pose estimation algorithm can be applied to video frames from various viewpoints to output a time-stamped joint coordinate sequence. Further, this operation can be achieved by using monocular RGB video combined with a pre-trained neural network for 3D pose enhancement, or by directly regressing the 3D skeletal position using depth maps or point cloud data, thus transforming visual observations into structured motion data. By registering the 3D skeletal point sequences from different viewpoints, a four-dimensional spatiotemporal skeletal point sequence of the target game object is obtained. This can be achieved by using multi-view geometric consistency constraints or a learned fusion model to align the heterogeneous viewpoint skeletal sequences to a unified world coordinate system and interpolate to complete the data. In a specific embodiment, this operation can be achieved by optimizing the global consistency of multi-view trajectories based on BundleAdjustment, or by using a spatiotemporal graph neural network to align and fuse multi-source skeletal sequences, thereby generating an unobstructed, highly complete continuous motion representation.

[0069] The process involves decomposing erroneous movements and extracting erroneous parameters based on a four-dimensional spatiotemporal skeleton sequence. This yields at least one original erroneous parameter for an erroneous movement. This can be achieved by segmenting, clustering, or matching the four-dimensional skeleton sequence to identify abnormal motion patterns and inferring their underlying parameter deviations. Further, this operation can locate abnormal frames and extract offsets through kinematic constraint checks (such as joint limits and velocity continuity), or by using anomaly detection models (such as VAEs or Transformers) to identify motion segments deviating from normal distributions and regress erroneous parameters. This allows for structured analysis from phenomenon to mechanism. A four-dimensional skeleton point update sequence is generated based on the correction results of the original erroneous parameters. This can be achieved by applying correction rules (such as smoothing filtering, physical projection, or IK resolving) to adjust the original erroneous parameters and regenerating a compliant skeleton trajectory. In an exemplary embodiment, this operation can be achieved by applying quaternion interpolation and limit clipping to joint rotations to generate a smooth trajectory, or by inputting the corrected parameters into an inverse dynamics solver to generate a physically reasonable sequence, thus producing correct animation data that can be used to drive the model.

[0070] Retrieving the repair animation request command entered through the error repair control in the debugging interface can be achieved by listening to the activation event of the error repair control in the debugging interface and capturing the user-initiated repair verification request. Furthermore, this operation can be implemented by binding a button click event callback function or by listening to shortcut key combinations and parsing them into repair commands, thereby triggering the repair animation generation process. Binding the four-dimensional skeletal point update sequence to the corresponding skeletal points of the pre-built three-dimensional model of the game object can be achieved by mapping the joint trajectories in the update sequence to nodes with the same name at the model's bone level and establishing a driving relationship. In a specific embodiment, this operation can be achieved by establishing a one-to-one mapping relationship through a bone name hash table or by using a semantic matching algorithm to align heterogeneous skeletal structures (such as a humanoid universal skeleton mapping), thereby enabling the preparation for data to be transformed into visualization.

[0071] Generating error-fixing animations based on the bound game object model can be achieved by driving the bound model to deform frame-by-frame according to the four-dimensional skeletal point update sequence and rendering it as an animation frame sequence. Furthermore, this operation can be implemented by generating animation frames in real-time through GPU skinning calculations, or by offline baking into standard animation clips for playback, thus outputting an intuitively assessable repair effect. The error-fixing animation can be displayed through a debugging interface, playing the generated animation in a dedicated viewport of the debugging interface, and supporting operations such as pausing, comparing, and exporting. In an exemplary embodiment, this operation can display the original error animation and the repair animation side-by-side in a dual-screen mode, or overlay a skeletal trajectory wireframe to assist in analyzing motion differences, thereby supporting multi-character collaborative verification of the repair solution.

[0072] Taking the intelligent repair of clipping issues in character animation as an example, the code reuse and management method in the game development process of this embodiment can be as follows: Testers discover that a character's arm passes through a wall when performing a roll in a multiplayer battle scene. The system records the error scene data and automatically associates it with supplementary view error scene data captured by a map monitoring camera at the same time. The key point detection module extracts the character's three-dimensional skeletal point sequence from two perspectives, and generates a complete four-dimensional spatiotemporal skeletal point sequence after multi-view registration, revealing that the arm undergoes non-physical adduction during the roll. Based on this, the system decomposes the error action into "elbow joint rotation exceeding the limit" and extracts the original error parameter: local rotation angle offset +45 degrees. The correction module trims this parameter to the joint limit range and generates a four-dimensional skeletal point update sequence. When the programmer clicks the "Preview Repair" button in the debugging interface, the sequence is bound to the character model skeleton, driving the generation of a clipping-free roll animation, which is played side by side with the original error animation in the debugging interface, allowing the artist to immediately confirm the repair effect and approve its integration.

[0073] In one embodiment, erroneous actions are decomposed and erroneous parameters are extracted based on the four-dimensional spatiotemporal skeleton sequence to obtain the original erroneous parameters of at least one erroneous action, and a four-dimensional skeleton point update sequence is generated based on the correction results of the original erroneous parameters, including: The spatiotemporal graph convolutional neural network is used to decompose and identify erroneous actions in a four-dimensional spatiotemporal skeleton point sequence, resulting in at least one erroneous action to be identified and its original error parameters.

[0074] The spatiotemporal graph convolutional neural network (SPCNN) is a deep learning model specifically designed for processing graph-structured data with spatial topology and temporal dynamics. It can be used to model four-dimensional spatiotemporal skeletal point sequences, enabling automatic decomposition of erroneous actions and extraction of original error parameters. In this embodiment, the SPCNN can use skeletal nodes as graph vertices and joint connections as edges, stacking graph convolutional layers in the time dimension to jointly learn spatial-temporal features. Furthermore, the SPCNN can be based on adjacency matrices such as ST-GCN, adaptive graph convolutional networks, or multi-scale spatiotemporal attention networks. The erroneous action to be identified can be a potential abnormal action fragment initially detected by the SPCNN from the four-dimensional spatiotemporal skeletal point sequence, which can be used as a candidate set for subsequent semantic discrimination, narrowing down the scope of key error localization. In an exemplary embodiment, the erroneous action to be identified can be input into a classifier trained based on an error knowledge base for identifying key erroneous actions.

[0075] By using a spatiotemporal graph convolutional neural network to decompose and identify erroneous actions in a four-dimensional spatiotemporal skeletal point sequence, at least one erroneous action to be identified and its original error parameters can be obtained. This can be achieved by inputting the four-dimensional spatiotemporal skeletal point sequence into a pre-trained spatiotemporal graph convolutional neural network, and outputting the abnormal action fragment and its corresponding low-level parameter deviations through forward inference. For example, this operation can be achieved by using a sliding window to segment long sequences and outputting the error probability and parameter residuals segment by segment, or by connecting an action segmentation head and a parameter regression head to the graph convolutional output layer to jointly optimize the identification and extraction tasks. This enables high-precision, automated action anomaly detection and parameter quantization.

[0076] The system identifies key error actions among the error actions to be identified by a classifier trained on an error knowledge base, and retrieves the standard repair parameters corresponding to the key error actions.

[0077] The error knowledge base can be a structured collection of domain knowledge storing historical animation error cases, corresponding repair strategies, and standard parameters. It can provide training supervision signals for the classifier and support the retrieval of standard repair parameters. In one specific embodiment, the error knowledge base can be constructed by accumulating debugging marker instructions, repair records, and animation specification documents from the project. Furthermore, the error knowledge base can include, but is not limited to, one or more of the following: a clipping error pattern library, a slippage correction rule set, and an IK failure response template. The classifier can be an artificial intelligence model trained based on the error knowledge base to determine the severity and type of error actions. It can be used to filter out key error actions that significantly impact the user experience from the error actions to be identified. In this embodiment, the classifier can be trained on labeled error samples using supervised learning methods (such as SVM, Transformer, or graph neural networks). For example, the classifier can rely on the labels and features provided by the error knowledge base, and its output determines whether to retrieve standard repair parameters.

[0078] Key erroneous actions can be types of erroneous actions that, as determined by the classifier, require priority repair, possess clear semantics, and have high impact. These can serve as the basis for triggering standard repair parameter calls, ensuring resources are focused on core issues. Furthermore, key erroneous actions can include, but are not limited to, one or more of the following: character clipping actions, foot slip sequences, and joint reverse bending postures. Standard repair parameters can be reference repair configurations bound to key erroneous action types and conforming to animation specifications or physical constraints. They can be used to provide goal guidance for the regression model, ensuring the rationality and consistency of the generated update sequence. In an exemplary embodiment, standard repair parameters can be obtained from an error knowledge base indexed by key erroneous action type and used together with the original error parameters as input to the regression model.

[0079] Identifying key erroneous actions within a given erroneous action using a classifier trained on an error knowledge base can be achieved by inputting the features of the erroneous action (such as movement amplitude, duration, and joint distribution) into the classifier and outputting a determination of whether it belongs to a key erroneous action. Furthermore, this operation can be implemented by using graph embedding vectors as classifier input to preserve skeletal topology information, or by combining a rule engine to perform secondary verification of the classification results (such as threshold filtering), thereby introducing domain priors and improving the semantic accuracy and business relevance of error screening. Retrieving standard repair parameters corresponding to key erroneous actions can be achieved by retrieving predefined standard repair parameters from the error knowledge base based on the identified key erroneous action type. For example, this operation can be implemented by directly searching for standard parameters by error type ID using a hash table, or by using similarity matching to recall the parameters of the closest historical repair cases from the knowledge base, thus providing a benchmark for the repair target and avoiding blind correction.

[0080] By using a regression model, the four-dimensional skeleton sequence is updated based on the standard repair parameters and the original error parameters, resulting in a four-dimensional skeleton point update sequence.

[0081] The regression model can be a machine learning module used to map the original error parameters to standard repair parameters and generate optimized skeletal trajectories. It can be used to achieve non-linear correction of error parameters and output a smooth, compliant four-dimensional skeletal point update sequence. In this embodiment, the regression model employs architectures such as multilayer perceptrons, LSTMs, or conditional variational autoencoders, trained on paired error-repair data. Furthermore, the regression model can include, but is not limited to, parameter interpolation regressors, physically constrained projection networks, and style-preserving correction models. By updating the four-dimensional skeletal sequence based on the standard repair parameters and the original error parameters using the regression model, the four-dimensional skeletal point update sequence can be obtained by inputting the original error parameters and standard repair parameters as conditions into the regression model, generating a corrected skeletal point trajectory sequence. In a specific embodiment, this operation can be achieved by using a conditional generative adversarial network (cGAN) to generate a repair sequence with standard parameters as conditions, or by using a deterministic regression model to output parameter offsets and superimposing them onto the original sequence to generate the update result. This allows for parameter-level precise repair, ensuring the naturalness and standardization of the movements.

[0082] For example, in the scenario of intelligently fixing the jitter problem in character rolling animation in a multiplayer online game, the code reuse and management method in the game development process of this embodiment can be as follows: Testers mark a character that exhibits high-frequency shoulder jitter when performing a roll during high-speed movement. The system has generated a four-dimensional spatiotemporal skeletal point sequence. The spatiotemporal graph convolutional neural network analyzes this sequence and detects two erroneous actions to be identified: one is a sudden change in shoulder joint rotation angle (±60° / frame), and the other is a slight over-limit of the elbow. The classifier determines the shoulder abnormality as a key erroneous action based on an error knowledge base (where "high-frequency rotational sudden change" is marked as a key error). The system then retrieves the standard repair parameters for "shoulder rotation smoothing" from the knowledge base: the maximum angular velocity is limited to 30° / frame, and cubic spline interpolation is used. The regression model receives the original error parameters (mutation sequence) and standard parameters, outputs the smoothed shoulder trajectory, and generates a four-dimensional skeletal point update sequence. The programmer previews the repaired animation in the debugging interface, confirms that the jitter has disappeared and the rolling is smooth, and adopts the repair solution with one click.

[0083] In one embodiment, before acquiring viewpoint interaction information entered through the viewpoint interaction interface of the code editing terminal, the method further includes: In response to the terminal's connection request, obtain the terminal's account login information, as well as the editing permission information and project authorization information that match the account login information; If the editing permission information includes scene editing permissions and the project authorization information matches any scene of the game project to be launched, the scene will be identified as the authorized scene of the terminal, and the terminal will be bound to the authorized scene. The binding relationship between the terminal and the authorized scene is sent to the scene rendering system so that when the scene rendering system receives the viewpoint interaction information entered by the terminal, it updates the game scene data of the authorized scene according to the viewpoint interaction information.

[0084] The terminal can be a client device or software instance that initiates a connection request to participate in collaborative editing. It can serve as the entry point for users to access the collaborative editing system and carry out subsequent viewpoint interaction and debugging operations. In an exemplary embodiment, the terminal can initiate a connection request to the collaborative server via a network protocol (such as HTTP / WebSocket). Furthermore, the terminal can establish a binding relationship with an authorized scene and act as the object that the scene rendering system processes viewpoint interaction information. The connection request can be an authentication and resource access request signal initiated by the terminal to the collaborative system, which can be used to trigger the start event of the permission verification and scene binding process. For example, the connection request can be automatically sent by the terminal when starting an editing session and includes basic connection metadata. Account login information can be credential data used to identify the user's identity, typically including a user ID, token, or session key, which can be used as the basis for permission matching and authorization verification. In a specific embodiment, the account login information can be carried by the terminal in the connection request or obtained through standard authentication protocols such as OAuth.

[0085] Editing permission information can be permission configuration data describing the set of operational capabilities an account possesses. It can be used to control the types of editing actions a user can perform, preventing unauthorized modifications. Furthermore, editing permission information can include, but is not limited to, one or more of the following: scene editing permissions, script modification permissions, and resource upload permissions. Project authorization information can be a list of authorized game projects and their sub-resources that a specified account can access. It can be used to restrict users to only operating on explicitly authorized project content, achieving project-level isolation. For example, project authorization information can include project read-only authorization, scene write authorization, and asset library access authorization.

[0086] Scene editing permission can be a specific permission item in the editing permission information, indicating that structural or attribute modifications to the game scene are permitted. It can be used as one of the key conditions for determining whether a terminal is allowed to bind a scene. In one specific embodiment, scene editing permission can be parsed from the permission management system based on account role policies. The game project to be launched can be the game development project entity that the current collaborative editing session targets, and can be used as a reference object for matching project authorization information. Further, the game project to be launched can be declared by the terminal in the connection request, or inferred by the server based on the context. Any scene can be any independently editable scene unit contained in the game project to be launched, and can be used as a specific unit of granularity for matching project authorization information. In an exemplary embodiment, any scene can be enumerated from the project resource list.

[0087] An authorized scenario can be a specific scenario formally assigned to the terminal for editing operations after undergoing dual verification of permissions and authorization. It can be used to define the scope of all subsequent viewpoint interaction information on the terminal, ensuring the legality of the operation. Furthermore, the authorized scenario can be bound to the terminal and serve as the target object for the scene rendering system to update game scene data. The binding relationship can be a mapping association record between the terminal and its authorized scenario, which can be used to provide operational scope constraints for the scene rendering system, preventing accidental cross-scene operations. In one specific embodiment, the binding relationship can be generated and persistently stored by the collaborative server after successful verification. For example, the binding relationship can be sent to the scene rendering system for filtering and routing viewpoint interaction information.

[0088] In response to a terminal's connection request, the system obtains the terminal's account login information. This can be achieved by listening for connection request events and extracting or obtaining account credentials through an authentication process. Further, this operation can be implemented by parsing the JWT token from the request header and verifying its validity, or by guiding the terminal through an OAuth 2.0 authorization code process to obtain the user ID, thus establishing a foundation for linking user identity with subsequent permission verification. Matching the editing permission information and project authorization information of the account login information can be done by querying the permission management database and retrieving the corresponding permission configuration and project authorization list based on the account ID. In a specific embodiment, this operation can be implemented by calling the RBAC (Role-Based Access Control) service to return a permission set, or by querying the ABAC (Attribute-Based Access Control) policy engine to dynamically evaluate the authorization status, thereby achieving fine-grained identity-based access control pre-verification.

[0089] If the editing permission information includes scene editing permissions and the project authorization information matches any scene of the game project to be launched, the scene is determined as the authorized scene for the terminal. This can be achieved by logically determining whether the editing permissions include scene editing permissions and checking whether the project authorization covers at least one scene in the project to be launched. If so, the scene is selected as the authorized scene. For example, this operation can be implemented by selecting the first writable scene in the project authorization information as the authorized scene, or by the user manually selecting the target scene from multiple authorized scenes. This ensures that the terminal can only operate on the scenes it is explicitly authorized to, achieving operation isolation. Binding the terminal to the authorized scene can be achieved by establishing a mapping relationship between the terminal identifier and the authorized scene ID on the collaborative server and marking it as a valid session. In an exemplary embodiment, this operation can be implemented by registering a binding entry in the in-memory session table and setting an expiration time, or by creating a temporary node in a distributed coordination service (such as ZooKeeper) to represent the binding. This solidifies the operational scope of the terminal and provides context constraints for subsequent interactions.

[0090] Sending the binding relationship between the terminal and the authorized scene to the scene rendering system can be achieved by synchronizing the binding relationship to the scene rendering system via an internal API or message queue. Furthermore, this operation can be implemented by calling the binding registration interface of the scene rendering system via gRPC, or by publishing a binding event to a shared message bus for the rendering system to subscribe to and consume. This allows the scene rendering system to filter and target viewpoint interaction information based on the binding relationship. When the scene rendering system receives viewpoint interaction information entered by the terminal, it updates the game scene data of the authorized scene based on the viewpoint interaction information. This can be done by verifying whether the terminal from which the viewpoint interaction information originates has a binding relationship with the corresponding scene; if so, the update is performed only on that authorized scene. In a specific embodiment, this operation can be achieved by loading and updating only the subtree of the authorized scene in the scene graph, or by directly discarding interaction requests from unauthorized scenes and recording them in the audit log. This enables scope isolation based on permissions, preventing unauthorized or cross-project misoperations.

[0091] Taking permission isolation in parallel development of multiple projects as an example, the code reuse and management method in the game development process of this embodiment can be as follows: A game company is developing two VR projects, A and B, simultaneously. Scene designer A has scene editing permissions for project A, but no authorization for project B. When A connects to the collaborative system using a code editing terminal, the system obtains his account login information and matches the editing permission information, which includes "scene editing permissions," but the project authorization information only includes project A. At this time, the game project to be launched is project A, and the system selects the "main city scene" as the authorized scene and establishes a binding relationship between the terminal and the scene. Subsequently, A moves and modifies the building layout in VR, and the scene rendering system only updates the main city scene of project A. If A tries to switch to the scene of project B, because there is no binding relationship, his viewpoint interaction information will be ignored, thereby avoiding accidental operation that contaminates the data of other projects.

[0092] In one embodiment, the method further includes: Update the scene performance statistics widget based on the performance data of each game object in the scene update data.

[0093] The performance data of each game object can be a set of runtime performance metrics generated by each independently manageable game entity in the scene within the current frame or time period. This data can be used to evaluate the impact of a single object on overall performance, supporting fine-grained performance analysis and optimization. In an exemplary embodiment, the performance data of each game object can be collected from object instances by the engine performance probe after each frame update and appended to the scene update data. For example, the performance data of each game object can include, but is not limited to, one or more of the following: number of rendering batches, script execution time, memory reference size, etc. The scene performance statistics widget can be a dynamic performance summary container that aggregates and structurally encapsulates the performance data of all game objects in the scene. This can be used to provide a performance context synchronized with the current scene state, supporting correlation analysis of performance anomalies during debugging. Furthermore, the scene performance statistics widget can be updated based on the performance data in the scene update data and merged with the real-time scene data at the current moment to generate scene node debugging data. In a specific embodiment, the scene performance statistics widget can include, but is not limited to, CPU load distribution maps, GPU rendering call summaries, resource loading latency logs, etc.

[0094] Updating the scene performance statistics widget based on the performance data of each game object in the scene update data can be achieved by extracting the performance metrics of each game object from the scene update data, aggregating them by category, and then refreshing the content of the scene performance statistics widget. Furthermore, this operation can be implemented by using a sliding window algorithm to calculate the average performance metric of the most recent N frames and updating the widget, or by grouping statistics based on object type (such as UI, character, environment) and generating categorized performance summaries. This allows for dynamic accumulation and visualization of performance data, providing performance context for subsequent debugging.

[0095] When the time data in the scene update data triggers the preset time condition of any scene node, or when a pause debugging command is received through the test interface, the real-time scene data at the current moment is obtained.

[0096] The time data can be the current game logic time or frame number information recorded in the scene update data, and can be used as a time reference for triggering preset time condition judgments. In one specific embodiment, the time data can be injected into the scene update data by the game's main loop each time the scene is updated. Scene nodes can be addressable units with independent logic or state control capabilities in the game scene graph, and can be used as basic units for event binding, animation control, or debugging anchors. For example, scene nodes can include, but are not limited to, one or more of animation controller nodes, trigger volume nodes, and AI behavior tree root nodes. Preset time conditions can be time triggering rules configured for specific scene nodes, used to activate debug capture when a time threshold is met. In one exemplary embodiment, preset time conditions can be set by the developer during the editing phase through the node attribute panel and stored in the node metadata.

[0097] The pause debugging command can be a control signal actively issued by the tester through the test interface to interrupt the current scene evolution and capture the state. It can be used to support manual intervention debugging, freezing the scene to preserve the complete context the moment an anomaly is detected. Furthermore, the pause debugging command can trigger the acquisition of real-time scene data at the current moment. This real-time scene data can be a snapshot of the complete scene state captured at the moment the pause debugging command is received, triggered under preset time conditions. It can be used as the core content carrier for generating scene node debugging data, ensuring state accuracy and timeliness. In a specific embodiment, the real-time scene data at the current moment can be serialized by the scene rendering system immediately upon the occurrence of the trigger event, serializing the entire scene state of the current frame.

[0098] When the time data in the scene update data triggers a preset time condition for any scene node, the real-time scene data at the current moment is obtained. This can be achieved by monitoring the time data in the scene update data and immediately capturing the current complete scene state when it meets the preset time condition for any scene node. Furthermore, this operation can be implemented by iterating through all scene nodes with preset time conditions and comparing the current time data for each match, or by maintaining a time condition index table and triggering a match check only when the time data crosses a key threshold. This allows for automated state snapshots of key logic nodes, recording important moments without manual intervention. When a pause / debugging command is received via the test interface, the real-time scene data at the current moment is obtained. This can be achieved by monitoring the input on the test interface and immediately freezing the scene evolution and capturing the current state upon receiving the pause / debugging command. For example, this operation can be triggered by mapping a gamepad shortcut key to pause and synchronously record the input device state, or by performing state capture after a confirmation dialog box pops up on the test interface to avoid accidental touches. This allows testers to proactively save a high-fidelity debugging context at any abnormal moment.

[0099] The current real-time scene data and scene performance statistics widget are used to generate scene node debugging data.

[0100] The scene node debugging data can be a structured debugging package generated by fusing real-time scene data and scene performance statistics widgets at the current moment. This package can simultaneously include functional status and performance context, supporting high-fidelity playback and multidimensional root cause analysis. In one specific embodiment, scene node debugging data may include, but is not limited to, state snapshots with performance heatmaps, time-series event-performance correlation records, and node-level resource dependency lists. Furthermore, scene node debugging data can be jointly generated from real-time scene data and scene performance statistics widgets at the current moment. Generating scene node debugging data from real-time scene data and scene performance statistics widgets at the current moment can be achieved by structurally merging the captured real-time scene data with the latest scene performance statistics widget to form a unified debugging data package. For example, this operation can be achieved by embedding performance widgets as metadata into the scene state serialization stream, or by constructing a joint data structure that allows the debugging interface to simultaneously browse visual status and performance heatmaps, thereby generating composite debugging data that simultaneously includes functional status and performance indicators, enhancing the dimensions of problem analysis.

[0101] Taking the debugging of performance-functional coupling anomalies in complex cutscenes as an example, the code reuse and management method in the game development process of this embodiment can be as follows: A certain cutscene should trigger a character expression change at the 15th second, but the test engineer found that the screen was lagging and the expression was not updated at this time. The animation node has a preset time condition of t=15.0s. When the scene time data reaches this value, the system automatically captures the real-time scene data at the current moment, and at the same time, the scene performance statistics widget shows that the Shader compilation time of a certain material instance suddenly increases. The two are merged to generate scene node debugging data. After the programmer loads this data in the code debugging terminal, he can not only replay the complete visual state at t=15s, but also directly locate the Shader compilation blockage caused by the incomplete loading of asynchronous resources, thereby quickly fixing the resource preloading logic.

[0102] In one embodiment, the method further includes: The scene update data is sent to the scene rendering display terminal in the venue so that the real-time scene rendering data can be displayed through the scene rendering display terminal; Send real-time view data and debug playback data to at least one target cloud test platform webpage; Acquire fixed-view scene data from image acquisition devices based on a fixed viewpoint of the scene, and send the fixed-view scene data to the on-site test monitoring webpage.

[0103] The on-site scene rendering display terminal can be a dedicated display device or client deployed at the development or review site to showcase the latest game scene rendering results. It can provide high-fidelity visual feedback synchronized with editing actions to non-editing roles (such as product managers and art reviewers), enabling real-time linkage between the development and presentation ends. In an exemplary embodiment, the on-site scene rendering display terminal can subscribe to scene update data via a local area network, driving a local lightweight renderer or video decoder to output the screen. Real-time scene rendering data can be a visualization image stream generated by the scene rendering system based on the latest scene state, intended for presentation purposes. It can be used to present an immersive screen consistent with editing operations on the on-site scene rendering display terminal for on-site review or demonstration. For example, the real-time scene rendering data can reuse the main output frame of the scene rendering system, encoded, and then pushed to the display terminal.

[0104] Sending scene update data to the on-site scene rendering display terminal can be achieved by transmitting scene update data generated by the scene rendering system to the on-site scene rendering display terminal via a local area network. Furthermore, this operation can trigger terminal re-rendering by broadcasting scene update events via UDP multicast, or by using a message queue to push complete scene snapshots for incremental updates to the terminal. This allows for synchronization between development / editing activities and the on-site display terminal's screen, supporting real-time review by non-editing roles. Displaying real-time scene rendering data through the scene rendering display terminal can be achieved by the on-site scene rendering display terminal receiving data and driving a local renderer or video decoder to output the screen. In one specific embodiment, this operation can run a lightweight engine instance to load scene update data and render it in real time, or decode the received video stream and play it in a full-screen window, resulting in a high-fidelity scene view on a dedicated display device consistent with the editing end.

[0105] The target cloud testing platform webpage can be a front-end interface of a remote testing collaboration platform built on web technology. It allows remote testers to access real-time view data and debug playback data through a standard browser, without requiring a local engine environment. In this embodiment, the target cloud testing platform webpage can receive debug data pushed by the server via HTTP / WebSocket and render it using WebGL or video tags. Sending real-time view data and debug playback data to at least one target cloud testing platform webpage can be achieved by transmitting the generated real-time view data and debug playback data to the cloud testing platform's server via the internet, which then pushes it to the corresponding webpage front-end. For example, this operation can package the data into a web-compatible format (such as GLB+JSON) and upload it via REST API, or establish a WebSocket long connection to push frame data and playback instructions in a streaming manner, allowing remote testers to access debug content in a standard browser and lowering the barrier to entry for the collaboration environment.

[0106] A fixed scene viewpoint can be a preset observation position and orientation in a virtual scene that does not change with user interaction. It can be used to provide a stable and repeatable observation benchmark for automated monitoring or regression testing. In a specific embodiment, the fixed scene viewpoint can include, but is not limited to, one or more of the following: an orthogonal top-down viewpoint, a main viewpoint from the character's spawn point, and a side viewpoint from a key interaction area. The image acquisition device can be a virtual camera component bound to the fixed scene viewpoint for continuously capturing the rendered image from that viewpoint. It can be used to generate objective visual records unaffected by the editor's subjective viewpoint for monitoring or automated comparison. Furthermore, the image acquisition device can be an additional camera in the scene rendering pipeline, performing independent rendering and outputting image frames for each frame. Fixed-view scene data can be a sequence of images and its timestamp metadata continuously acquired by the image acquisition device under the fixed scene viewpoint. It can be used to provide a standardized and repeatable visual monitoring stream, supporting automated regression testing and third-party anomaly verification. In this embodiment, the fixed-view scene data can be rendered and encoded into a video stream or image sequence by a virtual camera. Acquiring fixed-view scene data from an image acquisition device based on a fixed viewpoint can be achieved by activating a virtual camera bound to a preset fixed viewpoint, capturing its output image and attaching a timestamp during each frame rendering cycle. For example, this operation can be performed an additional rendering pass for the fixed-view camera within the main rendering loop, or a separate rendering thread can be started specifically to handle fixed-view image acquisition, thereby generating an objective visual recording stream unaffected by user interaction.

[0107] The on-site test monitoring webpage can be a web monitoring panel deployed on a local network to centrally display fixed-view scene data. It can provide the on-site testing team with visualization of scene status from a stable perspective, assisting in performance evaluation and anomaly identification. In an exemplary embodiment, the on-site test monitoring webpage can receive fixed-view scene data via an intranet HTTP service and play it in real time in a browser. Sending fixed-view scene data to the on-site test monitoring webpage can be achieved by pushing the acquired fixed-view image sequence to the webpage via intranet HTTP or WebSocket protocols. Furthermore, this operation can continuously push image frames via HTTP in the form of MJPEG streams, or package the image sequence and timestamps into TS fragments and distribute them via the HLS protocol, thereby building a stable and auditable local monitoring channel that supports automated testing and anomaly comparison.

[0108] Taking cross-regional team collaborative debugging and local automated monitoring as an example, the code reuse and management method in the game development process of this embodiment can be as follows: A scene designer adjusts the lighting parameters of a level in the code editing terminal. The scene update data is synchronously sent to the scene rendering display terminal deployed in the conference room, and the product manager can immediately see the adjusted visual effect on the large screen. Simultaneously, the real-time view data triggered by this operation and the debugging playback data generated by the previously tested markers are pushed to the company's cloud testing platform webpage. QA engineers located overseas can open a browser to load and reproduce the lighting anomaly. Meanwhile, image acquisition devices with three preset fixed perspectives (such as an overhead view of the entrance, a main view of the combat zone, and a side view of the exit) continuously capture images and push the fixed-perspective scene data to the local test monitoring webpage in real time. The automated script compares the frame differences under these perspectives daily, and if it finds that the lighting adjustment caused the shadow offset to exceed the threshold, it automatically submits a regression failure report. These three types of terminals serve review, remote debugging, and automated verification respectively, forming a multi-dimensional collaborative feedback loop.

[0109] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a code reuse and management program for game development, wherein when the code reuse and management program for game development is executed by a processor, it implements the steps of the code reuse and management method for game development as described above.

[0110] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for code reuse and management in a game development process, characterized in that, The method includes: The viewpoint interaction information entered through the viewpoint interaction interface of the code editing terminal is acquired, and the viewpoint interaction information is forwarded to the scene rendering system so that the scene rendering system updates the game scene data based on the viewpoint interaction information. The viewpoint interaction information includes viewpoint position and interaction type. Retrieve at least one target rendering parameter that matches the viewpoint position and the interaction type, generate real-time view data based on the target rendering parameters and real-time scene data, and send the real-time view data to the code debugging terminal so that the real-time view data can be displayed in real time through the debugging interface of the code debugging terminal; Historical scene code data is extracted based on the timestamp of the debugging mark instruction and the interaction type. The debugging mark instruction is an instruction entered on the test interface of the test terminal before the viewpoint interaction information is obtained. In response to data updates from the scene rendering system, a scene debugging widget is generated based on the scene update data. Debug playback data is generated based on the scene debugging widget and the historical scene code data. The debug playback data is then sent to the code debugging terminal to be displayed through the debugging interface.

2. The method for code reuse and management during game development as described in claim 1, characterized in that, Before generating debug playback data based on the scene debug widget and the historical scene code data, the method further includes: Acquire the timestamp of the debugging marker command entered through the test interface of the test terminal, as well as the viewpoint pose data of the scene rendering engine within a preset historical time period; The debugging clip parameters are determined based on the timestamp, the viewpoint pose data, and the interaction type. The historical scene code data is edited according to the aforementioned debugging and editing parameters to obtain the historical scene code data.

3. The method for code reuse and management during game development as described in claim 2, characterized in that, The debugging editing parameters include the target debugging duration, and the process of determining the target debugging duration includes: Identify the expected debugging duration matching the interaction type from the preset debugging duration mapping relationship set; Based on the viewpoint pose data, calculate the maximum continuous stable duration for which the viewpoint pose change deviation is less than a preset deviation threshold before the time point recorded by the marked timestamp, and use the maximum continuous stable duration as the viewpoint stable duration. If the ratio of the viewpoint stabilization time to the expected debugging time is greater than or equal to a preset percentage, then the expected debugging time is determined as the target debugging time. If the ratio of the viewpoint stabilization time to the expected debugging time is less than a preset percentage, the expected debugging time is corrected according to a correction coefficient, and the correction result is used as the target debugging time. The correction coefficient is an exponential function of the proportional deviation between the preset percentage and the ratio.

4. The method for code reuse and management during game development as described in claim 3, characterized in that, The debugging clipping parameters also include the debugging start image frame, and the process of determining the debugging start image frame includes: The key time point is calculated based on the marked timestamp and the preset delay duration, wherein the preset delay duration is determined based on historical instruction input delay data; The starting point is moved forward based on the interaction type, where different interaction types have their own pre-configured starting point forward time. The difference between the key time point and the starting point is used as the debugging start time point, and the image frame that matches the debugging start time point is identified from the historical scene code data as the debugging start image frame.

5. The method for code reuse and management during game development as described in claim 2, characterized in that, The historical scenario code data includes error scenario data, and the method further includes: Obtain supplementary viewpoint error scene data that matches the error scene data. Extract the three-dimensional skeleton point sequence of the target game object from the error scene data and the supplementary viewpoint error scene data respectively through key point detection. And obtain the four-dimensional spatiotemporal skeleton point sequence of the target game object by registering the three-dimensional skeleton point sequences from different viewpoints. Based on the four-dimensional spatiotemporal skeleton sequence, erroneous actions are decomposed and erroneous parameters are extracted to obtain the original erroneous parameters of at least one erroneous action, and a four-dimensional skeleton point update sequence is generated based on the correction results of the original erroneous parameters. When a repair animation request instruction is received through the error repair control in the debugging interface, the four-dimensional skeleton point update sequence is bound to the corresponding skeleton points of the pre-built three-dimensional model of the game object, and an error repair animation is generated based on the bound game object model and displayed through the debugging interface.

6. The method for code reuse and management during game development as described in claim 5, characterized in that, The step of decomposing erroneous actions and extracting erroneous parameters based on the four-dimensional spatiotemporal skeleton sequence to obtain original erroneous parameters for at least one erroneous action, and generating a four-dimensional skeleton point update sequence based on the correction results of the original erroneous parameters, includes: The four-dimensional spatiotemporal skeleton point sequence is decomposed and identified using a spatiotemporal graph convolutional neural network to obtain at least one erroneous action to be identified and the original error parameters of the erroneous action to be identified. The key error actions in the error actions to be identified are identified by a classifier trained based on an error knowledge base, and the standard repair parameters corresponding to the key error actions are retrieved. The four-dimensional skeleton sequence is updated using a regression model based on the standard repair parameters and the original error parameters to obtain the four-dimensional skeleton point update sequence.

7. The method for code reuse and management during game development as described in claim 1, characterized in that, Before acquiring the viewpoint interaction information entered through the viewpoint interaction interface of the code editing terminal, the method further includes: In response to a connection request from a terminal, obtain the terminal's account login information, as well as the editing permission information and project authorization information that match the account login information; If the editing permission information includes scene editing permissions and the project authorization information matches any scene of the game project to be launched, the scene is determined as the authorized scene of the terminal, and the terminal is bound to the authorized scene; The binding relationship between the terminal and the authorized scene is sent to the scene rendering system, so that when the scene rendering system receives the viewpoint interaction information recorded by the terminal, it updates the game scene data of the authorized scene according to the viewpoint interaction information.

8. The method for code reuse and management during game development as described in claim 1, characterized in that, The method further includes: Update the scene performance statistics widget based on the performance data of each game object in the scene update data; When the time data in the scene update data triggers the preset time condition of any scene node, or when a pause debugging command is received through the test interface, the real-time scene data at the current moment is obtained. The real-time scene data at the current moment and the scene performance statistics widget are used to generate scene node debugging data.

9. The method for code reuse and management during game development as described in claim 1, characterized in that, The method further includes: The scene update data is sent to the scene rendering and display terminal in the venue so that the real-time scene rendering data can be displayed through the scene rendering and display terminal; Send the real-time view data and the debug playback data to at least one target cloud test platform webpage; Acquire fixed-view scene data collected by an image acquisition device based on a fixed viewpoint of the scene, and send the fixed-view scene data to the on-site test monitoring webpage.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a code reuse and management program for game development, which, when executed by a processor, implements the steps of the code reuse and management method for game development as described in any one of claims 1 to 9.

Images