Game resource processing method and device, electronic equipment, and program product

Abstract

The present disclosure provides a game resource processing method, a game resource processing device, an electronic device and a computer program product, and belongs to the technical field of computers. The method comprises: obtaining plot resource data corresponding to a plurality of plot packages in a game; performing multiplexing analysis on the plot resource data corresponding to the plurality of plot packages, and determining plot resource data existing in at least two plot packages at the same time as shared resources; generating resource management information of each plot package based on the association relationship between each plot package and the shared resources; and sending the resource management information to a client, so that the client processes each plot package based on the resource management information. The present disclosure can avoid repeated downloading and accidental deletion of cross-plot resources, thereby improving resource management efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to game resource processing methods, game resource processing devices, electronic devices, and computer program products. Background Technology

[0002] With the rapid development of the gaming industry, the resource scale of story-driven mobile games continues to expand. Game resource management typically requires configuring corresponding resources for different story content to ensure that each storyline can be loaded and played correctly. Current technologies usually categorize and manage game resources based on resource type or functional system. However, resource reuse may occur between different storylines. Without a mechanism to differentiate resource management based on the actual usage needs of different storylines, resource processing efficiency is low. Therefore, how to effectively manage resources reused across storylines is a problem that current technologies urgently need to solve.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] This disclosure provides a method for processing game resources, a device for processing game resources, an electronic device, and a computer program product, thereby overcoming, to at least a certain extent, the problem that shared resources are difficult to effectively identify and manage in cross-story scenarios.

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

[0006] According to a first aspect of this disclosure, a game resource processing method is provided, applied to a server. The method includes: acquiring story resource data corresponding to multiple story packs in a game; performing reuse analysis on the story resource data corresponding to the multiple story packs, and identifying story resource data that exists simultaneously in at least two story packs as shared resources; generating resource management information for each story pack based on the association relationship between each story pack and the shared resources; and sending the resource management information to a client so that the client processes each story pack based on the resource management information.

[0007] According to a second aspect of this disclosure, a game resource processing method is provided, applied to a client, the method comprising: receiving resource management information from a server; the resource management information being used to indicate the association between a story pack and shared resources; the shared resources being resource data that simultaneously exists in story resource data corresponding to at least two story packs; and, in response to receiving an operation request for a target story pack, processing the target story pack according to the resource management information.

[0008] According to a third aspect of this disclosure, a game resource processing apparatus is provided, applied to a server. The apparatus includes: a resource data acquisition module, used to acquire story resource data corresponding to multiple story packs in a game; a shared resource determination module, used to perform reuse analysis on the story resource data corresponding to the multiple story packs, and determine the story resource data that exists simultaneously in at least two story packs as shared resources; a management information generation module, used to generate resource management information for each story pack based on the association relationship between each story pack and the shared resources; and a management information sending module, used to send the resource management information to a client, so that the client processes each story pack based on the resource management information.

[0009] According to a fourth aspect of this disclosure, a game resource processing apparatus is provided, applied to a client. The apparatus includes: a management information acquisition module, configured to receive resource management information from a server; the resource management information is used to indicate the association between a story pack and shared resources; the shared resources are resource data that simultaneously exist in the story resource data corresponding to at least two story packs; and a story pack processing module, configured to process the target story pack according to the resource management information in response to receiving an operation request for a target story pack.

[0010] According to a fifth aspect of this disclosure, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the method described in any one of the preceding methods by executing the executable instructions.

[0011] According to a sixth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in any of the preceding claims.

[0012] The exemplary embodiments disclosed herein have the following beneficial effects: The system acquires story resource data corresponding to multiple story packs in the game; performs reuse analysis on the story resource data corresponding to multiple story packs, identifying story resource data that exists in at least two story packs simultaneously as shared resources; generates resource management information for each story pack based on the association between each story pack and the shared resources; and sends the resource management information to the client so that the client can process each story pack based on the resource management information. On the one hand, by identifying shared resources that exist in multiple story packs and establishing their association with each story pack, the client can accurately know the correspondence between each story pack and the shared resources, thus avoiding duplicate downloads of shared resources already stored locally. On the other hand, by generating resource management information containing association relationships, the client can accurately determine whether a shared resource is still being used by other story packs when deleting a story pack, thus avoiding accidental deletion of resource data still referenced by other story packs.

[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

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

[0015] Figure 1 A flowchart illustrating a game resource processing method is shown; Figure 2 This diagram illustrates a flowchart for identifying shared resources and generating resource packages; Figure 3 This document illustrates a flowchart for obtaining story resource data corresponding to multiple story packs in a game. Figure 4 A flowchart illustrating another method for handling game resources; Figure 5 This illustrates a flowchart of a client downloading a target shared resource; Figure 6 This diagram illustrates a process of a client deleting a target story pack. Figure 7 This diagram illustrates a server-side processing flow for external resource data. Figure 8 A flowchart of a client-side download processing unit is shown; Figure 9 This diagram illustrates the overall flowchart of a game resource processing method. Figure 10 A structural block diagram of a game resource processing device is shown; Figure 11 This diagram illustrates the structure of another game resource processing device. Figure 12 An electronic device for implementing the above method is shown in this exemplary embodiment. Detailed Implementation

[0016] 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, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0017] An exemplary embodiment of this disclosure first provides a game resource processing method applied to a server. The server may include a game server, resource server, cloud server, or game backend server, etc. The server is used to uniformly manage story resources in the game, acquire and process story resource data corresponding to each story pack, identify shared resources across story packs, generate resource management information, and send the resource management information to the client to support the client in downloading and deleting story packs as needed.

[0018] The following is in conjunction with the appendix Figure 1 The exemplary embodiments will be further described as follows: Figure 1 As shown, the game resource processing method may include the following steps S110~S140: Step S110: Obtain the story resource data corresponding to multiple story packs in the game.

[0019] In this context, a story pack refers to information associated with the game's story content, indicating the relationship between the story content and resource data. For example, a story pack might be a list of related storylines, recording only the associated storylines without detailed resource data. A story pack can record resource identifiers or resource path information corresponding to a specific segment of story content in the game, such as a list of all resource file paths referenced by a chapter's storyline. A game can contain multiple story packs, each corresponding to different story content. For example, different game chapters, different story nodes, or different mission storylines can each correspond to different story packs. The story resource data corresponding to a story pack refers to the actual resource data referenced by the story content indicated by the story pack. This can be obtained by parsing the resource reference information in the story files corresponding to the story pack, or by retrieving it from pre-established index data. Story resource data can include audio resource data, video resource data, character portrait resource data, animation resource data, scene resource data, script configuration resource data, special effects resource data, or interface resource data, with its specific format depending on the type of resource it carries.

[0020] Obtaining story resource data corresponding to multiple story packs in a game can be achieved in several ways. For example, one can obtain the story content identifiers recorded in each story pack, determine the corresponding story file based on the story content identifiers, and then obtain the story resource data corresponding to each story pack by parsing the resource reference information in the story file. A game can contain multiple story packs, each corresponding to different story content. Each story pack itself does not contain resource data, but records the identifier information of its corresponding story content or the storage location of the story file. The corresponding story file can be located through this identifier information or storage location, and then the actual resource data referenced by the story content can be parsed from the story file. For example, the story resource data corresponding to each story pack can be obtained from pre-established index data. During the game resource production stage, the resources referenced by the story content corresponding to each story pack can be indexed in advance, establishing a mapping relationship between story packs and resource data and storing it as index data. The server can directly read the story resource data corresponding to each story pack from this index data when needed, without needing to parse the story file in real time. For example, multiple story packs corresponding to a specified game version can also be obtained from the version management system, and then the story resource data corresponding to these story packs can be obtained. Different versions of the game may have different story content, and the corresponding story packs may also be different. The server can obtain all the story packs for the corresponding version from the version management system based on the version number, and then obtain the story resource data corresponding to each story pack.

[0021] Step S120: Perform reuse analysis on the story resource data in multiple story packs, and identify the resource data that exists in at least two story packs at the same time as shared resources.

[0022] Reuse analysis involves comparing story resource data across multiple story packs to identify resource data that appears repeatedly in different packs. This comparison can be based on resource data identification information, such as the resource file path, hash value, or unique identifier. When resource data from two or more story packs contains resource data with the same identifier, that resource data is identified as a shared resource. Shared resources are resource data that exists simultaneously in the story resource data of at least two story packs and can be used by multiple story content segments.

