A game automation method and related apparatus

Abstract

This application discloses a game automation method and related apparatus in the field of artificial intelligence. The method includes: acquiring recorded sample data, including feature data corresponding to each frame of the reference screen during the recording of the game process. The feature data includes the position information of a virtual character and a time interval, where the time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen; controlling the virtual character to participate in the replay of the game process based on the recorded sample data. During this process, when the virtual character is at the position corresponding to the first feature data, a movement speed is determined according to the position of the virtual character and the position information and time interval included in the second feature data, and the virtual character is controlled to move towards the position corresponding to the second feature data according to the movement speed; the reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data. This method can improve the game AI effect.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a game automation method and related apparatus. Background Technology

[0002] Artificial intelligence (AI) in gaming is a technology that automatically controls virtual characters in games without human intervention. It is the foundational technology for achieving functions such as game automation, game companionship, and game testing.

[0003] Among related technologies, solutions for implementing game AI include a game-process-based recording and playback scheme. This scheme is implemented in two phases: a recording phase and a playback phase. During the recording phase, the position and actions of the virtual character in each frame of the game are recorded. During the playback phase, based on the data recorded during the recording phase, the virtual character is controlled frame-by-frame to reach the corresponding position and perform the corresponding actions.

[0004] When applying the above solution to multiplayer cooperative games, multiple devices are needed to control different virtual characters during the playback phase. However, devices with different configurations may play game footage at different frame rates. Controlling virtual characters frame by frame on multiple devices based on the data recorded during the recording phase can easily cause the relative movement speed of the virtual characters controlled by each device to change compared to the recording phase. Consequently, the positional relationships between multiple virtual characters will be disrupted, differing from the positional relationships between multiple virtual characters during the recording phase. This will affect the cooperation between virtual characters, and thus affect the game's AI performance. Summary of the Invention

[0005] This application provides a game automation method and related apparatus that can restore the positional relationships between multiple virtual characters during the recording phase in the replay phase of a multiplayer cooperative game, thereby better restoring the cooperation between multiple virtual characters and improving the game AI effect.

[0006] In view of the above, the first aspect of this application provides a game automation method, the method comprising:

[0007] Acquire recorded sample data; the recorded sample data includes feature data corresponding to each frame of the reference screen during the recording of the game. The feature data includes the position information of the virtual character in the corresponding reference screen and the time interval. The time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen.

[0008] Based on the recorded sample data, the virtual character is controlled to participate in the replay game process;

[0009] During the replay of the game, when the virtual character is at the position corresponding to the first feature data in the recorded sample data, the movement speed of the virtual character is determined based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data. The virtual character is then controlled to move towards the position of the virtual character corresponding to the second feature data at the movement speed. The reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data.

[0010] A second aspect of this application provides a game automation device, the device comprising:

[0011] The data acquisition module is used to acquire recorded sample data; the recorded sample data includes feature data corresponding to each frame of the reference screen during the recording of the game process, the feature data includes the position information of the virtual character in the corresponding reference screen and the time interval, the time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen.

[0012] The replay control module is used to control the virtual character to participate in the replay game process based on the recorded sample data;

[0013] The replay control module is further configured to, during the replay of the game, when the virtual character is at the position corresponding to the first feature data in the recorded sample data, determine the movement speed of the virtual character based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data, and control the virtual character to move towards the position of the virtual character corresponding to the second feature data at the movement speed; the reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data.

[0014] A third aspect of this application provides an electronic device, the device comprising a processor and a memory:

[0015] The memory is used to store computer programs;

[0016] The processor is configured to perform the steps of the game automation method as described in the first aspect above, according to the computer program.

[0017] A fourth aspect of this application provides a computer-readable storage medium for storing a computer program for performing the steps of the game automation method described in the first aspect.

[0018] A fifth aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of the game automation method described in the first aspect.

[0019] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0020] This application provides a game automation method. The method acquires recording sample data based on the recorded game process during the recording phase. This recording sample data includes feature data corresponding to each frame of the reference screen during the recorded game process. The feature data corresponding to each frame of the reference screen includes the position information of the virtual character and a time interval, where the time interval is the display time difference between the current frame and the previous frame. During the playback phase, i.e., the phase where the virtual character is controlled to participate in the replay game process based on the recording sample data, when the virtual character is at the position corresponding to the first feature data in the recording sample data, the movement speed of the virtual character is determined based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data. The virtual character is then controlled to move at the movement speed to the position corresponding to the virtual character in the second feature data. Here, the reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data. The method described above determines the movement speed of the virtual character based on the positional information of two adjacent reference frames during game recording and the time interval between these two frames. This ensures that the virtual character's movement speed during playback is replicated from the recording stage. Specifically, during playback, the virtual character moves from its position in the previous reference frame to its position in the next reference frame at the same speed as during recording. When applied to multiplayer cooperative games, this method can restore the movement speed of each virtual character during playback, ensuring that their relative movement speeds are the same as during recording. This allows for the restoration of the positional relationships of the virtual characters during recording, facilitating the reproduction of their cooperation and resulting in better game AI performance. Attached Figure Description

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of the game automation method provided in the embodiments of this application;

[0022] Figure 2 A flowchart illustrating a game automation method provided in an embodiment of this application;

[0023] Figure 3 A flowchart illustrating the method for automatically recording game processes provided in this application embodiment;

[0024] Figure 4 An exemplary static resource diagram provided for embodiments of this application;

[0025] Figure 5 A schematic diagram illustrating the implementation principle of determining the target location provided in an embodiment of this application;

[0026] Figure 6 This is a schematic diagram illustrating the implementation principle of recording sample data provided in the embodiments of this application;

[0027] Figure 7 A flowchart illustrating another game automation method provided in an embodiment of this application;

[0028] Figure 8 A schematic diagram of the interface of an FPS game provided for an embodiment of this application;

[0029] Figure 9 This is a schematic diagram of the structure of the game automation device provided in the embodiments of this application;

[0030] Figure 10 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application;

[0031] Figure 11 This is a schematic diagram of the server structure provided in an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0033] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] Artificial intelligence (AI) is the theory, methods, technology, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. In other words, AI is a comprehensive technology within computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine that can react in a way similar to human intelligence. AI studies the design principles and implementation methods of various intelligent machines, enabling them to possess the functions of perception, reasoning, and decision-making.

[0035] Artificial intelligence (AI) is a comprehensive discipline encompassing a wide range of fields, including both hardware and software technologies. Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies primarily include computer vision, speech processing, natural language processing, as well as machine learning / deep learning, autonomous driving, and intelligent transportation.

[0036] The solutions provided in this application involve artificial intelligence technology, which are specifically illustrated through the following embodiments:

[0037] In related technologies, solutions for implementing game AI based on game recording and playback involve controlling virtual characters to reach corresponding positions and perform corresponding operations frame by frame during the playback phase, based on the data recorded during the recording phase. When applying this solution to multiplayer cooperative games, if different devices with different configurations are used to control different virtual characters during the playback phase, the different frame rates of the playback on different devices will lead to different movement speeds for the virtual characters, resulting in a difference in the positional relationships between multiple virtual characters compared to the recording phase. For example, assuming 50 frames of data are recorded per second during the recording phase, and during the playback phase, device A (playing 50 frames per second) controls virtual character 'a', while device B (playing 20 frames per second) controls virtual character 'b'; then, during the playback phase, virtual character 'a' can execute up to the 50th recorded frame in the first second, while virtual character 'b' can only execute up to the 20th recorded frame in the first second. Clearly, the positional relationship between virtual characters 'a' and 'b' changes during the playback phase compared to the recording phase. Furthermore, it becomes impossible to reproduce the collaboration between multiple virtual characters during the recording phase during the playback phase, affecting the game AI performance.

[0038] To address the aforementioned issues, this application provides a game automation method. The method includes: acquiring recorded sample data, which includes feature data corresponding to each frame of a reference screen during game recording. The feature data includes the position information of a virtual character in the corresponding reference screen and a time interval, where the time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame. Furthermore, based on the recorded sample data, the method controls a virtual character to participate in a replay game process. During the replay, when the virtual character is at the position corresponding to the first feature data in the recorded sample data, the method determines the virtual character's movement speed based on the virtual character's current position, the position information of the virtual character included in the second feature data, and the time interval included in the second feature data. The method then controls the virtual character to move at the movement speed to the position corresponding to the virtual character in the second feature data. Here, the reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data.

[0039] The aforementioned game automation method determines the movement speed of the virtual character during the playback phase based on the positional information of two adjacent reference frames during game recording and the time interval between these two reference frames. This ensures that the movement speed of the virtual character during the recording phase is reproduced during playback. In other words, during playback, the virtual character can move from its position in the previous reference frame to its position in the next reference frame at the same speed as during recording. When applied to multiplayer cooperative games, this method can reproduce the movement speed of each virtual character during the recording phase, ensuring that the relative movement speed of each virtual character during playback is the same as during recording. This allows for the restoration of the positional relationships of the virtual characters during recording, facilitating the reproduction of their cooperation during recording and achieving better game AI effects.

[0040] Taking the example of recording 50 frames of data per second during the recording phase, the game automation method provided in this application embodiment can be used to record the first frame and the 50th frame as adjacent reference frames during the recording phase, and record the feature data corresponding to each of these reference frames, that is, record the position information of virtual character a and virtual character b in the first frame, record the position information of virtual character a and virtual character b in the 50th frame, and the time interval between the 50th frame and the first frame.

