Resource management method and system for game development

Abstract

This invention relates to the field of computer technology and discloses a resource management method and system for game development. The server constructs a dependency graph between game resources and generates a global version identifier. When a client initiates a resource update, it compares the server's global version identifier with its local identifier. If they are inconsistent, the client downloads the latest dependency graph and performs a difference analysis with the local graph to determine the changed nodes and dependency edges. Then, it executes an appropriate update strategy based on the type of dependency change. Finally, it updates the local dependency graph and resource version information and notifies the game engine to refresh the resource reference cache. This method can automatically detect dynamic changes in resource dependencies and perform differentiated updates, solving the problem of resource reference errors or loading failures caused by the inability of existing technologies to detect dependency changes.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a resource management method and system for game development. Background Technology

[0002] Currently, game development involves a vast number of resources with complex dependencies. For example, a character model depends on corresponding textures, materials, and animation files. Common resource management methods rely on developers manually recording and maintaining these dependencies, then updating and packaging resources based on these relationships. However, this approach has significant drawbacks: manual maintenance is labor-intensive and inefficient, and it's prone to oversights leading to missing or incorrect dependency information, which can cause resource loading failures or display anomalies during game runtime.

[0003] To overcome the aforementioned problems, existing technologies typically employ the following approach: both the server and client maintain their own resource version lists, each recording the file identifier and version number of each resource. During updates, the client retrieves the server's version list and compares it with its local list, identifying resources that are missing or have inconsistent version numbers. It then initiates update requests only for these resources, downloads the difference files, replaces the old local resources, and synchronously updates its local version list. This solution automates resource update comparison and on-demand downloading, avoiding the tediousness and errors of manually maintaining dependency lists.

[0004] However, the aforementioned existing technologies can only detect whether the resource files themselves have changed, but cannot detect changes in the dependencies between resources. For example, when two resources that were originally unrelated develop a new reference relationship due to adjustments in game logic, since the content of the resource files has not changed, version list comparisons will not indicate that an update is needed, but reference failures may occur during runtime. Furthermore, existing technologies lack the ability to detect changes in resource dependencies, making it difficult to automatically and correctly update when dependencies change dynamically. Summary of the Invention

[0005] The purpose of this invention is to provide a resource management method and system for game development, which solves the problem that existing technologies cannot detect changes in resource dependencies, leading to resource reference errors or loading failures.

[0006] To achieve the above objectives, the present invention provides a resource management method for game development, comprising the following steps: The server constructs a dependency graph between game resources and generates a global version identifier for the dependency graph; When a client initiates a resource update, it obtains the global version identifier of the dependency graph from the server and compares the obtained global version identifier with the global version identifier of the dependency graph stored locally on the client. If the comparison results are inconsistent, the client downloads the latest dependency graph from the server and performs a difference analysis between the downloaded latest dependency graph and the client's local dependency graph to determine the nodes and dependency edges that have changed. The client determines the type of dependency change based on the results of the difference analysis and executes an update strategy that matches the type of dependency change. The client updates its local dependency graph and resource version information based on the execution results, and notifies the game engine to refresh the resource reference cache.

[0007] Specifically, generating a global version identifier for the dependency graph includes: A hash calculation is performed on the overall data of the dependency graph, and the calculated hash value is used as a global version identifier.

[0008] This includes, after constructing a dependency graph between game resources on the server side, the following: The server generates a local dependency fingerprint for each resource node. The local dependency fingerprint is calculated by combining the version number of the resource node itself and the version numbers of all the directly dependent nodes of the resource node.

[0009] Specifically, the client downloads the latest dependency graph from the server, which includes: If an older version of the dependency graph exists locally on the client, the client will only download the patch data showing the differences between the latest dependency graph on the server and the client's local dependency graph; otherwise, the client will download the complete dependency graph.

[0010] Specifically, identifying the changed nodes and dependent edges includes: Identify newly added dependency edges, deleted dependency edges, and indirect dependency changes caused by changes in dependency node versions.

