Data processing method, device, storage medium and electronic device

Abstract

The present disclosure discloses a data processing method, device, storage medium and electronic device. The method includes: obtaining multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to characterize the process of the game, and the game process includes sub-processes; determining the operation data corresponding to each group of sub-processes to obtain multiple groups of operation data; responding to a game operation request sent by a client, determining the target operation data corresponding to the game operation request from the multiple groups of operation data; based on the target operation data, determining the operation state of a virtual object in the game at a target time. The present disclosure solves the technical problem of low efficiency in replaying the game state.

Description

Technical Field

[0001] The present disclosure relates to the field of computers, and in particular, to a data processing method, device, storage medium and electronic device. Background Art

[0002] Currently, in order to review the game status, frame synchronization or state synchronization is usually used to review the game. However, the review function of the state synchronization game is often very difficult to implement. Therefore, there is still a technical problem of low efficiency in reviewing the game status.

[0003] Currently, no effective solution has been proposed to the above-mentioned technical problem of low efficiency in reviewing the game status. Summary of the invention

[0004] At least some embodiments of the present disclosure provide a data processing method, apparatus, storage medium, and electronic device to at least solve the technical problem of low efficiency in reviewing game status.

[0005] According to one embodiment of the present disclosure, there is provided a data processing method, comprising: obtaining multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to characterize the process of a game, and the game process includes sub-processes; determining operation data corresponding to each group of sub-processes to obtain multiple groups of operation data; in response to a game operation request sent by a client, determining target operation data corresponding to the game operation request from the multiple groups of operation data; and determining the operation status of a virtual object in the game at a target moment based on the target operation data.

[0006] Optionally, obtaining a subprocess of the game process in the battle server includes: calling a fork function, copying the game process in the battle server, and obtaining the subprocess.

[0007] Optionally, the fork function is called every target time period.

[0008] Optionally, at every target time period, in response to a stop request, the subprocess is stopped.

[0009] Optionally, determining the operation data corresponding to each group of sub-processes includes: performing serialization processing on each group of sub-processes respectively to obtain the operation data corresponding to each group of sub-processes.

[0010] Optionally, multiple groups of running data are stored in multiple groups of databases respectively; based on the stop time of the running data stored in each group of databases and the battle name in the game, the database name of each group of databases is determined respectively, wherein the battle name is used to characterize the battle scenes in the game.

[0011] Optionally, in response to a game running request sent by the client, target running data corresponding to the game running request is determined from multiple groups of running data, including: based on the stop time in the game running request, the battle name and the database name in the game running request, a database matching the game running request is determined from multiple groups of databases to obtain a target database; and the running data stored in the target database is determined as the target running data.

[0012] Optionally, based on the target running data, determining the running state of the virtual object in the game at the target moment includes: deserializing the target running data to obtain restored data of the game; and determining the running state based on the restored data.

[0013] According to one embodiment of the present disclosure, there is also provided a data processing device, including: an acquisition unit, used to acquire multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to characterize the process of the game, and the game process includes sub-processes; a first determination unit, used to determine the running data corresponding to each group of sub-processes, and obtain multiple groups of running data; a second determination unit, used to respond to a game running request sent by a client, and determine the target running data corresponding to the game running request from the multiple groups of running data; a third determination unit, used to determine the running status of the virtual object in the game at the target moment based on the target running data.

[0014] According to one embodiment of the present disclosure, a computer-readable storage medium is further provided, in which a computer program is stored, wherein the computer program is configured to execute any of the above-mentioned data processing methods when running.

[0015] According to one embodiment of the present disclosure, there is also provided an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute any of the above data processing methods.

[0016] In the disclosed embodiment, multiple groups of sub-processes of the game process in the battle server are obtained, wherein the game process is used to characterize the process of the game, and the game process includes sub-processes; the operation data corresponding to each group of sub-processes is determined to obtain multiple groups of operation data; in response to the game operation request sent by the client, the target operation data corresponding to the game operation request is determined from the multiple groups of operation data; based on the target operation data, the operation state of the virtual object in the game at the target moment is determined. In other words, the disclosed embodiment obtains the sub-process by copying the game process, determines the target operation data based on the operation data corresponding to the sub-process, and processes the target operation data to achieve the technical effect of improving the efficiency of replaying the game state, and solves the technical problem of low efficiency in replaying the game state. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation on the present disclosure. In the drawings:

[0018] Figure 1 It is a hardware structure block diagram of a mobile terminal of a data processing method according to an embodiment of the present disclosure;

[0019] Figure 2 is a flow chart of a data processing method according to one embodiment of the present disclosure;

[0020] Figure 3 is a schematic diagram of frame synchronization according to one embodiment of the related art;

[0021] Figure 4 is a schematic diagram of state synchronization according to one embodiment of the related art;

[0022] Figure 5 is a flowchart of a game replay according to one embodiment of the present disclosure;

[0023] Figure 6 is a schematic diagram of a game data logic execution according to one embodiment of the present disclosure;

[0024] Figure 7 is a schematic diagram of a battle tree reference relationship according to one embodiment of the present disclosure;

[0025] Figure 8 is a structural block diagram of a data processing device according to an embodiment of the present disclosure;

