Event playback method and apparatus, storage medium, and electronic device

Abstract

The present application discloses an event playback method and apparatus, a storage medium, and an electronic device. The method comprises: displaying a running picture of a mobile game, wherein the running picture is a picture obtained by rendering on the basis of a first game resource, and the first game resource is a game resource used in a current match of the mobile game; in response to an event playback request, obtaining a reusable game resource from the first game resource, and forming a second game resource on the basis of the reusable game resource; and during the current match of the mobile game, rendering and playing back a historical game event on the basis of the second game resource. The present application solves the technical problem that real-time playback for event playback is not suitable for mobile games.

Description

Event playback methods, devices, storage media, and electronic devices

[0001] This application claims priority to Chinese Patent Application No. 2024100158447, filed on January 2, 2024, entitled “Real-time playback method, apparatus, storage medium and electronic device for event replay”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computers, specifically to game event replay technology. Background Technology

[0003] In PC games, real-time event replay functionality is typically deployed. However, this real-time replay functionality on PCs places a significant burden on memory and CPU performance, making it unsuitable for mobile games. This leads to the problem that real-time event replay is not applicable to mobile games. Summary of the Invention

[0004] This application provides an event playback method, apparatus, storage medium, and electronic device to at least solve the technical problem that real-time playback of events is not suitable for mobile games.

[0005] According to one aspect of the embodiments of this application, an event replay method is provided, comprising: displaying a running screen of a mobile game, wherein the running screen is a screen rendered based on a first game resource, the first game resource being the game resource used by the mobile game during the current match; responding to an event replay request, obtaining reusable game resources from the first game resource, and assembling a second game resource based on the reusable game resource, wherein the event replay request is used to request the replay of historical game events of the virtual character, and the second game resource is the game resource required for rendering and playing the historical game events; and rendering and playing the historical game events based on the second game resource when the mobile game is in the current match.

[0006] According to another aspect of the embodiments of this application, an event replay apparatus is also provided, comprising: a first display unit for displaying a running screen of a mobile game, wherein the running screen is a screen rendered based on a first game resource, the first game resource being the game resource used by the mobile game during the current match; a first acquisition unit for acquiring reusable game resources from the first game resource in response to an event replay request, and assembling a second game resource based on the reusable game resource, wherein the event replay request is used to request the replay of historical game events of the virtual character, and the second game resource is the game resource required for rendering and playing the historical game events; and a playback unit for rendering and playing the historical game events based on the second game resource when the mobile game is in the current match.

[0007] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the 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 the processor executes the computer instructions, causing the computer device to perform the event playback method as described above.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the event playback method described above through the computer program.

[0009] In this embodiment, a mobile game's running screen is displayed. This running screen is rendered based on a first game resource, which is the game resource used during the current game session. In response to an event replay request, reusable game resources are obtained from the first game resource, and a second game resource is formed based on these reusable resources. The event replay request is used to request the replay of historical game events of a virtual character, and the second game resource is the game resource required to render and play the historical game events. During the current game session, the historical game events are rendered and played based on the second game resource. By reusing some game resources (reusable game resources) from the first game resource used during the current game session to form the second game resource required to play the historical game events, redundant steps in creating new game resources are eliminated, thereby reducing performance overhead caused by redundant steps. This improves the technical effect of adapting real-time event replay to mobile games, thus solving the technical problem that real-time event replay is not suitable for mobile games. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0011] Figure 1 is a schematic diagram of the application environment of an optional event playback method according to an embodiment of this application;

[0012] Figure 2 is a schematic flowchart of an optional event playback method according to an embodiment of this application;

[0013] Figure 3 is a schematic diagram of an optional event playback method according to an embodiment of this application;

[0014] Figure 4 is a schematic diagram of another optional event playback method according to an embodiment of this application;

[0015] Figure 5 is a schematic diagram of another optional event playback method according to an embodiment of this application;

[0016] Figure 6 is a schematic diagram of another optional event playback method according to an embodiment of this application;

[0017] Figure 7 is a schematic diagram of another optional event playback method according to an embodiment of this application;

[0018] Figure 8 is a schematic diagram of an optional event playback device according to an embodiment of this application;

[0019] Figure 9 is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0020] 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 should fall within the scope of protection of the present application.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific 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 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.

[0022] UE4: Unreal Engine 4, a game engine developed by Epic Games, widely used in the development of shooting games.

[0023] Recording system: Records the game process by saving the server's network data as a file for later playback.

[0024] Elimination replay: In first-person shooting (FPS) games, after a character is eliminated, the process of the character being located, aimed at, and shot is often replayed from the enemy's perspective.

[0025] According to one aspect of the embodiments of this application, an event playback method is provided. Optionally, as an optional implementation, the event playback method can be applied to the environment shown in FIG1, but is not limited to. This environment may include, but is not limited to, a user device 102 and a server 112. The user device 102 may include, but is not limited to, a display 104, a processor 106, and a memory 108, and the server 112 may include, but is not limited to, a database 114 and a processing engine 116.

[0026] The specific process can be summarized in the following steps:

[0027] Step S102, user equipment 102 obtains an event playback request;

[0028] Step S104: Send the event replay request to the server 112 via network 110;

[0029] In steps S106-S108, server 112 responds to event replay requests through processing engine 116, obtains reusable game resources from the first game resources, assembles a second game resource based on the reusable game resources, and further obtains the historical game screen corresponding to the second game resource.

[0030] In step S110, the historical game screen is sent to the user device 102 via the network 110. The user device 102 displays the historical game screen on the display 104 via the processor 106 and stores the historical game screen in the memory 108.

[0031] Besides the example shown in Figure 1, the above steps can be completed independently by the user equipment or the server, or jointly by the user equipment and the server. For example, user equipment 102 can perform steps S106-S108, thereby reducing the processing load on server 112. User equipment 102 includes, but is not limited to, handheld devices (such as mobile phones), laptops, tablets, desktop computers, in-vehicle devices, smart TVs, etc. This application does not limit the specific implementation of user equipment 102. Server 112 can be a single server, a server cluster composed of multiple servers, or a cloud server.

[0032] Alternatively, as an optional implementation, as shown in Figure 2, the event playback method can be executed by an electronic device, such as the user device or server shown in Figure 1, and the specific steps include:

[0033] S202, Display the running screen of the mobile game, wherein the running screen is a screen rendered based on the first game resource, and the first game resource is the game resource used by the mobile game in the current game;