[0023] In one implementation, reuse analysis can be performed on a per-story-pack basis, calculating the intersection of the story resource data corresponding to each story pack with the story resource data corresponding to all other story packs. This intersection is then identified as the shared resources between the story pack and other story packs. Specifically, the server obtains the set of story resource data corresponding to the first story pack and compares it with the set of story resource data corresponding to the second story pack. Common resource data in both sets is identified as the shared resources between the first and second story packs. Then, the set of story resource data corresponding to the first story pack is compared with the set of story resource data corresponding to the third story pack, identifying common resource data as the shared resources between the first and third story packs. This process continues until the shared resources between the first story pack and all other story packs are determined. The above process is then repeated for the second and third story packs, and so on, until the shared resources between all story packs are determined.

[0024] Reuse analysis can compare resource data based on its actual content, without relying on its identifiers. For example, two audio files, even with different filenames, can be identified as shared resources if their audio content is identical or highly similar. This approach avoids redundancy caused by duplicate storage of resource files with inconsistent naming. Specifically, the server can calculate the perceptual hash value or feature vector of the resource data to compare the similarity of resource data corresponding to different story packs, identifying resource data with similarity exceeding a preset threshold as shared resources.

[0025] The above implementation method can automatically identify shared resources between different story packs, avoiding omissions and errors caused by manual identification, thereby improving the accuracy and efficiency of resource sharing identification and providing a reliable data foundation for the subsequent generation of resource management information.

[0026] Step S130: Based on the association between each story pack and shared resources, generate resource management information for each story pack.

[0027] The relationship between story packs and shared resources refers to the correspondence between shared resources and story packs that reference them. A shared resource can be associated with one or more story packs, and a story pack can be associated with multiple shared resources. For example, if shared resource R1 is referenced by story packs P1 and P2, then shared resource R1 is associated with both story packs P1 and P2. Resource management information refers to information describing the resource composition and management strategies of each story pack. Resource management information may include the relationship between each story pack and shared resources, as well as the identification information of shared resources, such as which shared resources each story pack is associated with and which story packs reference each shared resource. Resource management information may also include information about exclusive resources contained in each story pack. Exclusive resources refer to resource data that exists only in a specific story pack and is not referenced by any other story pack. Resource management information can be stored on the server in file format.

[0028] In one implementation, the association between each story package and shared resources can be recorded in the form of a shared resource mapping table. This table can be used to record the correspondence between each shared resource and its associated story packages. For example, it can be stored as key-value pairs, where the key is the identifier of the shared resource and the value is a list of associated story packages. Alternatively, it can be stored as a table, with each row recording a shared resource and its associated list of story packages. The shared resource mapping table can record only the correspondence between the identifiers of shared resources and story package identifiers, without recording the actual data content of the shared resources or story packages, thus reducing the storage space occupied by the data structure.

[0029] In another implementation, the association between each story package and shared resources can also be recorded in the form of a shared resource list corresponding to each story package. The shared resource list for each story package records the identification information of each shared resource associated with that story package, such as the name, path, identifier, or number of the shared resource. The shared resource list and the shared resource mapping table record the same set of correspondences, but from different organizational perspectives. The shared resource list uses story packages as indexes to facilitate finding the associated shared resources from the story package side, while the shared resource mapping table uses shared resources as indexes to facilitate finding the associated story packages from the shared resource side. Both can be used individually or simultaneously; this disclosure does not impose any restrictions on this.

[0030] In one implementation, the server determines the association between each shared resource and the story packs that reference it, based on the shared resources identified in step S120. Then, it generates resource management information for each story pack based on these associations. Specifically, assuming shared resource R1 is referenced by story packs P1 and P2, and shared resource R2 is referenced by story packs P2 and P3, the associations determined by the server include the associations between R1 and P1 / P2, and between R2 and P2 / P3. The server generates resource management information based on these associations, which records that story pack P1 is associated with shared resource R1, story pack P2 is associated with shared resources R1 and R2, and story pack P3 is associated with shared resource R2. After obtaining this resource management information, the client can know which shared resources each story pack is associated with, and which story packs reference each shared resource.

[0031] Step S140: Send resource management information to the client so that the client can process each story pack based on the resource management information.

[0032] After determining the resource management information, the server can send it to the client. Upon receiving the resource management information, the client can perform corresponding resource management operations based on this information. In one implementation, when downloading a story package, the client determines the association between the story package and shared resources based on the resource management information, identifies the corresponding shared resource, and then checks whether the shared resource is already stored locally on the client. If it is, the locally stored resource is reused; otherwise, it is downloaded from the server. In another implementation, when deleting a story package, the client determines the association between the story package and shared resources based on the resource management information, identifies the corresponding shared resource, and then queries the shared resource mapping table in the resource management information to determine whether the shared resource is also associated with other story packages besides the story package. If it is associated with other story packages, the shared resource is retained; otherwise, it is deleted from the client.

[0033] In one implementation, after generating resource management information for each story pack, the above method may further include: Configure download priority for shared resources.

[0034] Download priority is used to indicate the download order of multiple shared resources when the client needs to download them. When a client needs to download multiple shared resources, they can be downloaded sequentially in descending order of priority. Different shared resources can be configured with different download priorities. The download priority of a shared resource can be determined based on the number of story packs referenced by that shared resource. Shared resources referenced by more story packs are assigned a higher download priority. For example, if shared resource R1 is referenced by 5 story packs and shared resource R2 is referenced by 2 story packs, then R1 has a higher download priority than R2, and the client will download R1 first. This is because shared resources referenced by more story packs have higher utilization, and prioritizing their download can more quickly meet the operational needs of more story packs. The download priority of a shared resource can also be determined based on its file size. Smaller files are assigned a higher download priority. This allows for faster downloading of multiple small files, reducing the user's perceived waiting time. The download priority of a shared resource can also be determined based on its type. For example, audio resources are assigned a higher download priority, and video resources are assigned a lower download priority, because audio resources are usually smaller in size and have a more direct impact on the story experience; prioritizing their download allows users to quickly obtain the complete audio experience of the story.

[0035] In another implementation, if shared resources are not configured with a specific download priority, all shared resources can have the same default priority, and clients can download them in any order or sequentially according to the resource list. After configuring download priorities for shared resources, these priorities can be stored on the server and sent to the client as part of the resource management information. Through these implementation methods, the download strategy for shared resources can be optimized, ensuring that important or high-priority shared resources are downloaded first, thereby improving the efficiency and experience of users acquiring resources.

[0036] Based on the above description, in this exemplary embodiment, story resource data corresponding to multiple story packs in the game is obtained; the story resource data corresponding to the multiple story packs is subjected to reuse analysis, and story resource data that exists simultaneously in at least two story packs is identified as shared resources; resource management information for each story pack is generated based on the association relationship between each story pack and the shared resources; and the resource management information is sent to the client so that the client can process each story pack based on the resource management information. On the one hand, by identifying shared resources that exist simultaneously in multiple story packs and establishing their association relationship with each story pack, the client can accurately know the correspondence between each story pack and the shared resources, thereby avoiding duplicate downloads of shared resources already stored locally during download. On the other hand, by generating resource management information containing association relationships, the client can accurately determine whether the shared resources are still being used by other story packs when deleting a story pack, thereby avoiding accidental deletion of resource data that is still referenced by other story packs.

[0037] In one implementation, the above-described reuse analysis of story resource data in multiple story packs, identifying resource data that simultaneously exists in at least two story packs as shared resources, may include: For any story pack, determine the intersection between the story resource data in that story pack and the story resource data of other story packs, and define the intersection as the shared resources between that story pack and other story packs.

[0038] In this context, intersection refers to the set of elements that exist in both sets. For any story pack, its story resource data constitutes a resource data set, and the story resource data of other story packs each constitute their own resource data set. The intersection of these resource data sets is the resource data that these story packs share, and this shared resource data is defined as shared resources.

[0039] In one implementation, the intersection of the story resource data set of each story package with the story resource data sets of every other story package can be calculated sequentially. Specifically, the server obtains the story resource data set of the first story package and compares it with the story resource data set of the second story package to find the resource data that exists in both sets. This shared resource data is the shared resource between the first and second story packages. Then, the story resource data set of the first story package is compared with the story resource data set of the third story package to find the shared resource data that exists between the first and third story packages. This process continues until the shared resources between the first story package and all other story packages are determined. The above process is then repeated for the second story package, the third story package, and so on, until the shared resources between all story packages are determined. It should be noted that the determination of the shared resources between any story package and other story packages is performed independently. For example, the shared resources between P1 and P2 are b and c, and the shared resource between P1 and P3 is c. The two intersection results correspond to different sets of shared resources. Meanwhile, for the same pair of story packs, the intersection calculated from the perspective of P1 is the same as the intersection calculated from the perspective of P2. That is, the shared resources of P1 and P2 are the same as the shared resources of P2 and P1. Therefore, in specific implementation, duplicate calculations can be avoided by recording the resource pack pairs that have already been processed.

