Object loading method, apparatus, computer-readable medium, and electronic device

Abstract

The application provides an object loading method and device, a computer readable medium and an electronic device. The method comprises: when a target movable object needs to be loaded in a target scene, obtaining the target movable object from an object buffer pool comprising at least one movable object, wherein the objects in the object buffer pool are partial objects that can be loaded in the target scene, and the movable object is an object that can move in the target scene; and loading object resources corresponding to the target movable object according to the target movable object. The scheme protected in the application can significantly alleviate the terminal freezing problem and reduce the consumption of memory.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and more specifically, to an object loading method, apparatus, computer-readable medium, and electronic device. Background Technology

[0002] When rendering large-scale scenes on a terminal, the objects in the viewport need to constantly change as the character moves. Therefore, objects in the scene need to be created and destroyed repeatedly, which incurs additional time overhead and can cause lag on the terminal. Summary of the Invention

[0003] The embodiments of this application provide an object loading method, apparatus, computer-readable medium, and electronic device, which can significantly alleviate terminal lag problems to at least a certain extent and reduce memory consumption.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, an object loading method is provided, the method comprising: when it is necessary to load a target movable object in a target scene, obtaining the target movable object from an object buffer pool including at least one movable object, wherein the objects in the object buffer pool are a portion of objects that can be loaded in the target scene, and the movable object is an object that can be moved in the target scene; and loading object resources corresponding to the target movable object according to the target movable object.

[0006] According to one aspect of the embodiments of this application, an object loading apparatus is provided, the apparatus comprising: an object acquisition unit, configured to acquire the target movable object from an object buffer pool including at least one movable object when it is necessary to load the target movable object in a target scene, wherein the objects in the object buffer pool are a subset of objects that can be loaded in the target scene, and the movable object is an object that can be moved in the target scene; and a resource loading unit, configured to load object resources corresponding to the target movable object according to the target movable object.

[0007] In some embodiments of this application, based on the foregoing scheme, the object acquisition unit is configured to: when it is necessary to load a target movable object of the target type in the target scene, determine the target object buffer pool of the target type from the object buffer pools of each type; and acquire the target movable object from the target object buffer pool.

[0008] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a buffer pool creation unit; before determining that a target movable object needs to be loaded in the target scene, the buffer pool creation unit is used to: create at least one type of object buffer pool, each type of object buffer pool including at least one object belonging to the type, and the at least one type of object buffer pool including a target object buffer pool of the target type.

[0009] In some embodiments of this application, based on the foregoing scheme, the buffer pool creation unit is configured to: obtain the priority corresponding to each type of object, wherein the priority corresponding to each type of object is one of multiple priorities with different levels, and the priority corresponding to each type of object is determined by any of the following methods: determining the priority corresponding to the current type of object based on the loading frequency obtained from historical statistics of objects of the current type; determining the priority corresponding to the current type of object based on the distance between the current type of object and the location of a specified object; determining the priority corresponding to the current type of object based on the loading frequency obtained from historical statistics of objects of the current type and the distance between the current type of object and the location of a specified object; determining the creation probability of the object buffer pool corresponding to each type based on the priority corresponding to each type of object, wherein the level of priority is positively correlated with the creation probability of the corresponding object buffer pool; determining the type of object buffer pool to be created based on the creation probability of the object buffer pool corresponding to each type, and creating at least one type of object buffer pool according to the determined type.

[0010] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes an overall object release unit; after creating at least one type of object buffer pool, the overall object release unit is used to: release objects in each type of object buffer pool so that the objects in each type of object buffer pool are in an unused state.

[0011] In some embodiments of this application, based on the foregoing scheme, the device further includes an object release unit; after loading the object resources corresponding to the target movable object according to the target movable object, the object release unit is used to: release the target movable object in the target object buffer pool when it is necessary to unload the target movable object, so that the target movable object is in an unused state.

[0012] In some embodiments of this application, based on the foregoing scheme, after loading the object resources corresponding to the target movable object according to the target movable object, the overall object release unit is further configured to: when it is necessary to unload all movable objects belonging to the target type, release all movable objects in the target object buffer pool as a whole, so that all movable objects in the target object buffer pool, including the target movable object, are in an unused state.

[0013] In some embodiments of this application, based on the foregoing scheme, after creating at least one type of object buffer pool, the overall object release unit is further configured to: determine the release probability of each type of object buffer pool according to the priority corresponding to each type of object, wherein the priority is negatively correlated with the release probability of the corresponding object buffer pool; determine the object buffer pool to which the object to be unloaded belongs based on the release probability of each type of object buffer pool; and perform overall release of all movable objects in each determined object buffer pool so that each movable object in each object buffer pool is in an unused state.

[0014] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a reset unit; after creating at least one type of object buffer pool, the reset unit is used to: reset the target object buffer pool in the at least one type of object buffer pool to release the memory space occupied by each object in the target object buffer pool.

[0015] In some embodiments of this application, based on the foregoing scheme, each of the object buffer pools includes a list of available objects and a list of used objects; the object acquisition unit is configured to: remove the target movable object from the list of available objects in the target object buffer pool; and add the target movable object to the list of used objects in the target object buffer pool.

[0016] In some embodiments of this application, based on the foregoing scheme, the object release unit is configured to: remove the target movable object from the list of used objects in the target object buffer pool; and add the target movable object to the list of available objects in the target object buffer pool.

[0017] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the object loading method as described in the above embodiments.

[0018] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the object loading method as described in the above embodiments.

[0019] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions, causing the computer device to perform the object loading method as described in the above embodiments.

[0020] In some embodiments of this application, when a target movable object needs to be loaded in the target scene, the target movable object is obtained from the object buffer pool. However, the object resources corresponding to the target movable object are loaded according to the target movable object. Since the solution of this application uses the object buffer pool to manage and reuse a set of pre-allocated objects, when the object is no longer needed, it is returned to the object buffer pool instead of being destroyed. This can reduce the overhead caused by frequent creation and destruction of objects, improve the performance of the application, and significantly alleviate the lag problem of the terminal. At the same time, since the objects in the object buffer pool are only some of the objects that can be loaded in the target scene, and the object buffer pool includes movable objects, the position of movable objects in the target scene changes more frequently than that of non-movable objects. Therefore, if the object buffer pool is not used, more frequent creation and destruction are required. Therefore, by managing and reusing only the movable objects that can be loaded in the target scene in the object buffer pool, the lag problem of the terminal can be effectively reduced while reducing memory consumption.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0023] Figure 1 A schematic diagram illustrating the principle of performance optimization for large-world objects in related technologies is shown;

[0024] Figure 2 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown;

[0025] Figure 3 A flowchart of an object loading method according to an embodiment of this application is shown;

[0026] Figure 4 An embodiment according to this application is shown. Figure 3 A flowchart of the steps preceding step 330 in the embodiment;

[0027] Figure 5 A schematic diagram of the overall process for performance optimization of moving objects based on an object buffer pool according to an embodiment of this application is shown.

[0028] Figure 6 A flowchart illustrating the initialization of a mobile object buffer management system according to an embodiment of this application is shown;

[0029] Figure 7 A flowchart illustrating the creation of an underlying mobile object buffer pool according to one embodiment of this application is shown;

[0030] Figure 8 An embodiment according to this application is shown. Figure 4 A flowchart of the steps following step 310 in the embodiment;

[0031] Figure 9 An embodiment according to this application is shown. Figure 4 A flowchart detailing step 330 in the embodiment;

[0032] Figure 10 An embodiment according to this application is shown. Figure 9 A flowchart detailing step 332 in the embodiment;

[0033] Figure 11 A flowchart illustrating the creation and acquisition of a mobile object according to an embodiment of this application is shown;