[0034] S204, in response to the event replay request, obtain reusable game resources from the first game resources, and compose a second game resource based on the reusable game resources, wherein the event replay request is used to request the replay of the virtual character's historical game events, and the second game resource is the game resource required for rendering and playing the historical game events;

[0035] S206: When the current game is in progress on the mobile device, historical game events are rendered and played based on the second game resource.

[0036] Optionally, in this embodiment, the above-mentioned event replay method can be applied, but is not limited to, to first-person shooter (FPS) games on mobile devices. After a character (virtual character) is eliminated, the process of the character being located, aimed at, and shot is often replayed from the perspective of the enemy (historical game events).

[0037] Optionally, in this embodiment, the mobile game is a virtual game played by virtual characters and running on a mobile device. In mobile games, players typically control virtual characters by touching the screen or using external devices. Virtual characters can perform various activities in the virtual environment, including but not limited to moving, jumping, attacking, and defending. Furthermore, in a single match of a mobile game, a virtual character can be eliminated at least twice, and the victory condition for a match can be, but is not limited to, related to elimination; for example, the team with fewer virtual character eliminations wins the match.

[0038] Optionally, in this embodiment, the historical game event may be, but is not limited to, a specified historical game event, or any kind of historical game event. The specified historical game event may be, but is not limited to, a game event of a specified type experienced by the virtual character in the mobile game, while any kind of historical game event may be, but is not limited to, any type of game event experienced by the virtual character in the mobile game.

[0039] Specifically, assuming the specified type is a specified task type, and the virtual character experiences game event A of task type A in the mobile game, and task type A is the specified task type, game event A can be used as the specified historical game event; or, assuming the specified type is a specified interaction type, and the virtual character experiences game event B in the mobile game, and the virtual character interacts with a virtual character of the specified interaction type in game event B, game event B can be used as the specified historical game event; or, for example, the specified type is a type of special event, such as assuming the event of the virtual character being eliminated in the mobile game is a special event, and the elimination event can be used as the specified historical game event when the virtual character is eliminated in the mobile game.

[0040] To further illustrate, optionally, when a player-controlled virtual character loses health points or meets other elimination conditions in the game, the virtual character will transition from a non-elimination state to an eliminated state. This process, in this embodiment, can be, but is not limited to, referred to as the virtual character's elimination process (historical game event). During the historical game event, the virtual character may, but is not limited to, lose control of the game screen and cannot continue participating in the game. Simultaneously, in this embodiment, the mobile game may, but is not limited to, play an elimination animation or effect (playing the historical game event) to demonstrate the virtual character's elimination state to the player. This animation or effect may include the character falling, disappearing, or other visual effects to create an atmosphere of failure or ending. In addition to visual presentation, the mobile game may also emit sound effects or text prompts to further clarify the virtual character's elimination state. These effects and prompts can help players better understand that their virtual character has been eliminated and remind them that they need to restart the game or perform other actions.

[0041] Optionally, in this embodiment, the first game resource is the game resource used in the current game of the mobile game, such as character resources (virtual characters that players can choose in the game), scene resources (providing players with different game scenes and combat environments), item resources (items that players can obtain and use in the game), sound effect resources (various sound effects used in the game), plot resources (storylines and mission clues presented in the game), interactive resources (providing interactive functions for multiple accounts in the game), and image resources (images presented in the game), etc.

[0042] Optionally, in this embodiment, the running screen of the mobile game is a screen rendered based on the first game resource. Rendering can be understood, but is not limited to, converting game resources (such as characters, maps, items, etc.) into images and animations that can be displayed on the screen. In mobile games, rendering is typically performed by a game engine. A game engine can be, but is not limited to, a software tool used to create and manage game screens, responsible for converting game resources into images that can be displayed on the screen, and drawing and displaying them through a graphics processing unit (GPU).

[0043] Optionally, in this embodiment, the event replay request is used to request the playback of historical game events of the virtual character. Through the event replay request, players can rewatch the performance of their controlled virtual character in the game, including the virtual character's movement, attacks, defenses, and interactions with other characters or enemies. This replay function provides players with more opportunities for reflection and learning, helping them continuously improve their skills and tactical levels in the game. Furthermore, to provide a better user experience, this embodiment can also, but is not limited to, save the replay recording locally or to the cloud for viewing on other devices or platforms. This allows players to review their game performance anytime, anywhere, and share their elimination experiences with friends, increasing the social interactivity of the game.

[0044] Optionally, in this embodiment, reusable game resources are extracted from the first game resources and can be reused in other scenes or processes. Reusable game resources can include various elements and effects in the game, such as textures, models, sounds, and objects. The second game resource is composed of reusable game resources and is the game resource required for rendering and playing historical game events. These resources can include specific character models, animations, and sound effects to present the visual and auditory effects of virtual characters in historical game events (such as elimination). By obtaining reusable game resources from the first game resource and composing the second game resource required for rendering and playing historical game events based on these reusable game resources, game development can be more efficient, and repetitive work and waste can be reduced.

[0045] Optionally, in this embodiment, when playing historical game events, the game engine will present the corresponding character models, animations, and sound effects to the player in a replay manner according to the settings and requirements of the second game resource. For example, this may include the falling down, disappearing, or other visual effects of characters, as well as the elimination of related enemy characters.

[0046] It should be noted that by reusing some game resources (reusable game resources) from the first game resources used in the current game on the mobile device to form the second game resources required for playing historical game events, the step of creating new game resources is eliminated, thereby reducing the performance overhead caused by these steps. This achieves the technical effect of improving the adaptability of real-time event replay in response to event replay requests in mobile devices.

[0047] Further illustrating with an example, optionally, as shown in Figure 3(a), a running screen 304 of the mobile game is displayed. This running screen 304 is a screen rendered based on a first game resource. The first game resource is the game resource used during the current match in the mobile game. The mobile game is a virtual game running on the mobile device 302, involving virtual character 306 (and an enemy virtual character 308). Further responding to an event replay request, reusable game resources are obtained from the first game resource, and a second game resource is formed based on these reusable game resources. In this context, assuming the historical game event is the historical event where the enemy virtual character 308 eliminates the virtual character 306, then the event replay request is used to request the replay of the historical game event 310 in which the virtual character 306 is eliminated. The historical game event 310 can also be understood as the event that causes the virtual character 306 to change from a non-ending state to an ending state. The second game resource is the game resource required to play the historical game event 310. Furthermore, as shown in Figure 3(b), when the mobile game is in the current match, the historical game event 310 is rendered and played based on the second game resource.