[0041] During the playback phase, assume that device A, which plays at 50 frames per second, controls virtual character a, and device B, which plays at 20 frames per second, controls virtual character b. Since the initial appearance position of each virtual character during playback is guaranteed to be the same as its initial appearance position during recording, the initial appearance position of virtual character a during playback is the same as the position of virtual character a in the feature data corresponding to the first frame of the recording phase. Similarly, the initial appearance position of virtual character b during playback is the same as the position of virtual character b in the feature data corresponding to the first frame of the recording phase (in this example, it is assumed that virtual characters a and b appear simultaneously in the first frame during both the recording and playback phases). For device A, when virtual character a is at its corresponding position in the feature data of the first frame of the recording phase, device A can determine the movement speed of virtual character a based on its current position, its position information in the feature data of the 50th frame, and the time interval between the 50th and first frames. Then, it controls virtual character a to move at that speed to its corresponding position in the feature data of the 50th frame. Device B uses a similar method to control virtual character b to move from its corresponding position in the feature data of the first frame to its corresponding position in the feature data of the 50th frame. The time interval between the 50th and first frames is 1 second. If devices A and B control virtual characters a and b respectively using the above methods, both virtual characters a and b will reach their corresponding positions in the 50th frame within 1 second. Thus, during the playback phase, the devices controlling each virtual character accordingly control the virtual character to reach its corresponding position within a specific time interval. Compared to the frame-by-frame control method in related technologies, this method no longer controls the virtual characters on a frame-by-frame basis. Therefore, it can avoid the change in the positional relationship of each virtual character during the playback phase compared to the recording phase due to the different frame rates of the devices controlling each virtual character, thereby more accurately restoring the positional relationship between each virtual character during the recording phase.

[0042] It should be understood that the game automation method provided in this application embodiment can be executed by an electronic device that supports the operation of the game program. This electronic device can be a terminal device or a server. Terminal devices include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers.

[0043] To facilitate understanding of the game automation method provided in this application embodiment, the following example uses a terminal device as the execution subject of the game automation method to illustrate the application scenarios of the game automation method.

[0044] See Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the game automation method provided in this application embodiment. For example... Figure 1 As shown, this application scenario includes a terminal device 110 and a server 120, which can communicate with each other via wired or wireless network. The server 120 stores the recorded sample data from the recording phase; the terminal device 110 executes the game automation method provided in this embodiment, controlling a virtual character to participate in the replay game process based on the recorded sample data.

[0045] In practical applications, terminal device 110 can obtain recorded sample data from server 120. The recorded sample data includes feature data corresponding to each frame of the reference screen during the recording of the game. The feature data includes the position information of the virtual character in the corresponding reference screen and the time interval, which is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen sampled.

[0046] After obtaining the recorded sample data, the terminal device 110 can implement the playback stage based on the recorded sample data; that is, based on the recorded sample data, it can control the virtual character to participate in the replay game process, control the virtual character to move according to its movement path during the recorded game process, and execute the operations it performed during the recorded game process.

[0047] During game replay, when the terminal device 110 detects that the virtual character is at the position corresponding to the first feature data in the recorded sample data, it can determine the second feature data in the recorded sample data. The reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data. Then, based on the current position of the virtual character, the position information included in the second feature data, and the time interval included in the second feature data, the device determines the movement speed of the virtual character and controls the virtual character to move to the position corresponding to the second feature data at the movement speed.

[0048] Thus, by determining the virtual character's movement speed using the above method and controlling the virtual character to move at that speed, the movement speed of the virtual character during game recording can be accurately reproduced. That is, during playback, the movement speed used by the virtual character to move from the position corresponding to the first feature data to the position corresponding to the second feature data is the same as the movement speed used by the virtual character to move from the position corresponding to the first feature data to the position corresponding to the second feature data during recording; it can also be understood that during playback and recording, the virtual character moves from the position corresponding to the first feature data to the position corresponding to the second feature data within the same amount of time.

[0049] It should be understood that when the solution provided in this application embodiment is applied to a multiplayer cooperative game, the above application scenario should include multiple terminal devices 110. The configurations of the multiple terminal devices 110 can be the same or different. Here, the configuration of the terminal device can be understood as the configuration of the terminal device's display rendering performance. The central processing unit (CPU) and graphics processing unit (GPU) installed in the terminal device, as well as other related devices, can determine this configuration. At this time, the multiple terminal devices 110 control different virtual characters respectively. Each terminal device 110 controls the virtual character it controls to move and perform related operations during the replay of the game based on the data related to the virtual character it controls in the recorded sample data.

[0050] It should be understood that Figure 1 The application scenarios shown are merely examples. In practical applications, the game automation method provided in this application embodiment can also be applied to other scenarios. No limitations are made here on the application scenarios of the game automation method provided in this application embodiment.

[0051] The game automation method provided in this application will be described in detail below through method embodiments.

[0052] See Figure 2 , Figure 2 This is a flowchart illustrating the game automation method provided in an embodiment of this application. For ease of description, the following embodiments will still use a terminal device as the executing entity of the game automation method. Figure 2 As shown, the game automation method includes the following steps:

[0053] Step 201: Obtain recording sample data; the recording sample data includes feature data corresponding to each frame of the reference screen during the recording of the game. The feature data includes the position information of the virtual character in the corresponding reference screen and the time interval. The time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen.

[0054] In this embodiment, before the terminal device implements game AI based on the recording and playback of the game process, it needs to obtain the recording sample data recorded during the recording phase. This recording sample data will be used as the basis for controlling the virtual character's actions during the playback phase. For example, the terminal device can obtain the recording sample data from a server, database, or the terminal device itself, and this application does not limit the method of obtaining the recording sample data.

[0055] It should be noted that the solution for implementing game AI based on game recording and playback specifically includes two stages: a recording stage and a playback stage. In the recording stage, feature data corresponding to each frame of the reference screen during the game can be collected to form recording sample data. In the playback stage, the virtual character can be controlled to re-enter the game process based on the recording sample data, and the virtual character can be controlled to recreate its movement path and operations performed during the recording stage. In this embodiment, the game process in the recording stage is referred to as the recorded game process, and the game process in the playback stage is referred to as the playback game process.

[0056] It should be noted that during the recording phase, the virtual character can be manually controlled by relevant technicians to participate in the recording of the game, or it can be automatically controlled by relevant devices (such as terminal devices or backend servers). This application does not impose any limitations on the control method of the virtual character during the recording phase. Furthermore, this application provides an implementation method for automatically controlling the virtual character to participate in the recording of the game, which will be described below through another method embodiment. In the playback phase, the terminal device automatically controls the virtual character to participate in the playback of the game. Steps 202 and 203 described below are the implementation method for the playback phase.

[0057] In this embodiment of the application, the recorded sample data is data generated based on the recorded game process, which is used to guide the virtual character to restore its movement path and operation during the replay stage; the recorded sample data includes feature data corresponding to each frame of the reference screen during the recorded game process.

[0058] In this context, "reference frame" can be understood as a game frame during the recording process where feature data acquisition operations were performed. For example, a reference frame can be a game frame sampled at a preset frame interval during game recording. For instance, assuming a preset frame interval of 5 frames, the first, fifth, tenth, and fifteenth frames of the game during recording can all be used as reference frames. Alternatively, a reference frame can be a game frame where a virtual character performs a reference operation during game recording. This reference operation can be preset, and may include actions such as jumping, crawling, and shooting. Of course, in practical applications, every frame of the game during recording can be considered a reference frame; this application does not impose any limitations on this.

[0059] The feature data corresponding to the reference frame includes the position information of the virtual character in the reference frame and the time interval. The position information of the virtual character can be the coordinates of the virtual character in the game map. The time interval is the display time difference between the reference frame and the previous reference frame during the game recording process; for example, assuming that the fifth and tenth game frames during the game recording process are two adjacent sampled reference frames, then the time interval included in the feature data corresponding to the tenth game frame is the time difference between the display time of the tenth game frame and the display time of the fifth game frame; it should be understood that for the first reference frame during the game recording process, since there is no corresponding previous reference frame, the time interval in its corresponding feature data is zero. In addition, the feature data may also include the operation data of the virtual character in its corresponding reference frame, which is used to represent the operation performed by the virtual character in the reference frame.

[0060] When the method provided in this application is applied to a multiplayer cooperative game (i.e., a game in which multiple players control different virtual characters to cooperate in completing game tasks), the aforementioned feature data includes the position information of each of the multiple virtual characters in the corresponding reference screen. Here, the multiple virtual characters are the various virtual characters that players need to control during the game recording process. When the multiplayer cooperative game is a game that distinguishes factions, the feature data should include the position information of each virtual character included in each faction in the game. Furthermore, the feature data may also include the operation data of the aforementioned multiple virtual characters in the corresponding reference screen.

[0061] Step 202: Based on the recorded sample data, control the virtual character to participate in the replay game process.

[0062] After the terminal device obtains the recording sample data generated based on the recorded game process, it can enter the playback stage and control the virtual character to participate in the replay game process; that is, control the virtual character to restore its movement path during the recorded game process and restore the operations it performed during the recorded game process during the replay game process.

[0063] Specifically, during game replay, the terminal device can control the virtual character to move sequentially to the positions indicated by the position information in each feature data in the recorded sample data, as well as the timing of the reference frames corresponding to each feature data during the recorded game. This allows the virtual character to recreate its movement path during the recorded game. For example, assuming the recorded sample data includes feature data corresponding to the first, fifth, and tenth frames of the game during the recorded game, during replay, the virtual character can first be controlled to appear at the position indicated by the position information in the feature data corresponding to the first frame, then moved to the position indicated by the position information in the feature data corresponding to the fifth frame, and then moved to the position indicated by the position information in the feature data corresponding to the tenth frame, thus recreating the virtual character's movement path during the recorded game.

[0064] If the feature data also includes the virtual character's operation data, during game replay, the terminal device can control the virtual character to perform corresponding operations based on the operation data included in the feature data. For example, assuming the feature data corresponding to the fifth frame of the game screen includes the virtual character's jump operation data, then during game replay, when the virtual character is controlled to move to the position indicated by the position information included in the feature data corresponding to the fifth frame of the game screen, the virtual character also needs to perform a jump operation, thereby recreating the operation performed by the virtual character during the recorded game.