[0026] Fig. 9 is a schematic diagram of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the scheme of the present disclosure, the technical scheme in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without creative work should fall within the scope of protection of the present disclosure.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0029] In a possible implementation, in the computer field, a frame synchronization or state synchronization method is usually used for quick review of a game. After practice and careful research, the inventor found that the current technology still has a large amount of data for state synchronization due to different infrastructures of different games. Therefore, there is still a technical problem of low efficiency in quick review of the game. Based on this, the game scenario applied by the embodiment of the present disclosure can be a multiplayer online game scenario, and the game type targeted is generally a competitive game. A data processing method is proposed to obtain multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to characterize the process of the game, and the game process includes sub-processes; determine the running data corresponding to each group of sub-processes to obtain multiple groups of running data; in response to a game running request sent by a client, determine the target running data corresponding to the game running request from the multiple groups of running data; based on the target running data, determine the running state of the virtual object in the game at the target time, thereby achieving the purpose of quick review of the game, realizing the technical effect of improving the efficiency of reviewing the game state, and solving the technical problem of low efficiency of reviewing the game state.

[0030] According to one embodiment of the present disclosure, an embodiment of a data processing method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0031] The method embodiment can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, the mobile terminal can be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (MID for short), a PAD, a game console and other terminal devices. Figure 1FIG. 1 is a hardware structure block diagram of a mobile terminal of a data processing method according to an embodiment of the present disclosure. Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown in the figure) processor 102 (processor 102 may include but is not limited to a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processing (DSP) chip, a microprocessor (MCU), a programmable logic device (FPGA), a neural network processor (NPU), a tensor processor (TPU), an artificial intelligence (AI) type processor, etc.) and a memory 104 for storing data. Optionally, the mobile terminal may also include a transmission device 106 for communication functions, an input and output device 108, and a display device 110. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0032] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the data processing method in the embodiment of the present disclosure. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, the above-mentioned data processing method is realized. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0033] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0034] The inputs in the input / output device 108 may come from a plurality of human interface devices (HIDs), such as keyboards and mice, game controllers, and other dedicated game controllers (such as steering wheels, fishing rods, dance mats, remote controls, etc.). In addition to providing input functions, some human interface devices may also provide output functions, such as force feedback and vibration of game controllers, audio output of controllers, etc.

[0035] The display device 110 may be, for example, a head-up display (HUD), a touch-screen liquid crystal display (LCD), and a touch display (also referred to as a "touch screen" or "touch display screen"). The liquid crystal display may enable a user to interact with a user interface of the mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), and a user may interact with the GUI by finger contacts and / or gestures on a touch-sensitive surface, wherein the human-computer interaction functions here may optionally include the following interactions: creating web pages, drawing, word processing, making electronic documents, games, video conferencing, instant messaging, sending and receiving emails, call interfaces, playing digital videos, playing digital music, and / or web browsing, etc. The executable instructions for executing the above-mentioned human-computer interaction functions are configured / stored in a computer program product or a readable storage medium executable by one or more processors.

[0036] In a possible implementation, the present disclosure provides a data processing method. Figure 2 is a flow chart of a data processing method according to one embodiment of the present disclosure, such as Figure 2 As shown, the method may include the following steps:

[0037] Step S202, obtaining multiple groups of sub-processes of a game process in the battle server, wherein the game process is used to characterize the process of playing the game, including in the game, the game process includes sub-processes.

[0038] In the technical solution provided in the above step S202 of the present disclosure, multiple time sub-processes of the game process in the battle server can be obtained to obtain multiple groups of sub-processes, wherein the game process can be used to characterize the process of the game, and can include sub-processes, which can also be called parent processes, and the sub-processes can be used to characterize the process of the game at different times.

[0039] For example, the game processes at different times can be copied to other battle servers to obtain multiple groups of sub-processes at different times.

[0040] Step S204, determining the operation data corresponding to each group of sub-processes, and obtaining multiple groups of operation data.

[0041] In the technical solution provided in the above step S204 of the present disclosure, the sub-processes may be processed separately to obtain the operation data corresponding to each group of sub-processes, wherein the operation data may be the data that can be transmitted after being processed.

[0042] Optionally, the sub-process can be processed to convert it into data that can be maintained or transmitted (running data) to achieve the purpose of data transmission. Different processing methods can be used for data of different formats in the sub-process. No specific restrictions are made here on the method of converting the sub-process into transmittable data.

[0043] For example, the game process at different times can be copied to other battle servers to obtain multiple groups of sub-processes, and each group of sub-processes is serialized separately, so as to convert the sub-processes into data that can be stored and transmitted, and obtain the corresponding running data of each group of sub-processes.

[0044] Step S206, in response to the game running request sent by the client, determining target running data corresponding to the game running request from multiple groups of running data.

[0045] In the technical solution provided in the above step S206 of the present disclosure, a game running request can be sent on the client, and in response to the game running request, target running data corresponding to the game running request is determined from multiple sets of running data, wherein the game running request can be a game operation instruction, which can include game information that needs to be reviewed and the time when the review is required; the game information can be a game name or can be information used to represent battle scenes in the game.

[0046] For example, when a review is needed, the game information that needs to be reviewed can be entered on the client, such as the battle information (battle ID) and the time that needs to be reviewed, and a game running request issued by the client is obtained. In response to the battle information and the time that needs to be reviewed in the game running request, the game review request is sent to the corresponding battle server. The video archive time closest to the time in the game running request can be found forward / backward, an instruction (key) is generated, and the data corresponding to the time is downloaded from the database to obtain the target running data.