[0048] The embodiments provided in this application display the running screen of a mobile game. The running screen is rendered based on a first game resource, which is the game resource used during the current game session. In response to an event replay request, reusable game resources are obtained from the first game resource, and a second game resource is formed based on the reusable game resource. The event replay request is used to request the replay of historical game events of a virtual character, and the second game resource is the game resource required to play the historical game events. During the current game session, the historical game events are rendered and played based on the second game resource. By reusing some game resources (reusable game resources) from the first game resource used during the current game session to form the second game resource required to play historical game events, the redundant step of creating new game resources is eliminated, thereby reducing the performance overhead caused by redundant steps. This achieves the technical effect of improving the adaptability of real-time event replay in response to event replay requests within the mobile game.

[0049] As an optional approach, before retrieving reusable game resources from the first game resource in response to an event replay request and assembling the second game resource based on the reusable game resources, the method further includes:

[0050] S1-1, When a historical game event is in an ended state, display the event replay control, wherein the historical game event in an ended state is set to be unchangeable;

[0051] S1-2, responding to the playback trigger operation executed based on the event playback control, initiates an event playback request.

[0052] It should be noted that, in order to improve the intuitiveness of the event replay operation, an event replay control is displayed when the historical game event is in an ended state. Players can trigger the replay by performing a replay trigger operation based on the event replay control, thereby triggering the real-time playback of the event replay.

[0053] To further illustrate, optionally based on the scenario shown in Figure 3, continuing as shown in Figure 4(a), when the virtual character 306 is in a character elimination state (the message "Waiting to revive!" is displayed on the running screen 402), it is considered that the historical game event is in an ended state, and then the event replay control 404 is displayed, wherein the virtual character 306 in the character elimination state is set to be disabled; furthermore, in response to the replay trigger operation performed based on the event replay control 404, as shown in Figure 4(b), the historical game event 310 is played.

[0054] Through the embodiments provided in this application, when a historical game event is in an ended state, an event replay control is displayed, wherein the historical game event in the ended state is set to be unchangeable; in response to the replay trigger operation performed on the event replay control, an event replay request is triggered, thereby achieving the purpose of triggering real-time playback of the event replay through the replay trigger operation performed based on the event replay control, thereby achieving the technical effect of improving the intuitiveness of the event replay operation.

[0055] As an optional approach, the method also includes the following when displaying the event playback control:

[0056] S2-1 displays the event playback control in the disabled state and the countdown time of the disabled state, wherein the event playback control in the disabled state is set to disable the execution of playback trigger operation;

[0057] S2-2, when the countdown timer in the prohibited operation state is cleared, the event playback control in the allowed operation state is displayed, wherein the event playback control in the allowed operation state is set to allow the execution of playback trigger operation.

[0058] It should be noted that, in order to prevent information leakage due to event replay, when the historical game event is in an ended state, the state of the event replay control is first set to the disabled state, and a countdown time for the disabled state is set. This countdown time is the duration of the disabled state. In this way, the replay trigger operation based on the event replay control is prohibited during the time when information leakage is likely to occur, thereby avoiding the problem of information leakage and improving the user experience of event replay.

[0059] Furthermore, in order to replay historical game events, it is necessary to obtain reusable game resources from the first game resource and assemble the second game resource based on the reusable game resources. In order to avoid putting too much performance pressure on the mobile device, a countdown timer for the prohibited operation state is set so that this process has enough time to execute without having to use too many resources to consider the time issue.

[0060] To further illustrate, based on the scenario shown in Figure 4, and continuing as shown in Figure 5, an event playback control 404 in a prohibited operation state and a countdown time 502 in the prohibited operation state are displayed. If the countdown time is displayed as a progress bar and the progress bar is not cleared, the event playback control 404 will remain prohibited from performing playback trigger operations.

[0061] The embodiments provided in this application display an event playback control in a prohibited operation state and a countdown timer for the prohibited operation state. The event playback control in the prohibited operation state is set to prohibit the execution of playback trigger operations. When the countdown timer for the prohibited operation state is cleared, an event playback control in an allowed operation state is displayed. The event playback control in the allowed operation state is set to allow the execution of playback trigger operations. This prevents information leakage caused by event playback and avoids excessive performance pressure on mobile devices during the event playback process, thereby achieving the technical effect of improving the user experience of event playback.

[0062] As an alternative, reusable game resources can be obtained from the first game resource, including at least one of the following:

[0063] S3-1, Obtain reusable scene resources from the first game resource, where scene resources are the resources required to render the game scene of the current game;

[0064] S3-2, Obtain reusable object resources from the first game resource, wherein the object resources are the resources required to render game objects related to historical game events in the current game.

[0065] Optionally, in this embodiment, scene resources refer to the resources required to render the game scene of the current match, typically including textures, models, lighting, and special effects. These resources are important components of the game scene, used to present the appearance and effects of the game scene during the rendering process. In mobile games, scene resources are usually designed and produced according to different game scenes to provide corresponding visual effects and gaming experiences. By obtaining reusable scene resources from the first game resource, the scene resource can be reused to construct the corresponding game scene, thereby saving time and resource costs for event replay.

[0066] Optionally, in this embodiment, object resources may refer to, but are not limited to, the resources required for rendering game objects related to historical game events in the current game. Game objects may include characters, props, buildings, etc. Accordingly, object resources are used to present specific game elements and objects in the game. In mobile games, object resources are usually designed and produced according to different game objects to provide corresponding visual effects and game experience. By obtaining reusable object resources from the first game resources, the object resources can be reused to construct the corresponding game objects to restore the corresponding game process, thereby saving time and resource costs for event replay.

[0067] It should be noted that, in order to improve the diversity of reusable game resources, reusable scene resources and / or object resources can be obtained from the first game resource.

[0068] Through the embodiments provided in this application, reusable scene resources are obtained from the first game resources, wherein the scene resources are the resources required to render the game scene of the current game; reusable object resources are obtained from the first game resources, wherein the object resources are the resources required to render game objects related to historical game events in the current game, thereby achieving the purpose of obtaining reusable scene resources or object resources from the first game resources, thereby realizing the technical effect of improving the diversity of reusable game resources.

[0069] As an alternative, reusable object resources can be obtained from the first game resource, including:

[0070] The game object pool is used to retrieve the object resources needed to render game objects related to historical game events. The game object pool is used to manage reusable object resources.