[0065] When the method provided in this application is applied to a multiplayer cooperative game, multiple terminal devices can control multiple virtual characters to participate in the replay of the game process based on recorded sample data. For example, each terminal device can obtain recorded sample data corresponding to the virtual character it controls from the server. The feature data in this recorded sample data only includes the position information and operation data of the virtual character controlled by the terminal device. Of course, the feature data in this recorded sample data also includes the time interval used to indicate the display time difference between adjacent sampled reference frames. Furthermore, each terminal device can, based on the recorded sample data it has obtained, control the virtual character it manipulates to recreate the movement path and operations performed by the virtual character during the recorded game process, using the method described above.

[0066] It should be noted that in the above scenario, the configurations of the terminal devices used to control different virtual characters can be the same or different. Here, the terminal device configuration can be understood as the display rendering performance configuration of that terminal device, which is usually determined by the CPU, GPU, and related components within the terminal device. Terminal devices with different configurations will display game footage at different frame rates. Generally, terminal devices with higher configurations will display game footage at higher frame rates, and terminal devices with lower configurations will display game footage at lower frame rates. The frame rate can be understood as the number of game frames that can be displayed per unit of time.

[0067] It should be noted that multiplayer cooperative games, compared to single-player games, place greater emphasis on teamwork. In multiplayer cooperative games, multiple players typically control virtual characters that form specific formations (i.e., the virtual characters have specific positional relationships) to better complete team tasks. Taking a multiplayer cooperative shooting game as an example, in a common scenario, friendly and enemy virtual characters need to engage in team battles at specific locations within the game scene. In this case, all friendly and enemy virtual characters need to reach these locations and engage in combat using specific formations. Given the aforementioned characteristics of multiplayer cooperative games, the method provided in this application's embodiments is needed to control the movement of virtual characters in multiplayer cooperative games to ensure that the positional relationships of the virtual characters during the recording phase are restored during playback.

[0068] Step 203: During the replay of the game, when the virtual character is at the position corresponding to the first feature data in the recorded sample data, the movement speed of the virtual character is determined based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data. The virtual character is then controlled to move towards the position of the virtual character corresponding to the second feature data at the movement speed. The reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data.

[0069] During the replay of the game in step 202 above, the terminal device can control the movement of the virtual character in the following way: When the virtual character is at the position corresponding to the first feature data in the recorded sample data, a second feature data is determined in the recorded sample data. The reference screen corresponding to the second feature data is located after the reference screen corresponding to the first feature data and is adjacent to the sampling order of the reference screen corresponding to the first feature data. Then, based on the current position of the virtual character, the position information of the virtual character included in the second feature data, and the time interval included in the second feature data, the movement speed of the virtual character is determined; that is, the distance between the position indicated by the position information included in the second feature data and the current position of the virtual character is determined, and the movement speed of the virtual character is obtained by dividing the distance by the time interval included in the second feature data. Then, the virtual character is controlled to move towards the position of the virtual character corresponding to the second feature data according to the movement speed.

[0070] It should be noted that step 203 is essentially a sub-step of step 202. That is, when executing step 202 to control the virtual character to participate in the replay game process, step 203 is needed to determine the virtual character's movement speed during the replay game and control the virtual character to move at that speed from one position corresponding to one feature data point to another. The sampling order of the reference frames corresponding to these two feature data points is adjacent. In other words, step 203 is not executed after step 202. The numbering of the two steps in this embodiment does not imply a limitation on the execution order of these two steps.

[0071] It should be noted that the first feature data mentioned above can be any feature data in the recorded sample data except for the feature data corresponding to the last reference frame; the second feature data is the feature data that is adjacent to the first feature data, that is, the reference frame corresponding to the second feature data is located after the reference frame corresponding to the first feature data and is adjacent to the reference frame corresponding to the first feature data; assuming that the feature data corresponding to the first frame, the fifth frame, the eighth frame and the tenth frame are sampled sequentially during the game recording process, when the feature data corresponding to the fifth frame is the first feature data, the feature data corresponding to the eighth frame is the second feature data.

[0072] Furthermore, the location of the virtual character corresponding to the feature data mentioned above (the location corresponding to the first feature data and the location corresponding to the second feature data) can be determined based on the location information of the virtual character included in the feature data. For example, it can be the location indicated by the location information of the virtual character included in the feature data, or it can be a location that is close to the location indicated by the location information of the virtual character included in the feature data (such as any location within half a meter of the location indicated by the location information). This application does not specifically limit the location corresponding to the feature data here.

[0073] To facilitate understanding of how the virtual character's movement is controlled during game replay, the following example uses recorded sample data including feature data 1, feature data 2, and feature data 3 to illustrate this implementation method. Feature data 1, feature data 2, and feature data 3 correspond to the first, fifth, and eighth frames of the game during game recording, respectively. These first, fifth, and eighth frames are reference frames captured sequentially during game recording.

[0074] When the virtual character is at the position corresponding to feature data 1, the terminal device can determine the distance between the virtual character's current position and the position indicated by the position information in feature data 2. Dividing this distance by the time interval in feature data 2 yields the virtual character's movement speed, and the device then controls the virtual character to move towards the position indicated by the position information in feature data 2 at this speed. In this process, feature data 1 is the aforementioned first feature data, and feature data 2 is the second feature data. When the virtual character moves to the position corresponding to feature data 2, the terminal device can determine the distance between the virtual character's current position and the position indicated by the position information in feature data 3. Dividing this distance by the time interval in feature data 3 yields the virtual character's movement speed, and the device then controls the virtual character to move towards the position indicated by the position information in feature data 3 at this speed. In this process, feature data 2 is the aforementioned first feature data, and feature data 3 is the second feature data.

[0075] It should be understood that when the recorded sample data includes more feature data, the terminal device can control the virtual character to move from the position corresponding to one feature data to the position corresponding to another feature data in the manner described above, until the virtual character moves to the position corresponding to the last feature data (corresponding to the last frame of reference image).

[0076] When the method provided in this application is applied to a multiplayer cooperative game, during game replay, it is necessary to control different virtual characters through multiple terminal devices. In this case, for each virtual character, its movement needs to be controlled in the manner described above. That is, for each virtual character, when the virtual character is at the position corresponding to its position information in the first feature data, the movement speed of the virtual character is determined based on its current position, the position information in the second feature data, and the time interval included in the second feature data. Then, the virtual character is controlled to move towards the position corresponding to its position information in the second feature data according to this movement speed.

[0077] For example, suppose the virtual characters participating in the game recording process include virtual character a, virtual character b, and virtual character c, and the recorded sample data includes feature data 1, feature data 2, and feature data 3. Each feature data includes the location information of virtual character a, virtual character b, and virtual character c respectively. Accordingly, during the playback stage, three terminal devices are needed to control virtual character a, virtual character b, and virtual character c to participate in the game playback process.

[0078] During game replay, when virtual character A is at the position corresponding to its location information in feature data 1, the distance between virtual character A's current position and the position indicated by its location information in feature data 2 can be determined. Dividing this distance by the time interval in feature data 2 yields the movement speed of virtual character A, which is then used to control virtual character A to move towards the position corresponding to its location information in feature data 2. Similarly, for the terminal devices controlling virtual character B and virtual character C, the movement of virtual characters B and C can be controlled accordingly during game replay.

[0079] It should be noted that the location corresponding to the virtual character's location information in the above feature data can be understood as the location indicated by the location information in the game map, or as a location in the game map that is close to the location indicated by the location information (such as any location within half a meter of the location indicated by the location information). This application does not make specific limitations on the location corresponding to the location information.

[0080] Thus, following the above method, controlling the movement of multiple virtual characters in a multiplayer cooperative game during the playback phase is not limited by the frame rate of the terminal device controlling the virtual characters. This ensures that each controlled virtual character reproduces its movement speed during the recording phase, thereby restoring the relative movement speed of each virtual character during the recording phase, as well as the positional relationships between the virtual characters. For example, assuming that feature data 1 is recorded in the 1st second of the game recording process and feature data 2 is recorded in the 5th second, then during the game playback process, when each virtual character is in the position corresponding to the position information of that virtual character in feature data 1, each terminal device needs to control its controlled virtual character to move to the position corresponding to the position information of that virtual character in feature data 2 within 4 seconds. That is, it ensures that each virtual character moves to the position indicated by the position information of each virtual character in feature data 2 after 4 seconds, thus restoring the relative movement speed and positional relationships of each virtual character during the game recording phase.

[0081] In this embodiment of the application, in order to ensure that the positional relationship between multiple virtual characters in a multiplayer cooperative game is not disrupted, before each terminal device controls its virtual character to move to the position corresponding to the position information of the virtual character in the second feature data, it is necessary to perform a relevant condition judgment operation. After detecting that the relevant state meets the specific conditions, each terminal device then controls the virtual character to continue moving to the position corresponding to the position information of the virtual character in the second feature data.

[0082] As an example, for each virtual character, the reference distance corresponding to the virtual character can be determined based on the current position of the virtual character and the position information of the virtual character in the first feature data; then, it is checked whether the reference distances corresponding to each virtual character are all less than a preset distance threshold; if so, the virtual character is controlled to move to the position corresponding to the position information of the virtual character in the second feature data according to the movement speed.