[0047] Optionally, there are multiple ways to input game information that needs to be reviewed on the client. For example, when the game is disconnected in the middle of the game, you can log in to the game software on the client and select the game session to enter. The above-mentioned click operation can issue a corresponding game running request. Based on the game running request, the target running data corresponding to the game running request is determined, wherein the time when the game needs to be reviewed at this time can be the current login time.

[0048] Step S208, determining the running state of the virtual object in the game at the target time based on the target running data.

[0049] In the technical solution provided in the above step S208 of the present disclosure, operation data that meets the game operation request is selected from multiple groups of operation data to obtain target operation data. The target operation data can be processed to restore the operation state of the virtual object in the game at the target moment, wherein the virtual object can be a virtual game object in the game; the operation state can be used to characterize the state of the virtual game object, for example, it can be the health value, force value, etc. of the virtual game object; the target moment can be the moment selected by the client in the game operation request.

[0050] For example, the target running data can be processed to obtain data corresponding to the target running data for characterizing the running state of the virtual game object at the target time. The data can be game-related information, such as the battle server address where the battle is located, which is synchronized to all players participating in the battle and the virtual objects (avatars) in the game server process, and the state of the virtual object is updated to the in-battle state. The player can be notified to log in again, and when logging in again, the state of the virtual object can be detected as in-battle. The battle can be connected through the previously synchronized battle ID and the battle server address. After connecting to the battle, the battle is in a paused state, and the game can be continued after the pause is manually ended.

[0051] Through steps S202 to S208, multiple groups of sub-processes of the game process in the battle server are obtained, wherein the game process is used to characterize the process of the game, and the game process includes sub-processes; the operation data corresponding to each group of sub-processes is determined to obtain multiple groups of operation data; in response to the game operation request sent by the client, the target operation data corresponding to the game operation request is determined from the multiple groups of operation data; based on the target operation data, the operation state of the virtual object in the game at the target moment is determined. In other words, the embodiment of the present disclosure obtains the sub-process by copying the game process, determines the target operation data based on the operation data corresponding to the sub-process, and achieves the technical effect of improving the efficiency of replaying the game state through the target operation data, thereby solving the technical problem of low efficiency in replaying the game state.

[0052] The above method of the embodiment of the present disclosure is further introduced below.

[0053] As an optional embodiment, obtaining a subprocess of a game process in a battle server includes: calling a fork function, copying the game process in the battle server, and obtaining the subprocess.

[0054] In this embodiment, the game process in the battle server can be copied by calling a fork function to obtain a child process. For example, the fork function can be called at the current moment to copy the game process at the current moment to another battle server to obtain a child process, thereby completing the copying of the game process at the current moment.

[0055] Optionally, the time when the child process needs to be obtained can be set in advance. When the time is the preset time, the fork function can be called to copy the game process in the battle server to obtain the child process. For example, the child process can be preset to be obtained at 5:00, 5:30, 6:00, and 6:20 respectively. When the time reaches any one of 5:00, 5:30, 6:00, and 6:20, the fork function is called to copy the game process in the battle server to obtain the child process.

[0056] As an optional embodiment, the fork function is called every target time period.

[0057] In this embodiment, a target time period can be preset according to actual conditions, and the fork function can be called every target time period, wherein the target time period can be a target time period preset according to actual conditions, for example, the target time period can be one day, one hour, 5-10 seconds, etc.

[0058] Optionally, a loop timer may be deployed in the battle server, and the loop timer may be used to call the fork function every target time period, thereby controlling the time for copying the game process in the battle server.

[0059] For example, when the game starts, a loop timer deployed in the battle server can be started. When the loop timer expires, the fork function in the battle server can be called to copy the game process to obtain a child process.

[0060] For another example, it is known that the game is prone to disconnection problems between 7:00 and 9:00 p.m., so you can set a shorter target time period between 7:00 and 9:00 p.m., and set a longer target time period in other time periods. Call the fork function in each target time period, so that sub-processes at different times can be saved, and the frequency of saving sub-processes can be selected according to actual conditions.

[0061] From the above, it can be seen that the shorter the time interval of the loop timer, the higher the accuracy of the recoverable moment, but at the same time, a large number of sub-processes will be generated that need to be stored, which will bring huge pressure to the server. However, in the present embodiment, since the game process is copied to obtain the sub-process, the location of the sub-process you want to store can also be selected, and the sub-process can be stored to the maximum extent.

[0062] As an optional embodiment, the subprocess is stopped in response to a stop request every target time period.

[0063] In this embodiment, the fork function in the battle server can be called every target time period to generate a child process of the game process, and the stop request of the game can be called immediately. In response to the stop request, the child process can be frozen at the current moment to stop running the child process, wherein the stop request can be a pause instruction, which can be used to stop the child process from continuing to run.

[0064] For example, when the loop timer expires, the fork function in the battle server can be called to generate a child process for the battle server, and the pause command of the game can be called immediately to freeze the game state at the current moment.

[0065] As an optional embodiment, determining the operation data corresponding to each group of sub-processes includes: performing serialization processing on each group of sub-processes respectively to obtain the operation data corresponding to each group of sub-processes.