[0071] It's important to note that retrieving the game object resources needed to render game objects related to historical game events from the game object pool is an efficient management and rendering strategy. A game object pool can be, but is not limited to, a mechanism for managing reusable object resources. It allows for caching and reusing object resources, reducing the overhead of resource allocation and release, and improving game performance and efficiency. In mobile games, the game object pool is typically provided and managed by the game engine.

[0072] Optionally, in this embodiment, when it is necessary to render game objects from historical game events, the game engine can obtain corresponding object resources from the game object pool. These resources include reusable object resources, such as characters, props, and buildings, used to present specific game objects. By obtaining object resources from the game object pool, the frequent creation and destruction of game objects can be avoided, reducing system overhead and memory usage.

[0073] The embodiments provided in this application obtain the object resources required for rendering game objects related to historical game events from the game object pool. The game object pool is used to manage reusable object resources, thereby reducing the overhead of resource allocation and release, and thus achieving the technical effect of improving the performance and efficiency of the game.

[0074] As an alternative approach, the method may also include the following before obtaining reusable game resources from the first game resource:

[0075] The game resources used during normal gameplay on the mobile device are separated from the game resources required to play any historical game event on the mobile device. Normal gameplay includes the current game, and any historical game event includes historical game events.

[0076] Optionally, in this embodiment, during a normal game, the game engine uses a specific set of game resources, including resources used to render elements such as characters, maps, items, and buildings, to construct the game scene and present game content. These game resources are typically dynamically loaded and rendered based on the specific circumstances of the current game.

[0077] When playing any historical game event, the game engine uses another specific set of game resources, including specific character models, animations, and sound effects, to recreate the historical game event in multiple dimensions, including visual and auditory aspects. These game resources may, but are not limited to, be pre-prepared and stored in the game engine, and are used for rendering and playback when the historical game event is executed or is executed.

[0078] By isolating game resources used in normal matches and historical game events, game resources and data can be better managed and controlled. Different resources can be developed and maintained independently, avoiding interference and conflicts between them. This isolation also improves the game's scalability and maintainability, facilitating future upgrades and expansions.

[0079] It should be noted that isolating the game resources used during normal gameplay on mobile devices from those required for playing any historical game event can improve the game's maintainability and scalability.

[0080] The embodiments provided in this application isolate the game resources used during normal gameplay of a mobile game from the game resources required to play any historical game event. Normal gameplay includes the current game, and any historical game event includes historical game events. This achieves the goal of isolating the game resources used during normal gameplay from the game resources required to play historical game events, thereby improving the maintainability and scalability of the game.

[0081] As an optional approach, before data isolation is performed on game resources used during normal gameplay on a mobile device and game resources required to play any historical game event on the mobile device, the method also includes:

[0082] Create a first channel list and a second channel list. The first channel list is used to store and manage game resources used during normal gameplay on the mobile device, while the second channel list is used to store and manage game resources required when the mobile device plays any historical game event.

[0083] As an optional solution, game resources used during normal gameplay on a mobile device are separated from those required to play any historical game event. This includes:

[0084] The game resources stored in the first channel list and the second channel list are isolated.

[0085] Optionally, in this embodiment, the first channel list can be used to store and manage game resources used during normal gameplay, such as resources used to render elements like characters, maps, items, and buildings. These game resources are used to construct game scenes and present game content, and can be dynamically loaded and rendered according to the specific circumstances of the current game. By storing game resources used during normal gameplay in the first channel list, these game resources can be easily managed and controlled, ensuring that they are only loaded and used during normal gameplay.

[0086] Optionally, in this embodiment, the second channel list can be used to store and manage game resources required when playing any historical game event, such as specific character models, animations, and sound effects.

[0087] To further illustrate, optionally, assuming a historical game event is an event where a virtual character loses health or meets other elimination conditions, the resources stored and managed using the second-channel list can be used to present the visual and auditory effects of a character's elimination. These effects can be rendered and played when the virtual character loses health or meets other elimination conditions. By storing the resources required for rendering historical game events in the second-channel list, loading and using these resources during normal gameplay can be avoided, thereby improving game performance and efficiency.

[0088] It's important to note that, to achieve data isolation, different game resources can be stored and managed in the first and second channel lists respectively. This allows game resources used during normal gameplay and those required to play any historical game event to be loaded, rendered, and managed independently. This data isolation avoids interference and conflicts between resources used in different situations, improving the game's maintainability and scalability.

[0089] The embodiments provided in this application create a first channel list and a second channel list. The first channel list is used to store and manage game resources used during normal gameplay on the mobile device, while the second channel list is used to store and manage game resources required when the mobile device plays any historical game event. By isolating the game resources stored in the first and second channel lists, the mutual interference and conflict between resources used in different situations are avoided, thereby achieving the technical effect of improving the maintainability and scalability of the game.

[0090] As an optional solution, a second game resource can be constructed based on reusable game resources, including:

[0091] Redundant replay resources are removed from reusable game resources to obtain a second game resource, wherein the resource similarity between the redundant replay resources and the game resources required to play historical game events is less than or equal to a preset threshold.

[0092] Optionally, in this embodiment, to eliminate redundant replay resources, algorithms and techniques can be used to analyze and compare the similarity between game resources. By calculating the resource similarity between the redundant replay resources and the game resources required to play historical game events, it can be determined whether they are duplicates or similar. If the similarity is less than or equal to a preset threshold, the redundant replay resources can be removed from the reusable game resources, thereby obtaining the second game resource.

[0093] Furthermore, in this embodiment, before removing redundant replay resources, it is necessary to ensure that reusable game resources are complete and correct, and can meet the needs of historical game events. When removing redundant replay resources, careful judgment and screening are required to avoid mistakenly deleting important resources needed for rendering historical game events. After removing redundant replay resources, the loading and management of game resources need to be optimized to improve game performance and efficiency. As the game is updated and expanded, the game resource library needs to be updated and maintained in a timely manner to ensure the integrity and correctness of the resources.

[0094] It should be noted that replay redundant resources refer to game resources that are not needed during game replay, such as information interaction resources from normal gameplay. These resources are not used during event replay, but they are repeatedly loaded and used during the actual replay process, resulting in resource waste. By eliminating replay redundant resources, the additional performance overhead caused by resource waste is reduced, and the adaptability of real-time event replay playback on mobile games is improved.

[0095] Through the embodiments provided in this application, replay redundant resources are removed from reusable game resources to obtain a second game resource. The resource similarity between the replay redundant resource and the game resource required to play historical game events is less than or equal to a preset threshold, thereby reducing the additional performance overhead caused by resource waste. This achieves the technical effect of improving the adaptability of real-time playback of event replay in mobile games.