[0040] The process of determining the intersection can also include other implementation methods. For example, it can be based on the identification information of resource data. Each resource data can have a unique identifier, such as the path of a resource file, the hash value of a resource file, or a unique identifier of a resource file. When calculating the intersection, the identifiers of the resource data can be compared to determine whether two resource data are the same resource. Alternatively, it can be implemented through set operations. Specifically, the resource data in the story resource data set of each story pack can be sorted or hash-indexed according to their identification information, and then the intersection of the two sets can be calculated using the set intersection operation function. Through the above implementation methods, the shared resources between story packs can be accurately and efficiently determined, providing a reliable data foundation for the subsequent generation of resource management information.

[0041] By identifying shared resources in the above manner, the association between each shared resource and each story pack can be accurately recorded when generating resource management information in the future.

[0042] In one embodiment, the above method may further include: Shared resources are removed from the story resource data of each story pack to obtain the exclusive resources corresponding to each story pack; The resource management information for each story pack, generated based on the association between each story pack and shared resources, may include: Based on exclusive resources and the relationship between each story pack and shared resources, resource management information for each story pack is generated.

[0043] In this context, exclusive resources refer to resource data that exists only in a single story package and is not referenced by any other story package. After determining the shared resources among the story packages in step S120, for any story package, all resource data identified as shared resources are removed from its story resource data. The remaining story resource data is the exclusive resource of that story package. For example, assuming the story resource data of story package P1 includes resource files a, b, and c, where resource files b and c are identified as shared resources, after removing b and c from P1's story resource data, resource file a becomes P1's exclusive resource. After shared resources are removed, they no longer belong to any story package's exclusive resource but are managed as independent shared resources. In one implementation, removing shared resources from the story resource data of each story package can be achieved using set difference operations. For each story package, subtracting the set of shared resources associated with that story package from its story resource data set yields the exclusive resource set of that story package.

[0044] After determining the exclusive resources of each story pack and the association between each story pack and shared resources, the server incorporates the information about exclusive resources and the association information of shared resources into the resource management information. For example, the resource management information of story pack P1 can record that P1's exclusive resource is resource file a, and P1's associated shared resources are resource files b and c. By combining the information about exclusive resources and the association information of shared resources into the resource management information, the client can fully understand the resource composition of each story pack after obtaining the resource management information, that is, which exclusive resources the story pack contains and which shared resources the story pack is associated with.

[0045] In one implementation, the above-mentioned acquisition of story resource data corresponding to multiple story packs in the game may include: Obtain multiple story packs in the game, as well as the mapping relationship between multiple story packs and story content identifiers; Based on the mapping relationship between multiple story packs and story content identifiers, determine the story files corresponding to each story pack; Parse the resource reference information in the plot file to determine the resource data referenced by the plot file; Based on the resource data referenced in the story files, determine the story resource data corresponding to multiple story packs.

[0046] The plot content identifier is used to uniquely identify a segment of plot content in the game. It can be a chapter identifier, node identifier, quest identifier, or plot paragraph identifier. A chapter identifier identifies a chapter in the game; for example, "Chapter_01" represents the first chapter. A node identifier identifies a plot node; for example, "Node_003" represents the third plot node. A quest identifier identifies a game quest; for example, "Quest_1001" represents quest number 1001. A plot paragraph identifier identifies a paragraph within the plot; for example, "Paragraph_01" represents the first plot paragraph. Through plot content identifiers, a specific segment of plot content and its corresponding plot file can be uniquely located within the game project. A mapping relationship exists between plot packages and plot content identifiers. This mapping relationship can be stored in a configuration file or a database, indicating which plot content each plot package corresponds to. The plot file describes the plot content and can include plot flow, dialogue, events, and information about resources referenced by the plot. The plot file format can be a script file, configuration file, JSON file, XML file, or other custom format.

[0047] In one implementation, the server first obtains multiple story packs from the game, along with the mapping relationship between each story pack and its corresponding story content identifier. This mapping relationship can be pre-configured, and the server can obtain it by reading a configuration file or querying a database. Then, based on this mapping relationship, the server determines the story content identifier corresponding to each story pack, and further determines the corresponding story file based on the story content identifier. For example, if the story content identifier corresponding to story pack P1 is "Chapter_01", the server finds the story file describing the first chapter's story based on this identifier. Next, the server parses the resource reference information in the story file, extracting the resource paths or resource identifiers recorded in the story file to determine the resource data referenced by that story file. The resource reference information can include directly referenced resource paths or indirectly referenced resource paths. Directly referenced resource paths refer to the paths corresponding to resources directly recorded in the story file and directly called by the story flow, such as the audio file path corresponding to a dialogue in the story file or the background image file path corresponding to a scene. Indirectly referenced resource paths refer to the paths of other resources that resources directly referenced by a story file further depend on. For example, if a story file directly references a character model file, and that character model file further references texture files, audio files, effects files, animation files, video files, or prefab files, then the paths of these texture files, audio files, effects files, animation files, video files, or prefab files are the indirectly referenced resource paths. When determining resource data, the server needs not only to obtain the directly referenced resources but also to trace the indirectly referenced resources that the directly referenced resources depend on layer by layer until all levels of dependent resources are obtained. Finally, the server determines the story resource data corresponding to each story package based on the resource data referenced by the story file. In one implementation, the resource data obtained by parsing the story file is the story resource data corresponding to that story package. In another implementation, the parsed resource data needs to be further processed before it can be used as the story resource data corresponding to the story package; for example, resource data called by non-story systems needs to be removed.

[0048] In another implementation, the server can retrieve multiple story packs and their mapping relationships corresponding to a specified game version from the version management system based on the version number. Different game versions may have different story content, and the corresponding story packs may also be different. For example, game version V1.0 has story packs 1 to 5, while game version V2.0 adds story pack 6. The server can retrieve the corresponding set of story packs based on the currently processed version number. By obtaining multiple story packs and their corresponding story resource data, a data foundation can be provided for subsequent reuse analysis, enabling the identification of shared resources to be performed globally.

[0049] Figure 2A flowchart illustrating the identification of shared resources and generated resource subpackages is shown, which may specifically include the following steps: Step S202: Obtain the story resource list corresponding to each story pack; such as story pack resource list 1, story pack resource list 2, ..., story pack resource list n; Step S204: Perform reuse analysis on the story resource data of each story pack to identify shared resources between story packs; Step S206: Generate a list of shared resources for each story pack, record a table of shared resource mapping relationships, and generate a list of exclusive resources for each story pack. Step S208: Output the generated exclusive resource list and shared resource list respectively. The exclusive resource list of each story pack is used to generate the corresponding story pack resource pack in the future. The shared resource mapping table and shared resource list are used to generate shared resource packs in the future and provide them to each story pack. For example, exclusive resource list 1 + shared resource list 1 of the story pack, exclusive resource list 2 + shared resource list 2 of the story pack, ..., exclusive resource list n + shared resource list n of the story pack. Step S210: Generate the resource packs corresponding to each story pack; Step S212: Associate and output the resource packs of each generated story pack with the corresponding shared resource list; for example, resource pack 1 of story pack + shared resource list 1, resource pack 2 of story pack + shared resource list 2, ..., resource pack n of story pack + shared resource list n; Step S214: Construct a shared resource mapping table based on the shared resource list of each story pack; Step S216: Generate a shared resource package based on the shared resource mapping relationship table.

[0050] The story pack resource list refers to a list of resource identifiers or resource paths corresponding to each story pack. It records the identification information of the resources referenced by the story pack, such as the path or resource ID of the resource file, and may not include the actual resource data. Shared resources refer to the resource data in the story resource data that exists in at least two story packs. The shared resource list is a list indexed by story packs, recording which shared resources each story pack is associated with. It can store the identification information of shared resources, and each story pack corresponds to one shared resource list. The shared resource mapping table can be used to reflect the relationship between shared resources and story packs. It can record a global mapping table of which story packs reference each shared resource. The shared resource mapping table and the shared resource list can record the same set of mapping relationships, but from different organizational perspectives. The shared resource list facilitates querying the shared resources associated with a story pack from the story pack side, while the shared resource mapping table facilitates querying which story packs reference a shared resource from the shared resource side. The exclusive resource list refers to the list of resources that belong only to that story pack after removing shared resources from the complete resource data of the story pack. A story pack's resource package is a physical file generated based on the exclusive resource list, containing the actual data of the story pack's exclusive resources. Each story pack corresponds to one resource package. A shared resource package is a physical file generated based on the shared resource list and shared resource mapping table, containing the actual data of all shared resources. All shared resources are packaged into the same shared resource package, and the client retrieves the required shared resources from this data package as needed, based on the shared resource list corresponding to the story pack.