[0066] In this embodiment, in order to convert the sub-process into data that can be transported and used (for example, marked), the sub-process can be serialized to obtain running data that can be transported and used. Optionally, the game process at different times is copied to obtain multiple groups of sub-processes, and each group of sub-processes can be serialized separately to obtain running data of each group of sub-processes.

[0067] Optionally, the persistence (dill) module in the serialization module can be used to serialize the sub-processes to obtain the running data corresponding to each group of sub-processes, wherein the serialization processing can include serializing the data by defining an interface method, serializing the data by defining a receiving method (__reduce__ method), etc. There is no specific limitation on the serialization processing method here, and the method of converting the sub-process into maintainable or transmittable running data should be within the protection scope of the present disclosure.

[0068] For example, you can use registered serialization (copy_reg) to obtain functions and object creation functions. When the dill module encounters a non-serializable object, it can find out whether the method registered by copy_reg exists for the object type. If so, it calls the registered data reading method to read the child process and complete the serialization of the child process data.

[0069] Although it takes a long time to serialize the process, since it is in the child process of the forked function at this time, the embodiment of the present invention can allow the serialization to be executed for a long time, thereby improving the accuracy of data storage.

[0070] As an optional embodiment, multiple groups of operation data are stored in multiple groups of databases respectively; based on the stop time of the operation data stored in each group of databases and the battle name in the game, the database name of each group of databases is determined respectively, wherein the battle name is used to characterize the battle scenes in the game.

[0071] In this embodiment, the sub-process is processed to obtain the transportation data of the sub-process and multiple groups of operation data. Each group of operation data can be stored in a database respectively. The stop time of the operation data stored in the database and the corresponding battle name can be combined to obtain the name of the database, wherein the database can be in a local cache file or a storage database, etc. The database that can be used for storage should be within the protection scope of the present disclosure. The battle name can be battle information (battle id), which can be used to characterize which battle it is, for example, it can be a battle number of a game.

[0072] Optionally, the running data is stored in a database, and the result of the combination of the stop time of the running data and the battle name is used as the database name (key).

[0073] For example, to obtain the running data (serialized data) corresponding to the child process, the serialized data can be written into this database and uploaded to the database for persistent storage. At the same time, the data uploaded to the server can be named according to the battle name and the time of the game, so as to facilitate the rapid determination of the running data that needs to be reviewed in the distributed server environment later.

[0074] As an optional embodiment, in response to a game running request sent by a client, target running data corresponding to the game running request is determined from multiple groups of running data, including: based on the stop time in the game running request, the battle name and the database name in the game running request, a database matching the game running request is determined from multiple groups of databases to obtain a target database; and the running data stored in the target database is determined as the target running data.

[0075] In this embodiment, a game running request sent by the client is obtained, and it is determined that the game needs to be reviewed. In response to the game running request sent by the client, a target database is determined from multiple databases based on the stop time in the obtained game running request and the battle name in the game running request. The data in the target database can be target running data. The target running data is processed to obtain the running status of the virtual object in the game.

[0076] Optionally, after obtaining the running data corresponding to the child process, the running data can be written into the database, and the server can be named according to the battle name and the time of the game. Since the stop time and battle name cannot be the same, the name of each server is different. Therefore, the target database can be quickly determined from multiple databases based on the game running request to obtain the target running data.

[0077] As an optional embodiment, based on the target operation data, the operation state of the virtual object in the game at the target moment is determined, including: deserializing the target operation data to obtain the restored data of the game; and determining the operation state based on the restored data.

[0078] In this embodiment, the target operation data can be obtained from the target database, the target operation data can be deserialized to obtain the restored data of the game, and the restored data can be run to determine the operation status of the virtual object in the game at the target time.

[0079] Optionally, the target running data can be obtained from the target database, but at this time the target running data is serialized data after serialization processing. Therefore, the target running data needs to be deserialized to obtain executable data, so that the running status of the virtual object at the target time can be determined based on the restored data after deserialization processing.

[0080] In the disclosed embodiment, a sub-process is obtained by copying the game process, and target running data is determined based on the running data corresponding to the sub-process. The technical effect of improving the efficiency of reviewing the game status is achieved through the target running data, thereby solving the technical problem of low efficiency in reviewing the game status.

[0081] The technical solution of the disclosed embodiment is further described below with examples in combination with preferred implementations. Specifically, a game replay method based on a computer programming language (python) server is used for description.

[0082] Multiplayer online tactical competitive games have gradually begun to develop, but in order to solve the problem of players disconnecting, the game cannot be reconnected due to technical reasons. During the game, usually after an important team battle, the game will be paused and stored to prevent the game from being forced to be interrupted due to unexpected situations such as players disconnecting, freezing, and network disconnection. The game needs to be restarted, which affects the fairness of the game.

[0083] With the advancement of online game technology, web games usually support the function of reconnecting after disconnection, so the demand for storage is gradually decreasing. However, there are still some small probability game failures (such as bugs) that will not only have an unfair impact on the game, but may even reverse the result of the game. For example, there are some serious program failures that cause the game to be restarted. The restart of the game seriously affects the mentality of the players and even leads to a change in the result of the game. At the same time, restarting the game will rebuild the game battlefield, and various random factors such as the player's birth point will affect the result of the game. In order to better solve the above problems, it is proposed to use game backtracking or game replay to make the battle go back to a certain moment before the failure occurs, and all players reconnect to the battle scene at this moment and continue the game from this moment, thereby retaining the advantages accumulated by the advantaged party in the early stage of the game.