[0096] As an optional approach, in the process of rendering and playing historical game events based on second game resources, the method also includes:

[0097] S4-1, Obtain the game performance parameters of the mobile device running the mobile game. The game performance parameters are used to evaluate the performance of the mobile device when running the mobile game.

[0098] S4-2, based on game performance parameters, performs frame-by-frame processing on the second game resource, limiting the amount of data from the second game resource used to render each frame of the game when playing historical game events, wherein the amount of data is matched with the game performance parameters.

[0099] Optionally, in this embodiment, the amount of resources required to render each frame in the historical game events is reasonably allocated based on game performance parameters and mobile device performance metrics. If a frame requires more resources, it can be processed separately while ensuring its quality and smoothness.

[0100] Optionally, in this embodiment, during frame-by-frame processing, it is necessary to maintain consistency in the visuals and effects between different frames to ensure the continuity of historical game event replays and user experience. After frame-by-frame processing, resource loading and management need to be optimized. By using techniques such as asynchronous loading and preloading, resource latency and stuttering can be avoided, improving the game's responsiveness and smoothness.

[0101] It should be noted that, in order to limit the amount of data of the second game resources used to render each frame of the game when playing historical game events, and to ensure the performance and smoothness of the game, the game performance parameters of the mobile device are obtained, and the second game resources are processed into frames accordingly.

[0102] To illustrate further, one option is to first obtain the mobile device's game performance parameters, which can be used to assess the device's performance metrics when running mobile games, such as processor speed, memory usage, and battery consumption. These parameters can be used to understand the mobile device's performance bottlenecks and optimization potential, providing a reference for subsequent game optimization. Then, by using the game performance parameters to perform frame-by-frame processing on the second game resource, the amount of data from the second game resource used to render each frame of the game when playing historical game events can be limited. By analyzing the game performance parameters, the amount of resources required for each frame in historical game events can be determined, and corresponding adjustments and optimizations can be made based on the device's performance metrics. This ensures smooth gameplay and responsiveness while reducing unnecessary data transfer and loading.

[0103] The embodiments provided in this application obtain game performance parameters of a mobile device, which are used to evaluate the performance indicators of the mobile device when running mobile games. Based on the game performance parameters, the second game resources are processed by frame segmentation to limit the amount of data of the second game resources used to render each frame of the game screen when playing historical game events. The amount of data is matched with the game performance parameters, thereby achieving the purpose of limiting the amount of data of the second game resources used in each frame of the game screen when playing historical game events, thereby achieving the technical effect of improving the performance and smoothness of the game.

[0104] As an optional approach, in the process of rendering and playing historical game events based on second game resources, the method also includes:

[0105] The rendering server obtains the rendering data packets sent to the mobile device running the mobile game via data transmission. These rendering data packets are used to render historical game events and are divided into a target number of frame sub-data, the target number of which matches the network latency of the data transmission.

[0106] It should be noted that too many frame data points may increase network latency, affecting game smoothness and responsiveness; too few frame data points may result in choppy visuals or wasted resources. Therefore, this embodiment balances and optimizes the situation based on actual conditions, matching the number of segmented frame data points to network latency to achieve optimal game performance and user experience.

[0107] To further illustrate, an optional rendering server generates a rendering data packet containing all the necessary information for rendering historical game events, such as character models, animations, sound effects, and other game resources. These game resources are packaged into a single rendering data packet and then transmitted to the mobile device. Before data transmission, to accommodate network latency and traffic fluctuations, the rendering data packet can be divided into multiple sub-frames. These sub-frames can be transmitted and loaded independently, thus avoiding the latency and congestion that can occur when transmitting a large rendering data packet at once. The number of sub-frames can be dynamically adjusted according to network conditions to adapt to different network environments and device performance.

[0108] Optionally, on the mobile device, after receiving these frame sub-data, they can be reassembled and parsed according to preset rules and algorithms to recover the complete rendering data packet. These rendering data packets are then used to render historical game events to present the corresponding game visuals and effects.

[0109] The embodiments provided in this application obtain rendering data packets sent by the rendering server to the mobile device via data transmission. The rendering data packets are used to render historical game events. The rendering data packets are divided into a target number of frame sub-data. The target number is matched with the network latency of data transmission, thereby achieving the purpose of balancing and optimizing according to the actual situation, so that the number of segmented frame sub-data matches the network latency, thereby achieving the technical effect of improving game performance and user experience.

[0110] As an alternative approach, after rendering and playing historical game events based on the second game resource, the method also includes:

[0111] Delete the second game resource if the replay save function is disabled in the mobile game;

[0112] Alternatively, if the replay save function is enabled in the mobile game, the second game resource can be saved to the local storage space of the mobile device running the mobile game.

[0113] Optionally, in this embodiment, when saving the second game resource, it can be, but is not limited to, directly saved to the local storage space of the mobile device. This local storage space can be the mobile device's built-in memory or an external storage medium (such as an SD card). Furthermore, to save storage space, the second game resource can be compressed before saving. Various compression algorithms and techniques can be used to reduce the data size and storage space occupied.

[0114] It should be noted that in mobile games, different actions can be taken to handle the second game resource depending on the user's needs and settings. If the replay save function is disabled in the mobile game, the second game resource can be deleted to free up storage space; if the replay save function is enabled in the mobile game, the second game resource can be saved to the local storage space of the mobile device for later use.

[0115] Furthermore, when the replay saving function of mobile games is disabled, secondary game assets may no longer need to be retained on the mobile device. To free up storage space and avoid unnecessary data redundancy, these secondary game assets can be deleted. Deletion can be performed automatically or manually by the user. Before deletion, a backup or tagging of these game assets can be created for restoration if needed.

[0116] On the other hand, when the replay save function of a mobile game is enabled, secondary game resources can be saved to the local storage space of the mobile device. This allows users to conveniently use these game resources when replaying or rewinding the game. To ensure the correctness and integrity of the game resources, the saving operation should be performed in a secure environment, with necessary encryption and protection measures in place.

[0117] Through the embodiments provided in this application, when the replay save function of a mobile game is turned off, the second game resource is deleted; or, when the replay save function of a mobile game is turned on, the second game resource is saved to the local storage space of the mobile device. This achieves the purpose of taking different operations to process the second game resource according to the user's needs and settings, thereby realizing the technical effect of improving the user experience of event replay.