[0034] Figure 12 An embodiment according to this application is shown. Figure 10 A flowchart of the steps following step 340 in the embodiment;

[0035] Figure 13 An embodiment according to this application is shown. Figure 12 A flowchart detailing step 350 in the embodiment;

[0036] Figure 14 This diagram illustrates a comparison of performance data regarding lag issues between related technical solutions and the solutions presented in this application.

[0037] Figure 15 A block diagram of an object loading apparatus according to an embodiment of this application is shown;

[0038] Figure 16 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0039] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0040] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0041] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0042] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0043] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0044] Open-world games are a genre characterized by providing a vast, open game world for players to freely explore. Players can freely choose their routes, task order, and exploration methods, rather than following a fixed linear path. This type of game typically features rich environments, diverse quests, and complex systems, offering players a high degree of freedom and immersion.

[0045] Figure 1 A schematic diagram illustrating the principle of performance optimization for large-world objects in related technologies is shown. Please refer to [link / reference]. Figure 1 As shown, the main process for optimizing performance in open-world games is as follows: After completing the development of resource objects such as characters and vehicles, PerfDog data recording is performed based on acceptance test scenarios. If the overall lag rate is found to be high, Stat recording analysis is performed to view specific lag function records. Generally, instantaneous lag is caused by issues such as forced loading of various characters. After completing the lag analysis, the developers will attempt to optimize, usually by enabling lazy loading and other optimization methods for resources that are forced to load. Then, a new round of iterations is started until the target is met.

[0046] Therefore, when using this related technology for performance optimization to address stuttering, when stuttering occurs, personnel need to build a debug version to record performance data (Stat) for the stuttering scenario. The entire process from analysis to optimization takes a long time, making the overall development process very time-consuming and requiring a high level of experience from the relevant personnel. To prevent stuttering caused by forced loading, the optimization method used in this technology is to perform lazy loading of the resource. This can lead to incomplete resource display or various white-mimicking resources when the object moves too fast. Incomplete resource display means that the object resource is not displayed completely, while white-mimicking resources mean that although the object resource is fully displayed, a part of it is incorrectly displayed as white. Therefore, the overall effect of using this related technology for performance optimization to address stuttering is very poor.

[0047] To address this, this application first provides an object loading method. The object loading method provided by this application overcomes the aforementioned deficiencies in related technologies. By creating a buffer for moving objects, object buffers such as characters and vehicles are pre-created at the start of the game. When various objects are being created in the field of view, they only need to be directly retrieved from the buffer pool for assignment, avoiding lag during creation. When an object is no longer needed, it is returned to the buffer pool instead of being destroyed, avoiding the time consumption of destroying various objects and preventing white model display caused by untimely resource creation. Furthermore, no manual troubleshooting or optimization is required, significantly reducing labor costs.

[0048] Figure 2 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown. Please refer to... Figure 2 As shown, the system architecture 200 may include multiple user terminals and a backend server 240. Specifically, the multiple user terminals may include a first user terminal 210, a second user terminal 220, and a third user terminal 230. Users of different user terminals are different players in the large-scale game. Each user terminal establishes a communication connection with the backend server 240, enabling each user terminal to interact with the backend server 240. The backend server 240 deploys the server-side software for the large-scale game, while each user terminal deploys a client-side software for the large-scale game that can access the server-side software. Each user terminal can serve as the execution subject of the scheme in this application embodiment. Taking the first user terminal 210 as an example, when the object loading method provided in this application embodiment is applied... Figure 2In the system architecture shown, a process can be as follows: First, the user of the first user terminal 210 requests entry into the island battle scene of the game by operating the client of the open-world game deployed on the first user terminal 210. In this island battle scene, the user can control a character with attack equipment to fight against other user-controlled characters with attack equipment. Then, the first user terminal 210 creates a character object buffer pool containing multiple character objects, a vehicle object buffer pool containing multiple vehicle objects, and an attack equipment object buffer pool containing multiple attack equipment objects, and releases the objects in these object buffer pools. Next, when entering the island battle scene, since the character object to be controlled by the user needs to be loaded, a character object is immediately obtained from the character object buffer pool, and the corresponding game resources of the character object are loaded. Then, the user can control the character to move in the island battle scene. Whenever another object needs to enter the field of vision of the user-controlled character, it needs to be retrieved from the corresponding buffer pool. The system retrieves the corresponding objects from the object buffer pool. For example, when an attack equipment item enters the field of view of a user-controlled character, an attack equipment object needs to be retrieved from the attack equipment object buffer pool. The user can then deploy the attack equipment corresponding to this attack equipment object onto their controlled character. When another user-controlled character holding an attack equipment item enters the field of view of the user-controlled character, a new character object needs to be retrieved from the character object buffer pool, and a new attack equipment object needs to be retrieved from the attack equipment object buffer pool. The game resources corresponding to the new character object and the new attack equipment object, i.e., the game resources corresponding to the other user-controlled character holding the attack equipment, are loaded respectively. Finally, when the other user-controlled character holding the attack equipment item leaves the field of view of the user-controlled character, the corresponding character object in the character object buffer pool and the corresponding attack equipment object in the attack equipment object buffer pool are released, allowing the character object and the attack equipment object to be retrieved again.

[0049] In some embodiments of this application, the aforementioned open-world game includes multiple modes, and the island battle scenario belongs to the target mode of the open-world game.

[0050] In some embodiments of this application, when the battle in the island battle scene ends, the first user terminal 210 will reset the already created character object buffer pool, vehicle object buffer pool and attack equipment object buffer pool to release the memory space occupied by these object buffer pools.

[0051] In some embodiments of this application, the first user terminal 210, the second user terminal 220, and the third user terminal 230 simultaneously enter the same instance of the same island battle scene in the open-world game.

[0052] In some embodiments of this application, the first user terminal 210, the second user terminal 220, and the third user terminal 230 respectively enter different instances of the same island battle scene in the open-world game.

[0053] In some embodiments of this application, the first user terminal 210, the second user terminal 220, and the third user terminal 230 are simultaneously in different scenes of the large-scale game.

[0054] In some embodiments of this application, the number of buffer pools created by the same user terminal when requesting to enter different scenes of the large-scale game is different.

[0055] In some embodiments of this application, the number of objects created in the same type of object buffer pool differs when the same user terminal requests to enter different scenes of the large-scale game.

[0056] In some embodiments of this application, the number of buffer pools created by different user terminals when requesting to enter the same scene of the large-scale game is different.

[0057] In some embodiments of this application, when different user terminals request to enter the same scene of the large-scale game, the number of objects created in the same type of object buffer pool is different.

[0058] In some embodiments of this application, different user terminals are smartphones at different price points.

[0059] In some embodiments of this application, the character objects, attack equipment objects, and vehicle objects in the created object buffer pools are some of the movable objects that can be loaded in the island battle scene.

[0060] It should be noted that, Figure 2 The example shown is only one embodiment of this application. Although Figure 2 The solution in this embodiment is applied to the gaming field, but in other embodiments of this application, it can also be applied to other fields such as virtual reality and smart healthcare; although Figure 2 The solution in this embodiment is applied to open-world games in the gaming field, but in other embodiments of this application, it can also be applied to other types of games; although Figure 2 The solution in this embodiment is applied to the island battle scenario in the game, but in other embodiments of this application, it can also be applied to other game scenarios of the same game; although in Figure 2In the embodiments of this application, all user terminals are smartphones. However, in other embodiments, the user terminals may also be laptops, tablets, portable wearable devices, vehicle terminals, etc., and different user terminals may have different terminal types. Figure 2 In the embodiment of the scheme, the server-side of the game is deployed on a backend server, but in other embodiments of this application, it may also be deployed in the cloud or on a server cluster. This application does not limit the scope of protection in any way, nor should it restrict the scope of protection of this application.