[0084] The main synchronization methods of competitive online games may include: frame synchronization and state synchronization.

[0085] Figure 3 is a schematic diagram of frame synchronization according to one embodiment of the related art, such as Figure 3 As shown, for frame-synchronized games, Client 1, Client 2, and Client 3 upload the current frame to the server by periodically uploading instructions. The server issues instructions to all clients according to the frame. After the client receives the operation, the driving logic and the performance state machine step forward. For example, the start state passes the state to state 1 through instruction 1, and so on, until instruction N is passed to state N.

[0086] Optionally, the basic principle of frame synchronization is that the same starting state plus the same input instructions can get the same game state. Therefore, it can be seen that the frame synchronization review method is often relatively simple. The server only needs to record the starting state of the game (for example, some random number seeds, scene configurations, battle configurations and other related information), and record the operations sent by the client in each frame. When review is required, a review moment is selected, and the operation frames before that moment are sent to the client at one time. The client quickly executes the logic of each frame frame by frame to quickly drive the game state to the state N position.

[0087] From the above, it can be seen that the game can be automatically reviewed by utilizing the synchronization mechanism of frame synchronization. Therefore, almost all frame synchronization games are implemented in a similar manner. However, frame synchronization cannot achieve the same result state with the same starting state and the same input, and there is a technical problem of low efficiency in reviewing the game.

[0088] Figure 4 is a schematic diagram of state synchronization according to one embodiment of the related art, such as Figure 4 As shown, during the state synchronization process, Client 1, Client 2 and Client 3 send upload instructions to the server (serve). Since the game's logic state machine is on the server, most logic judgments are executed in the server. The server drives the logic state machine to step according to the upload instructions uploaded by the client. The server only needs to process the logic state machine. The server sends the state changes to the client, and the client drives the client performance according to the state changes.

[0089] As for state synchronization, the core idea of ​​replay is to replay the server state to a certain moment, and then the client can disconnect and reconnect. When replay is needed, the server logic state machine can be driven to step to a certain state and stop according to the recorded initial state of the game and the client instruction data, so as to complete the replay of the server state to a certain moment; or during the game, the full state data of each state in the server can be recorded, and then the state at a certain moment can be directly restored through the data. However, the synchronization mechanism of state synchronization itself does not support replay. In fact, most games are difficult or impossible to implement state synchronization due to the limitations of their infrastructure design or implementation language characteristics.

[0090] For many state synchronization games, the synchronization of receiving input and state is often not well encapsulated or there is no need to tightly encapsulate it. Therefore, it is impossible to achieve frame-by-frame input and output like frame synchronization in the synchronization architecture itself. At the same time, the time used in the game logic is often real time rather than relative time (usually used to calculate a time period, for logical calculations or to start timers). Without the support of these mechanisms, it is almost impossible to drive the state machine from the beginning to a certain state like frame synchronization. In order to achieve this function, it is necessary to modify and support these underlying mechanisms at a great cost, and a lot of testing is required to ensure functional stability.

[0091] For state synchronization, another approach is to record the full state data of the state. Different from the many special requirements of the above-mentioned state-driven replay method for the underlying mechanism of the game, this method basically has no special underlying mechanism requirements, so it is also a method that can be considered for most state synchronization. However, for a complex competitive game, the state of a battle on the server is often extremely complex, the state data under a state is also very large, and the reference relationship between various objects is also very complex. If you want to complete the reading and recovery of data, relying on manpower to complete it will be very costly for the later maintenance. Every time a new function is developed, developers need to consider the replay function and add the corresponding replay code. Without sufficient testing, it is also difficult to ensure the validity of the replay results. Therefore, this method requires a greater operating cost during later maintenance. At this stage, online games are often updated very frequently. Under such a fast game update speed, using this method will become a huge burden for both development and testing. In addition, reading the full state requires recursion of the entire battle object, which often takes a lot of time. Since the state of the main thread needs to be continuously advanced while reading the state at a certain moment in the thread, some logically single-threaded games cannot insert the logic of state saving in the main thread, and executing it in the thread cannot read the complete state at a certain moment.

[0092] In summary, the replay function of state synchronization games is often very difficult to implement, which is mainly directly related to the synchronization mechanism of state synchronization. In addition, state synchronization projects often do not consider these auxiliary functions in the early stages of development, nor do they formulate special development specifications for these functions. When the project enters the operation period and finds the need to provide such functions, the implementation cost will become very huge.

[0093] To solve the above problems, the disclosed embodiment proposes to use the copy-on-write mechanism of the fork function (fork) to replicate the game state at a certain moment to obtain a child process, and then in the child process, use the game pause mechanism to suspend the game state, and at the same time, use the object serialization (pickle) mechanism of the computer language (python) to serialize the battle object in the process into a file, and mark the battle name (battle id) and the time to which the object belongs in the file. When it is necessary to review the game, select the battle process of a certain server, pull the file data, load the battle object of this battle, and actively modify the memory data state of the player participating in this battle, so that the player client can automatically reconnect to the restored battle after re-login, thereby achieving the technical effect of improving the efficiency of reviewing the game state and solving the technical problem of low efficiency in reviewing the game state.

[0094] The following further introduces the embodiments of the present disclosure by taking a fighting game as an example.