[0083] Specifically, it can determine whether each virtual character in a multiplayer cooperative game has reached its corresponding position in the first feature data. That is, for each terminal device controlling a virtual character, it can determine the distance between the current position of the virtual character it controls and the position indicated by the virtual character's position information in the first feature data, using this distance as a reference distance for that virtual character, and upload this reference distance to the backend server. After receiving the reference distances for the virtual characters uploaded by each terminal device, the backend server can check whether the reference distances for each virtual character during game replay are all less than a preset distance threshold; this preset distance threshold can be set according to actual needs, for example, it can be set to 0.5 meters. If it is determined that the reference distances corresponding to each virtual character are all less than the preset distance threshold, the backend server can send control instructions to each terminal device to instruct each terminal device to control the virtual character it controls to move to the position corresponding to the position information of the virtual character in the second feature data. If it is determined that the reference distances corresponding to each virtual character are not all less than the preset distance threshold, the backend server needs to further receive the reference distances corresponding to the virtual characters controlled by each terminal device and check again whether the reference distances corresponding to each virtual character are all less than the preset distance threshold, until it is determined that the reference distances corresponding to each virtual character are all less than the preset distance threshold.

[0084] In this way, by detecting whether each virtual character in a multiplayer cooperative game has reached the corresponding position in the first feature data, and then deciding whether to control each virtual character to continue moving to the corresponding position in the second feature data based on the detection results, the positional relationship between each virtual character can be effectively guaranteed to restore the positional relationship during the recording stage, and the positional relationship between each virtual character can be avoided from being disrupted.

[0085] As another example, the target time difference can be determined based on the current time point and the time point when the virtual character arrives at the position corresponding to the third feature data; here, the reference screen corresponding to the third feature data is located before and adjacent to the reference screen corresponding to the first feature data; then, it is detected whether the target time difference is greater than or equal to the time interval included in the first feature data; if so, the virtual character is controlled to move towards the position corresponding to the second feature data according to the movement speed.

[0086] Specifically, each time the terminal device detects that its controlled virtual character has reached the location corresponding to the virtual character's location information in a feature data set, it records the time point at which the virtual character arrived at that location. When deciding whether to control the virtual character to continue moving towards the location corresponding to the virtual character's location information in the second feature data set, the terminal device can first determine the time point at which the virtual character reaches the location corresponding to the virtual character's location information in the third feature data set. Here, the third feature data set is the feature data adjacent to the first feature data set in the preceding direction, and the reference frame corresponding to the third feature data set is located before the reference frame corresponding to the first feature data set and is adjacent to the reference frame corresponding to the first feature data set in the sampling order. Then, the terminal device can calculate the time difference between the current time point and the first feature data set as the target time difference and detect whether the target time difference is greater than or equal to the time interval included in the first feature data set. If yes, it means that other virtual characters in the multiplayer cooperative game should have moved from their corresponding positions in the third feature data to their corresponding positions in the first feature data. At this time, the terminal device can control the virtual character to continue moving to its corresponding position in the second feature data. If no, it means that other virtual characters in the multiplayer cooperative game may not have moved from their corresponding positions in the third feature data to their corresponding positions in the first feature data, that is, they have not reached their corresponding positions in the first feature data. At this time, the terminal device can continue to perform the above time difference detection operation until it detects that the determined target time difference is greater than or equal to the time interval included in the first feature data.

[0087] In this way, by detecting whether the time difference between the current time point and the time point when the virtual character arrives at the corresponding position in the previous feature data exceeds the time interval in the current feature data, and then deciding whether to control the virtual character to continue moving to the corresponding position in the second feature data based on the detection result, it is possible to effectively ensure that the movement of each virtual character in a multiplayer cooperative game is relatively synchronized, and avoid a situation where a virtual character moves too fast or too slow. By controlling the waiting between each virtual character based on the time interval in the feature data, the positional relationship between each virtual character during the recording stage can be accurately restored.

[0088] It should be noted that in practical applications, either of the two conditions mentioned above can be used to determine whether to control the virtual character to continue moving to the corresponding position in the next feature data, or both conditions can be used simultaneously to determine whether to control the virtual character to continue moving to the corresponding position in the next feature data. This application does not impose any limitations on this.

[0089] In one possible implementation, when the method provided in this application is applied to a multiplayer cooperative game, the performance of the multiplayer cooperative game can be tested during the replay stage. Specifically, during game replay, when each virtual character reaches the target location on the game map, each virtual character is controlled to perform the target operation; the target location here is a location on the game map where the resource complexity meets preset resource conditions, and the target operation here is an operation whose performance consumption meets preset performance conditions.

[0090] For example, during the recording phase, locations within the game map whose resource complexity meets preset resource conditions can be determined based on the game map's resource data. Here, resource complexity can be understood as the complexity of the static rendering resources corresponding to game elements. Generally, the more complex a game element is designed, the higher its resource complexity, and the more processing resources are required to render it. In this embodiment, a target location can be determined based on the resource complexity of each game element in the game map, where the target location includes game elements with high resource complexity. The aforementioned preset resource conditions are used to measure the resource complexity of a region within the game map. If a location in the game map meets these preset resource conditions, it indicates that the resource complexity of that location is high, requiring more processing resources to render it; in this case, that location can be considered the target location.

[0091] Furthermore, target operations can be preset during the recording phase. These target operations are those that meet preset performance requirements. In other words, controlling the virtual character to perform this target operation requires more processing resources than controlling it to perform other ordinary operations. The preset performance requirements are pre-defined conditions used to measure the performance consumption of the virtual character's operations. If the processing resources consumed by the virtual character when performing a certain operation meet these preset performance requirements, it means that controlling the virtual character to perform that operation requires a significant amount of processing resources, and this operation can be considered the target operation. For example, the target operation could be an attack operation (such as firing a weapon).

[0092] It should be understood that during the game recording process, the virtual characters in the multiplayer cooperative game will be controlled to move towards the aforementioned target location, and when all the virtual characters have reached the same target location, the virtual characters will be controlled to perform the target operation together; the recording sample data generated based on the above game recording process will be able to reflect the above game recording process.

[0093] Accordingly, when controlling the virtual characters in a multiplayer cooperative game to participate in the replay process based on the aforementioned recorded sample data, the system can control each virtual character to reach the target location on the game map according to the feature data recorded in the sample data. After all virtual characters have reached the target location, they can be controlled to perform the target operation together. During the replay process, the terminal device automatically records the device's performance data during game execution, such as the game's frame rate refresh rate and CPU usage, and generates a corresponding performance report. Based on this performance report, the test results of the multiplayer cooperative game's performance can be determined.

[0094] In this way, during game replay, each virtual character is controlled to perform high-performance operations in areas with high resource complexity on the game map, automatically simulating the situation of maximizing resource consumption, and testing the game's performance in the process. This achieves automated testing of game performance, while ensuring that the test results are reliable and have high reference value.

[0095] The aforementioned game automation method determines the movement speed of the virtual character during the playback phase based on the positional information of two adjacent reference frames during game recording and the time interval between these two reference frames. This ensures that the movement speed of the virtual character during the recording phase is reproduced during playback. In other words, during playback, the virtual character can move from its position in the previous reference frame to its position in the next reference frame at the same speed as during recording. When applied to multiplayer cooperative games, this method can reproduce the movement speed of each virtual character during the recording phase, ensuring that the relative movement speed of each virtual character during playback is the same as during recording. This allows for the restoration of the positional relationships of the virtual characters during recording, facilitating the reproduction of their cooperation during recording and achieving better game AI effects.

[0096] Furthermore, embodiments of this application also provide a solution for automatically recording the game process. See [link to documentation]. Figure 3 , Figure 3 This is a flowchart illustrating the method for automatically recording game processes provided in this application embodiment. For ease of description, the following description will still take a terminal device as the execution subject. Figure 3 As shown, the method includes the following steps:

[0097] Step 301: Determine the target location in the game map based on the resource data of the game map corresponding to the recorded game process.

[0098] In this embodiment, before automatically controlling the virtual character to participate in the game recording process, it is necessary to determine the target location in the game map based on the resource data of the game map corresponding to the game recording process. The resource data of the game map is data used to reflect the rendering resources required by each game element in the game map; the target location is the position that the virtual character needs to reach during the game recording process, and this target location can be, for example, a position in the game map that requires a large amount of rendering resources.

[0099] In one possible implementation, the target location in the game map can be determined as follows: the game map is divided into multiple sub-regions; for each sub-region, based on the resource data of the game map, the total amount of resources required by each game element in that sub-region is determined as the resource consumption amount corresponding to that sub-region; then, the sub-regions in the game map whose corresponding resource consumption amounts meet preset conditions are determined as target sub-regions, and the aforementioned target location is determined in the target sub-regions.

[0100] For example, after entering the game, you can first obtain the static resources of each game element (virtual elements in the game map, including but not limited to houses, trees, characters, etc.) in the game map through the game interface. Static resources are usually composed of multiple triangles (the smallest unit of static resources). The more triangles that make up the static resources of a game element, the more complex the game element is, and the more performance is required to render the game element. Through the game interface, you can obtain the position coordinates of each game element in the game map, as well as the number of triangles included in its static resources. These data are the resource data of the game map. Figure 4 This is an example of a static resource diagram, such as... Figure 4 As shown, a cube consists of six faces, each of which is composed of two triangular faces, meaning that the static resource of a cube element consists of twelve triangular faces.

[0101] Figure 5 This is a schematic diagram illustrating the implementation principle of determining the target location as provided in an embodiment of this application. Figure 5As shown, the game map can be divided into multiple grid regions (i.e., sub-regions mentioned above), each with a side length of, for example, 100 meters. For each grid region, the terminal device can use resource data obtained through the game interface to count the number of triangles included in the static resources of each game element, i.e., count the total number of triangles included in that grid region. The total number of triangles included in that grid region is the resource consumption corresponding to that grid region. Then, a preset number of grid regions with the highest resource consumption can be selected from all the grid regions, i.e., the preset number of grid regions with the highest total number of triangles included. These selected grid regions are designated as target sub-regions. Furthermore, the aforementioned target location is determined within these target sub-regions.