[0011] The types of dependency changes include: only the dependency changes while the content of the related resource files remains unchanged; the dependency changes and the versions of the resource files it depends on also change; and the dependency change leads to a broken reference chain or a circular dependency.

[0012] Specifically, when only the dependency relationship changes while the content of the related resource files remains unchanged, the update strategy that matches the type of dependency relationship change is executed as follows: The client only downloads the latest dependency graph and updates its local dependency graph storage; it does not download resource files.

[0013] Specifically, when dependencies change and the versions of the dependent resource files also change, the update strategy that matches the type of dependency change is executed as follows: The client downloads the changed resource files in the order of the dependent resources being downloaded first, followed by the dependent resources, and updates the local dependency graph after the download is complete.

[0014] Specifically, when a dependency change leads to a broken reference chain or a circular dependency, the update strategy that matches the type of dependency change is executed as follows: The client aborts the update process and reports the error to the server or developer.

[0015] A resource management system for game development, including server-side and client-side modules; The server module includes a dependency extraction unit, a version management unit, and a response unit; the dependency extraction unit is connected to the version management unit, and the version management unit is connected to the response unit. The client module includes a version comparison unit, a difference analysis unit, a strategy execution unit, and a storage unit; the version comparison unit is connected to the difference analysis unit, the difference analysis unit is connected to the strategy execution unit, and the strategy execution unit is connected to the storage unit. The response unit and the version comparison unit are connected via bidirectional network communication. The server module is used to generate and provide a dependency graph and a global version identifier; The client module is used to perform global version identifier comparison, dependency graph difference analysis, update strategy execution, and local graph storage, and collaboratively complete the version comparison, difference analysis, and differentiated update of the dependency graph.

[0016] This invention discloses a resource management method and system for game development. First, the server establishes a dependency graph between game resources and calculates a global version identifier for this graph. When a client needs to update resources, it compares the obtained global version identifier from the server with its own saved version identifier. If they are inconsistent, the client downloads the latest dependency graph from the server and compares it with its local graph to identify the specific changed resource nodes and their dependent edges. Then, it selects the appropriate update processing method based on the type of change. Finally, the client saves the updated dependency graph and resource version information locally and triggers the game engine to refresh the resource reference cache. This invention can automatically capture dynamic changes in resource dependencies and perform differentiated update operations based on the type of change, thereby overcoming the problem of existing technologies that easily cause resource reference errors or loading failures due to the inability to detect dependency changes. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0018] Figure 1 This is a flowchart of the steps of the resource management method for game development according to the first embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram of the resource management system for game development according to the second embodiment of the present invention.

[0020] In the diagram: 201-Server module, 202-Client module, 203-Depth extraction unit, 204-Version management unit, 205-Response unit, 206-Version comparison unit, 207-Difference analysis unit, 208-Strategy execution unit, 209-Storage unit. Detailed Implementation

[0021] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, but should not be construed as limiting the present invention.

[0022] First embodiment: Please refer to Figure 1 This invention provides a resource management method for game development, comprising the following steps: S101: The server constructs a dependency graph between game resources and generates a global version identifier for the dependency graph; Specifically, in the game development process, the server first needs to manage all resource files in the game project uniformly. Resource files include, but are not limited to, models, textures, materials, animations, audio, configuration files, etc. The server uses resource import tools or static code analysis to parse the content of each resource file and extract information about other resources referenced within it. For example, a 3D model file typically references texture files as textures, material files as surface properties, and animation files as skeletal motion data. The server records these reference relationships as dependency edges, with each resource file as a node, thus constructing a directed graph, i.e., a dependency graph. This graph can be stored on the server in JSON, XML, or binary format, with each node recording a unique identifier for the resource file (such as a file path or UUID), and each edge recording the dependency type (such as strong dependency or weak dependency).