[0095] Figure 5 is a flowchart of a game replay according to one embodiment of the present disclosure, such as Figure 5 As shown, reviewing the game may include the following steps.

[0096] Step S501, start the cycle timer.

[0097] In this embodiment, when the battle game starts, a recurring timer deployed in the battle server may be started.

[0098] Optionally, Figure 6 is a schematic diagram of the game data logic execution according to one embodiment of the present disclosure, such as Figure 6 As shown, the game server can be divided into a game server (which can be referred to as a game server for short) and a battle server (which can be referred to as a battle server for short). The player's data logic is executed in the game server. Before the player joins the battle, client one establishes a connection with game server one, and client two establishes a connection with game server two. After the player joins the battle, the players belonging to the same battle are added to the same battle server. Client one then establishes another new connection with battle server three, and client two also establishes a new connection with battle server three, so that different players in the same battle are in the same process in battle server three, but may be in different processes in the game server.

[0099] Step S502, calling the fork function.

[0100] In this embodiment, when the loop timer expires, the fork function in the battle server can be called to generate a subprocess for the battle server, and the pause instruction of the game can be called immediately to freeze the game state at the current moment.

[0101] Step S503, serialize the sub-process.

[0102] In this embodiment, the persistence (dill) module in the serialization module can be used to complete the serialization of Python built-in objects.

[0103] Alternatively, although the serialization of Python built-in objects takes a long time to execute, since it is in the child process of the forked function, the serialization can be allowed to execute for a long time.

[0104] In this embodiment, the dill module can be used to perform serialization operations on the sub-processes, and the data in the sub-processes (such as virtual object states) can be converted into a format that can be maintained or transmitted, so as to achieve the purpose of data transmission.

[0105] For pure Python code, serialized data can often be generated directly. However, for efficiency reasons, game servers will rewrite some business logic codes into user-defined codes (for example, C++ codes), and then export them to Python for use in games. Figure 7 is a schematic diagram of a battle tree reference relationship according to one embodiment of the present disclosure, such as Figure 7 As shown, a room object (Room) is serialized, and the room object can be used to represent the battle. The room object can include: player manager (avatarDict), collision manager (Collisionmgr) and battle object manager (UnitMgr) and data that cannot be serialized (for example, logger, Pos: math3d.vector), etc. Figure 7 The contents contained in the room are for illustrative purposes only and are not intended to be limiting of the contents of the room object.

[0106] Optionally, the player object may include a player manager one (avatarSoul) and a player manager two (avatarSoul); a collision manager (Collisionmgr) may be used to manage a collision object manager (scene_col), and the collision object manager may include a collision object one (col_object) and a collision object two (col_object); a battle object manager (UnitMgr) may include a **battle object one (**Unit) and a **battle object two (**Unit).

[0107] exist Figure 7 In the example, the slashed square can be used to represent C++ module objects. Therefore, it is necessary to solve the serialization problem of the C++ module objects referenced in the slashed square. Figure 7 Each square in the battle tree can represent a battle object used in the battle process, and the reference relationship diagram of the battle tree can be determined according to the reference relationship in the actual battle process.

[0108] like Figure 7 As shown in the figure, there will be C++ objects referenced by Python objects in the component tree. For pure C++ objects, the dill module cannot handle this part of the logic. To solve the above problem, the C++ code needs to be processed in a targeted manner. For example, by selecting an adaptive serialization method, the dill module can recognize and correctly serialize these objects.

[0109] For example, data can be serialized by defining interface methods. For Python objects inherited from C++ objects, the dill module can customize the state (__getstate_) and set state (__setstate_) serialization interfaces in the class. When serializing the object, if the object has a __getstate__ method, __getstate__ can be called during serialization to obtain data, and __setstate__ can be called during deserialization to pass in the data and restore the working state. Deserialization can be used to characterize the recovery process of the game.

[0110] For another example, you can serialize data by defining a receiving method (__reduce__ method). The __reduce__ method is more flexible than __getstate__. The __reduce__ method combines the functions of __getstate__ and __setstate__. You can define the __reduce__ method to return a five-tuple, which determines how to create virtual objects in the game during deserialization. The __reduce__ method can also be used to serialize a virtual object and then deserialize it into another type of virtual object.

[0111] As an optional example, for special objects created by extension classes written in C++, since such objects are custom C extension classes, they can be directly exported in C++ through the above custom methods, and specific methods can be used to process specific classes.

[0112] As another optional example, you can use registered serialization (copy_reg) to obtain functions and object creation functions. When the dill module encounters a non-serializable object, it can find out whether the method registered by copy_reg exists for the object type. If so, the registered data reading method is called to read the object data. Similarly, the object can be restored according to the registered object creation method to complete the deserialization process.

[0113] As another optional example, you can inherit the C++ class through a python class, and the instance object created by the script is created using the python inherited class instead of directly creating it through the C++ class in the extension library. In this way, you can use __getstate__ and __setstate__ in the inherited class to read and restore the object.

[0114] It should be noted that, whether using inheritance or copy_reg registration serialization, the essence of solving the C++ object problem is to add an additional Python layer encapsulation for the C++ object. In addition to some simple cases of referencing C++ objects, there may be some special cases. For the case where C++ objects directly reference C++ objects, you can inherit at the Python layer and then add an additional layer of Python reference relationship at the Python layer to help the dill module find the object reference relationship hidden in the C++ object during serialization. At the same time, through some special hook writing methods, when the object is restored, the object data is used to rebuild the C++ object and restore the reference relationship within the C++ object. The above serialization method is only for example, and no specific restrictions are made on the serialization method here.