[0051] In one implementation, determining the story resource data corresponding to multiple story packs based on the resource data referenced in the story file may include: Remove resource data that is not called by the story system from the resource data to obtain the story resource data corresponding to the story pack.

[0052] Non-story systems refer to all functional systems in the game other than the story system, such as the combat system, quest system, character system, event system, shop system, or social system. Resource data accessed by non-story systems refers to resource data that is loaded by other functional systems besides the story system. If a resource is accessed by a non-story system, it cannot be included in the story package because it also needs to serve other systems; including it in the story package might cause those other systems to malfunction. The basis for removing resource data accessed by non-story systems can be the resource loading record. This record contains information about the system from which each resource was loaded; querying this record can determine whether a resource was ever loaded by a non-story system.

[0053] In one implementation, after the server obtains the resource data from parsing the story file, it queries the resource loading record for each resource data to determine the system to which it originated. If the query shows that the resource data was loaded by a non-story system, it is removed from the story package's resource data. If the query shows that the resource data was only loaded by the story system and never by any non-story system, it is retained and used as the story resource data corresponding to the story package. For example, assuming the resource data obtained from parsing the story file includes R1, R2, and R3, and the resource loading record shows that R1 was only loaded by the story system, R2 was loaded by both the story system and the combat system, and R3 was only loaded by the story system, then R2 is removed because it was called by a non-story system, while R1 and R3 are retained. Ultimately, the story resource data corresponding to this story package are R1 and R3.

[0054] In another implementation, the criterion for removing resource data accessed by non-storyline systems could be to remove it whenever the resource data has been loaded by a non-storyline system even once. Alternatively, the criterion could be to remove resource data only when the number of times it is loaded by a non-storyline system exceeds a preset threshold, such as 5 times. If a resource data is loaded by a non-storyline system more than 5 times, it is removed; if it is loaded less frequently, it can be retained. This avoids the accidental removal of resources due to occasional non-storyline calls.

[0055] Through the above implementation method, the plot resource data corresponding to each plot pack can be accurately obtained, ensuring that the resource data included in each plot pack only serves the corresponding plot content, avoiding the incorrect inclusion of cross-system shared resources into plot packs, thereby avoiding affecting the normal operation of other systems.

[0056] In one implementation, the process of removing resource data that is not accessed by the story system from the resource data to obtain the story resource data corresponding to the story package may include: Retrieve resource loading records; the resource loading records show the system to which each resource data originated when it was loaded. If the resource data referenced by the story file is found to be loaded from a non-story system according to the resource loading record, then the resource data will be removed. The removed resource data will be used as the story resource data for the story pack.

[0057] The resource loading record refers to a collection of information about the systems to which each resource data belongs when it is loaded during game execution. It can be constructed by collecting and statistically analyzing resource loading behavior during game operation. The resource loading record can record one or more systems to which each resource data belongs as a loading source. For example, if resource R1 has been loaded by both the story system and the battle system, then the resource loading record will record that R1 belongs to both the story system and the battle system.

[0058] In one implementation, after the server obtains the resource loading record, for each resource data in the resource data referenced by the story file, it queries the resource loading record to find the system to which the loading source belongs. If the query result shows that the loading source system corresponding to the resource data includes non-story systems, then the resource data is removed; if the query result shows that the loading source system corresponding to the resource data only includes story systems, then the resource data is retained. For example, assuming the resource data referenced by the story file includes R1, R2, and R3, and the resource loading record records that R1 is loaded by the story system, R2 is loaded by both the story system and the combat system, and R3 is loaded only by the story system, then R2 is removed because its loading source system includes a non-story system (combat system), while R1 and R3 are retained, and the removed R1 and R3 are used as the story resource data corresponding to this story package.

[0059] In another implementation, the removal criterion could be to remove the resource data if any non-story system exists in the system to which the loading source belongs. Alternatively, the removal criterion could be to remove the resource data only when the number of times it is loaded by a non-story system exceeds a preset threshold, thus avoiding accidental removal of resources due to occasional non-story system calls.

[0060] Through the above implementation method, it is possible to accurately determine whether each resource data is called by a non-story system based on the resource loading record, remove resource data whose callers include non-story systems, ensure that the story resource data corresponding to the story package only serves the story system, and avoid incorrectly classifying cross-system shared resources into the story package.

[0061] Figure 3 This diagram illustrates a flowchart for obtaining story resource data corresponding to multiple story packs in a game, which may specifically include the following steps: Step S302: Determine the mapping relationship between each plot package and the plot content identifier; Step S304: Obtain multiple story packs from the game; Step S306: Based on the mapping relationship between each plot package and plot content identifier, parse the resource reference information in the plot file corresponding to each plot package; Step S308: Based on the parsing results, generate a list of candidate resources for each story pack. Step S310: Filter the resource data in the candidate resource list of each story package and remove resource data that has been loaded and recorded by non-story system. Step S312: Determine the resource list of each story pack based on the filtering results.

[0062] The mapping relationship between story packs and story content identifiers refers to the identifier information of the story content corresponding to each story pack, indicating which story content the story pack is associated with. This mapping relationship allows the location of the corresponding story file. The story pack candidate resource list is the initial list of resource identifiers obtained after parsing the resource reference information in the story file; the resource data in this list has not yet been filtered. The story pack resource list is the final resource list obtained after filtering the candidate resource list; it may include identifier information of which resource data the story pack requires.

[0063] In one implementation, before removing resource data accessed by non-storyline systems from the resource data, the method may further include: Obtain resource loading behavior information and generate resource loading records based on the resource loading behavior information.

[0064] The resource loading record records information about the system from which each resource data is loaded. This information serves as a basis for removing resource data from the story pack that has been called by non-story systems. Specifically, querying this record can determine whether a resource data has been loaded by a non-story system, thus deciding whether that resource data can be included in the story pack. The resource loading record can be represented in the form of a resource loading record library, which is constructed by collecting and statistically analyzing resource loading behavior during game execution.

[0065] In one implementation, resource loading behavior information can be collected through code instrumentation in the game program's resource loading function or interface. When resource loading is triggered during game execution, the instrumented code automatically records information such as the resource path, the identifier of the system to which the loading source belongs, the loading time, and the top-level interface identifier of the current game interface, and reports this information to the server or log system, forming a resource loading record. In another implementation, resource loading behavior information can also be actively reported by the client to the server, and the server, upon receiving the reported information, writes it into the resource loading record.

[0066] In one implementation, the collected resource loading behavior information may include a resource loading record identifier (ID, Identity), a resource path (Uri), a system identifier of the loading source (Belong), a reporting time (Upload_time), and a top-level interface identifier (Topview). The resource loading record identifier uniquely identifies a resource loading record and can be generated by combining the resource path and the system identifier of the loading source, uniquely distinguishing the resource loading record within the story system. The resource path identifies the loaded resource data and can be a relative path, an absolute path, or a Uniform Resource Identifier (URI). The system identifier of the loading source identifies the system to which the resource loading originates. This system can be a story system, combat system, quest system, character system, event system, shop system, social system, or interface system, etc., and can be represented by the system name, system number, or system ID. The reporting time identifies the reporting time or last reporting time of this resource loading behavior. The top-level interface identifier identifies the client's current top-level interface when the resource is loaded, representing the user's interface context at the time of the resource loading.

[0067] In one implementation, for resource loading behavior information with the same resource loading record identifier—that is, loading behaviors with the same resource path and the same system identifier of the loading source—an overwrite update method can be used to retain the latest reported resource loading behavior information. For example, if the resource file "character / hero.png" is loaded multiple times by the story system, each load will generate a reporting message. These reporting messages have the same resource path and the same system identifier of the loading source (story system), so their resource loading record identifiers are the same. Only the latest reported message is retained, and the previous records are overwritten, thereby avoiding the storage of a large amount of duplicate data in the resource loading records and reducing storage space usage.

[0068] By generating resource loading records, it is possible to record which systems loaded each resource during game execution. This provides a basis for judging which resource data was called by non-story systems when removing it from the resource data of the story package. For example, if resource A is recorded in the resource loading record as having been loaded by both the story system and the basic game system, then this resource is determined to have been called by non-story systems and cannot be included in the story resource package. If resource B is recorded in the resource loading record as having been loaded only by the story system, then this resource was not called by non-story systems and can be included in the story resource package.

[0069] In one embodiment, the above method may further include: Determine the resource data to be distributed during the game update phase; Based on the resource management information of each story pack, identify the off-pack resource data that has not been included in the story pack from the resource data to be distributed; According to the preset merging rules, the external resource data is divided into one or more download units, and corresponding index information is generated for each download unit; The index information is sent to the client so that the client can download the download unit based on the index information.