[0023] Based on this, the server generates a global version identifier for the entire dependency graph. Specifically, the server takes the entire graph data (including all node and edge information) as input and uses a hash algorithm (such as MD5, SHA-1, or SHA-256) to calculate a fixed-length hash value, which serves as the global version identifier. When any node or edge in the graph changes, the recalculated hash value changes accordingly, thus uniquely identifying the version state of the graph. Furthermore, after constructing the dependency graph, the server also generates a local dependency fingerprint for each resource node. This local dependency fingerprint is calculated by combining the resource node's own version number (e.g., the hash value of the file content) and the version numbers of all its directly dependent nodes, which can be done by concatenating these values ​​before hashing. The purpose of the local dependency fingerprint is to quickly locate the scope of impact of dependency changes, avoiding the need to compare the entire graph every time.

[0024] S102: When the client initiates a resource update, it obtains the global version identifier of the dependency graph on the server and compares the obtained global version identifier of the server with the global version identifier of the dependency graph stored locally on the client. Specifically, when the client game needs to check for resource updates during startup or operation, the client first sends an update request to the server. This request carries the client's current local version information (such as the game version number or resource version number). After receiving the request, the server returns the global version identifier of its latest dependency graph to the client. After obtaining the global version identifier returned by the server, the client reads the global version identifier of the dependency graph stored locally. The local identifier is saved by the client after the last successful resource update, and is usually stored in a local configuration file or resource version manifest file.

[0025] Subsequently, the client compares the server-side global version identifier with the local global version identifier. If they match perfectly, it means the dependency graphs on the server and client are identical, indicating no changes to the dependencies. The client does not need to update the dependency level and can directly proceed to the traditional resource file version comparison process. If they do not match, it means the server-side dependency graph has changed relative to the local graph, and the client needs to obtain the latest graph data and perform further processing. This comparison process is simple and efficient, requiring only the transmission and comparison of two hash values, resulting in minimal network overhead.

[0026] S103: If the comparison results are inconsistent, the client downloads the latest dependency graph from the server and performs a difference analysis between the downloaded latest dependency graph and the client's local dependency graph to determine the changed nodes and dependency edges; Specifically, when the comparison result in step S102 shows that the server-side global version identifier is inconsistent with the local global version identifier, the client needs to obtain the latest dependency graph from the server. In the implementation, the client first checks whether an older version of the dependency graph already exists locally. If an older version graph exists locally, the client requests the server to download the difference patch data between the latest graph and the local graph, rather than downloading the complete graph file. The server calculates the differences between the two versions (e.g., newly added nodes, deleted edges, modified node attributes, etc.) based on the local graph version information provided by the client, and packages this difference data into a patch file and returns it to the client. After downloading the patch file, the client applies it to the local older version graph to restore the complete latest graph. If the client does not have any older version graph locally (e.g., when installing the game for the first time), the client directly downloads the complete dependency graph stored on the server.

[0027] After obtaining the latest dependency graph, the client performs a difference analysis between the new graph and the local graph. Specifically, the client compares the nodes and dependency edges in the two graphs item by item to determine the specific changes. The types of changes include: newly added dependency edges (dependencies that were not previously present appear in the new graph); deleted dependency edges (dependencies that were previously present are removed from the new graph); and indirect dependency changes caused by changes in the version of dependent nodes. Indirect dependency changes refer to situations where, when the version number of a resource node changes, all parent nodes that depend on that node, although their direct dependency edges remain unchanged, will have their local dependency fingerprints affected and therefore need to be marked as affected nodes. Through difference analysis, the client can accurately identify which resource nodes and dependency edges have changed, providing a basis for subsequent update strategy development. The results of the difference analysis can be stored in the form of a change list, with each change item recording the change type (added, deleted, modified) and the involved node identifiers and edge information.

[0028] S104: The client determines the type of dependency change based on the results of the difference analysis and executes an update strategy that matches the type of dependency change; Specifically, after completing the difference analysis, the client obtains a list of nodes that have changed and their dependent edges. The client then determines the type of dependency change based on the details of the change. In this invention, dependency changes are mainly categorized into three types.