[0061] It should be understood that Figure 2 The number of user terminals and backend servers shown is merely illustrative. Depending on implementation needs, there can be any number of user terminals and backend servers. That is, there can be multiple user terminals, and the backend servers can be a server cluster consisting of multiple servers.

[0062] As is readily understood, the object loading method provided in this application embodiment is generally executed by a user terminal, and correspondingly, the object loading device is generally located in the user terminal. However, in other embodiments of this application, the server may also have similar functions to the user terminal, thereby executing the object loading scheme provided in this application embodiment.

[0063] Therefore, the embodiments of this application can be applied to terminals or servers. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions.

[0064] The object loading method provided in this application can be applied to various fields and games. Below, we will use the object loading method provided in this application as an example in a large-scale game. The implementation details of the technical solution in this application are described in detail below:

[0065] Figure 3A flowchart of an object loading method according to an embodiment of this application is shown. This object loading method can be executed by various devices with processing and computing capabilities. Specifically, it can be executed by a computer device, such as a user terminal or a cloud server. User terminals include, but are not limited to, smartphones, tablets, laptops, smart home appliances, in-vehicle terminals, aircraft, smartwatches, etc. Please refer to... Figure 3 As shown, the object loading method includes at least the following steps:

[0066] Step 330: When it is necessary to load a target movable object in the target scene, retrieve the target movable object from an object buffer pool that includes at least one movable object. The objects in the object buffer pool are some of the objects that can be loaded in the target scene, and the movable object is an object that can be moved in the target scene.

[0067] Before going into detail about step 330, let’s first go into the steps that precede step 330.

[0068] Figure 4 An embodiment according to this application is shown. Figure 3 A flowchart of the steps preceding step 330 in this embodiment. Please refer to [link / reference]. Figure 4 As shown, before determining that a target movable object needs to be loaded into the target scene, the object loading method may include the following steps:

[0069] In step 310, an object buffer pool of at least one type is created, each type of object buffer pool includes at least one object belonging to that type, and the object buffer pool of at least one type includes a target object buffer pool of the target type.

[0070] Each type of object buffer pool is used to buffer objects belonging to the corresponding type. Specifically, to reduce terminal lag and memory consumption, each type of object buffer pool is used to buffer movable objects belonging to the corresponding type. The target object buffer pool of the target type can be used to store movable objects belonging to the target type. An object buffer pool of a type can be a single object buffer pool, and different object buffer pools (object buffer pools of different types) can contain the same or different numbers of objects. Object buffer pools corresponding to each of one or more types can be created.

[0071] Each type of object buffer pool is used to buffer game objects belonging to the corresponding type.

[0072] For example, you can create a character object pool that includes multiple character objects, a vehicle object pool that includes multiple vehicle objects, and an attack equipment object pool that includes multiple attack equipment objects.

[0073] Character objects are the characters that users can control in the open-world game; vehicle objects are the vehicles that characters can ride in or drive; and attack equipment objects are the tools that users use to control their characters in combat. The type corresponding to the character object buffer pool is "character," and the type corresponding to the vehicle object buffer pool is "vehicle."

[0074] Creating an object pool of at least one type can be an operation performed at the start of a game, such as when entering the target scene of a large-scale game; of course, creating an object pool of at least one type can also be an operation performed during combat in the game.

[0075] In this embodiment of the application, by pre-creating the object buffer pool, the creation of the object buffer pool is avoided when it is needed, which can effectively reduce the lag phenomenon.

[0076] In one embodiment of this application, creating at least one type of object buffer pool includes: obtaining the priority corresponding to each type of object, wherein the priority corresponding to each type of object is one of multiple priorities with different levels, and the priority corresponding to each type of object is determined by any of the following methods: determining the priority corresponding to the current type of object based on the loading frequency obtained from historical statistics of objects of the current type; determining the priority corresponding to the current type of object based on the distance between the current type of object and the location of a specified object; determining the priority corresponding to the current type of object based on the loading frequency obtained from historical statistics of objects of the current type and the distance between the current type of object and the location of a specified object; determining the creation probability of the object buffer pool corresponding to each type based on the priority corresponding to each type of object, wherein the level of priority is positively correlated with the creation probability of the corresponding object buffer pool; determining the type of object buffer pool to be created based on the creation probability of the object buffer pool corresponding to each type, and creating at least one type of object buffer pool according to the determined type.

[0077] The priority level for each type of object can be one of the following: high priority, medium priority, or low priority.

[0078] The priority of each object type can be determined by statistically analyzing the historical loading frequency of objects of that type. A higher priority for an object type indicates a higher historical loading frequency of that type. In other words, priority can be a tiered ranking of loading frequencies based on different object types.

[0079] In open-world games, the loading frequencies for different types of objects are shown in Table 1:

[0080] Loading frequency level object High loading frequency Vehicle objects, character objects Medium loading frequency Attack equipment object, backpack object low loading frequency Accessory items, helmet items

[0081] Table 1

[0082] The historical loading frequency of each object type can be categorized as high, medium, or low. Therefore, if an object type has a high loading frequency, its priority can be determined as high; if it has a medium loading frequency, its priority as medium; and if it has a low loading frequency, its priority as low.

[0083] The priority of each object type can also be determined based on the distance between the corresponding object and the specified object. Specifically, the priority of an object of a certain type can be determined based on the statistical results of the distance between the current object of that type and the specified object. The specified object can be the current role.

[0084] For example, if the average distance between an object of a certain type and the current character's position is greater than the first distance, its priority can be defined as low priority; if the average distance between an object of a certain type and the current character's position is between the second and first distances, its priority can be defined as medium priority; and if the average distance between an object of a certain type and the current character's position is less than the second distance, its priority can be defined as high priority. Here, the first distance is greater than the second distance.

[0085] The correspondence between priority and type of object and the distance interval to which the average distance between the current character's position belongs can be shown in Table 2:

[0086]

[0087] Table 2

[0088] After obtaining the average distance between the current type of object and the current role's position, the priority of that type of object can be determined by looking up Table 2.

[0089] The specific methods for determining the priority of objects of the current type based on historical statistics of loading frequency and the distance between the current type of object and the specified object can be varied.

[0090] For example, the first candidate priority of the current type of object can be determined based on the loading frequency obtained from historical statistics of the current type of object; the second candidate priority of the current type of object can be determined based on the distance between the current type of object and the location of the specified object; and the priority corresponding to the current type of object can be determined based on the first candidate priority and the second candidate priority.

[0091] Specifically, the higher priority among the first and second candidate priorities can be used as the priority of the current type of object, or the lower priority among the first and second candidate priorities can be used as the priority of the current type of object.

[0092] Alternatively, the priority of an object of the current type can be determined by querying a mapping table of loading frequency, distance range, and priority based on the historical loading frequency of objects of the current type and the distance between the current type of object and the specified object.

[0093] The mapping relationship between loading frequency, distance range, and priority is shown in Table 3:

[0094]

[0095] Table 3

[0096] In Table 3, loading frequency is the statistical result of the historical loading frequency of an object of a certain type, and distance interval is the distance interval to which the average distance between the current object of a certain type and the current character's position belongs.

[0097] Alternatively, you can first map the loading frequency obtained from historical statistics of objects of the current type to a loading frequency score, and then map the distance between the current type of object and the location of a specified object to a distance score. Then, calculate the weighted sum of the loading frequency score and the distance score, and finally determine the priority of the current type of object based on the weighted sum interval to which the weighted sum belongs.