[0070] The game update phase can be a game version update or resource patch distribution phase. For example, when a new version of the game is released, new or updated resources need to be distributed to the client online; this phase is the game update phase. In this embodiment, the processing of story resources is completed during the game resource packaging phase. That is, resource management information for each story package is generated through story package division and shared resource identification, allowing story resources to be downloaded and deleted on demand within the game, eliminating the need for patch distribution during the game update phase and thus reducing the amount of resources downloaded during the game update phase. The resource data to be distributed refers to the resource files that need to be distributed to the client in the new version. It can be determined through version difference comparison, for example, by comparing the resource list of the new version with the resource list of the old version to determine the resources that need to be added or updated. The resource management information records the story resource data corresponding to each story package, i.e., which resources have been included in the story package. The server uses this information to exclude resources already included in the story package from the resource data to be distributed, and the remaining ones are the resource data outside the package. External resource data refers to resource data that is not included in any story pack. This includes story-related resources that have been removed from story packs due to being accessed by non-story systems, as well as general resources unrelated to the story, such as general UI resources, system function resources, or global configuration resources. External resource data cannot be obtained by the client through the on-demand download mechanism of story packs; therefore, it needs to be distributed via patches during game updates.

[0071] Preset merging rules determine how to distribute out-of-package resource data across download units. These rules can be based on resource package (resources belonging to the same package are grouped into the same download unit), resource path (resources with similar paths are grouped into the same download unit, e.g., all audio resources with paths starting with " / audio / " are grouped into the same download unit), resource type (resources of the same type are grouped into the same download unit, e.g., all audio resources are grouped into one download unit, and all image resources into another), resource version (resources of the same or similar versions are grouped into the same download unit), target platform (resources for different target platforms are grouped into different download units, e.g., resources for Android are grouped into download unit A, and resources for iOS are grouped into download unit B), or combinations of these rules. By using preset merging rules, large amounts of scattered out-of-package resource data can be organized into a small number of large file download units, thereby reducing the number of network requests.

[0072] In one implementation, after determining the external resource data and before dividing it according to preset merging rules, the external resource data can be further filtered. Specifically, resources in the external resource data can be filtered based on one or more of the following: resource loading record information, resource type identifier, the functional module to which the resource belongs, or the resource size. Resources that are not suitable for merging and transmission can be removed. For example, resources with excessively large file sizes can be distributed separately without participating in unit division, or certain specific types of resources can be distributed separately.

[0073] Index information is auxiliary information used to describe the structure and content of download units. After merging, corresponding index information is generated for each download unit, which may include the download unit identifier, the resource file entries contained in the download unit, the offset position of each resource file in the download unit, the length of each resource file, the verification information and version information of each resource file. The download unit identifier is used to uniquely identify a download unit, such as "DownloadUnit_001" or "DU_001". The resource file entries record which resource files are contained in the download unit, as well as the name and path of each resource file. The offset position indicates the starting position of the resource file in the download unit, allowing the client to extract a specific resource file from the download unit based on the offset position. The length indicates the size of the resource file, allowing the client to determine the amount of data to be read. Verification information, such as MD5 or SHA values, is used to verify the integrity of the resource file. Version information indicates the version number of the resource file.

[0074] After the server sends the index information to the client, the client can obtain the download address and resource location information of each download unit based on the index information, and then download the corresponding download unit. After the client completes the download, it can perform an integrity check on the download unit according to the verification information in the index information. If the check passes, the client can extract each resource file from the download unit according to the offset position and length of each resource file in the index information, unpack and restore it, and then write it to its corresponding target resource directory, completing the resource deployment during the game update phase.

[0075] In one implementation, the index information can also be used for exception handling and compatibility control. When a client encounters an exception while downloading or processing a download unit, it can perform recovery or compatibility processing based on the index information. Specifically, when a download unit verification fails, the client can re-fetch the corresponding resource file in single-file mode based on the resource file entries in the index information. Verification failure may be due to network transmission errors, storage errors, or other reasons causing partial data corruption in the download unit. In this case, re-downloading the entire download unit might consume a lot of time and bandwidth. Through the index information, the client can determine which resource files are corrupted and then re-download these resource files in single-file mode, without having to re-download the entire download unit. When an unpacking exception occurs, the client can also re-fetch the corresponding resource file in single-file mode based on the resource file entries in the index information. Unpacking exceptions may be caused by corrupted compressed files or errors during the decompression process. The client can determine which resource files cannot be unpacked normally based on the index information and then re-download these resource files in single-file mode. When writing the target resource fails, the client can also re-fetch the corresponding resource file in single-file mode based on the resource file entries in the index information. Write failures may be due to insufficient disk space, file permission issues, or other storage errors. The client can retry writing or write the resource file to an alternative location. Through these exception handling methods, when an exception occurs in the download unit, the client can use the index information to retrieve the resource as a single file, without needing to re-download the entire download unit. This ensures the stability and efficiency of the update process and reduces bandwidth and time consumption in abnormal situations.

[0076] Through the above implementation methods, the story resources are divided into packages and shared resources are identified during the game resource packaging stage. This allows story resources to be managed independently within the game through on-demand downloading and deletion, eliminating the need for patch distribution during game updates and reducing the amount of resources downloaded during these stages. Simultaneously, the external resource data is consolidated, grouping large amounts of scattered external resource data into larger download units for distribution. This reduces the number of network requests, lowers protocol overhead and disk fragmentation write overhead in small file transfers, improves download speed and deployment efficiency, and reduces user waiting time during game updates.

[0077] In one implementation, the above-mentioned allocation of out-of-package resource data to one or more download units may include: Obtain pre-configured cell size information; The number of download units is determined based on the total data volume and unit size information of the external resource data to be distributed; Based on the number of download units and preset partitioning rules, resources in the external resource data are partitioned into corresponding download units.

[0078] The unit size information refers to the expected or maximum size of each download unit. This can be pre-configured based on factors such as network transmission efficiency, client storage performance, and download concurrency. For example, the size of each download unit can be configured to not exceed 100MB, or to be between 50MB and 100MB. The unit size information can be stored on the server as a configuration file, or configured and adjusted by operations personnel through a management interface. The number of download units refers to the total number of download units generated after merging. The number of download units can be obtained by dividing the total amount of out-of-packet resource data by the unit size information and rounding up. For example, if the total amount of out-of-packet resource data is 450MB and the unit size of each download unit is 100MB, then the number of download units is 5, i.e., 450 divided by 100 equals 4.5, rounded up to 5. In another implementation, the number of download units can also be manually specified by operations personnel without calculation.

[0079] After determining the number of download units, resources from outside the package can be allocated to the corresponding number of download units according to preset allocation rules. These preset allocation rules can be based on: resource package (resources belonging to the same package are allocated to the same download unit); resource path (resources with similar paths are allocated to the same download unit); resource type (resources of the same type are allocated to the same download unit); resource version (resources of the same or similar versions are allocated to the same download unit); target platform (resources for different target platforms are allocated to different download units); preset size threshold (when the accumulated resource size reaches the preset size threshold, these resources are allocated to one download unit, and then a new download unit allocation begins); preset package number (resources are directly and evenly distributed into a preset number of download units, with each download unit containing approximately the same number of resource files); or a combination of the above rules. In one implementation, the actual size of each download unit can be controlled during the allocation process by combining the unit size information, so that the size of each download unit is as close as possible to the unit size information, avoiding download units that are too large or too small.

[0080] Through the above implementation method, the resource data outside the package can be reasonably allocated to multiple download units according to the preset division rules, so that the size of each download unit is moderate. This can reduce the number of download requests and avoid the increased risk of download failure caused by an excessively large single download unit. At the same time, the diverse division rules can flexibly adapt to the resource organization characteristics of different game projects.

[0081] This disclosure also provides a game resource processing method, applied to a client, such as... Figure 4 As shown, the steps S410~S420 may be included: Step S410: Receive resource management information from the server; the resource management information is used to indicate the association between the story pack and the shared resources; the shared resources are resource data that exist simultaneously in the story resource data corresponding to at least two story packs.

[0082] Resource management information refers to server-generated information describing the resource composition and management strategies of each story pack. This includes the association information between each story pack and shared resources, such as which shared resources each story pack is associated with and which story packs reference each shared resource. A story pack refers to information associated with story content determined by game configuration. It indicates the association between the game's story content and resource data, but the story pack itself does not contain the actual resource data. Shared resources refer to resource data that exists simultaneously in the story resource data of at least two story packs. These resources can be used by multiple story content; for example, if the same character model is referenced by multiple chapters of the story, that character model data is a shared resource. Association refers to the correspondence between a shared resource and the story pack that references it. A shared resource can be associated with one or more story packs, and a story pack can be associated with multiple shared resources. For example, if shared resource R1 is referenced by story packs P1 and P2, then shared resource R1 has an association with both story packs P1 and P2. Resource management information can be stored on the server as a file. Clients can retrieve this resource management information from the server via the network. For example, a client can send a request to the server to obtain the latest resource management information when starting the game, entering a new game chapter, or when it needs to download a story pack.