[0118] As an optional solution, for ease of understanding, the above event replay method is applied to the scenario of real-time playback of elimination replays in mobile FPS games based on the UE4 engine. Due to limitations in product and technical capabilities, as well as the cumbersome replay system module of the UE4 engine itself, mobile FPS games based on the UE4 engine currently do not have the function of real-time playback of elimination replays. This embodiment is the first to propose a real-time elimination replay technology for mobile devices, which solves the problem that elimination replays cannot be viewed in real time on UE4 mobile devices.

[0119] Alternatively, the traditional UE4-Replay execution method can be used. After acquiring the memory recording data, a new world is created for each PlayReplay session, and playback begins after loading the map and level. Alternatively, two Worlds can be created at the start of the game: the replay world and the real world. During normal gameplay, both Worlds will exist simultaneously, switching between them when entering an elimination replay. Another option is to use a DuplicateLevelCollection to copy the DynamicLevels of the main level and store them in the same world. However, all these methods are limited to PC platforms due to their high memory and CPU performance overhead, making them unsuitable for mobile devices.

[0120] It should be noted that in FPS games, the battlefield is highly chaotic, there are many gun lines, and skills are strongly linked to eliminations. As a result, there are many reasons for eliminations. New players, who have limited control over the battlefield situation, have a higher demand for elimination replay functions compared to other games.

[0121] The elimination replay in this embodiment can help players clarify the reason for elimination and the location of the eliminated player, reducing the frustration caused by sudden or unknown elimination. In addition, players can learn from the clear reason for elimination to avoid being eliminated for the same reason in the future and think about countermeasures. At the same time, it reduces the negative feedback caused by unknown elimination and allows players to learn from the enemy's operation by watching the elimination perspective.

[0122] In addition, in terms of information presentation, the elimination replay in this embodiment allows players to clearly understand and learn at least one of the following information: who the eliminated player is, the location of both players when the eliminated player eliminates them, the means used by the eliminated player to eliminate them, the preparatory actions of the eliminated player in the period before eliminating them, so that viewers can clearly perceive that this is an elimination scene rather than a spectator's view, thus avoiding confusion.

[0123] Optionally, in this embodiment, the built-in recording system of UE4 provides the ability to save network data. The recording network driver (DemoNetDriver) on the server pushes network synchronization data to the recording streamer (Replay Streamer), which saves the network data as a recording file. On the client side, after obtaining the recording file, this embodiment deserializes it into network data through the Streamer and finally reproduces it as a game scene through the DemoNetDriver.

[0124] Optionally, in this embodiment, the `AcotrPoolSubsystem` object pooling technology is customized for the UE engine. Actor pooling is a design pattern for optimizing performance and resource utilization, typically used to manage and reuse repeatedly created and destroyed objects. Actor pooling allows existing objects to be used where they are needed, avoiding frequent object creation and destruction operations, thus improving system performance and efficiency. The object pool may, but is not limited to, contain a pre-created collection of objects. When an object is needed, a free object is retrieved from the pool and returned to the pool after use, rather than being destroyed. This avoids the overhead of repeatedly creating and destroying objects, saving system resources and reducing memory fragmentation. Using object pooling reduces the frequency of object allocation and garbage collection, thereby reducing system overhead. This is frequently used in game development, web servers, and concurrent programming scenarios to improve performance and response speed.

[0125] Optionally, in this embodiment, level reuse technology is used to achieve sharing and reuse among multiple levels. In game development, there are typically multiple levels or level scenes, each with its own design, map, items, enemies, and other content. However, sometimes some levels may have similar structures or elements, so they can be shared and reused through certain technical means, thereby reducing repetitive work and resource consumption. Through level reuse technology, developers can design and create levels more efficiently, reducing workload and ensuring consistency and quality between levels. Simultaneously, it can also reduce memory usage and loading time, improving game performance and user experience.

[0126] To further illustrate, as shown in Figure 6, upon entering the game, a normal network synchronization driver, IPNetDriver, is created for the network packet synchronization serialization and deserialization process. In the post-elimination spectator interface, as shown in Figure 7, a defeat replay button is added above the elimination list (the button highlighted in white on the right in Figure 7). This defeat replay button is initially grayed out and has a countdown timer; it can only be clicked to enter the elimination replay after the countdown ends.

[0127] Before the countdown ends, the server sends the network data stream recorded by DemoNetDriver to the client cache. Scene switching occurs when playback is needed. To ensure accurate scene restoration during scene switching, this embodiment employs a simple Data Sheet (DS) recording method – the lightweight DemonetDriver. The playback client manages two ChannelLists for isolation, and separates various systems for project business processing to avoid affecting the accuracy of in-game / playback scene data. For example, PlayerState and GameState correspond to relevant System processing.

[0128] Clicking the defeat replay button hides the game objects (Actors) in the normal battle scene before entering the elimination replay, and caches and pauses network packets to ensure the restoration of the normal battle scene. To avoid client-side lag during transitions and reduce performance pressure on the phone, NoLoadingMap reuses the levels from the original normal battle, eliminating unloading and reloading, thus reducing significant performance consumption. Furthermore, this embodiment uses ActorPoolSubsystem-Resue technology to generate game objects (SpawnActors), greatly improving execution efficiency and ultimately enabling rapid switching between the normal battle scene and the replay scene. Moreover, it reduces unnecessary performance overhead caused by redundant business logic, such as useless data in PlayerState and GameState, avoiding the overhead of unnecessary registration and binding. SpawnActors are processed in frames to prevent performance backlog caused by a large number of SpawnActors, which could lead to lag. Since the resources for the normal battle scene have already been preloaded, no further resource loading is needed, avoiding lag caused by resource loading.

[0129] Optionally, in this embodiment, to avoid synchronization lag when the client receives packets due to accumulated traffic from the DS, and to alleviate mobile data usage pressure, the DS performs frame-by-frame transmission of Remote Procedure Call (RPC) messages to prevent the client connection from reaching buffer saturation. Furthermore, after exiting elimination replay, this embodiment cleans up the ChannelList under the DemonetDriver. Previously hidden Actors in the normal combat scene will be displayed, and network packets will be restored to recreate the normal combat scene.

[0130] The embodiments provided in this application provide a technology for real-time elimination playback on mobile devices, which solves the problem that elimination playback cannot be viewed in real time on UE4 mobile devices.

[0131] It is understood that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

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

[0133] According to another aspect of the embodiments of this application, an event playback apparatus for implementing the above-described event playback method is also provided. As shown in FIG8, the apparatus includes:

[0134] The first display unit 802 is used to display the running screen of the mobile game, wherein the running screen is a screen rendered based on the first game resource, and the first game resource is the game resource used by the mobile game when performing the current game.