[0098] Mapping historical load frequencies of objects of the current type to load frequency scores can be done by using a predefined mapping relationship, where load frequency tiers are mapped to load frequency scores. For example, a load frequency score of 5 can be defined for high load frequencies, 3 for medium load frequencies, and 1 for low load frequencies.

[0099] The specific method for mapping the distance between the current type of object and the location of the specified object to a distance fraction can be as follows: if the distance between the current type of object and the location of the specified object is 60 meters, then the distance is mapped to a distance fraction of 5; if the distance between the current type of object and the location of the specified object is less than 60 meters, then the distance between the current type of object and the location of the specified object is divided by 12 to obtain the distance fraction.

[0100] The correspondence between each weighted sum interval and priority can be pre-defined. Based on this correspondence, the priority of the current type of object can be determined according to the weighted sum interval to which the weighted sum belongs.

[0101] For example, the priority corresponding to the weighted sum interval (0,4] can be defined as low priority, the priority corresponding to the weighted sum interval (4,7) can be defined as medium priority, and the priority corresponding to the weighted sum interval [7,10) can be defined as high priority.

[0102] The creation probability of an object pool can be a real number in the range [0,1]. For example, the creation probability of an object pool for a high-priority object type can be 0.8, for a medium-priority object type can be 0.5, and for a low-priority object type can be 0.2.

[0103] Whether an object buffer pool of each type needs to be created can be randomly determined based on the creation probability of the corresponding object buffer pool. Therefore, the object buffer pool for the type of a high-priority object is more likely to be created, while the object buffer pool for the type of a low-priority object is less likely to be created.

[0104] In one embodiment of this application, creating an object buffer pool of at least one type includes: creating an object buffer pool of the corresponding type for all types of movable objects that can be loaded in the target scene.

[0105] For example, if only 5 types of movable objects can appear in the target scene, then create object buffer pools for these 5 types respectively, and use them to buffer movable objects of the corresponding types.

[0106] In one embodiment of this application, creating an object buffer pool of at least one type includes: creating an object buffer pool of a corresponding type for each type of movable object that can be loaded in the target scene.

[0107] For example, if there are 10 types of movable objects in the target scene, then corresponding object buffer pools can be created for 6 of these types of movable objects. That is, 6 object buffer pools are created to buffer the corresponding types of movable objects.

[0108] Specifically, when creating object buffer pools for different types of movable objects that can be loaded in the target scene, the loading frequency of each type of movable object can be determined by statistically analyzing the movable objects loaded in the target scene within a predetermined time period, either historically or before the current time. Then, based on the loading frequency of each type of movable object, it can be determined which types of movable objects need to have their corresponding object buffer pools created. For example, movable objects of each type can be sorted from highest to lowest loading frequency, and a predetermined number of movable objects at the top can be selected as the movable objects for which corresponding object buffer pools need to be created. Alternatively, movable objects with loading frequencies higher than a predetermined loading frequency threshold can also be selected as the movable objects for which corresponding object buffer pools need to be created.

[0109] In one embodiment of this application, creating an object buffer pool of at least one type includes: determining the type of the terminal; determining the type of object buffer pool to be created based on the type of the terminal; and creating the corresponding object buffer pool according to the determined type.

[0110] Specifically, the terminal type can be a terminal tier, such as high-end, mid-range, and low-end. The terminal tier can be determined by the terminal model, or by parameters such as the terminal's processor model, memory type, and memory size. For high-end terminals, a first number of object buffer pools of a certain type can be created; for mid-range terminals, a second number of object buffer pools of a certain type can be created; and for low-end terminals, a third number of object buffer pools of a certain type can be created; where the first number is greater than the second number, and the second number is greater than the third number.

[0111] For example, you can create 30 object buffer pools for high-end machines, 20 object buffer pools for mid-range machines, and 10 object buffer pools for low-end machines.

[0112] Of course, the number of objects contained in the same type of object buffer pool created for different types of terminals can also be different. For example, for any type of object buffer pool, the number of objects contained in the object buffer pool of that type created for a high-end machine can be greater than the number of objects contained in the object buffer pool of that type created for a mid-range machine, and the number of objects contained in the object buffer pool of that type created for a mid-range machine can be greater than the number of objects contained in the object buffer pool of that type created for a low-end machine.

[0113] In this embodiment, the object buffer pool is pre-created based on the type of terminal, so that the pre-creation of the object buffer pool can be adapted to the performance of the terminal, which can give full play to the performance of the terminal while avoiding excessive consumption of terminal resources.

[0114] Of course, in other embodiments of this application, the number and type of object buffer pools created can even be customized by the user. For example, the system can recommend object buffer pool types to the user, who can then select one, and the system creates the object buffer pool according to the user's selection. This approach greatly enhances the user's autonomy and improves the user experience.

[0115] In one embodiment of this application, after creating at least one type of object buffer pool, the object loading method may further include the following steps: determining the release probability of each type of object buffer pool according to the priority of each type of object, wherein the priority is negatively correlated with the release probability of the corresponding object buffer pool; determining the object buffer pool to which the object to be unloaded belongs based on the release probability of each type of object buffer pool; and releasing all movable objects in each determined object buffer pool as a whole, so that each movable object in each object buffer pool is in an unused state.

[0116] The release probability of an object buffer pool can be a real number in the range [0,1]. For example, the release probability of an object buffer pool corresponding to high priority can be 0.2, that of an object buffer pool corresponding to medium priority can be 0.5, and that of an object buffer pool corresponding to low priority can be 0.8.

[0117] Whether objects in each type of object pool need to be released as a whole can be randomly determined based on the release probability of the corresponding object pool. The higher the release probability of an object pool, the more likely its movable objects are to be released as a whole. Since the priority of an object pool is negatively correlated with its release probability, objects in low-priority object pools are more likely to be released as a whole, while objects in high-priority object pools are less likely to be released as a whole.

[0118] Figure 5 A schematic diagram illustrating the overall process of performance optimization for moving objects based on an object buffer pool according to an embodiment of this application is shown below. Figure 5 The following will further describe the solutions of the embodiments of this application. Please refer to [link / reference]. Figure 5 As shown, the overall process for performance optimization of moving objects based on object buffer pools can include the following steps:

[0119] Step 510: Initialize the moving object buffer management system.

[0120] In this embodiment, the mobile object buffer management system serves as the operation interface for all core data modules, facilitating the processing of various mobile object data. Therefore, it is through this system that performance optimization of mobile objects based on an object buffer pool is achieved. The mobile object buffer management system can be initialized at the start of a game.

[0121] Initializing the movable object buffer management system involves creating the underlying actual data storage module—the object buffer pool. In the object buffer pool, a series of commonly used movable objects are pre-created based on the game content.

[0122] Figure 6 A flowchart illustrating the initialization of a mobile object buffer management system according to an embodiment of this application is shown. See also... Figure 6 As shown, the initialization of the move object buffer management system includes the following steps:

[0123] Step 610: Create a character object buffer pool containing 8 character objects.

[0124] Step 620: Release the role object buffer pool by class.

[0125] Step 630: Create a vehicle object buffer pool containing 4 vehicle objects.

[0126] Step 640: Release the vehicle object buffer pool by class.

[0127] Step 650: Create an attack equipment object buffer pool containing 8 attack equipment objects.

[0128] Step 660: Release the attack equipment object buffer pool by category.

[0129] In the steps described above, after each creation of an object pool, the object pool must be released by class. The process of releasing objects by class will be explained later and will not be detailed here.

[0130] The pseudocode for initializing the mobile object buffer management system can be as follows: the PostInitialize() function of UactorCahePoolSubsystem.