[0083] Step S420: In response to receiving an operation request for the target story pack, process the target story pack according to the resource management information.

[0084] The target story pack can be any story pack. An operation request refers to a user's instruction to the target story pack, which can include download and deletion requests. In one implementation, when a user clicks the "Download a Chapter's Story" button in the game interface, the client receives a download request for the corresponding story pack. The client determines the exclusive and shared resources corresponding to the target story pack based on resource management information and then executes the corresponding download operation. In another implementation, when a user clicks the "Delete a Chapter's Story" button in the game interface, the client receives a deletion request for the corresponding story pack. The client determines the exclusive and shared resources corresponding to the target story pack based on resource management information and then executes the corresponding deletion operation.

[0085] Through the above implementation method, the client can intelligently manage the story pack according to the resource management information generated by the server. When downloading, it can reuse the stored shared resources to avoid duplicate downloads. When deleting, it can decide whether to retain or delete the shared resources based on whether they are still referenced by other story packs, thereby avoiding duplicate downloads and accidental deletion of shared resources.

[0086] In one implementation, the above-mentioned response to receiving an operation request for a target story pack, and processing the target story pack according to resource management information, may include: In response to receiving a download request for a target story pack, the system obtains the exclusive resources of the target story pack from the server and determines the target shared resources corresponding to the target story pack based on the association between story packs and shared resources. The management method for the target shared resource is determined based on whether it is already stored locally.

[0087] The target story pack can be any story pack. The client's download request for the target story pack can be triggered by user actions in the game; for example, if the user clicks the button to download a specific chapter's story in the game interface, the client sends a download request to the server for the story pack corresponding to that chapter.

[0088] Specifically, upon receiving a download request for a target story pack, the client can obtain the exclusive resources of that story pack from the server and determine the target shared resources corresponding to the target story pack based on the association between story packs and shared resources. Obtaining exclusive resources means the client sends a request to the server, the server sends the exclusive resources of the target story pack to the client, and the client receives and stores these exclusive resources. For example, the client can request the corresponding exclusive resource data from the server based on the identifier information of the exclusive resources recorded in the resource management information. The server reads these resources from the storage system and transmits them to the client via the network, where the client receives and stores them locally. Determining target shared resources means the client searches for all shared resources associated with the target story pack based on the association between story packs and shared resources recorded in the resource management information. For example, if the target story pack is P1, and its associated shared resources are R1 and R3, then the target shared resources are R1 and R3.

[0089] After identifying the target shared resource, the client determines its management method based on whether the target shared resource is already stored locally. The client can query the storage status of each target shared resource in local storage, for example, by checking if the corresponding shared resource file exists in the local resource directory. If the target shared resource is already stored locally, the client does not need to download it again; if the target shared resource is not stored locally, the client needs to download it from the server. In one implementation, the client can sequentially check the local storage status of each target shared resource. For target shared resources not stored locally, the client sends a download request to the server to obtain the corresponding shared resource data.

[0090] Through the above implementation method, when the client downloads the target story package, it can only download exclusive resources. For shared resources, it first checks whether they are already stored locally, and only downloads them if they are not stored locally. This avoids repeated downloads of shared resources and reduces network bandwidth consumption and storage space occupation.

[0091] In one implementation, determining the management method of the target shared resource based on whether it is already stored locally may include: If the target shared resource is already stored locally, then the stored target shared resource is reused; If the target shared resource is not stored locally, then download the target shared resource.

[0092] Reuse refers to the client directly using locally stored shared resources when loading a target story package without needing to download it again. For example, suppose the client has previously downloaded story package P2, which is associated with shared resource R1, so R1 is already stored locally on the client. Now the client needs to download story package P1, which is also associated with shared resource R1. When downloading P1, the client checks that R1 is already stored locally, so it directly reuses the locally stored R1 without needing to download R1 again from the server.

[0093] Downloading refers to a client requesting a shared resource from a server, the server sending the shared resource to the client, and the client receiving and storing the shared resource. For example, suppose the client needs to download the story pack P3, which is associated with the shared resource R2, but the client does not have R2 stored locally. In this case, the client needs to download R2 from the server and then store R2 locally.

[0094] In one implementation, when the target shared resource is not stored locally on the client, the server can send the target shared resource along with the exclusive resources of the target story pack to the client to reduce the number of network requests. For example, the server can package the exclusive and shared resources into a single package and send it to the client at once. The client then stores the exclusive and shared resources separately. In another implementation, when multiple target shared resources are not stored locally on the client, the client can download each target shared resource sequentially according to a preset download priority. For example, a download priority can be configured for shared resources, and the client downloads shared resources in descending order of priority, thereby ensuring that important shared resources are downloaded first. Through these implementation methods, the client can intelligently reuse stored shared resources when downloading story packs, downloading new shared resources only when necessary, thereby improving resource download efficiency and reducing network traffic consumption.

[0095] Figure 5 A flowchart illustrating a client downloading a target shared resource is shown, which may specifically include the following steps: Step S502: The client initiates a request to download the target story package; Step S504: In response to the download request, the client downloads the story resource data of the target story package from the resource data package 510 of the story package corresponding to the target story package; Step S506: The client checks whether there are any missing local shared resources in the target shared resources corresponding to the target story pack according to the shared resource list 520; Step S508: If there is a missing shared resource locally, the client downloads the missing target shared resource from the shared resource package 530. Step S510: After downloading the plot resource data of the target plot package and the missing target shared resources, the download of the target plot package is completed.

[0096] The story pack's resource data package stores the exclusive resource data of the target story pack. When downloading the target story pack, the exclusive resources are first retrieved from this resource data package. The shared resource package stores all shared resources. The client retrieves any missing shared resources from this shared resource package. The shared resource list records the association between the target story pack and shared resources, indicating which shared resources the target story pack requires. This allows the client to check if any corresponding shared resources are missing locally. The shared resource list may not include the actual data content of the shared resources.

[0097] In one implementation, the above-mentioned response to receiving an operation request for a target story pack, and processing the target story pack according to resource management information, may include: In response to receiving a deletion request for a target story pack, delete the exclusive resources of the target story pack, and determine the target shared resources corresponding to the target story pack based on the association between story packs and shared resources. The management method for the target shared resource is determined based on whether the target shared resource is associated with other story packs besides the target story pack.

[0098] Upon receiving a deletion request for a target story pack, the client removes the exclusive resources of that story pack from local storage. For example, the client can delete the exclusive resource files corresponding to the target story pack in the game's installation directory. Simultaneously, the client determines the target shared resources corresponding to the target story pack based on the associations between story packs and shared resources recorded in the resource management information. Determining the target shared resources means that the client searches for all shared resources associated with the target story pack based on the associations recorded in the resource management information. For example, if the target story pack is P1, and its associated shared resources are R1 and R3, then the target shared resources are R1 and R3.

[0099] After identifying the target shared resource, the client determines its management method based on whether the target shared resource is associated with other story packs besides the target story pack. This determination can be based on a shared resource mapping table, which records the correspondence between each shared resource and all associated story packs. The client can query the shared resource mapping table to obtain a list of all story packs associated with the target shared resource. If the list contains other story packs besides the target story pack, then the target shared resource is associated with other story packs besides the target story pack; if the list contains only the target story pack, then the target shared resource is not associated with other story packs besides the target story pack.

[0100] Through the above implementation method, the client can correctly delete exclusive resources when deleting the target story pack. For shared resources, it decides whether to keep or delete them based on whether they are still referenced by other story packs, thus avoiding the accidental deletion of shared resources that are still referenced by other story packs.

[0101] In one implementation, determining the management method of the target shared resource based on whether it is associated with other story packs besides the target story pack may include: If the target shared resource is associated with a story pack other than the target story pack, then the target shared resource is retained; If the target shared resource is not associated with any other story pack besides the target story pack, then delete the target shared resource.

[0102] Retention means that the client continues to store the shared resource locally without deleting it. For example, suppose shared resource R1 is associated with story packs P1, P2, and P3. If the client wants to delete story pack P1, a query of the shared resource mapping table shows that R1 is also associated with P2 and P3. Therefore, R1 should be retained and not deleted, because P2 or P3 may still be installed on the client and still require R1 to function. If the target shared resource is not associated with any other story pack besides the target story pack, then the target shared resource is deleted from the client.