[0029] The first type involves changes to dependencies while the content of the related resource files remains unchanged. This occurs when references between resources are added or removed, but the binary data of the resource files themselves is not modified. For example, a developer adds a texture reference to a character model, but the content of both the character model file and the texture file remains unchanged. For this type, the client's update strategy is to only download the latest dependency graph from the server and update its local dependency graph storage with the downloaded graph, while simultaneously updating the global version identifier of the local graph. Since the resource files themselves do not change, the client does not need to download any resource files, thus saving network bandwidth and storage space.

[0030] The second type involves changes in dependencies and version changes to the dependent resource files. For example, a low-level texture file might be modified, and multiple model files referencing that texture might have their dependency parameters adjusted accordingly. In this case, the client downloads the changed resource files sequentially, starting with the dependent resources and then downloading the dependent resources. Specifically, based on the direction in the dependency graph, the client first downloads the dependent low-level resources (such as textures and materials), and then downloads the high-level resources (such as models and scenes) that depend on these low-level resources. This order ensures that when replacing resources locally, there won't be an intermediate state where high-level resources are updated while low-level resources are missing. After the download is complete, the client updates the latest dependency graph and the corresponding resource version information locally.

[0031] The third type involves dependency changes leading to broken reference chains or circular dependencies. For example, a new dependency graph might contain a resource that references a non-existent resource, or a closed loop might form in the dependency graph. Clients can identify these anomalies during difference analysis because missing nodes or circular structures will be detected. For this type, the client immediately halts the update process, neither downloading any resource files nor modifying the local dependency graph. Simultaneously, the client reports the anomaly to the server or developers, including the identifiers of the broken or circular dependencies and their specific dependency edge information, so that developers can investigate and fix the problem. This method prevents abnormal versions of resources from being published to the client, which could cause the game to crash.

[0032] S105: The client updates the local dependency graph and resource version information based on the execution result, and notifies the game engine to refresh the resource reference cache.

[0033] Specifically, after the above update strategy is executed, the client persists the update results to local storage. Specifically, if the client downloads the latest dependency graph or difference patch in step S104, the client saves the updated dependency graph completely to the specified local location, and updates the global version identifier of the locally saved dependency graph to match the global version identifier on the server. Furthermore, if resource files are also downloaded in step S104, the client similarly saves these resource files to the corresponding local resource directory and updates the local resource version information, such as updating the version number or hash value record for each resource file.

[0034] After completing the aforementioned storage update, the client sends a notification to the game engine, requesting it to refresh the resource reference cache. During runtime, the game engine typically maintains a resource reference cache table to accelerate resource lookup and loading. When the dependency graph changes, the original cached information may become outdated; for example, existing resource references may have been deleted or modified. Continuing to use the old cache could lead to loading incorrect resources or reference failures. Therefore, the client notifies the game engine to rebuild the resource reference cache based on the latest dependency graph, ensuring that subsequent resource loading operations correctly follow the new dependencies. This notification can be implemented by calling an interface provided by the game engine or sending a custom event.

[0035] This invention enables automatic detection and differentiated updates of changes in game resource dependencies, thereby effectively avoiding resource reference errors or loading failures caused by changes in dependencies.

[0036] Second embodiment: Please refer to Figure 2 This invention provides a resource management system for game development, including a server module 201 and a client module 202. The server module 201 includes a dependency extraction unit 203, a version management unit 204, and a response unit 205; the dependency extraction unit 203 is connected to the version management unit 204, and the version management unit 204 is connected to the response unit 205. The client module 202 includes a version comparison unit 206, a difference analysis unit 207, a strategy execution unit 208, and a storage unit 209; the version comparison unit 206 is connected to the difference analysis unit 207, the difference analysis unit 207 is connected to the strategy execution unit 208, and the strategy execution unit 208 is connected to the storage unit 209. The response unit 205 and the version comparison unit 206 are connected via bidirectional network communication. The server module 201 is used to generate and provide a dependency graph and a global version identifier; The client module 202 is used to perform global version identifier comparison, dependency graph difference analysis, update strategy execution, and local graph storage, and to collaboratively complete the version comparison, difference analysis, and differentiated update of the dependency graph.