[0102] For example, such as Figure 5 As shown, the game map is divided into 16 grid regions, and the total number of triangles in each grid region is counted. Figure 5 The darker the color of the grid area, the more triangular faces it contains. The terminal device can sort the grid areas in descending order of the total number of triangular faces it contains, and then select the top three grid areas as target sub-regions and determine the center position of these three grid areas as the target position.

[0103] In this way, by determining the target location that the virtual character needs to reach during the game recording process, it can be ensured that the determined target location is a location with high resource complexity in the game map. Subsequently, after controlling the virtual character to reach the target location during the game recording process, the high performance-intensive target operation can be performed, which can lay the foundation for game performance testing in the replay stage.

[0104] It should be understood that in practical applications, the target location can also be determined by other means, and this application does not impose any restrictions on the method of determining the target location.

[0105] Step 302: During the game recording process, the movement path corresponding to the virtual character is planned based on the virtual character's position and the target position.

[0106] After determining the target location through step 301 above, the spawn location of the virtual character participating in the game recording process can be determined based on the target location (i.e., the initial appearance location of the virtual character on the game map). For example, the spawn location of the virtual character can be randomly determined within a preset distance from the target location. Then, based on the spawn location and the target location, the corresponding movement path of the virtual character can be planned. This movement path is the path that guides the virtual character to move to the target location.

[0107] In some cases, multiple target locations can be determined through step 301 above. In this case, the arrival order of these multiple target locations can be randomly determined, and then the spawn location of the virtual character can be determined based on the first target location to be reached.

[0108] In some cases, when the method provided in this application is applied to a multiplayer cooperative game, the virtual characters participating in recording the game process include multiple virtual characters. In this case, the spawn positions of these multiple virtual characters can be determined based on a first target location; for example, the spawn positions of multiple virtual characters can be randomly determined within a 100-meter radius of the first target location. Then, the game interface can be called to obtain the identifier (e.g., ID) of each virtual character participating in the game recording process, and the identifiers of each virtual character can be arranged in descending order. Furthermore, the game's teleportation interface can be called to move each virtual character to its assigned spawn position; specifically, when assigning spawn positions to each virtual character, the larger the identifier, the farther the spawn position is from the first target location.

[0109] After a virtual character reaches its spawn point, its movement path can be planned based on its current location and target location. This application proposes a path planning scheme based on ray detection. Ray detection refers to emitting a detection ray (the length of which can be preset) from the starting point in a specific direction. If the detection ray collides with an element in the game scene, it returns information about the collided element.

[0110] Specifically, the terminal device can iteratively perform multiple rounds of raycasting based on the virtual character's location to determine multiple feasible points. Here, feasible points refer to locations on the game map that the virtual character can reach, or locations that can be reached without being blocked by obstacles. Then, based on the target location, the target endpoint is determined from the multiple feasible points, and a backtracking operation is performed based on the target endpoint and the multiple feasible points to determine the movement path corresponding to the virtual character.

[0111] In other words, during game recording, the terminal device can perform forward raycasting based on the virtual character's current position and the target position the virtual character needs to reach next. This identifies several feasible points that the virtual character can reach on its way to the target position, and the virtual character will not be obstructed by obstacles when reaching these feasible points. After identifying several feasible points through forward raycasting, the feasible point closest to the target position can be selected as the target endpoint. Then, a backward backtracking operation is performed from this target endpoint to plan the movement path from the virtual character's current position to the target endpoint based on the connection relationships between the identified feasible points.

[0112] It should be noted that the aforementioned backward backtracking operation refers to starting from the target endpoint determined by the last round of ray detection operation, and searching forward round by round for feasible points with connections based on the connection relationships between feasible points determined by each round of ray detection operation, thereby obtaining the path from the target endpoint to the current position of the virtual character. This path is also the movement path that guides the virtual character from its current position to the target endpoint.

[0113] In one possible implementation, the terminal device can iteratively execute the above multi-round ray detection operation to determine multiple feasible points in the following way: When executing the i-th round of ray detection operation, starting from the feasible point of the (i-1)-th round, detection rays of preset length are emitted in multiple different directions. Based on the detection rays that do not collide with obstacle elements in the game scene, target detection rays are determined. Based on the endpoints of each target detection ray, the feasible point of the i-th round is determined. Here, i is an integer greater than or equal to 1 and less than or equal to N, and N is an integer greater than 1. When i equals 1, the feasible point of the (i-1)-th round is determined based on the position of the virtual character.

[0114] Taking the current position of the virtual character as its spawn point, and the need to plan its movement path to the first target position as an example, the terminal device can determine the feasible point for round 0 based on the spawn point of the virtual character. For example, assuming the spawn point of the virtual character is (x, y, z), the terminal device can directly use (x, y, z) as the feasible point for round 0. Alternatively, if the virtual character can perform a jump operation, the terminal device can use (x, y, z + h) as the feasible point for round 0, that is, offset upwards by the jump height h from the spawn point of the virtual character.

[0115] When the terminal device performs the first round of ray detection, it can launch detection rays of preset length in four directions—east, west, south, and north—starting from the feasible point in round 0. This preset length can be the distance a virtual character can move in a single movement (e.g., the distance a character can move in a single jump). If the detection ray does not collide with any obstacle in the game scene, meaning no obstacle is detected at the ray's endpoint, it can be used as a candidate target detection ray. The feasible point for round 1 is determined based on the endpoint of the candidate target detection ray. More specifically, if the starting point of the ray detection operation is (x, y, z), then the aforementioned candidate target detection ray can be directly used as the target detection ray, and its endpoint is determined as the feasible point for round 1. If the starting point of the ray detection operation is (x, y, z+h), it is necessary to further detect whether there is a foothold for the virtual character below the endpoint of the candidate target detection ray. If so, the candidate target detection ray can be used as the target detection ray, and the foothold below its endpoint is determined as the feasible point for round 1.

[0116] When the terminal device performs the second round of ray detection, it can launch detection rays of preset lengths in four directions—east, west, south, and north—starting from a feasible point in the first round or from an offset point h above that feasible point. If the detection ray does not collide with any obstacle element in the game scene, i.e., no obstacle element is detected at the endpoint of the detection ray, the detection ray can be used as a candidate target detection ray, and the feasible point for the second round is determined based on the endpoint of the candidate target detection ray. More specifically, if the starting point of the ray detection operation is a feasible point in the first round, then the aforementioned candidate target detection ray can be directly used as the target detection ray, and the endpoint of the target detection ray is determined as the feasible point for the second round. If the starting point of the ray detection operation is an offset point h above that feasible point in the first round, then it is necessary to further detect whether there is a landing point below the candidate target detection ray. If so, the candidate target detection ray can be used as the target detection ray, and the landing point below the endpoint of the target detection ray can be used as the feasible point for the second round.

[0117] Repeat the above process until the number of ray detection operations reaches N rounds, where N is a preset number of rounds, which can be, for example, equal to 50, thus obtaining multiple feasible points for planning the movement path.

[0118] Considering that the number of feasible points detected in each round of ray detection operations may increase exponentially with the number of rounds performed, if each round of ray detection operations continues to detect feasible points based on all feasible points detected in the previous round, it will generate a large computational cost and affect the efficiency of recording the game process. To solve this problem, in this embodiment of the application, when the number of endpoints of each target detection ray in a round of ray detection operations exceeds a preset number, a preset number of endpoints can be selected from the endpoints of each target detection ray as feasible points for this round, based on the distance between the endpoints of each target detection ray and the current target location.

[0119] For example, taking the aforementioned preset quantity of 5 as an example, assuming that the endpoints of the target detection rays determined through the i-th round of ray detection operations include 10, then for each endpoint of the target detection ray, the terminal device can determine the distance between it and the target location that the virtual character is currently heading to, as the distance corresponding to the endpoint of that target detection ray. Furthermore, the endpoints of each target detection ray are arranged in ascending order of their corresponding distances, and the endpoints of the top 5 target detection rays in the sorted order are taken as the feasible points for the i-th round.

[0120] In this way, the computational cost generated during subsequent ray detection operations can be effectively reduced, while ensuring the rationality and reliability of the determined feasible points, thereby ensuring the rationality of the subsequently planned movement path.

[0121] In one possible implementation, after performing N rounds of ray detection operations, the target endpoint can be determined from the feasible points of the N rounds as follows, and the movement path of the virtual character can be planned accordingly: the feasible point closest to the target position is determined from the feasible points of the Nth round as the target endpoint; then, based on the target endpoint and the detection ray connection relationship between feasible points of each adjacent two rounds in the N rounds of ray detection operations, the movement path corresponding to the virtual character is obtained by backtracking from the target endpoint to the feasible point of the 0th round.

[0122] For example, for each feasible point in the Nth round, the distance between it and the target location that the virtual character is currently heading to can be determined as the distance corresponding to that feasible point; then the feasible point with the smallest corresponding distance is selected as the target destination. Since the connection relationship between feasible points determined by each two adjacent rounds of ray detection is fixed, after determining the target endpoint, the system can backtrack from the target endpoint to the feasible point of round 0 based on this connection relationship. For example, in the feasible points of round N-1, the parent feasible point of the target endpoint (i.e., the feasible point of round N-1 used to determine the target endpoint when performing the Nth round of ray detection) is found as the target feasible point of round N-1. In the feasible points of round N-2, the parent feasible point of the target feasible point of round N-1 (i.e., the feasible point of round N-2 used to determine the target feasible point of round N-1) is found as the target feasible point of round N-2. This process continues until the system backtracks to the feasible point of round 0 (i.e., the position of the virtual character). Then, by connecting the feasible points in round 0 with the target feasible points in rounds 1 to N-1 and the target endpoint, we can obtain the movement path of the virtual character from its current location to the target terminal.