[0131] {

[0132] for each of the 8 character object indices do

[0133] Call the Create0rGetActor function to create an object buffer pool containing the role object corresponding to the current role object's ordinal number;

[0134] Call the ReleaseActorByClass function to release the role object buffer pool by class;

[0135] end for

[0136] for each of the 4 vehicle object serial numbers, do

[0137] Call the Create0rGetActor function to create an object buffer pool containing the vehicle object corresponding to the current vehicle object's ordinal number;

[0138] Call the ReleaseActorByClass function to release the vehicle object buffer pool by class;

[0139] end for

[0140] for each of the 8 attack equipment object serial numbers, do

[0141] Call the Create0rGetActor function to create an object buffer pool containing the attack equipment object corresponding to the current attack equipment object's sequence number;

[0142] The ReleaseActorByClass function is called to release the attack equipment object buffer pool by class;

[0143] end for

[0144] }

[0145] Here, `UActorCahePoolSubsystem` represents the mobile object buffer management system, and `PostInitialize()` is the initialization function. As can be seen, during initialization, a character object buffer pool containing 8 character objects (player objects), a vehicle object buffer pool containing 4 vehicle objects, and an attack equipment object buffer pool containing 8 attack equipment objects are also created. These buffer pools can be created based on the characteristics of the open-world game. Character objects, vehicle objects, and attack equipment objects are all movable objects. The creation of each object buffer pool is achieved through the `Create0rGetActor` function.

[0146] In open-world games, it is also necessary to create objects such as accessories, helmets, and backpacks. An object buffer pool containing these objects can be dynamically created in the game.

[0147] An Actor is the base class of Objects that can be placed or generated within a level. An Actor can contain many Components used to control the Actor's movement and rendering. Another important function of an Actor is that, in a networked environment, it allows for property copying and function calls via the network. A Component is a functional block that can be added to an Actor to provide specific behaviors or properties. For example, a Spot Light Component allows an Actor to emit light like a spotlight, while a Rotating Movement Component allows an Actor to rotate.

[0148] In one embodiment of this application, creating an object buffer pool of at least one type includes: when it is necessary to create an object buffer pool of a specified type, determining whether an object buffer pool of the specified type already exists in the set of already created object buffer pools; if an object buffer pool of the specified type already exists, directly obtaining a movable object of the specified type from the object buffer pool of the specified type; if an object buffer pool of the specified type does not exist in the set of already created object buffer pools, creating an object buffer pool of the specified type and adding the object buffer pool of the specified type to the set of object buffer pools; and obtaining a movable object of the specified type from the object buffer pool of the specified type in the set of object buffer pools.

[0149] As can be seen, the creation process of the object buffer pool actually involves the process of obtaining objects.

[0150] Please continue reading Figure 5 Step 520: Create the underlying moving object buffer pool.

[0151] This step is actually a specific sub-step of the initialization of the mobile object buffer management system.

[0152] Figure 7 A flowchart illustrating the creation of an underlying mobile object buffer pool according to one embodiment of this application is shown. See also... Figure 7 As shown, the creation of the underlying move object buffer pool may include the following steps:

[0153] Step 710: Determine whether an object buffer pool of the specified type exists in the object buffer pool collection.

[0154] If yes, proceed to step 720; otherwise, proceed to step 730.

[0155] Step 720: Obtain a movable object of the specified type from the object buffer pool of the specified type.

[0156] Step 730: Create a new object buffer pool.

[0157] The type of the newly created object buffer pool is not defined in this step.

[0158] Step 740: Add the newly created object buffer pool as an object buffer pool of the specified type to the object buffer pool collection.

[0159] Step 750: Obtain a movable object of the specified type from the object buffer pool of the specified type in the object buffer pool collection.

[0160] Therefore, during the initialization of the mobile object buffer management system, the creation of the object buffer pool is actually accompanied by the process of obtaining objects of the corresponding type.

[0161] The following section details the Create0rGetActor function in the pseudocode involved in the initialization of the aforementioned mobile object buffer management system.

[0162] The pseudocode for creating the underlying move object buffer pool can be as follows:

[0163] The `Create0rGetActor(ActorClass)` function of `UactorCahePoolSubsystem`

[0164] {

[0165] If the object cache pool collection ActorCachePools contains a cache pool of type ActorClass, then

[0166] Call the GetOrCreateActor function to retrieve an object instance from the pool of type ActorClass;

[0167] else

[0168] Create a new object buffer pool, NewPool;

[0169] Add the object cache pool to the object cache pool collection ActorCachePools;

[0170] Call the GetOrCreateActor function on the object buffer pool NewPool to obtain an object of type ActorClass;

[0171] end if

[0172] }

[0173] In the pseudocode related to the creation of the underlying mobile object buffer pool, when the object buffer management system UactorCachePoolSubsystem needs to obtain a certain type of object ActorClass, it first checks whether there is an object buffer pool Pool of that type in the current object buffer pool collection ActorCachePools. If there is an object buffer pool of that type, it directly obtains the object instance of this type through the object buffer pool Pool->GetOrCreateActor; if there is no object buffer pool of that type, it directly creates a new object buffer pool NewPool and adds the new object buffer pool to the object buffer pool collection ActorCachePools. Finally, it obtains the object instance of this type from the new object buffer pool NewPool.GetOrCreateActor(ActorClass). Specifically, it can be seen that the Create0rGetActor function in the pseudocode above calls the GetOrCreateActor function, and the GetOrCreateActor function is used to create and obtain objects.

[0174] Figure 8 An embodiment according to this application is shown. Figure 4 A flowchart of the steps following step 310 in the embodiment. Please refer to [link / reference]. Figure 8 As shown, after creating an object buffer pool of at least one type, the object loading method may include the following steps:

[0175] In step 320, objects in each type of object buffer pool are released so that the objects in each type of object buffer pool are in an unused state.

[0176] As is easy to understand, what is being released here are movable objects in the object buffer pool, which are used to put the movable objects in the object buffer pool into an unused state.

[0177] In this step, movable objects in all object pools created in step 310 can be released.

[0178] As can be seen, the pseudocode involved in the initialization of the aforementioned mobile object buffer management system also includes the function ReleaseActorByClass. This function is used to release movable objects by class. Here, class refers to a type. In other words, this function can be used to release all objects in the object buffer pool of a type.

[0179] As mentioned earlier, objects are obtained when creating an object buffer pool, but these objects are often not needed at this time. Later, when the object is actually needed, it cannot be retrieved again because it has already been obtained, thus requiring a new object to be created, which can easily cause lag. In this embodiment, by creating an object buffer pool first and then releasing the objects in the buffer pool for each type, the object can be directly retrieved when it is actually needed, without the need for creation, effectively reducing lag.

[0180] Below is a detailed introduction. Figure 3 The steps are shown in the example.

[0181] In step 330, when it is necessary to load a target movable object in the target scene, the target movable object is obtained from an object buffer pool that includes at least one movable object. The objects in the object buffer pool are some of the objects that can be loaded in the target scene, and the movable object is an object that can be moved in the target scene.

[0182] The target movable object needs to be loaded into the target scene, which means the target movable object needs to be used in the game.

[0183] When a target movable object is about to appear in the view of the current user (the character controlled by the current user), it is determined that the target movable object needs to be loaded into the target scene.

[0184] The operation of obtaining a target movable object is to obtain a usable object instance.

[0185] Figure 9 An embodiment according to this application is shown. Figure 4 A flowchart detailing step 330 in the embodiment is provided. Please refer to [link / reference]. Figure 9 As shown, when a target movable object needs to be loaded into the target scene, the target movable object is obtained from an object buffer pool that includes at least one movable object. Specifically, this may include the following steps:

[0186] In step 331, when it is necessary to load a target movable object of the target type in the target scene, the target object buffer pool of the target type is determined from the object buffer pools of each type.