[0037] Specifically, server-side module 201 is deployed on the game server and is mainly responsible for generating the dependency graph and managing its versions. Server-side module 201 comprises three units: a dependency extraction unit 203, a version management unit 204, and a response unit 205. The dependency extraction unit 203 scans all resource files in the game project, parses the information of other resources referenced in each resource file, and thus constructs a dependency graph between resources. The output of this unit is connected to the input of the version management unit 204, transmitting the constructed dependency graph to the version management unit 204. After receiving the dependency graph, the version management unit 204 generates a global version identifier for the graph. Specifically, a hash algorithm can be used to calculate the hash value of the entire graph data as the version identifier. Simultaneously, the version management unit 204 can also generate local dependency fingerprints for each resource node. The output of the version management unit 204 is connected to the input of the response unit 205, transmitting the dependency graph and its global version identifier to the response unit 205. The response unit 205 is used to respond to the client's update request and return the corresponding data according to the client's request content, including the global version identifier, the complete dependency graph or the difference patch data.

[0038] The client module 202 is deployed on the game client and is mainly responsible for version comparison, difference analysis, strategy execution, and local storage. The client module 202 specifically comprises four units: a version comparison unit 206, a difference analysis unit 207, a strategy execution unit 208, and a storage unit 209. The version comparison unit 206, when the client initiates a resource update, sends a request to the response unit 205 of the server module 201 to obtain the latest global version identifier of the dependency graph from the server, and compares the obtained identifier with the local global version identifier stored in the local storage unit 209. The output of the version comparison unit 206 is connected to the input of the difference analysis unit 207. When the comparison results are inconsistent, the version comparison unit 206 triggers the difference analysis unit 207 to start working. The difference analysis unit 207 downloads the latest dependency graph (or difference patch) from the server and performs difference analysis on the downloaded latest graph and the local graph read from the storage unit 209 to determine the changed nodes and dependency edges. The output of the difference analysis unit 207 is connected to the input of the strategy execution unit 208, transmitting the analyzed change list to the strategy execution unit 208. The strategy execution unit 208 determines the type of dependency change based on the change list and executes an update strategy matching that type. The output of the strategy execution unit 208 is connected to the input of the storage unit 209, transmitting the updated dependency graph, global version identifier, and resource version information to the storage unit 209 for persistent storage. Furthermore, the strategy execution unit 208 is also responsible for notifying the game engine to refresh the resource reference cache.

[0039] The response unit 205 and the version comparison unit 206 are connected via bidirectional network communication. Specifically, the version comparison unit 206 of the client module 202 sends an HTTP or TCP request to the response unit 205 of the server module 201, and the response unit 205 returns corresponding data according to the request type. For example, when the version comparison unit 206 requests to obtain the global version identifier, the response unit 205 returns the latest identifier; when the version comparison unit 206 requests to download a difference patch, the response unit 205 calculates the patch data and returns it.

[0040] During collaborative work, the dependency extraction unit 203 of the server module 201 generates a dependency graph, which then flows sequentially to the version management unit 204 and the response unit 205. The version comparison unit 206 of the client module 202 obtains the global version identifier from the response unit 205, compares the results, and passes the instructions to the difference analysis unit 207. The difference analysis unit 207 obtains the latest graph data from the response unit 205, analyzes the data, and passes the results to the strategy execution unit 208. The strategy execution unit 208 executes the update and then passes the results to the storage unit 209 for storage. The entire process forms a closed loop, realizing the version management, difference awareness, and differentiated update functions of the dependency graph.