[0115] Step S504: Name the serialized data.

[0116] In this embodiment, after obtaining the serialized data corresponding to the child process, the serialized data can be written into a local file (for example, cache) or a database. Uploading it to the database can be persistent. At the same time, it is convenient for later reconstruction of game objects (battle objects) in a distributed server environment. The data uploaded to the server can be named according to the battle name (battle id) and the moment of the game.

[0117] Step S505, obtaining a game replay request.

[0118] In this embodiment, when a review is required, the game operation instruction can be used to input the name of the battle to be reviewed and the time to be reviewed, obtain a game review request, and send the game review request to a certain battle suit. The video archive time closest to the time in the game operation instruction can be found forward, an instruction (key) can be generated, and the data corresponding to the time can be downloaded from the database. The running status of the virtual object can be restored by deserialization.

[0119] Step S506, synchronizing battlefield information to all participating players.

[0120] In this embodiment, information related to the battle, such as the battle ID and the battle server address where the battle is located, can be synchronized to all players participating in the battle and the corresponding virtual objects (avatars) in the game server process, and the status of the virtual objects can be updated to the in-battle status.

[0121] Optionally, the player can be notified to log in again. When logging in again, the virtual object status can be detected as being in combat. The player can enter the combat through the previously synchronized combat ID and the combat server address. After entering the combat, the combat is in a paused state, and the player can manually end the pause to continue the game.

[0122] The disclosed embodiment utilizes the copy_on_write mechanism of the fork function so that the memory state of the parent process can be completely copied to the child process. Even if the battle service where the parent process is located continues, the state of the child process can still be retained at the time of the fork function call. At the same time, other execution logic of the child process will not affect the operation of the parent process, thereby achieving the purpose of quickly tracing the battle state back to a time point close to the target point; utilizing the pickle mechanism, only the object attribute value is read, thereby realizing the reading of the battlefield state from the bottom-level perspective, avoiding the insertion of too much state reading and state recovery code in the business, greatly reducing the subsequent maintenance and testing costs, and reducing the abnormal risks that may be caused by the replay function.

[0123] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present disclosure, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present disclosure.

[0124] In the present embodiment, a data processing device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "unit" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.

[0125] Figure 8 is a structural block diagram of a data processing device according to an embodiment of the present disclosure, such as Figure 8 As shown, the data processing device may include: an acquisition unit 802 , a first determination unit 804 , a second determination unit 806 and a third determination unit 808 .

[0126] An acquisition unit 802 is used to acquire multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to represent the process of playing a game, and the game process includes sub-processes;

[0127] A first determining unit 804 is used to determine the operation data corresponding to each group of sub-processes to obtain multiple groups of operation data;

[0128] A second determining unit 806 is configured to determine target running data corresponding to the game running request from multiple sets of running data in response to the game running request sent by the client;

[0129] The third determining unit 808 is used to determine the running state of the virtual object in the game at the target time based on the target running data.

[0130] In this embodiment, multiple groups of sub-processes of a game process in a battle server are acquired through an acquisition unit, wherein the game process is used to characterize the process of the game, and the game process includes sub-processes; the operation data corresponding to each group of sub-processes is determined through a first determination unit to obtain multiple groups of operation data; the target operation data corresponding to the game operation request is determined from the multiple groups of operation data in response to the game operation request sent by the client through a second determination unit; the operation status of the virtual object in the game at the target moment is determined based on the target operation data through a third determination unit, thereby achieving the technical effect of improving the efficiency of reviewing the game status and solving the technical problem of low efficiency in reviewing the game status.

[0131] It should be noted that the above-mentioned units can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to this: the above-mentioned units are all located in the same processor; or the above-mentioned units are located in different processors in any combination.

[0132] An embodiment of the present disclosure further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0133] Optionally, in this embodiment, the non-volatile storage medium may be configured to store a computer program for performing the following steps:

[0134] S1, obtaining multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to represent the process of the game, and the game process includes sub-processes;

[0135] S2, determining the operation data corresponding to each group of sub-processes, and obtaining multiple groups of operation data;

[0136] S3, in response to the game running request sent by the client, determining target running data corresponding to the game running request from multiple sets of running data;

[0137] S4, determining the running state of the virtual object in the game at the target time based on the target running data.

[0138] Optionally, in this embodiment, the above-mentioned computer-readable storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store computer programs.

[0139] An embodiment of the present disclosure further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0140] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0141] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0142] S1, obtaining multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to represent the process of the game, and the game process includes sub-processes;

[0143] S2, determining the operation data corresponding to each group of sub-processes, and obtaining multiple groups of operation data;

[0144] S3, in response to the game running request sent by the client, determining target running data corresponding to the game running request from multiple sets of running data;

[0145] S4, determining the running state of the virtual object in the game at the target time based on the target running data.

[0146] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0147] Fig. 9 is a schematic diagram of an electronic device according to an embodiment of the present disclosure. Fig. 9 As shown, the electronic device 900 is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0148] like Fig. 9 As shown, the electronic device 900 is in the form of a general computing device. The components of the electronic device 900 may include but are not limited to: at least one processor 910, at least one memory 920, a bus 930 connecting different system components (including the memory 920 and the processor 910), and a display 940.