[0103] Deletion refers to the client removing the shared resource from local storage and freeing up storage space. For example, suppose the shared resource R2 is only associated with the story pack P1. If the client wants to delete the story pack P1, it can be found by querying the shared resource mapping table that R2 is not associated with any other story packs besides P1. Therefore, R2 should be deleted because no other story packs need R2.

[0104] In one implementation, when deleting a target story package, the client first deletes the exclusive resources of the target story package, and then checks each shared resource associated with the target story package one by one. For each shared resource, the client queries the shared resource mapping table to determine whether the shared resource is still referenced by other installed story packages. If it is referenced by other installed story packages, the shared resource is retained; otherwise, it is deleted. In another implementation, the client can process the deletion of shared resources in batches. That is, it first identifies all shared resources associated with the target story package, then queries the shared resource mapping table to determine which shared resources are still referenced by other story packages and which are no longer referenced. All no longer referenced shared resources are deleted at once. In yet another implementation, the client can only mark the resource package as deleted when deleting the target story package, while the actual deletion of the resource files is delayed. For example, the client can first mark the target story package as pending deletion, and then actually delete the corresponding resource files when storage space is insufficient or at a specific time, thereby avoiding the performance overhead caused by frequent deletion operations.

[0105] Through the above implementation method, the client can intelligently handle shared resources when deleting story packs, only deleting shared resources that are no longer referenced by any installed story packs, and retaining shared resources that are still referenced by other story packs, thereby avoiding resource loss problems caused by accidental deletion, while maximizing the release of storage space.

[0106] Figure 6 The flowchart illustrates a client-side deletion of a target story pack, which may include the following steps: Step S602: The client initiates a request to delete the target story pack; Step S604: In response to the deletion request, delete the story resource data of the target story pack; Step S606: Based on the shared resource mapping relationship table 610 and the list of installed story packs 620, check whether the shared resources associated with the target story pack are still referenced by other installed story packs. Step S608: Delete shared resources that are not currently referenced by other installed story packs; Step S610: Complete the deletion of the target story pack.

[0107] Figure 7 This diagram illustrates a server-side processing flowchart for external resource data, which may include the following steps: Step S702: Determine the candidate resource data to be distributed during the game update phase; Step S704: Exclude story resource data that has been assigned to each story pack from the candidate resource data, and filter the remaining resource data according to other filtering rules; Step S706: Determine the filtered resource data as external resource data; Step S708: According to the preset merging rules, the external resource data is divided into one or more download units; Step S710: Generate each download unit and its corresponding index information; Step S712: Output the divided download units and the corresponding index information of each download unit; such as download unit 1 + index information 1, download unit 2 + index information 2, and order unit n + index information n, etc.

[0108] Candidate resource data refers to the set of resource files that need to be distributed to clients after version difference comparison during the game update phase. When a new version of the game is released, the server compares the resource list of the new version with the resource list of the old version to determine the resource files that need to be added or updated; these resource files can serve as candidate resource data. Figure 6 In step S604, candidate resource data serves as the input. The server excludes story resource data already included in various story packs (i.e., resources that can be obtained through the story pack on-demand download mechanism) from the candidate resource data. Further filtering is then performed based on other filtering rules (such as filtering excessively large files or specific file types). The remaining resource data is the off-packet resource data. This off-packet resource data is then divided into one or more download units in step S608, and corresponding index information is generated. The final output is then available for client download.

[0109] Figure 8 A flowchart of a client-side download processing unit is shown, which may specifically include the following steps: Step S802: During the game update phase, the client requests and downloads the target download unit; Step S804: Verify the integrity of the target download unit based on the index information 800; If the verification fails, proceed to step S806 to retrieve the corresponding target resource again based on index information 800. After retrieval, you can either return to step S704 to re-execute the verification or continue execution. If the verification passes, proceed to step S808, unpack the target download unit according to the index information 800, and restore each resource file; Step S810: Deploy the restored resource files to the corresponding target resource directory; Step S812: Complete the resource deployment for the game update phase.

[0110] The game update phase refers to the game version update or resource patch distribution phase. During this phase, the client obtains the actual resource files corresponding to the external resource data by downloading download units. Index information is auxiliary information generated by the server when creating download units. It can include the download unit identifier, the resource file entries contained in the download unit, the offset position of each resource file in the download unit, the length of each resource file, the verification information and version information of each resource file. Based on the index information, the client can determine the position and size of each resource file in the download unit, thereby verifying the integrity of the download unit during verification and extracting each resource file from the download unit during unpacking. The target download unit refers to the download unit currently requested by the client. The target resource refers to one or more specific resource files in the download unit. When a verification error occurs, the client re-fetches the target resource as a single file based on the index information, rather than re-downloading the entire target download unit. Resource files refer to the actual resource data files existing in the game, such as audio files, video files, image files, model files, animation files, or configuration files. The resource files restored after unpacking by the client are these actual resource files, which can be deployed to the target resource directory for use during game runtime.

[0111] Figure 9 This diagram illustrates an overall flowchart of a game resource processing method, which may include the following steps: Step S902: Obtain resource loading behavior information; Step S904: Generate a resource loading record based on the resource loading behavior information; Step S906: parse the plot resource reference relationships in the plot files corresponding to each plot package; Step S908: Construct a plot resource reference relationship library based on plot resource reference relationships; Step S910: Based on the plot resource reference relationship library, divide the plot resource data of each plot package into plot resources according to the plot, and remove the resource data referenced by non-plot systems. Step S912: Perform reuse analysis on the story resource data of each story package after removal, and identify cross-story shared resources; Step S914: Output each story pack and its corresponding shared resource list; e.g., Story Pack 1 + Shared Resource List 1, Story Pack 2 + Shared Resource List 2, ..., Story Pack n + Shared Resource List n Step S916: Determine the off-package resource data that has not been included in the story package; Step S918: Filter the data for resources outside the package based on resource usage. Step S920: Merge the filtered out-of-package resource data to generate a download unit; Step S922 yields multiple download units; for example, download unit 1, download unit 2, ..., download unit n; Step S924: The client downloads the story pack as needed; Step S926: The client dynamically uninstalls the story pack as needed; In step S928, the client downloads and decompresses the download unit.

[0112] The resource loading record is generated based on resource loading behavior information and records the system to which each resource data originates when it is loaded. The plot resource reference relationship refers to the resource reference information recorded in the plot files, including resource paths or resource identifiers directly and indirectly referenced by the plot content. The plot resource reference relationship database is a database built based on the resource reference information in the plot files corresponding to each plot package, used to record the resource data referenced by each plot package. A download unit is a large file generated after dividing the external resource data; each download unit contains multiple resource files. Client-side on-demand download refers to the client downloading exclusive resources and missing shared resources of the target plot package according to actual needs. Client-side on-demand dynamic uninstallation refers to the client determining whether a shared resource is still referenced by other plot packages when deleting a target plot package, based on the shared resource mapping table and the list of installed plot packages; if not, the shared resource is deleted. Download unit download and decompression / restore refers to the client verifying, decompressing, and restoring each resource file based on the index information after downloading the download unit, and then deploying it to the corresponding target resource directory.

[0113] An exemplary embodiment of this disclosure also provides a game resource processing apparatus applied to a server. (Refer to...) Figure 10 The game resource processing device 1000 may include: a resource data acquisition module 1010, used to acquire story resource data corresponding to multiple story packs in the game; a shared resource determination module 1020, used to perform reuse analysis on the story resource data corresponding to multiple story packs, and determine the story resource data that exists in at least two story packs at the same time as shared resources; a management information generation module 1030, used to generate resource management information for each story pack based on the association relationship between each story pack and the shared resources; and a management information sending module 1040, used to send the resource management information to the client so that the client can process each story pack based on the resource management information.

[0114] In one implementation, the shared resource determination module includes: a reuse analysis unit, configured to, for any story package, determine the intersection between story resource data in any story package and story resource data of other story packages, and determine the intersection as the shared resource between any story package and other story packages.

[0115] In one embodiment, the game resource processing device further includes: a resource removal module, used to remove shared resources from the story resource data of each story pack to obtain exclusive resources corresponding to each story pack; and a story pack management module, used to generate resource management information for each story pack based on the exclusive resources and the association between each story pack and the shared resources.

[0116] In one implementation, the resource data acquisition module is used to acquire multiple story packs in the game, as well as the mapping relationship between the multiple story packs and story content identifiers; determine the story file corresponding to each story pack based on the mapping relationship between the multiple story packs and story content identifiers; parse the resource reference information in the story file to determine the resource data referenced by the story file; and determine the story resource data corresponding to the multiple story packs based on the resource data referenced by the story file.

[0117] In one implementation, the resource data acquisition module is used to remove resource data that is called by non-story systems from the resource data to obtain the story resource data corresponding to the story package.