[0187] When multiple object buffer pools exist, the corresponding target object buffer pool needs to be determined based on the type of the target movable object to be loaded.

[0188] Each type of object buffer pool can include a list of available objects and a list of used objects; the list of available objects stores objects that are not currently in use, and the list of used objects stores objects that are currently in use.

[0189] In step 332, the target movable object is obtained from the target object buffer pool.

[0190] In this embodiment of the application, by creating object buffer pools by class, and when a target movable object is needed, finding the corresponding object buffer pool according to the type, and then obtaining the movable object from the found object buffer pool, the efficiency of object retrieval can be improved.

[0191] Figure 10 An embodiment according to this application is shown. Figure 9 A flowchart detailing step 332 in the embodiment is provided. Please refer to [link / reference]. Figure 10 As shown, retrieving the target movable object from the target object buffer pool can specifically include the following steps:

[0192] In step 3321, the target movable object is removed from the list of available objects in the target object buffer pool.

[0193] The available object list is a list of unused objects. Since the target movable object will be used after it is obtained, it needs to be removed from the available object list.

[0194] In step 3322, the target movable object is added to the list of used objects in the target object buffer pool.

[0195] In this embodiment of the application, by adding the target movable object to the list of used objects, the target movable object can be prevented from being obtained repeatedly.

[0196] Please continue reading Figure 5 After step 520, the following also includes:

[0197] Step 530: Move object creation and acquisition.

[0198] Figure 11 A flowchart illustrating the creation and acquisition of a mobile object according to one embodiment of this application is shown. See also... Figure 11 As shown, the creation and acquisition of a moving object may include the following steps:

[0199] Step 1110: Determine whether there are any unused movable objects of the target type in the object buffer pool.

[0200] If yes, proceed to step 1120; otherwise, proceed to step 1140.

[0201] Step 1120: Remove the movable object of the target type from the list of available objects in the object buffer pool of the target type.

[0202] Step 1130: Set the movable object of the target type to a usable state.

[0203] After completing this step, proceed to step 1150.

[0204] Step 1140: Create a movable object of the target type in the object buffer pool of the target type.

[0205] After completing this step, proceed to step 1150.

[0206] Step 1150: Add the movable object of the target type to the list of used objects in the object buffer pool of the target type.

[0207] The following is a detailed explanation of the pseudocode involved in creating and retrieving the move object. The pseudocode for creating and retrieving the move object can be as follows:

[0208] The function Get0rCreateActor(ActorClass) of FActorCachePool

[0209] {

[0210] For each unused object in the list of available InactiveActors, do...

[0211] If the type of InactiveActor is the same as that of ActorClass, then

[0212] Assign the InactiveActor to the Actor;

[0213] Calling the RemoveSingleSwap function removes the InactiveActor from the list of available objects, InactiveActors;

[0214] end if

[0215] end for

[0216] If the value of Actor is non-zero, then

[0217] Call the SetActorEnable function to set the Actor object to a usable state;

[0218] end if

[0219] if Actor's value is zero then

[0220] The `SpawnActor` function is called to create an object of type `ActorClass`, and then the object is assigned to `Actor`.

[0221] end if

[0222] Add the Actor object to the list of used objects, ActiveActors;

[0223] }

[0224] The pseudocode above is the specific implementation of the Get0rCreateActor function. The method for retrieving an object (Actor) from the FactorCachePool is as follows: First, check if there is an object cache pool for the corresponding type ActorClass that contains an unused InactiveActor. If found, the RemoveSingleSwap function is called to remove the object from the entire list of available InactiveActors in the object cache pool, and the object is set to a usable state using SetActorEnable(Actor, true). If no unused object is found in the entire object cache pool, the most basic method for object creation, SpawnActor(ActorClass), is used to directly create an object of that type in the object cache pool. Finally, the Add function is used to add the retrieved object to the list of used objects in the entire cache pool.

[0225] In step 340, the object resources corresponding to the target movable object are loaded according to the target movable object.

[0226] After obtaining the target movable object, you can assign values ​​to it. For example, you can assign the vehicle object to a truck, motorcycle, car, etc. Then, you can load the corresponding model, texture, and other resources on the terminal.

[0227] Figure 12 An embodiment according to this application is shown. Figure 10 A flowchart of the steps following step 340 in this embodiment. Please refer to [link / reference]. Figure 12 As shown, after loading the object resources corresponding to the target movable object based on the target movable object, the object loading method may further include the following steps:

[0228] In step 350, when it is necessary to unload the target movable object, the target movable object in the target object buffer pool is released so that the target movable object is in an unused state.

[0229] When the target movable object is no longer needed, it needs to be released.

[0230] When the target movable object leaves the current user's (the role controlled by the current user) field of view, it is determined that the target movable object needs to be unloaded.

[0231] Other methods can also be used to determine when a target movable object needs to be unloaded. For example, when the target movable object leaves the current user's (the character controlled by the current user) field of vision by a predetermined distance, it can be determined that the target movable object needs to be unloaded; or, when the target movable object leaves the current user's (the character controlled by the current user) field of vision for a predetermined period of time, it can be determined that the target movable object needs to be unloaded.

[0232] In this embodiment of the application, by releasing the target movable object in a timely manner when it needs to be unloaded, it can be obtained in a timely manner when it needs to be loaded, thereby further alleviating the lag phenomenon.

[0233] Figure 13 An embodiment according to this application is shown. Figure 12 A flowchart detailing step 350 in the embodiment is provided. Please refer to [link / reference]. Figure 13 As shown, releasing the target movable object in the target object buffer pool can specifically include the following steps:

[0234] In step 351, the target movable object is removed from the list of used objects in the target object buffer pool.

[0235] Remove the target movable object from the list of used objects so that it can be retrieved correctly when it needs to be loaded again.

[0236] In step 352, the target movable object is added to the list of available objects in the target object buffer pool.

[0237] The available object list is a list of unused objects. When a target movable object is released, it needs to be added to the available object list so that it can be used next time.

[0238] Once an object is created in the object pool, it will continue to occupy memory, regardless of whether the object is acquired or released.

[0239] In the embodiments of this application, the accurate release of objects can be achieved by using a list of used objects and a list of available objects to manage the release of objects.

[0240] Please continue reading Figure 5 After step 530, the following also includes:

[0241] Step 540: Release the moved object.

[0242] Below, we will explain in detail the pseudocode involved in releasing a moved object. The pseudocode for releasing a moved object can be as follows:

[0243] The `ReleaseActor(Actor)` function of `FActorCachePool`

[0244] {

[0245] If the list of used objects, ActiveActors, contains the currently movable object, Actor, then...

[0246] Remove the Actor object from the list of used objects, ActiveActors;

[0247] Add the Actor object to the list of available objects, InactiveActors;

[0248] Calling the SetActorEnable function sets the Actor object to an unused state;

[0249] end if

[0250] }

[0251] The pseudocode above releases movable objects using the `ReleaseActor` function. The specific process is as follows: It checks if the `ActiveActors` list of used objects contains the current movable object (Actor). If it does, the current movable object can be released. If it can be released, the current movable object is removed from the `ActiveActors.RemoveAt` list of used objects in the object buffer pool. Then, the current movable object is added to the list of available objects using `InactiveActors.Push`, and the object is set to an unused state using `SetActorEnable(Actor, false)`.

[0252] In one embodiment of this application, after loading the object resources corresponding to the target movable object according to the target movable object, the object loading method may further include the following steps: when it is necessary to unload all movable objects belonging to the target type, release all movable objects in the target object buffer pool as a whole, so that all movable objects in the target object buffer pool, including the target movable object, are in an unused state.