[0123] In this way, by automatically planning the movement path of the virtual character during the game recording process, it can be ensured that the virtual character can move smoothly without being blocked by obstacles, thus laying the foundation for the automation of the game recording process.

[0124] Step 303: Control the virtual character to move towards the target location according to its corresponding movement path.

[0125] After the terminal device plans the movement path of the virtual character in step 302 during the game recording process, it can control the virtual character to move according to the movement path.

[0126] It should be noted that in some cases, the destination of the movement path planned in step 302 may not be a target location. After the virtual character moves to the destination of the movement path, the terminal device can return to step 302 and continue planning a movement path based on the destination (i.e., the current location of the virtual character) and the target location that the virtual character needs to reach. After planning the movement path, step 303 is executed to control the virtual character to continue moving along the path. In this way, steps 302 and 303 are executed iteratively until the virtual character reaches the target location according to the planned movement path.

[0127] It should be understood that "the virtual character reaching the target location" here can be interpreted as the virtual character reaching any location within a preset distance threshold, such as any location within 10 meters of the target location. In other words, as long as the virtual character reaches a location within a preset distance threshold, it can be considered that the virtual character has reached the target location.

[0128] Step 304: When the virtual character arrives at the target location, control the virtual character to perform the target operation.

[0129] Once the virtual character reaches the target location, the terminal device can control the virtual character to perform the target operation. This target operation can be an operation that meets preset performance requirements. Controlling the virtual character to perform this target operation requires more processing resources than controlling it to perform other ordinary operations; the target operation could be, for example, an attack operation (such as firing a weapon).

[0130] It should be noted that when the method provided in this application is applied to a multiplayer cooperative game, the terminal device can control the virtual character to perform the target operation when it detects that all virtual characters participating in the game have reached the target location. Taking the target operation as firing, when all virtual characters participating in the game have reached the same target location, each terminal device used to control each virtual character can correspondingly control its controlled virtual character to perform the firing operation, that is, to achieve a concentrated fire attack (the behavior of multiple virtual characters firing at the enemy character together). After each virtual character continuously performs the target operation for a preset time (such as 1 minute), each terminal device can correspondingly control each virtual character to move to the next target location or end the game.

[0131] It should be understood that, after determining multiple target locations on the game map through step 301 above, once each virtual character completes its target operation at the first target location, the terminal device can return to steps 302 and 303 to continue planning the virtual character's movement path from its current location to the next target location, and control the virtual character to move along that path. When all virtual characters have reached the next target location, the terminal device can execute step 304 to control the virtual character to perform its target operation. This process is repeated, from steps 302 to 304, until each virtual character has traversed all target locations and completed its target operation at each location.

[0132] During the aforementioned game recording process, the backend server can record data in the following ways. Figure 2 The recording sample data used in the illustrated embodiment is as follows: reference frames are sampled at preset frame intervals, and the frames in which the virtual character performs reference operations are sampled as reference frames; the position information of the virtual character in the reference frames and the display time difference between the reference frames and the previous frame of reference frames are recorded as feature data corresponding to the reference frames; the recording sample data are composed using the feature data corresponding to each frame of reference frames.

[0133] Figure 6 This is a schematic diagram illustrating the implementation principle of recording sample data, as provided in an embodiment of this application. Figure 6 As shown, 601 represents the game frame sequence corresponding to the recorded game process, including each frame of the recorded game process arranged in chronological order of display time. During game recording, a frame can be sampled every four frames as a reference frame. For example, the first, sixth, eleventh, sixteenth, and so on frames can be sampled from the above game frame sequence as reference frames. Furthermore, game frames containing reference operations (such as virtual characters performing jump or fire actions) can also be sampled as reference frames. For example, if reference operations exist in the fourth and thirteenth frames of the game frame sequence, they can also be used as reference frames.

[0134] The reason for including game footage with reference actions (such as jumping and shooting) as reference footage is that these actions are usually very time-sensitive. If they are delayed during replay, results may occur, such as failing to jump over obstacles or missing enemy virtual characters when shooting. For other regular actions (such as movement), it is not necessary to record every frame; recording at preset frame intervals is sufficient. This will not affect the replay quality and will also reduce memory consumption.

[0135] For each sampled reference frame, the position information of the virtual character in that frame can be recorded, specifically the coordinates of the virtual character on the game map. When the method provided in this embodiment is applied to a multiplayer cooperative game, the position information of each virtual character in the reference frame can be recorded, including the position information of virtual characters in one's own faction and the position information of virtual characters outside one's own faction, so as to reproduce the positional relationship between the virtual characters in the subsequent replay stage. In addition, the time interval also needs to be recorded, that is, the time difference between the display time of the current reference frame and the display time of the previous sampled reference frame. Furthermore, the operation data of the virtual characters in the reference frame can also be recorded, which is used to reflect the operations performed by the virtual characters; when the method provided in this embodiment is applied to a multiplayer cooperative game, the operation data of each virtual character in the reference frame can be recorded. Figure 6 The triangle in the middle represents the feature data recorded for each reference frame.

[0136] In this way, by sampling each frame of reference screen during the game recording process and recording the feature data corresponding to each frame of reference screen, it can be ensured that the replay process based on the recorded sample data can accurately reproduce the recorded game process. At the same time, it can also reduce memory consumption to a certain extent and save storage resources.

[0137] The automated method for recording game processes provided in this application can autonomously determine the target location that a virtual character needs to reach in the game map, autonomously plan the path for the virtual character to reach the target location, and then control the virtual character to perform the target operation after reaching the target location. Thus, game process recording is achieved without any human intervention, i.e., fully automated game process recording. Furthermore, during the above-mentioned game recording process, reference frames are sampled and the feature data corresponding to each frame of the reference frame are recorded to form recording sample data. Based on this recording sample data, the replay stage can accurately reproduce the recorded game process.

[0138] To facilitate a further understanding of the game automation method provided in the embodiments of this application, the following example uses the method provided in the embodiments of this application to test the performance consumption of a multiplayer cooperative game in extreme scenarios, combined with... Figure 7The illustrated application scenario diagram serves as an example to illustrate the game automation method. It should be understood that the aforementioned multiplayer cooperative game can be any game that allows multiple virtual characters to participate simultaneously, such as first-person shooter (FPS), third-person shooter (TPS), multiplayer online battle arena (MOBA), etc. This application does not impose any limitations on the type of multiplayer cooperative game. Figure 8 This is a schematic diagram of the interface of an FPS game provided in an embodiment of this application.

[0139] This embodiment of the application aims to test the performance consumption of multiplayer cooperative games in extreme scenarios. It requires controlling multiple virtual characters to perform concentrated fire operations in resource-complex scenarios. Specifically, it controls multiple virtual characters to simultaneously reach target locations with high resource complexity on the game map, and then attacks based on the positions of enemy virtual characters. The implementation of this scheme can be divided into five stages: finding game resource data, planning target locations, multi-machine dynamic exploration and movement paths, recording sample data, and multi-machine precise replay. The first four stages all belong to the recording stage. Figure 7 The application scenarios for the left and middle halves, the last one belongs to the playback stage, corresponding to Figure 7 Application scenarios for the right half of the screen. The following sections will introduce each of the aforementioned stages.

[0140] During the game resource data retrieval phase, after entering the game, you can first obtain the static resources of various game elements (virtual elements in the game map, including but not limited to houses, trees, characters, etc.) in the game map through the game interface. Static resources are usually composed of multiple triangles. The more triangles that make up the static resources of a game element, the more complex the game element is, and the more performance is required to render the game element. Through the game interface, you can obtain the position coordinates of each game element in the game map, as well as the number of triangles included in its static resources. This data is the resource data of the game map.

[0141] During the target location planning phase, the game map can be divided into multiple grid areas, each with a side length of, for example, 100 meters. For each grid area, based on resource data obtained through the game interface, the number of triangles included in the static resources of each game element within that grid area can be counted; that is, the total number of triangles included in that grid area can be calculated. Then, the grid areas are sorted in descending order of the total number of triangles included, and the top three grid areas are selected. The center of these three grid areas is chosen as the target location. The reason for choosing the center location as the target location is that the resource complexity is usually higher near the center of the grid area.

[0142] During the multi-machine dynamic exploration and movement path phase, after identifying multiple target locations, the arrival order of these target locations can be randomly determined. Within a 100-meter radius of the first target location, multiple virtual characters' spawn locations are randomly generated. At this point, the game interface can be called to obtain the IDs of each virtual character participating in the game recording process, and the virtual characters can be arranged in descending order of ID. The game's teleportation interface can then be used to move each virtual character to its corresponding spawn location. For example, the spawn location of a virtual character with a larger ID can be farther away from the first target location.

[0143] After each virtual character reaches its corresponding spawn point, its movement path can be planned based on raycasting. Specifically, the virtual character's position (x, y, z) is first obtained, and then the position is shifted upwards by the virtual character's jump height h to obtain (x, y, z + h), which serves as the feasible point for round 0. Then, starting from this feasible point for round 0, detection rays are emitted in the four directions of east, west, south, and north. The length of the detection ray can be the virtual character's jump distance. If no obstacle element is detected at the endpoint of the detection ray, and there is a place for the virtual character to land below the endpoint, then this place can be considered a feasible point for round 1. Then, based on the feasible point of the first round, offset the jump height by h, and launch detection rays again in the four directions of east, west, south, and north from this offset point. If no obstacle element is detected at the endpoint of the detection ray, and there is a place for the virtual character to land below the endpoint, then that place can be considered a feasible point for the second round. This process continues until the number of ray detection operations reaches 50 rounds. It should be noted that if the number of feasible points in a round exceeds 5, the 5 feasible points closest to the first target position can be selected from the feasible points of that round and retained, while the other feasible points of that round are discarded to reduce subsequent computational costs.