[0149] The memory 920 stores program codes, which can be executed by the processor 910, so that the processor 910 executes the steps according to various exemplary embodiments of the present invention described in the method part of the embodiment of the present application.

[0150] The memory 920 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 9201 and / or a cache memory unit 9202, and may further include a read-only memory unit (ROM) 9203, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.

[0151] In some examples, the memory 920 may also include a program / utility 9204 having a set (at least one) of program modules 9205, such program modules 9205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or a combination thereof may include the implementation of a network environment. The memory 920 may further include a memory remotely disposed relative to the processor 910, and these remote memories may be connected to the electronic device 900 via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0152] Bus 930 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a local bus of processor 910, or a bus using any of a variety of bus architectures.

[0153] The display 940 may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the electronic device 900 .

[0154] Optionally, the electronic device 900 may also communicate with one or more external devices 1400 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device 900, and / or any device that enables the electronic device 900 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed through an input / output (I / O) interface 950. Furthermore, the electronic device 900 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter 960. Fig. 9 As shown, the network adapter 960 communicates with other modules of the electronic device 900 via the bus 930. It should be understood that although Fig. 9Not shown, other hardware and / or software modules may be used in conjunction with the electronic device 900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0155] The electronic device 900 may further include: a keyboard, a cursor control device (such as a mouse), an input / output interface (I / O interface), a network interface, a power supply and / or a camera.

[0156] It can be understood by those skilled in the art that Fig. 9 The structure shown is for illustration only and does not limit the structure of the above electronic device. Fig. 9 More or fewer components as shown, or with Figure 1 The memory 920 may be used to store computer programs and corresponding data, such as the computer programs and corresponding data corresponding to the data processing method in the embodiment of the present disclosure. The processor 910 executes various functional applications and data processing by running the computer programs stored in the memory 920, that is, implements the above-mentioned data processing method.

[0157] The serial numbers of the above-mentioned embodiments of the present disclosure are only for description and do not represent the advantages or disadvantages of the embodiments.

[0158] In the above embodiments of the present disclosure, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0159] In the several embodiments provided in the present disclosure, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0160] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0161] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0162] If the integrated unit is implemented in the form of 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 the present disclosure is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present disclosure. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0163] The above is only a preferred embodiment of the present disclosure. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present disclosure. These improvements and modifications should also be regarded as the scope of protection of the present disclosure.

Claims

1. A data processing method, characterized in that: include: Acquire multiple groups of sub-processes of a game process in a battle server, wherein the game process is used to represent the process of playing the game, and the game process includes the sub-processes; Determine the operation data corresponding to each group of the sub-processes to obtain multiple groups of the operation data; In response to a game running request sent by a client, determining target running data corresponding to the game running request from the plurality of sets of running data; Determining the running state of the virtual object in the game at a target time based on the target running data; Wherein, the obtaining of multiple groups of sub-processes of the game process in the battle server includes: calling a fork function, copying the game process in the battle server, and obtaining the sub-processes; The step of determining the operation data corresponding to each group of the sub-processes includes: performing serialization processing on each group of the sub-processes respectively to obtain the operation data corresponding to each group of the sub-processes.

2. The method according to claim 1, characterized in that: The method further comprises: The fork function is called every target time period.

3. The method according to claim 1, characterized in that The method further comprises: At every target time period, in response to the stop request, the sub-process is stopped.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: storing the plurality of sets of operating data in a plurality of sets of databases respectively; Based on the stop time of the running data stored in each group of the databases and the battle name in the game, the database name of each group of the databases is determined respectively, wherein the battle name is used to characterize the battle scenes in the game.

5. The method according to claim 4, characterized in that In response to the game running request sent by the client, determining the target running data corresponding to the game running request from multiple groups of the running data includes: Based on the stop time in the game running request, the battle name in the game running request and the database name, determining a database matching the game running request from multiple groups of databases to obtain a target database; The operating data stored in the target database is determined as target operating data.

6. The method according to any one of claims 1 to 3, characterized in that: Determining the running state of the virtual object in the game at the target time based on the target running data includes: Deserializing the target running data to obtain restored data of the game; The operating status is determined based on the restored data.

7. A data processing device, characterized in that: include: An acquisition unit, used for acquiring a plurality of groups of sub-processes of a game process in a battle server, wherein the game process is used for representing the process of playing a game, and the game process includes the sub-processes; A first determining unit, configured to determine the operation data corresponding to each group of the sub-processes, and obtain multiple groups of the operation data; A second determining unit, configured to determine, in response to a game running request sent by a client, target running data corresponding to the game running request from a plurality of sets of running data; A third determining unit, configured to determine an operating state of the virtual object in the game at a target time based on the target operating data; The acquisition unit is used to acquire multiple groups of sub-processes of the game process in the battle server by the following steps: calling a fork function, copying the game process in the battle server, and obtaining the sub-processes; The first determining unit is used to determine the operation data corresponding to each group of the sub-processes through the following steps: serializing each group of the sub-processes respectively to obtain the operation data corresponding to each group of the sub-processes.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the method according to any one of claims 1 to 6 when executed by a processor.

9. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 6.

Images