[0253] This application also provides a technical means to release movable objects by class, using an object buffer pool as the unit. This can improve the efficiency of unloading movable objects and prevent high memory consumption caused by the object buffer pool.

[0254] When a class of movable objects no longer needs to be used within a short period of time, movable objects can be released by class.

[0255] The ReleaseActorByClass function in the pseudocode involved in the initialization of the mobile object buffer management system in the above embodiment can be used to release objects by class.

[0256] Please continue reading Figure 5 After step 540, the following also includes:

[0257] Step 550: Release by category.

[0258] The pseudocode for releasing by class can be as follows:

[0259] The function `ReleaseActorByClass(ActorClass)` in `UActorCahePoolSubsystem`

[0260] {

[0261] If the object cache pool collection ActorCachePools contains an object cache pool of type ActorClass, then

[0262] Call the ReleaseAll() function to release the buffer pool for this object by class;

[0263] end if

[0264] }

[0265] The function ReleaseA11() of void FActorCachePool

[0266] {

[0267] for each object in the list of used objects ActiveActors then

[0268] Call the SetActorEnable function to set the object to an unused state;

[0269] end for

[0270] Calling the Append function adds all objects from the ActiveActors list of used objects to the InactiveActors list of available objects;

[0271] Call the Empty function to clear the list of used objects, ActiveActors.

[0272] ...

[0273] }

[0274] When a certain type of object needs to be released, the solution in this application embodiment also provides the function ReleaseActorByClass to release the object buffer pool containing a certain type of object: FActorCachePool::ReleaseAll. Specifically, during the release, we set all objects in the list of used objects ActiveActors to an unused state: SetActorEnable(Actor, false), add all objects to the list of available objects: InactiveActors.Append(ActiveActors), and also clear the list of active objects—the list of used objects ActiveActors: ActiveActors.Empty().

[0275] In one embodiment of this application, after creating an object buffer pool of at least one type, the object loading method further includes: resetting the target object buffer pool in the object buffer pool of at least one type to release the memory space occupied by each object in the target object buffer pool.

[0276] This application embodiment can also reset any existing object buffer pool as a whole. When a game is completed, all object buffer pools can be reset.

[0277] The previous object release only put the object into an idle, inactive state, without actually destroying it. Resetting, however, completely destroys the class's buffer pool, including all objects contained within it.

[0278] Please continue reading Figure 5 After step 550, the following also includes:

[0279] Step 560: Reset the entire buffer pool.

[0280] The pseudocode for resetting the entire buffer pool can be as follows:

[0281] The function `ResetPool(ActorClass)` in `UActorCahePoolSubsystem`

[0282] {

[0283] If the object cache pool collection ActorCachePools contains an object cache pool of type ActorClass, then

[0284] Call the ResetPool() function to reset the buffer pool for this object;

[0285] end if

[0286] }

[0287] The function ResetPool() of FActorCachePool

[0288] {

[0289] Reset the list of available objects, InactiveActors;

[0290] Reset the list of used objects, ActiveActors;

[0291] }

[0292] The buffer pool can be reset by calling the UActorCahePoolSubsystem::ResetPool function. When resetting the entire buffer pool, it will find the buffer pool containing objects of that type and reset the ResetPool. As can be seen from the specific function implementation, it completely clears the saved list of available objects (InactiveActors) and the list of used objects (ActiveActors), thus releasing memory.

[0293] In this embodiment of the application, by resetting the object buffer pool by class, memory can be released in a timely manner, avoiding lag caused by insufficient memory.

[0294] Figure 14 This diagram illustrates a comparison of the performance of related technical solutions and the solutions in this application's embodiments regarding lag. In a large-scale online game with full island combat, the inventors of this application conducted experiments to compare the lag performance of related technical solutions and the solutions in this application's embodiments. Figure 14 The table shown is actually used to record experimental data on lag performance between related technical solutions and the solutions in the embodiments of this application. Please refer to... Figure 14As shown, the default number of stutters is the number of stutters obtained when using related technical solutions, while the number of stutters when object buffer pool optimization is enabled is the number of stutters obtained when using the solution of this application embodiment. It can be seen that on high-end models, the number of stutters per hour obtained when using related technical solutions is 59, while the number of stutters per hour obtained when using the solution of this application embodiment is 46. Therefore, based on 59 and 46, the stutter optimization margin (59-46) / 59 = 22% can be calculated. It can be seen that compared with related technical solutions, the solution of this application embodiment achieves optimizations of 11%-22% on various models, with the most significant improvement on high-end models, achieving a stutter optimization margin of 22%.

[0295] In summary, the object loading method provided by the embodiments of this application proposes for the first time a performance optimization technology for large-scale mobile objects based on an object buffer pool. Based on the technical solution of this application, various commonly used large-scale objects in the game, such as characters, vehicles, and attack equipment, can be effectively cached, avoiding lag caused by frequent creation and unloading within the field of view. This has achieved an optimization of 11%-22% in complete games on various high-, medium-, and low-end mobile devices, and has achieved the following technical effects:

[0296] 1. The solution can optimize only the frequently created moving objects in the game based on the buffer pool, avoiding the full object caching performed by the conventional object buffer pool (the full number of objects in the world will be millions). The solution of this application embodiment only caches the key frequently destroyed and created moving objects (only tens of thousands of moving objects in the world will be created), which can greatly reduce memory consumption while reducing lag.

[0297] 2. It can pre-create commonly used mobile objects, avoiding the lag caused by the regular object pool creating them in time.

[0298] 3. It can support the release and destruction of objects by class, preventing high memory consumption caused by the buffer pool.

[0299] The following describes an apparatus embodiment of this application, which can be used to execute the object loading method described above in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the object loading method described above in this application.

[0300] Figure 15 A block diagram of an object loading apparatus according to an embodiment of this application is shown. Please refer to... Figure 15As shown, an object loading apparatus 1500 according to an embodiment of this application includes an object acquisition unit 1510 and a resource loading unit 1520. The object acquisition unit 1510 is used to acquire a target movable object from an object buffer pool containing at least one movable object when it is necessary to load a target movable object in a target scene. The objects in the object buffer pool are a subset of objects that can be loaded in the target scene, and the movable object is an object that can be moved in the target scene. The resource loading unit 1520 is used to load object resources corresponding to the target movable object.

[0301] In some embodiments of this application, based on the foregoing scheme, the object acquisition unit 1510 is configured to: when it is necessary to load a target movable object of the target type in the target scene, determine the target object buffer pool of the target type from the object buffer pools of each type; and acquire the target movable object from the target object buffer pool.

[0302] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a buffer pool creation unit; before determining that a target movable object needs to be loaded in the target scene, the buffer pool creation unit is used to: create at least one type of object buffer pool, each type of object buffer pool including at least one object belonging to the type, and the at least one type of object buffer pool including a target object buffer pool of the target type.

[0303] In some embodiments of this application, based on the foregoing scheme, the buffer pool creation unit is configured to: obtain the priority corresponding to each type of object, wherein the priority corresponding to each type of object is one of multiple priorities with different levels, and the priority corresponding to each type of object is determined by any of the following methods: determining the priority corresponding to the current type of object based on the loading frequency obtained from historical statistics of objects of the current type; determining the priority corresponding to the current type of object based on the distance between the current type of object and the location of a specified object; determining the priority corresponding to the current type of object based on the loading frequency obtained from historical statistics of objects of the current type and the distance between the current type of object and the location of a specified object; determining the creation probability of the object buffer pool corresponding to each type based on the priority corresponding to each type of object, wherein the level of priority is positively correlated with the creation probability of the corresponding object buffer pool; determining the type of object buffer pool to be created based on the creation probability of the object buffer pool corresponding to each type, and creating at least one type of object buffer pool according to the determined type.