[0144] After identifying 50 feasible points through the aforementioned 50 rounds of raycasting, the feasible point closest to the first target location can be selected from the feasible points of the 50th round as the target endpoint. Since the connection relationships between the raycasts of feasible points in each round are known, the movement path of the virtual character to the target endpoint can be generated by backtracking. For example, starting from the target endpoint, the parent node of the target endpoint can be found in the feasible points of the 49th round, and then the parent node of the parent node can be found in the feasible points of the 48th round. This process is iterated until the initial feasible point, i.e., the location of the virtual character, is found, thus determining the movement path of the virtual character to the target endpoint.

[0145] After the virtual character moves to the target endpoint according to the above-described movement path, a new movement path is determined in the same manner, and the virtual character continues to move along this path until it reaches within 10 meters of the target location. Once the virtual characters controlled by multiple terminal devices have all reached the target location, they can be controlled to perform a concentrated fire operation to increase the performance consumption at that target location. After one minute of concentrated fire, the virtual characters can be controlled to move to the next target location, until all target locations on the game map have been traversed.

[0146] Since the dynamic exploration and movement path process described above is relatively performance-intensive, performance testing cannot be performed directly based on the recorded game process. However, we can record sample data based on the recorded game process, and then replay the recorded game process based on the recorded sample data. Since the complexity of the replay stage is low, game performance testing can be performed during the replay stage.

[0147] During the recording of sample data, reference frames can be sampled from each frame of the game at preset frame intervals during the game recording process. Game frames with special operations (such as jumping or shooting) can also be sampled as reference frames. The corresponding feature data of each reference frame is recorded, and the recorded sample data is composed of these feature data. The recorded feature data may include the position information and operation data of each virtual character in the reference frame, as well as the time interval, which is the display time difference between the current reference frame and the previous sampled reference frame.

[0148] In the multi-device precise replay stage, multiple terminal devices can be controlled simultaneously to replay the game. Each terminal device replays the script corresponding to a virtual character. This stage requires reproducing the positional relationships between the virtual characters during the recorded game, thus achieving precise targeting of multiple virtual characters. During this stage, each terminal device obtains the ID of the virtual character it controls, downloads the corresponding script from the backend based on that ID, reads the recorded sample data within the script, and controls that virtual character to participate in the replay process based on that recorded sample data.

[0149] When controlling a virtual character to move along a recorded path during game replay, each time the virtual character reaches a position corresponding to a feature data point, the system determines the movement speed required for the virtual character to move from the current position to the next feature data point based on the character's current position, the position information included in the next feature data point, and the time interval included in the next feature data point. The system then controls the virtual character to move to the next feature data point at this speed, ensuring that the virtual character can reach the next feature data point within this timeframe. Before controlling the virtual character to move to the next feature data point, two prerequisites must be met: first, all virtual characters must be within half a meter of their corresponding positions in the feature data point; second, the time difference between the current time point and the time when the virtual character reaches the position corresponding to the previous feature data point must be greater than the time interval in the feature data point. The purpose of these two conditions is to ensure that the virtual character reaches the corresponding position within the recorded time interval. If the virtual character needs to perform a specific operation at a certain position, the corresponding game function can be called to control the virtual character to perform that operation.

[0150] During the replay of the game, the performance consumption of the terminal device can be recorded, and the performance test results for multiplayer cooperative games can be determined accordingly.

[0151] In response to the game automation method described above, this application also provides a corresponding game automation device to enable the above game automation method to be applied and implemented in practice.

[0152] See Figure 9 , Figure 9 This is consistent with the above text Figure 2 The diagram shows a structural schematic of a game automation device 900 corresponding to the game automation method illustrated. Figure 9 As shown, the game automation device 900 includes:

[0153] The data acquisition module 901 is used to acquire recorded sample data; the recorded sample data includes feature data corresponding to each frame of the reference screen during the recording of the game process, the feature data includes the position information of the virtual character in the corresponding reference screen and the time interval, the time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen.

[0154] The replay control module 902 is used to control the virtual character to participate in the replay game process based on the recorded sample data;

[0155] The replay control module 902 is further configured to, during the replay of the game, when the virtual character is at the position corresponding to the first feature data in the recorded sample data, determine the movement speed of the virtual character based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data, and control the virtual character to move towards the position of the virtual character corresponding to the second feature data at the movement speed; the reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data.

[0156] Optionally, the feature data includes the position information of each of the multiple virtual characters in the corresponding reference frame; the playback control module 902 is specifically used for:

[0157] Based on the recorded sample data, the multiple virtual characters are controlled to participate in the replay game process;

[0158] For each virtual character, when the virtual character is at the position corresponding to the virtual character's position information in the first feature data, the movement speed of the virtual character is determined based on the virtual character's position, the virtual character's position information in the second feature data, and the time interval included in the second feature data; the virtual character is then controlled to move to the position corresponding to the virtual character's position information in the second feature data according to the movement speed.

[0159] Optionally, the device further includes: a first detection module; the first detection module is used for:

[0160] For each virtual character, a reference distance is determined based on the current position of the virtual character and the position information of the virtual character in the first feature data.

[0161] Detect whether the reference distances corresponding to each of the multiple virtual characters are all less than a preset distance threshold;

[0162] If so, then the virtual character is controlled to move at the specified speed to the location corresponding to the virtual character's location information in the second feature data.

[0163] Optionally, the device further includes: a second detection module; the second detection module is used for:

[0164] The target time difference is determined based on the current time and the time when the virtual character arrives at the position corresponding to the third feature data; the reference screen corresponding to the third feature data is located before and adjacent to the reference screen corresponding to the first feature data.

[0165] Detect whether the target time difference is greater than or equal to the time interval included in the first feature data;

[0166] If so, then the virtual character is controlled to move at the speed specified in the second feature data to the location of the virtual character.

[0167] Optionally, the playback control module 902 is further configured to:

[0168] During the replay of the game, when all the virtual characters reach the target location on the game map, the virtual characters are controlled to perform the target operation; the target location is a location on the game map whose resource complexity meets preset resource conditions, and the target operation is an operation whose performance consumption meets preset performance conditions.

[0169] Optionally, the device further includes: a recording control module; the recording control module includes:

[0170] The location determination submodule is used to determine the target location in the game map based on the resource data of the game map corresponding to the recorded game process;

[0171] The path planning submodule is used to plan the movement path of the virtual character based on the virtual character's position and the target position during the game recording process.

[0172] The movement control submodule is used to control the virtual character to move towards the target location according to its corresponding movement path;

[0173] The operation control submodule is used to control the virtual character to perform the target operation when the virtual character arrives at the target location.

[0174] Optionally, the device further includes: a data recording module; the data recording module is used for:

[0175] During the game recording process, the reference screen is sampled at a preset frame interval, and the screen where the virtual character performs the reference operation is sampled as the reference screen; the position information of the virtual character in the reference screen and the display time difference between the reference screen and the sampled previous frame reference screen are recorded as feature data corresponding to the reference screen;

[0176] The recorded sample data is composed of the feature data corresponding to each frame of the reference image.

[0177] Optionally, the position determination submodule is specifically used for:

[0178] The game map is divided into multiple sub-regions;

[0179] For each sub-region, based on the resource data, the total amount of resources required by each game element in the sub-region is determined as the resource consumption amount corresponding to the sub-region;

[0180] Identify a sub-region in the game map whose resource consumption meets preset conditions as the target sub-region; determine the target location within the target sub-region.

[0181] Optionally, the path planning submodule is specifically used for:

[0182] Based on the position of the virtual character, multiple rounds of ray detection operations are performed iteratively to determine multiple feasible points;

[0183] Based on the target location, determine the target endpoint from among the plurality of feasible points; perform a backtracking operation based on the target endpoint and the plurality of feasible points to determine the movement path corresponding to the virtual character.

[0184] Optionally, the path planning submodule is specifically used for:

[0185] When performing the ray detection operation in the i-th round, detection rays of preset length are emitted from the feasible point in the (i-1)-th round in multiple different directions. Target detection rays are determined based on the detection rays that do not collide with obstacle elements in the game scene. The feasible point in the i-th round is determined based on the endpoint of each target detection ray.

[0186] Where i is an integer greater than or equal to 1 and less than or equal to N, and N is an integer greater than 1; when i equals 1, the feasible point of the (i-1)th round is determined based on the position of the virtual character.

[0187] Optionally, the path planning submodule is specifically used for:

[0188] When the number of endpoints of each target detection ray exceeds a preset number, the preset number of endpoints are selected from the endpoints of each target detection ray as feasible points in the i-th round, based on the distance between the endpoints of each target detection ray and the target position.

[0189] Optionally, the path planning submodule is specifically used for:

[0190] Among the feasible points in the Nth round, the feasible point closest to the target location is determined and used as the target endpoint;

[0191] Based on the target endpoint and the connection relationship between the detection rays between feasible points in each of the N rounds of ray detection operations, the movement path corresponding to the virtual character is obtained by tracing back from the target endpoint to the feasible point in the 0th round.

[0192] The aforementioned game automation device determines the movement speed of the virtual character during the playback phase based on the positional information of two adjacent reference frames during game recording and the time interval between these two reference frames. This ensures that the movement speed of the virtual character during the recording phase is reproduced during playback. In other words, during playback, the virtual character can move from its position in the previous reference frame to its position in the next reference frame at the same speed as during recording. When this method is applied to multiplayer cooperative games, the movement speed of each virtual character during the recording phase can be reproduced during playback, ensuring that the relative movement speed of each virtual character during playback is the same as during recording. This allows for the restoration of the positional relationships of each virtual character during recording, facilitating the reproduction of their cooperation during recording and achieving better game AI effects.

[0193] This application also provides an electronic device for realizing game automation. The electronic device may be a terminal device or a server. The terminal device and server provided in this application will be described from the perspective of hardware implementation below.