[0041] The above-disclosed embodiments are merely one or more preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art can understand that all or part of the processes for implementing the above embodiments and equivalent variations made in accordance with the claims of this application still fall within the scope of this application.

Claims

1. A resource management method for game development, characterized in that, Includes the following steps: The server constructs a dependency graph between game resources and generates a global version identifier for the dependency graph; When a client initiates a resource update, it obtains the global version identifier of the dependency graph from the server and compares the obtained global version identifier with the global version identifier of the dependency graph stored locally on the client. If the comparison results are inconsistent, the client downloads the latest dependency graph from the server and performs a difference analysis between the downloaded latest dependency graph and the client's local dependency graph to determine the nodes and dependency edges that have changed. The client determines the type of dependency change based on the results of the difference analysis and executes an update strategy that matches the type of dependency change. The client updates its local dependency graph and resource version information based on the execution results, and notifies the game engine to refresh the resource reference cache.

2. The resource management method for game development as described in claim 1, characterized in that, Generate a global version identifier for the dependency graph, specifically including: A hash calculation is performed on the overall data of the dependency graph, and the calculated hash value is used as a global version identifier.

3. The resource management method for game development as described in claim 1, characterized in that, After building the dependency graph between game resources on the server side, the following is also included: The server generates a local dependency fingerprint for each resource node. The local dependency fingerprint is calculated by combining the version number of the resource node itself and the version numbers of all the directly dependent nodes of the resource node.

4. The resource management method for game development as described in claim 1, characterized in that, The client downloads the latest dependency graph from the server, specifically including: If an older version of the dependency graph exists locally on the client, the client will only download the patch data showing the differences between the latest dependency graph on the server and the client's local dependency graph; otherwise, the client will download the complete dependency graph.

5. The resource management method for game development as described in claim 1, characterized in that, Identify the nodes and dependent edges that have changed, specifically including: Identify newly added dependency edges, deleted dependency edges, and indirect dependency changes caused by changes in dependency node versions.

6. The resource management method for game development as described in claim 1, characterized in that, The types of dependency changes include: only the dependency changes while the content of the related resource files remains unchanged; the dependency changes and the versions of the dependent resource files also change; and the dependency change leads to a broken reference chain or a circular dependency.

7. The resource management method for game development as described in claim 6, characterized in that, When only the dependency relationship changes while the content of the related resource files remains unchanged, the update strategy that matches the type of dependency relationship change is executed as follows: The client only downloads the latest dependency graph and updates its local dependency graph storage; it does not download resource files.

8. The resource management method for game development as described in claim 6, characterized in that, When dependencies change and the versions of the dependent resource files also change, the update strategy that matches the type of dependency change is executed as follows: The client downloads the changed resource files in the order of the dependent resources being downloaded first, followed by the dependent resources, and updates the local dependency graph after the download is complete.

9. The resource management method for game development as described in claim 6, characterized in that, When a change in dependency leads to a broken reference chain or a circular dependency, the update strategy that matches the type of dependency change is executed as follows: The client aborts the update process and reports the error to the server or developer.

10. A resource management system for game development, used to execute the resource management method for game development as described in any one of claims 1 to 9, characterized in that, Includes server-side and client-side modules; The server module includes a dependency extraction unit, a version management unit, and a response unit; the dependency extraction unit is connected to the version management unit, and the version management unit is connected to the response unit. The client module includes a version comparison unit, a difference analysis unit, a strategy execution unit, and a storage unit; the version comparison unit is connected to the difference analysis unit, the difference analysis unit is connected to the strategy execution unit, and the strategy execution unit is connected to the storage unit. The response unit and the version comparison unit are connected via bidirectional network communication. The server module is used to generate and provide a dependency graph and a global version identifier; The client module is used to perform global version identifier comparison, dependency graph difference analysis, update strategy execution, and local graph storage, and collaboratively complete the version comparison, difference analysis, and differentiated update of the dependency graph.

Images