[0118] In one implementation, a resource data acquisition module is used to acquire resource loading records; the resource loading records record the system to which the loading source of each resource data belongs when it is loaded; for resource data referenced by the plot file, if the system to which the loading source of the resource data belongs according to the resource loading record includes a non-plot system, then the resource data is removed; the removed resource data is used as the plot resource data corresponding to the plot package.

[0119] In one embodiment, the game resource processing device further includes a loading record generation module, used to acquire resource loading behavior information and generate resource loading records based on the resource loading behavior information.

[0120] In one embodiment, the game resource processing device further includes: an off-package resource processing module, used to determine the resource data to be distributed during the game update phase; to determine off-package resource data not included in the story pack from the resource data to be distributed according to the resource management information of each story pack; to divide the off-package resource data into one or more download units according to a preset merging rule, and to generate corresponding index information for each download unit; and to send the index information to the client so that the client can download the download unit according to the index information.

[0121] In one implementation, the out-of-package resource processing module is used to obtain pre-configured unit size information; determine the number of download units based on the total data volume and unit size information of the out-of-package resource data to be distributed; and divide the resources in the out-of-package resource data into the corresponding download units according to the number of download units and preset division rules.

[0122] An exemplary embodiment of this disclosure also provides a game resource processing apparatus applied to a client. (See also...) Figure 11 The game resource processing device 1100 may include: a management information acquisition module 1110, used to receive resource management information from the server; the resource management information is used to indicate the association between the story pack and the shared resources; the shared resources are resource data that exist simultaneously in the story resource data corresponding to at least two story packs; and a story pack processing module 1120, used to process the target story pack according to the resource management information in response to receiving an operation request for the target story pack.

[0123] In one implementation, the story package processing module includes: a download unit, configured to, in response to receiving a download request for a target story package, obtain exclusive resources of the target story package from the server, and determine the target shared resource corresponding to the target story package based on the association between the story package and shared resources; and determine the management method of the target shared resource based on whether the target shared resource is already stored locally.

[0124] In one implementation, the download unit is configured to reuse the stored target shared resource if it is already stored locally, and download the target shared resource if it is not stored locally.

[0125] In one implementation, the story pack processing module includes: a deletion unit, configured to, in response to receiving a deletion request for a target story pack, delete the exclusive resources of the target story pack, and determine the target shared resource corresponding to the target story pack based on the association between the story pack and shared resources; and determine the management method of the target shared resource based on whether the target shared resource is associated with other story packs besides the target story pack.

[0126] In one implementation, the deletion unit is configured to retain the target shared resource if it is associated with a story pack other than the target story pack, and delete the target shared resource if it is not associated with a story pack other than the target story pack.

[0127] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0128] 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 exemplary embodiments of this disclosure, 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.

[0129] Exemplary embodiments of this disclosure also provide a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the above-described game resource processing method.

[0130] In one implementation, the computer program product can be a tangible product containing a computer program, such as a computer-readable storage medium storing the computer program. The readable storage medium can be a storage medium based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, including but not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. For example, the computer program product can be implemented as a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0131] In one implementation, the computer program product can be an intangible product containing a computer program. For example, the computer program product can be implemented as a virtual digital product, such as an executable file, installation package, or other digital file storing the computer program.

[0132] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0133] Computer programs can be carried or transmitted via signals such as electricity, magnetism, light, electromagnetic fields, and infrared radiation. Electronic devices can convert the signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, to execute by the processor of the electronic device) the method steps of various exemplary embodiments of this disclosure, such as the game resource processing method described above.

[0134] Exemplary embodiments of this disclosure also provide an electronic device. The electronic device may include a processor and a memory. The memory stores executable instructions of the processor, such as program code. The processor executes the executable instructions to perform the methods of this exemplary embodiment. Furthermore, the electronic device may also include a display for displaying a graphical user interface.

[0135] The following is for reference. Figure 12 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 12 The electronic device 1200 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0136] like Figure 12 As shown, the electronic device 1200 may include: a processor 1210, a memory 1220, a bus 1230, an I / O (input / output) interface 1240, a network adapter 1250, and a display 1260.

[0137] Memory 1220 may include volatile memory, such as RAM 1221 and cache unit 1222, and may also include non-volatile memory, such as ROM 1223. Memory 1220 may also include one or more program modules 1224, such program modules 1224 including, but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 1224 may include the modules in the above-described apparatus.

[0138] The processor 1210 may include one or more processing units, such as an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor, and / or an NPU (Neural-Network Processing Unit).

[0139] The processor 1210 can be used to execute executable instructions stored in the memory 1220, such as the game resource processing method described above.

[0140] Bus 1230 is used to connect different components of electronic device 1200, and may include data bus, address bus and control bus.

[0141] Electronic device 1200 can communicate with one or more external devices 1300 (such as keyboard, mouse, external controller, etc.) through I / O interface 1240.

[0142] Electronic device 1200 can communicate with one or more networks via network adapter 1250. For example, network adapter 1250 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 1250 can communicate with other modules of electronic device 1200 via bus 1230.

[0143] Electronic device 1200 can display a graphical user interface via display 1260.

[0144] although Figure 12 Other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, may also be configured in the electronic device 1200.

[0145] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0146] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

[0147] Those skilled in the art will understand that various aspects of this disclosure can be implemented as systems, methods, or program products. Therefore, various aspects of this disclosure can be embodied in entirely hardware implementations, entirely software implementations (including firmware, microcode, etc.), or implementations combining hardware and software aspects, collectively referred to herein as “circuit,” “module,” or “system.” Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0148] It should be understood that this disclosure is not limited to the precise structures 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 disclosure is defined only by the appended claims.

Claims

1. A method for processing game resources, characterized in that, Applied to the server side, the method includes: Retrieve story resource data corresponding to multiple story packs in the game; A reuse analysis is performed on the plot resource data corresponding to the multiple plot packs, and the plot resource data that exists in at least two plot packs at the same time is identified as shared resources. Based on the association between each story pack and shared resources, resource management information for each story pack is generated; The resource management information is sent to the client so that the client can process each of the story packs based on the resource management information.

2. The method according to claim 1, characterized in that, The reuse analysis of the story resource data corresponding to the multiple story packs, and the determination of story resource data that exists in at least two story packs simultaneously as shared resources, includes: For any story pack, determine the intersection between the story resource data in the story pack and the story resource data of other story packs, and define the intersection as the shared resource between the story pack and other story packs.

3. The method according to claim 1, characterized in that, The method further includes: The shared resources are removed from the story resource data of each story pack to obtain the exclusive resources corresponding to each story pack; The generation of resource management information for each story pack based on the association between each story pack and shared resources includes: Based on the exclusive resources and the association between each story pack and the shared resources, resource management information for each story pack is generated.

4. The method according to claim 1, characterized in that, The acquisition of story resource data corresponding to multiple story packs in the game includes: Obtain multiple story packs in the game, and the mapping relationship between the multiple story packs and story content identifiers; Based on the mapping relationship between the multiple plot packages and plot content identifiers, determine the plot file corresponding to each plot package; Parse the resource reference information in the plot file to determine the resource data referenced by the plot file; Based on the resource data referenced in the plot file, determine the plot resource data corresponding to multiple plot packs.

5. The method according to claim 4, characterized in that, The step of determining the plot resource data corresponding to multiple plot packs based on the resource data referenced in the plot file includes: The resource data that is not called by the story system is removed from the resource data to obtain the story resource data corresponding to the story package.

6. A method for processing game resources, characterized in that, Applied to a client, the method includes: Receive resource management information from the server; the resource management information is used to indicate the association between the story pack and the shared resources; the shared resources are resource data that exist simultaneously in the story resource data corresponding to at least two story packs; In response to receiving an operation request for a target story pack, the target story pack is processed according to the resource management information.

7. A game resource processing device, characterized in that, Applied to the server side, the device includes: The resource data acquisition module is used to acquire story resource data corresponding to multiple story packs in the game; The shared resource determination module is used to perform reuse analysis on the plot resource data corresponding to the multiple plot packs, and determine the plot resource data that exists in at least two plot packs at the same time as shared resources. The management information generation module is used to generate resource management information for each story pack based on the association between each story pack and the shared resources. The management information sending module is used to send the resource management information to the client, so that the client can process each of the story packs based on the resource management information.

8. A game resource processing device, characterized in that, Applied to a client, the device includes: The management information acquisition module is used to receive resource management information from the server; the resource management information is used to indicate the association between story packs and shared resources; the shared resources are resource data that exist simultaneously in the story resource data corresponding to at least two story packs; The story pack processing module is used to respond to receiving an operation request for a target story pack and process the target story pack according to the resource management information.

9. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the method of any one of claims 1-6 by executing the executable instructions.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1-6.

Images