[0304] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes an overall object release unit; after creating at least one type of object buffer pool, the overall object release unit is used to: release objects in each type of object buffer pool so that the objects in each type of object buffer pool are in an unused state.

[0305] In some embodiments of this application, based on the foregoing scheme, the device further includes an object release unit; after loading the object resources corresponding to the target movable object according to the target movable object, the object release unit is used to: release the target movable object in the target object buffer pool when it is necessary to unload the target movable object, so that the target movable object is in an unused state.

[0306] In some embodiments of this application, based on the foregoing scheme, after loading the object resources corresponding to the target movable object according to the target movable object, the overall object release unit is further configured to: when it is necessary to unload all movable objects belonging to the target type, release all movable objects in the target object buffer pool as a whole, so that all movable objects in the target object buffer pool, including the target movable object, are in an unused state.

[0307] In some embodiments of this application, based on the foregoing scheme, after creating at least one type of object buffer pool, the overall object release unit is further configured to: determine the release probability of each type of object buffer pool according to the priority corresponding to each type of object, wherein the priority is negatively correlated with the release probability of the corresponding object buffer pool; determine the object buffer pool to which the object to be unloaded belongs based on the release probability of each type of object buffer pool; and perform overall release of all movable objects in each determined object buffer pool so that each movable object in each object buffer pool is in an unused state.

[0308] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a reset unit; after creating at least one type of object buffer pool, the reset unit is used to: reset the target object buffer pool in the at least one type of object buffer pool to release the memory space occupied by each object in the target object buffer pool.

[0309] In some embodiments of this application, based on the foregoing scheme, each of the object buffer pools includes a list of available objects and a list of used objects; the object acquisition unit 1510 is configured to: remove the target movable object from the list of available objects in the target object buffer pool; and add the target movable object to the list of used objects in the target object buffer pool.

[0310] In some embodiments of this application, based on the foregoing scheme, the object release unit is configured to: remove the target movable object from the list of used objects in the target object buffer pool; and add the target movable object to the list of available objects in the target object buffer pool.

[0311] Figure 16 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0312] It should be noted that, Figure 16 The computer system 1600 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0313] like Figure 16 As shown, the computer system 1600 includes a Central Processing Unit (CPU) 1601, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1602 or programs loaded from storage portion 1608 into Random Access Memory (RAM) 1603, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1603. The CPU 1601, ROM 1602, and RAM 1603 are interconnected via bus 1604. An input / output (I / O) interface 1605 is also connected to bus 1604.

[0314] The following components are connected to I / O interface 1605: an input section 1606 including a keyboard, mouse, etc.; an output section 1607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1608 including a hard disk, etc.; and a communication section 1609 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1609 performs communication processing via a network such as the Internet. A drive 1610 is also connected to I / O interface 1605 as needed. Removable media 1611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1610 as needed so that computer programs read from them can be installed into storage section 1608 as needed.

[0315] Specifically, according to embodiments of this application, the processes described above with reference to the 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 communication section 1609, and / or installed from removable medium 1611. When the computer program is executed by central processing unit (CPU) 1601, it performs various functions defined in the system of this application.

[0316] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0317] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0318] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0319] In one aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0320] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0321] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0322] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0323] The data collection and processing plan outlined in this application must be implemented in strict accordance with the requirements of relevant national laws and regulations, obtaining the informed consent or separate consent of the data subject (or having a legal basis as stipulated by the relevant national laws and regulations), and conducting subsequent data use and processing within the scope authorized by laws and regulations and the data subject.

[0324] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. An object loading method, characterized in that, The method includes: When it is necessary to load a target movable object in the target scene, the target movable object is obtained from an object buffer pool that includes at least one movable object. The objects in the object buffer pool are a subset of objects that can be loaded in the target scene, and the movable object is an object that can be moved in the target scene. Based on the target movable object, load the object resources corresponding to the target movable object.

2. The object loading method according to claim 1, characterized in that, When a target movable object needs to be loaded in the target scene, the step of obtaining the target movable object from an object buffer pool that includes at least one movable object includes: When it is necessary to load a target movable object of the target type in the target scene, the target object buffer pool of the target type is determined from the object buffer pool of each type; The target movable object is obtained from the target object buffer pool.

3. The object loading method according to claim 2, characterized in that, Before determining that the target movable object needs to be loaded into the target scene, the method further includes: Create an object buffer pool of at least one type, each object buffer pool of the type including at least one object belonging to the type, and the object buffer pool of the at least one type including a target object buffer pool of the target type.

4. The object loading method according to claim 3, characterized in that, Creating an object buffer pool of at least one type includes: Obtain the priority of each object type. The priority of each object type is one of several priorities with varying levels of intensity. The priority of each object type is determined by any of the following methods: determining the priority based on the historical loading frequency of objects of the current type; determining the priority based on the distance between the current object and a specified object; or determining the priority based on both the historical loading frequency of objects of the current type and the distance between the current object and a specified object. The creation probability of the object buffer pool for each type is determined based on the priority of each type of object. The higher the priority, the higher the creation probability of the corresponding object buffer pool. Based on the creation probability of the object buffer pool corresponding to each type, determine the type of object buffer pool to be created, and create at least one type of object buffer pool according to the determined type.

5. The object loading method according to claim 4, characterized in that, After creating an object buffer pool of at least one type, the method further includes: Release objects in the object pools of each type to make them unused.

6. The object loading method according to claim 4, characterized in that, After loading the object resources corresponding to the target movable object based on the target movable object, the method further includes: When it is necessary to unload the target movable object, the target movable object in the target object buffer pool is released so that the target movable object is in an unused state.

7. The object loading method according to claim 4, characterized in that, After loading the object resources corresponding to the target movable object based on the target movable object, the method further includes: When it is necessary to unload all movable objects belonging to the target type, all movable objects in the target object buffer pool are released as a whole, so that all movable objects in the target object buffer pool, including the target movable object, are in an unused state.

8. The object loading method according to claim 4, characterized in that, After creating an object buffer pool of at least one type, the method further includes: The release probability of each type of object buffer pool is determined based on the priority of each type of object. The higher the priority, the lower the release probability of the corresponding object buffer pool. Based on the release probability of each type of object buffer pool, determine the object buffer pool to which the object to be unloaded belongs; All movable objects in the identified object buffer pools are released as a whole, so that all movable objects in each object buffer pool are in an unused state.

9. The object loading method according to claim 4, characterized in that, After creating an object buffer pool of at least one type, the method further includes: The target object buffer pool in at least one type of object buffer pool is reset to release the memory space occupied by each object in the target object buffer pool.

10. The object loading method according to claim 6, characterized in that, Each of the aforementioned object buffer pools includes a list of available objects and a list of used objects; obtaining the target movable object from the target object buffer pool includes: Remove the target movable object from the list of available objects in the target object buffer pool; Add the target movable object to the list of used objects in the target object buffer pool.

11. The object loading method according to claim 10, characterized in that, The step of releasing the target movable object from the target object buffer pool includes: Remove the target movable object from the list of used objects in the target object buffer pool; Add the target movable object to the list of available objects in the target object buffer pool.

12. An object loading device, characterized in that, The device includes: An object acquisition unit is used to acquire the target movable object from an object buffer pool containing at least one movable object when it is necessary to load the target movable object in the target scene. The objects in the object buffer pool are a portion of the objects that can be loaded in the target scene, and the movable object is an object that can be moved in the target scene. The resource loading unit is used to load the object resources corresponding to the target movable object based on the target movable object.

13. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the object loading method as described in any one of claims 1 to 11.

14. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the object loading method as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the object loading method as described in any one of claims 1 to 11.

Images