[0135] The first acquisition unit 804 is used to respond to an event replay request, acquire reusable game resources from the first game resources, and compose a second game resource based on the reusable game resources. The event replay request is used to request the replay of the virtual character's historical game events, and the second game resource is the game resource required for rendering and playing the historical game events.

[0136] Playback unit 806 is used to render and play historical game events based on the second game resource when the current game is in progress on the mobile device.

[0137] For specific implementation examples, please refer to the example shown in the event playback device above, which will not be repeated here.

[0138] As an optional solution, the device also includes:

[0139] The second display unit is used to display the event replay control when the historical game event is in an ended state, before retrieving reusable game resources from the first game resource in response to the event replay request and assembling the second game resource based on the reusable game resources. The historical game event in the ended state is set to be unchangeable.

[0140] The second acquisition unit is used to initiate an event replay request in response to a replay trigger operation performed based on the event replay control before acquiring reusable game resources from the first game resources in response to the event replay request and assembling the second game resources based on the reusable game resources.

[0141] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0142] As an optional solution, the device also includes:

[0143] The third display unit is used to display the event playback control in the prohibited operation state and the countdown time of the prohibited operation state during the display of the event playback control. The event playback control in the prohibited operation state is set to prevent the execution of playback trigger operation.

[0144] The fourth display unit is used to display the event playback control in the allowed operation state when the countdown timer of the prohibited operation state is cleared during the display of the event playback control. The event playback control in the allowed operation state is set to allow the execution of playback trigger operations.

[0145] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0146] As an optional solution, the first acquisition unit 804 includes at least one of the following:

[0147] The first acquisition module is used to acquire reusable scene resources from the first game resources, wherein the scene resources are the resources required to render the game scene of the current game.

[0148] The second acquisition module is used to acquire reusable object resources from the first game resources, wherein the object resources are the resources required to render game objects related to historical game events in the current game.

[0149] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0150] As an optional solution, the second acquisition module includes:

[0151] The Get submodule is used to retrieve the object resources required for rendering game objects related to historical game events from the game object pool, where the game object pool is used to manage reusable object resources.

[0152] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0153] As an optional solution, the device also includes:

[0154] An isolation unit is used to isolate the game resources used during normal gameplay of the mobile game and the game resources required for playing any historical game event of the mobile game before reusing game resources are obtained from the first game resources. Normal gameplay includes the current game, and any historical game event includes historical game events.

[0155] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0156] As an optional solution, the device further includes: a creation unit for creating game resources used during normal gameplay of the mobile game and game resources required when the mobile game plays any historical game event, and creating a first channel list and a second channel list before data isolation, wherein the first channel list is used to store and manage game resources used during normal gameplay of the mobile game, and the second channel list is used to store and manage game resources required when the mobile game plays any historical game event;

[0157] The isolation unit includes an isolation module for data isolation of the game resources stored in the first channel list and the second channel list respectively.

[0158] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0159] As an optional solution, the first acquisition unit 804 includes:

[0160] The elimination module is used to eliminate replay redundant resources from reusable game resources to obtain a second game resource, wherein the resource similarity between the replay redundant resource and the game resource required to play historical game events is less than or equal to a preset threshold.

[0161] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0162] As an optional solution, the device also includes:

[0163] The third acquisition unit is used to acquire the game performance parameters of the mobile device running the mobile game during the process of rendering and playing historical game events based on the second game resources. The game performance parameters are used to evaluate the performance indicators of the mobile device when running the mobile game.

[0164] The frame segmentation unit is used to perform frame segmentation processing on the second game resources based on game performance parameters during the rendering and playback of historical game events based on the second game resources. This limits the amount of data from the second game resources used to render each frame of the game screen when playing historical game events, and the amount of data is matched with the game performance parameters.

[0165] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0166] As an optional solution, the device also includes:

[0167] The fourth acquisition unit is used to acquire the rendering data packets sent by the rendering server to the mobile device running the mobile game during the rendering and playback of historical game events based on the second game resources. The rendering data packets are used to render historical game events and are divided into a target number of frame sub-data, the target number of which matches the network latency of the data transmission.

[0168] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0169] As an optional solution, the device also includes:

[0170] The management unit is used to delete the second game resource after rendering and playing historical game events based on the second game resource, if the replay save function of the mobile game is turned off; or, if the replay save function of the mobile game is turned on, save the second game resource to the local storage space of the mobile device running the mobile game.

[0171] For specific implementation examples, please refer to the examples shown in the event playback method above. These examples will not be repeated here.

[0172] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described event playback method is also provided. The electronic device may be, but is not limited to, the user device 102 or the server 112 shown in FIG1. ​​This embodiment takes the user device 102 as an example for illustration. Further as shown in FIG9, the electronic device includes a memory 902 and a processor 904. The memory 902 stores a computer program, and the processor 904 is configured to execute the steps in any of the above-described method embodiments through the computer program.

[0173] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0174] Optionally, in this embodiment, the processor can be configured to execute the event playback method via a computer program.

[0175] Optionally, those skilled in the art will understand that the structure shown in FIG9 is merely illustrative and does not limit the structure of the electronic device described above. For example, the electronic device may also include more or fewer components (such as network interfaces) than shown in FIG9, or have a different configuration than shown in FIG9.

[0176] The memory 902 can be used to store software programs and modules, such as the program instructions / modules corresponding to the real-time playback method and device for event playback in this embodiment. The processor 904 executes various functional applications and data processing by running the software programs and modules stored in the memory 902, thereby realizing the aforementioned real-time playback method for event playback. The memory 902 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 902 may further include memory remotely located relative to the processor 904, and these remote memories can be connected to electronic devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 902 may be used, but is not limited to, to store information such as running screens, first game resources, and second game resources. As an example, as shown in FIG9, the memory 902 may include, but is not limited to, the first display unit 802, the first acquisition unit 804, and the playback unit 806 in the aforementioned real-time playback device for event playback. In addition, other module units in the real-time playback device for the aforementioned event replay may also be included, but will not be described in detail in this example.

[0177] Optionally, the transmission device 906 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 906 includes a Network Interface Controller (NIC), which can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 906 is a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0178] In addition, the aforementioned electronic device also includes: a display 908 for displaying information such as the aforementioned running screen, the first game resource, and the second game resource; and a connection bus 910 for connecting the various module components in the aforementioned electronic device.