[0194] See Figure 10 , Figure 10 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. For example... Figure 10 As shown, for ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application. The terminal can be any terminal device including mobile phones, tablets, personal digital assistants (PDAs), point-of-sale (POS) terminals, in-vehicle computers, etc. Taking a smartphone as an example:

[0195] Figure 10This is a block diagram illustrating a portion of the structure of a smartphone related to the terminal provided in the embodiments of this application. (Reference) Figure 10 The smartphone includes: a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030 (including a touch panel 1031 and other input devices 1032), a display unit 1040 (including a display panel 1041), a sensor 1050, an audio circuit 1060 (which can connect to a speaker 1061 and a microphone 1062), a wireless fidelity (WiFi) module 1070, a processor 1080, and a power supply 1090, etc. Those skilled in the art will understand that... Figure 10 The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0196] The memory 1020 can be used to store software programs and modules. The processor 1080 executes various functions and data processing of the smartphone by running the software programs and modules stored in the memory 1020. The memory 1020 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1020 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0197] The processor 1080 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1020 and by accessing data stored in the memory 1020. Optionally, the processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1080.

[0198] In this embodiment of the application, the processor 1080 included in the terminal is also used to execute the steps of any implementation of the game automation method provided in this embodiment of the application.

[0199] See Figure 11 , Figure 11This is a schematic diagram of the structure of a server 1100 provided in an embodiment of this application. The server 1100 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 1122 (e.g., one or more processors) and memory 1132, and one or more storage media 1130 (e.g., one or more mass storage devices) for storing application programs 1142 or data 1144. The memory 1132 and storage media 1130 can be temporary or persistent storage. The program stored in the storage media 1130 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1122 may be configured to communicate with the storage media 1130 and execute the series of instruction operations in the storage media 1130 on the server 1100.

[0200] Server 1100 may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1150, one or more input / output interfaces 1158, and / or one or more operating systems, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0201] The steps performed by the server in the above embodiments can be based on this Figure 11 The server structure shown.

[0202] The CPU 1122 can also be used to execute any of the steps of the game automation method provided in the embodiments of this application.

[0203] This application also provides a computer-readable storage medium for storing a computer program that executes any one of the implementation methods of the game automation method described in the foregoing embodiments.

[0204] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the implementation methods of the game automation method described in the foregoing embodiments.

[0205] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0206] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0207] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0208] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0209] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0210] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0211] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A game automation method, characterized in that, The method includes: Acquire recorded sample data; the recorded sample data includes feature data corresponding to each frame of the reference screen during the recording of the game. The feature data includes the position information of the virtual character in the corresponding reference screen and the time interval. The time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen. Based on the recorded sample data, the virtual character is controlled to participate in the replay game process; During the replay of the game, when the virtual character is at the position corresponding to the first feature data in the recorded sample data, the movement speed of the virtual character is determined based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data. The virtual character is then controlled to move towards the position of the virtual character corresponding to the second feature data at the movement speed. The reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data. The feature data includes the position information of multiple virtual characters in their corresponding reference frames; the step of controlling the virtual characters to participate in the replay game process based on the recorded sample data includes: Based on the recorded sample data, the multiple virtual characters are controlled to participate in the replay game process; When the virtual character is located at the position corresponding to the first feature data in the recorded sample data, the movement speed of the virtual character is determined based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data. The virtual character is then controlled to move towards the position corresponding to the second feature data at the movement speed, including: For each virtual character, when the virtual character is at the position corresponding to the virtual character's position information in the first feature data, the movement speed of the virtual character is determined based on the virtual character's position, the virtual character's position information in the second feature data, and the time interval included in the second feature data; the virtual character is then controlled to move to the position corresponding to the virtual character's position information in the second feature data according to the movement speed.

2. The method according to claim 1, characterized in that, Before controlling the virtual character to move to the position corresponding to the virtual character's position information in the second feature data according to the movement speed, the method further includes: For each virtual character, a reference distance is determined based on the current position of the virtual character and the position information of the virtual character in the first feature data. Detect whether the reference distances corresponding to each of the multiple virtual characters are all less than a preset distance threshold; If so, then the virtual character is controlled to move at the specified speed to the location corresponding to the virtual character's location information in the second feature data.

3. The method according to any one of claims 1 to 2, characterized in that, Before controlling the virtual character to move to the position of the virtual character corresponding to the second feature data according to the movement speed, the method further includes: The target time difference is determined based on the current time and the time when the virtual character arrives at the position corresponding to the third feature data; the reference screen corresponding to the third feature data is located before and adjacent to the reference screen corresponding to the first feature data. Detect whether the target time difference is greater than or equal to the time interval included in the first feature data; If so, then the virtual character is controlled to move at the speed specified in the second feature data to the location of the virtual character.

4. The method according to claim 1, characterized in that, The method further includes: During the replay of the game, when all the virtual characters reach the target location on the game map, the virtual characters are controlled to perform the target operation; the target location is a location on the game map whose resource complexity meets preset resource conditions, and the target operation is an operation whose performance consumption meets preset performance conditions.

5. The method according to claim 1, characterized in that, The game recording process is achieved in the following way: Based on the resource data of the game map corresponding to the recorded game process, determine the target location in the game map; During the game recording process, the movement path of the virtual character is planned based on the virtual character's position and the target position; Control the virtual character to move towards the target location according to its corresponding movement path; When the virtual character reaches the target location, control the virtual character to perform the target operation.

6. The method according to claim 5, characterized in that, The recorded sample data was determined in the following way: During the game recording process, the reference frame is sampled at a preset frame interval, and the frame of the virtual character performing the reference operation is sampled as the reference frame; Record the position information of the virtual character in the reference frame, as well as the display time difference between the reference frame and the sampled previous frame reference frame, as feature data corresponding to the reference frame; The recorded sample data is composed of the feature data corresponding to each frame of the reference image.

7. The method according to claim 5, characterized in that, The step of determining the target location in the game map based on the resource data of the game map corresponding to the recorded game process includes: The game map is divided into multiple sub-regions; For each sub-region, based on the resource data, the total amount of resources required by each game element in the sub-region is determined as the resource consumption amount corresponding to the sub-region; Identify a sub-region in the game map whose resource consumption meets preset conditions as the target sub-region; determine the target location within the target sub-region.

8. The method according to claim 5, characterized in that, The step of planning the movement path corresponding to the virtual character based on the virtual character's position and the target position includes: Based on the position of the virtual character, multiple rounds of ray detection operations are performed iteratively to determine multiple feasible points; Based on the target location, determine the target endpoint from among the plurality of feasible points; perform a backtracking operation based on the target endpoint and the plurality of feasible points to determine the movement path corresponding to the virtual character.

9. The method according to claim 8, characterized in that, The process involves iteratively performing multiple rounds of raycasting based on the virtual character's position to determine multiple feasible points, including: When performing the ray detection operation in the i-th round, detection rays of preset length are emitted from the feasible point in the (i-1)-th round in multiple different directions. Target detection rays are determined based on the detection rays that do not collide with obstacle elements in the game scene. The feasible point in the i-th round is determined based on the endpoint of each target detection ray. Where i is an integer greater than or equal to 1 and less than or equal to N, and N is an integer greater than 1; when i equals 1, the feasible point of the (i-1)th round is determined based on the position of the virtual character.

10. The method according to claim 9, characterized in that, The step of determining the feasible point of the i-th round based on the endpoint of each of the target detection rays includes: When the number of endpoints of each target detection ray exceeds a preset number, the preset number of endpoints are selected from the endpoints of each target detection ray as feasible points in the i-th round, based on the distance between the endpoints of each target detection ray and the target position.

11. The method according to claim 9, characterized in that, The step of determining the target endpoint from the plurality of feasible points based on the target location includes: In the Nth round of feasible points, the feasible point closest to the target location is determined and used as the target endpoint; The step of performing a backtracking operation based on the target endpoint and the multiple feasible points to determine the movement path corresponding to the virtual character includes: Based on the target endpoint and the connection relationship between the detection rays between feasible points in each of the N rounds of ray detection operations, the movement path corresponding to the virtual character is obtained by tracing back from the target endpoint to the feasible point in round 0.

12. A game automation device, characterized in that, The device includes: The data acquisition module is used to acquire recorded sample data; the recorded sample data includes feature data corresponding to each frame of the reference screen during the recording of the game process, the feature data includes the position information of the virtual character in the corresponding reference screen and the time interval, the time interval is the display time difference between the reference screen corresponding to the feature data and the previous frame of the reference screen. The replay control module is used to control the virtual character to participate in the replay game process based on the recorded sample data; The replay control module is further configured to, during the replay of the game, when the virtual character is at the position corresponding to the first feature data in the recorded sample data, determine the movement speed of the virtual character based on the position of the virtual character and the position information of the virtual character included in the second feature data, as well as the time interval included in the second feature data, and control the virtual character to move towards the position of the virtual character corresponding to the second feature data at the movement speed; the reference screen corresponding to the second feature data is located after and adjacent to the reference screen corresponding to the first feature data; The feature data includes the position information of multiple virtual characters in their corresponding reference frames; the playback control module is specifically used for: Based on the recorded sample data, the multiple virtual characters are controlled to participate in the replay game process; For each virtual character, when the virtual character is at the position corresponding to the virtual character's position information in the first feature data, the movement speed of the virtual character is determined based on the virtual character's position, the virtual character's position information in the second feature data, and the time interval included in the second feature data; the virtual character is then controlled to move to the position corresponding to the virtual character's position information in the second feature data according to the movement speed.

13. An electronic device, characterized in that, The device includes a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the game automation method according to any one of claims 1 to 11 according to the computer program.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the game automation method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or the instructions are executed by the processor, the game automation method according to any one of claims 1 to 11 is implemented.

Images