[0179] In other embodiments, the aforementioned user equipment or server can be a node in a distributed system, wherein the distributed system can be a blockchain system, which is a distributed system formed by connecting multiple nodes through network communication. The nodes can form a peer-to-peer network, and any form of computing device, such as a server, user equipment, or other electronic device, can become a node in the blockchain system by joining this peer-to-peer network.

[0180] According to one aspect of this application, a computer program product is provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions provided in embodiments of this application.

[0181] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0182] It should be noted that the computer system of the electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0183] A computer system includes a Central Processing Unit (CPU), which performs various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) or loaded from RAM. ROM also stores various programs and data required for system operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output interfaces (I / O interfaces) are also connected to the bus.

[0184] The following components are connected to the input / output interface: input sections including keyboards, mice, etc.; output sections including cathode ray tubes (CRTs), liquid crystal displays (LCDs), and speakers; storage sections including hard drives; and communication sections including network interface cards such as LAN cards and modems. The communication section performs communication processing via a network such as the Internet. Drives are also connected to the input / output interface as needed. Removable media, such as disks, optical discs, magneto-optical discs, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage section as required.

[0185] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions defined in the system of this application.

[0186] According to one aspect of this application, a computer-readable storage medium is provided, wherein a processor of a computer device reads computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the computer device to perform the methods provided in the various alternative implementations described above.

[0187] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the event playback method described above.

[0188] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware of an electronic device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0189] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0190] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned 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 one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

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

[0192] In the several embodiments provided in this application, it should be understood that the disclosed user equipment can be implemented in other ways. The device embodiments described above are merely illustrative; for example, 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 displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0193] 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.

[0194] 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.

[0195] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An event playback method, executed by an electronic device, comprising: Displays the running screen of a mobile game, wherein the running screen is a screen rendered based on a first game resource, and the first game resource is the game resource used by the mobile game during the current game. In response to an event replay request, reusable game resources are obtained from the first game resources, and a second game resource is formed based on the reusable game resources. The event replay request is used to request the replay of historical game events of the virtual character, and the second game resource is the game resource required for rendering and playing the historical game events. During the current game on the mobile device, the historical game events are rendered and played based on the second game resource.

2. The method according to claim 1, prior to obtaining reusable game resources from the first game resources in response to an event replay request, and assembling a second game resource based on the reusable game resources, the method further includes: When the historical game event is in an ended state, the event replay control is displayed, wherein the historical game event in the ended state is set to be unchangeable; In response to a playback trigger operation performed based on the event playback control, the event playback request is initiated.

3. The method according to claim 2, wherein during the process of displaying the event playback control, the method further includes: The event playback control is displayed in a disabled state, and a countdown time for the disabled state, wherein the event playback control in the disabled state is set to disable the playback trigger operation; When the countdown timer for the prohibited operation state is cleared, the event playback control in the allowed operation state is displayed, wherein the event playback control in the allowed operation state is set to allow the execution of the playback trigger operation.

4. The method according to any one of claims 1 to 3, wherein obtaining reusable game resources from the first game resources comprises at least one of the following: Obtain reusable scene resources from the first game resource, wherein... The scene resources are the resources required to render the game scene of the current match; Reusable object resources are obtained from the first game resources, wherein the object resources are the resources required to render game objects related to the historical game events in the current game.

5. The method according to claim 4, wherein obtaining reusable object resources from the first game resources comprises: The game object pool is used to manage reusable object resources, which are obtained from the game object pool when rendering game objects related to the historical game events.

6. The method according to any one of claims 1 to 5, wherein before obtaining reusable game resources from the first game resource, the method further comprises: The game resources used during a normal game on the mobile device are isolated from the game resources required when the mobile device plays any historical game event. The normal game includes the current game, and any historical game event includes the historical game event.

7. The method according to claim 6, before performing data isolation between the game resources used during normal gameplay of the mobile game and the game resources required when the mobile game plays any historical game event, the method further includes: Create a first channel list and a second channel list, wherein the first channel list is used to store and manage game resources used by the mobile game during normal gameplay, and the second channel list is used to store and manage game resources required by the mobile game when playing any historical game event; The data isolation of game resources used during normal gameplay on the mobile device and game resources required when the mobile device plays any historical game event includes: The game resources stored in the first channel list and the second channel list are isolated.

8. The method according to any one of claims 1 to 7, wherein composing the second game resource based on the reusable game resource comprises: The replay redundant resources are removed from the reusable game resources to obtain the second game resource, wherein the resource similarity between the replay redundant resources and the game resources required to play the historical game events is less than or equal to a preset threshold.

9. The method according to any one of claims 1 to 8, wherein during the process of rendering and playing the historical game event based on the second game resource, the method further comprises: Obtain the game performance parameters of the mobile device running the mobile game, wherein the game performance parameters are used to evaluate the performance indicators of the mobile device when running the mobile game; Based on the game performance parameters, the second game resource is processed by frame segmentation to limit the amount of data of the second game resource used to render each frame of the game screen when playing the historical game events, wherein the amount of data is matched with the game performance parameters.

10. The method according to any one of claims 1 to 9, wherein during the process of rendering and playing the historical game event based on the second game resource, the method further comprises: The rendering server obtains rendering data packets sent to the mobile device running the mobile game via data transmission. The rendering data packets are used to render the historical game events. The rendering data packets are divided into a target number of frame sub-data, the target number being matched with the network latency of the data transmission.

11. The method according to any one of claims 1 to 10, after rendering and playing the historical game event based on the second game resource, the method further includes: If the replay saving function is disabled in the mobile game, delete the second game resource; Alternatively, if the replay save function is enabled in the mobile game, the second game resource can be saved to the local storage space of the mobile device running the mobile game.

12. An event playback device, comprising: The first display unit is used to display the running screen of the mobile game, wherein the running screen is a screen rendered based on the first game resource, and the first game resource is the game resource used by the mobile game in the current game. The first acquisition unit is configured to, in response to an event replay request, acquire reusable game resources from the first game resources and compose a second game resource based on the reusable game resources, wherein the event replay request is used to request the replay of historical game events of the virtual character, and the second game resource is the game resource required for rendering and playing the historical game events; The playback unit is used to render and play the historical game events based on the second game resource when the current game is in progress on the mobile game.

13. A computer-readable storage medium comprising a stored program, wherein, The program is executed by the electronic device to perform the method described in any one of claims 1 to 11.

14. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method described in any one of claims 1 to 11.

15. An electronic device comprising a memory and a processor, the memory storing a computer program, the processor being configured to perform the method of any one of claims 1 to 11 via the computer program.

Images