Method and system for unified processing of multi-source heterogeneous data based on dynamic script engine

Abstract

The application provides a multi-source heterogeneous data unified processing method and system based on a dynamic script engine, relates to the technical field of game engines and software development, and the application converts various game engine protocol signals into a unified intermediate representation format, extracts asset specification parameters and engine compatibility identifiers, and injects them into the unified intermediate representation format to form enhanced asset data; analyzes and verifies dynamic script codes, converts the dynamic script codes into bytecodes, loads the bytecodes into memory, and establishes a dynamic script hot updating mechanism; then, the enhanced asset data is loaded concurrently according to the mechanism state, and when the loading fails, an error is recorded, an exception is triggered, and a backup path is switched to reload; finally, the asset format is converted into a native format of a target engine, the quality of an updating algorithm is optimized by using the hot updating mechanism, and the target engine requirements are ensured, so that asset data enhancement, dynamic script hot updating, concurrent loading fault tolerance, asset format conversion and quality optimization can be achieved, and the asset can meet the requirements of the target game engine.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of game engines and software development, and particularly relates to a multi-source heterogeneous data unified processing method and system based on a dynamic script engine. BACKGROUND

[0002] In modern game development, multi-source asset collaborative processing is urgently needed. Cross-team collaboration makes asset sources scattered, and multiple engine formats need to be compatible. In development, formats need to be converted in real time according to engine iteration or function adjustment. In the testing and operation stage, assets need to be dynamically loaded, and loading stability needs to be ensured to avoid the influence of single asset loading failure on the process. Therefore, the scheme needs to have the integrated ability of real-time format conversion, multi-engine adaptation and dynamic loading.

[0003] At present, the mainstream scheme in the industry is the combination of a fixed template asset conversion tool and an independent dynamic loading module. Fixed conversion scripts are written in advance for different assets, developers manually select asset types and target engine templates, and the tool converts according to the templates. Dynamic loading relies on an independent module, and converted assets are loaded according to a predefined path. The two logics are independent, and an additional configuration file is needed to associate data.

[0004] However, this scheme has obvious limitations: poor conversion flexibility, fixed templates difficult to adapt to asset specification adjustment, parameters or engine updates need to rewrite scripts, and real-time conversion cannot be met; low function coupling, conversion and loading modules are independent, it is difficult to synchronize the state, and assets may fail due to parameter mismatch; poor fault tolerance and scalability, no unified exception handling for loading, failure needs to be repaired manually, and new asset types need to be reconstructed. SUMMARY

[0005] The present application aims to provide a multi-source heterogeneous data unified processing method and system based on a dynamic script engine to solve the problem of poor fault tolerance and scalability in the prior art.

[0006] To solve the above technical problems, in a first aspect, the present application provides a multi-source heterogeneous data unified processing method based on a dynamic script engine, comprising:

[0007] Converting game engine protocol signals of multiple different formats and structures into a unified intermediate representation format, and extracting asset specification parameters and engine compatibility identifiers from game design documents and art direction books;

[0008] Dynamically injecting the asset specification parameters and engine compatibility identifiers into the data structure of the intermediate representation format to form enhanced asset data with engine-specific markers;

[0009] Syntax analysis and semantic verification are performed on the corresponding dynamic script code based on processing requirements of the enhanced asset data, the dynamic script code is converted into executable bytecode and loaded into memory, and a dynamic script hot updating mechanism supporting runtime code updating is established in memory;

[0010] Based on the execution state of the dynamic script hot updating mechanism, the enhanced asset data is processed in large-scale concurrent loading, and a multi-thread processed asset data set is generated. When asset loading failure is detected, error information is automatically recorded and an exception capturing mechanism is triggered, and the loading operation is re-executed by switching to a preset backup resource path;

[0011] The format of the asset data set is converted into a native format required by the target game engine, the execution parameters of the asset optimization algorithm are updated through the dynamic script hot updating mechanism, and batch quality optimization processing is performed on the asset data in the native format to ensure that the processed assets meet the performance requirements and quality standards of the target engine.

[0012] Optionally, syntax analysis and semantic verification are performed on the corresponding dynamic script code based on processing requirements of the enhanced asset data, the dynamic script code is converted into executable bytecode and loaded into memory, and a dynamic script hot updating mechanism supporting runtime code updating is established in memory, including:

[0013] Based on the processing requirement markers embedded in the enhanced asset data, the code block identifier and input parameter list of the required dynamic script code are determined, the character sequence start position and end position are located according to the code block identifier, and the character sequence of the dynamic script code is read;

[0014] The character sequence is lexically parsed to generate a token stream, the token stream is syntax parsed to construct an abstract syntax tree, and whether the node types and connection relationships of the abstract syntax tree conform to the predefined syntax rule set is verified, error markers and error types are recorded for node positions that do not conform to the rules;

[0015] The input parameter list is mapped to a variable node in the abstract syntax tree, based on the structure of the abstract syntax tree and the context information of the enhanced asset data, data dependency and execution flow consistency in the code logic are analyzed, variable reference conflicts and resource access conflicts are identified, and the identified conflicts are recorded and the current processing flow is terminated;

[0016] The verified abstract syntax tree is converted into an executable bytecode instruction sequence, and the bytecode instruction sequence is optimized to improve execution efficiency and reduce memory occupancy;

[0017] The continuous memory space is allocated, the optimized bytecode instruction sequence is loaded into the memory space, the read-write execution permission attribute of the memory page is set to realize the runtime code replacement, and the dynamic script hot updating mechanism is established.

[0018] Optionally, the continuous memory space is allocated, the optimized bytecode instruction sequence is loaded into the memory space, the read-write execution permission attribute of the memory page is set to realize the runtime code replacement, and the dynamic script hot updating mechanism is established, comprising:

[0019] The total length and runtime memory requirement of the optimized bytecode instruction sequence are calculated, a continuous virtual address space is applied to an operating system according to the calculation result, and the virtual address space is divided into memory blocks with a fixed size;

[0020] An idle block meeting the bytecode instruction sequence storage requirement is selected from the memory blocks by using a memory allocation algorithm, and the optimized bytecode instruction sequence is written into the start address of the idle block;

[0021] The access control attribute of the memory block is modified, the memory page storing the bytecode instruction sequence is set to a readable and writable and executable state, the loading address and permission attribute of the bytecode instruction sequence are recorded to a memory mapping table, and the memory mapping table is associated to a dynamic script hot updating manager;

[0022] The memory state of the memory mapping table is tracked through the dynamic script hot updating manager, when a bytecode instruction sequence updating instruction is received, the target memory block is located according to the memory mapping table, and a code replacement operation is performed.

[0023] Optionally, game engine protocol signals in multiple different formats and structures are converted into a unified intermediate representation format, and asset specification parameters and engine compatibility identifiers are extracted from game design documents and art direction books, comprising:

[0024] According to the differences in transmission format characteristics of the game engine protocol signals, the received protocol data packets are divided into two categories of binary coded protocol data packets and text coded protocol data packets;

[0025] The fixed length field of the data packet header and the variable length structure of the data body are parsed from the binary coded protocol data packets, the key-value pair separator and the nested level mark are parsed from the text coded protocol data packets, and the parsed protocol data packets are decoded into structured data elements containing type identifiers and original data values;

[0026] According to the type and content of the structured data elements, a unified intermediate representation format is established, and the structured data elements are allocated to the numerical storage fields of the data containers corresponding to the intermediate representation format according to their types.

[0027] reading text information of the game design document, extracting asset specification parameters by scanning content of the text information and matching keywords and numerical expression associated with asset size attributes and asset type attributes;

[0028] querying text content and graphical symbols of the art direction book, extracting engine compatibility identifiers by locating identifiers related to engine version adaptation conditions.

[0029] Optionally, according to the difference in transmission format characteristics of the game engine protocol signal, the received protocol data packet is divided into two categories: binary encoded protocol data packet and text encoded protocol data packet, including:

[0030] analyze the transmission format characteristics of the game engine protocol signal, the transmission format characteristics including the start identifier characteristics of the data packet and the content encoding characteristics;

[0031] obtain the byte sequence of the protocol data packet, identify whether the numerical value of the fixed position field information in the byte sequence matches the predefined protocol identifier based on the start identifier characteristics, and obtain the field identification result;

[0032] based on the content encoding characteristics, content analysis is performed on the byte sequence, the structure characteristics of the data content are determined by calculating the proportion of non-printable characters and counting the distribution pattern of readable characters, and a content distribution analysis result is generated;

[0033] According to the combination of the field identification result and the content distribution analysis result, the protocol data packet is classified as a binary encoded protocol data packet or a text encoded protocol data packet.

[0034] Optionally, according to the execution state of the dynamic script hot update mechanism, the enhanced asset data is processed for large-scale concurrent loading, and a multi-threaded processed asset data set is generated. When asset loading fails, error information is automatically recorded and an exception capture mechanism is triggered, and the loading operation is re-executed by switching to a preset backup resource path, including:

[0035] detect the running state indicators of the dynamic script hot update mechanism, obtain the code execution progress and system resource occupation data, the system resource occupation data including CPU core utilization and memory bandwidth utilization, and the code execution progress indicating the execution stage and remaining task quantity of the current hot update script;

[0036] According to the code execution progress and the system resource occupation data, dynamically calculate the optimal thread pool size and memory buffer allocation scheme, initialize the multi-threaded execution environment according to the optimal thread pool size, and allocate the memory buffer area according to the memory buffer allocation scheme;

[0037] The enhanced asset data is divided into multiple independent processing blocks and stored in the memory buffer area, the independent processing blocks are loaded concurrently in the initialized multi-thread execution environment, dynamic script logic is applied to process the data content of each independent processing block, and the multi-thread processing results are integrated into a unified asset data set;

[0038] When a failure event in the asset loading process is detected, error details are recorded to a system log file, and an exception capture handler is triggered to abort the current loading process, switch to a preset backup resource path, and re-initiate the loading operation.

[0039] Optionally, the format of the asset data set is converted to a native format required by a target game engine, execution parameters of an asset optimization algorithm are updated through the dynamic script hot update mechanism, batch quality optimization is performed on the asset data in the native format, and it is ensured that the processed asset meets the performance requirements and quality standards of the target engine, including:

[0040] A native format specification of the target game engine is identified, data field mapping rules and type conversion rules are defined based on data structure definitions and storage requirements in the native format specification;

[0041] According to the data field mapping rules and type conversion rules, the file organization structure and data encoding method of the asset data set are adjusted, and native format data meeting the reading requirements of the target game engine are generated;

[0042] The latest execution parameter set of the asset optimization algorithm is obtained through the dynamic script hot update mechanism to query parameter update instructions, and the configuration items and threshold settings of the processing algorithm are updated using the latest execution parameter set;

[0043] The native format data is subjected to batch quality optimization operation using the updated processing algorithm, and the texture resolution value, polygon quantity value, and material attribute parameter value of the native format data are adjusted;

[0044] It is verified whether the performance indicators of the optimized data meet the rendering efficiency standards and memory occupation standards of the target game engine, and the asset data that does not meet the quality requirements is subjected to repeated optimization processing until the quality requirements are met.

[0045] In a second aspect, the application provides a multi-source heterogeneous data unified processing system based on a dynamic script engine, including:

[0046] An extraction module is configured to convert game engine protocol signals in multiple different formats and structures into a unified intermediate representation format, and extract asset specification parameters and engine compatibility identifiers from game design documents and art direction books;

[0047] An injection module is configured to inject the asset specification parameters and the engine compatibility identification into the data structure in the intermediate representation format to form enhanced asset data with engine-specific marks;

[0048] A conversion module is configured to perform syntax analysis and semantic verification on the corresponding dynamic script code based on processing requirements of the enhanced asset data, convert the dynamic script code into executable bytecode and load the bytecode into memory, and establish a dynamic script hot update mechanism in the memory to support runtime code updating;

[0049] A generation module is configured to perform large-scale concurrent loading processing on the enhanced asset data according to an execution state of the dynamic script hot update mechanism, generate an asset data set processed by multi-threading, automatically record error information and trigger an exception capturing mechanism when detecting asset loading failure, and switch to a preset backup resource path to re-execute the loading operation;

[0050] An update module is configured to convert a format of the asset data set into a native format required by a target game engine, update execution parameters of an asset optimization algorithm through the dynamic script hot update mechanism, perform batch quality optimization processing on the asset data in the native format, and ensure that the processed asset meets performance requirements and quality standards of the target engine.

[0051] In a third aspect, the present application provides an electronic device, comprising:

[0052] A memory is configured to store a computer program;

[0053] A processor is configured to implement steps of a kind of multi-source heterogeneous data unified processing method based on dynamic script engine as described in the first aspect when executing the computer program.

[0054] In a fourth aspect, the present application provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program can implement steps of a kind of multi-source heterogeneous data unified processing method based on dynamic script engine as described in the first aspect when executed by a processor.

[0055] The application provides a multi-source heterogeneous data unified processing method based on a dynamic script engine, which can realize multi-source heterogeneous data standardization, lay a foundation for unified processing and obtain key adaptation information by converting various game engine protocol signals into a unified intermediate representation format, extracting asset specification parameters and engine compatibility identifiers; can enrich asset data dimensions, carry engine adaptation key information and provide support for accurate processing of different engines by dynamically injecting asset specification parameters and engine identifier compatibility identifiers into the intermediate representation format to form enhanced asset data; can ensure script effectiveness and executability, realize code dynamic updating and improve processing logic flexibility by verifying dynamic script code based on enhanced asset data demand analysis, converting the code into bytecode, loading memory and establishing a dynamic script hot updating mechanism; can improve loading efficiency, guarantee stability and fault tolerance and reduce the impact of loading failure by concurrently loading enhanced asset data based on the state of the dynamic script hot updating mechanism, recording errors, triggering exception capture and switching a backup path for reloading when a failure occurs; and can realize efficient adaptation of assets and target engines, guarantee asset quality and performance compliance and meet application requirements by converting asset data sets into target engine native formats, updating optimization algorithm parameters through the hot updating mechanism and performing batch quality optimization. BRIEF DESCRIPTION OF DRAWINGS

[0056] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0057] Figure 1 A flowchart of a multi-source heterogeneous data unified processing method based on a dynamic script engine provided by an embodiment of the present application is shown in the figure.

[0058] Figure 2 A specific implementation flowchart of a multi-source heterogeneous data unified processing method based on a dynamic script engine provided by an embodiment of the present application is shown in the figure.

[0059] Figure 3 A scenario diagram of a multi-source heterogeneous data unified processing method based on a dynamic script engine provided by an embodiment of the present application is shown in the figure.

[0060] Figure 4 A structural diagram of a multi-source heterogeneous data unified processing system based on a dynamic script engine provided by an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0061] In modern game development, the existing solution of multi-source asset processing has obvious shortcomings: on the one hand, it relies on fixed template to convert asset format, and once the asset specification is adjusted or the game engine version is updated, the conversion script needs to be re-written, which cannot adapt to changes in real time; on the other hand, the asset conversion tool and the dynamic loading module are independent of each other, and need to be associated with data by additional configuration files, which is easy to cause problems such as state asynchronization and parameter mismatch, resulting in asset failure; at the same time, the asset loading lacks a unified exception handling mechanism, and after loading fails, manual troubleshooting is needed, and new asset types also need to restructure the loading module, which has poor fault tolerance and extensibility, which seriously affects the game development efficiency and asset processing stability.

[0062] In view of the above problems, the present application provides a multi-source heterogeneous data unified processing method based on a dynamic script engine. The method first converts game asset data of different formats into a unified intermediate format, extracts asset key parameters and engine adaptation identifiers and injects them into the intermediate format, then verifies and loads the processing logic through the dynamic script engine, and establishes a script hot update mechanism supporting real-time update; based on the mechanism, large-scale concurrent loading of assets is realized, and when loading fails, the system can automatically switch to a backup path for retry, and finally the assets are converted into the target engine format and the quality is optimized. The present application solves the flexibility problem of fixed templates through dynamic scripts, eliminates the coupling problem of independent modules through the integrated process of "conversion-loading-optimization", and improves the extensibility through automatic fault tolerance and script update, fundamentally solving the defects of the existing solution and ensuring the efficiency and stability of asset processing in game development.

[0063] In order to enable those skilled in the art to better understand the present application, the present application will be further described in detail below in combination with the drawings and specific embodiments. Obviously, the described embodiments are only part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0064] The core of the present application is to provide a multi-source heterogeneous data unified processing method based on a dynamic script engine, and a specific embodiment of the method is shown in the flowchart as Figure 1 The method comprises the following steps:

[0065] S101, converting game engine protocol signals of multiple different formats and structures into a unified intermediate representation format, and extracting asset specification parameters and engine compatibility identifiers from game design documents and art direction books;

[0066] Optionally, step S101 can specifically include the following steps:

[0067] S1011, according to the difference of the transmission format characteristics in the game engine protocol signal, the received protocol data packet is divided into two categories of binary encoding protocol data packet and text encoding protocol data packet;

[0068] Among them, step S1011 can specifically include the following process: analyze the transmission format characteristics of the game engine protocol signal, the transmission format characteristics include the starting identification characteristics and content encoding characteristics of the data packet; obtain the byte sequence of the protocol data packet, identify whether the value of the fixed position field information in the byte sequence matches the predefined protocol identifier based on the starting identification characteristics, and obtain the field identification result; based on the content encoding characteristics, content analysis is performed on the byte sequence, the structure characteristics of the data content are determined by calculating the proportion of non-printing characters and counting the distribution mode of readable characters, and a content distribution analysis result is generated; according to the combination of the field identification result and the content distribution analysis result, the protocol data packet is classified as a binary encoding protocol data packet or a text encoding protocol data packet.

[0069] S1012, parse the fixed length field of the data packet header and the variable length structure of the data body from the binary encoding protocol data packet, parse the key-value pair separator and nested level mark from the text encoding protocol data packet, and decode the parsed protocol data packet into structured data elements containing type identification and original data values;

[0070] S1013, according to the type and content of the structured data element, a unified intermediate representation format is established, and the structured data element is allocated to the numerical storage field of the data container corresponding to the intermediate representation format according to its type;

[0071] S1014, read the text information of the game design document, and extract asset specification parameters by scanning the content of the text information and matching keywords and numerical expressions associated with asset size attributes and asset type attributes;

[0072] S1015, query the text content and graphical symbols of the art director book, and extract engine compatibility identifiers by locating identifiers related to engine version adaptation conditions.

[0073] In the above steps, the game engine protocol signal is a signal for transmitting asset-related data by different engines in game development, and contains various formats and structures. The unified intermediate representation format is a standardized data format set for integrating multi-source data, which can be compatible with different original formats. The asset specification parameter is data describing the characteristics of the asset, including asset size attributes and asset type attributes, etc. The asset size attributes are, for example, model length, width and height, and the asset type attributes are, for example, texture type and audio type. The engine compatibility identifier is identification information for determining whether the asset is adapted to a specific engine version, such as A engine 3.0 version and B engine 5.0 version. The binary encoding protocol data packet is a protocol data packet encoded in binary form, stored in byte sequence, and with a high proportion of non-printable characters. The text encoding protocol data packet is a protocol data packet encoded in text form and containing readable characters. The start identifier feature is a field feature in the byte sequence of the protocol data packet for identifying the type of the protocol. The content encoding feature is a feature reflecting the content encoding method of the data packet, which can be judged by the character type distribution. The field identification result is the result of judging whether the value of the fixed position field in the byte sequence of the protocol data packet matches the predefined protocol identifier. The content distribution analysis result is a result reflecting the structure characteristics of the data content obtained by calculating the proportion of non-printable characters and counting the readable character distribution mode. The structured data element is a data unit containing type identifier and original data value obtained after parsing the protocol data packet, such as "model data" and "audio data" for type identifier, and model vertex coordinates and audio sampling data for original data value. The data container is a module for classifying and storing different types of structured data elements in the intermediate representation format, and contains corresponding numerical storage fields.

[0074] In the embodiments of the present application, first, through step S1011, the method is implemented through the following specific technical solutions: in the protocol analysis stage, a protocol classification method based on feature analysis is adopted, and it is determined that the binary encoded protocol data packet when the proportion of non-printing characters is more than 70%, and it is determined that the text encoded protocol data packet when the proportion of non-printing characters is less than 30%. That is, the transmission format characteristics of the game engine protocol signal are analyzed, the transmission format characteristics include the starting identification characteristics and the content encoding characteristics, then the byte sequence of the protocol data packet is obtained, whether the value of the fixed position field information in the byte sequence matches the predefined protocol identifier is identified based on the starting identification characteristics to obtain the field identification result, and then the content of the byte sequence is analyzed based on the content encoding characteristics, the specific way is to calculate the proportion of non-printing characters and count the readable character distribution mode, the content distribution analysis result is generated through this analysis, finally, the protocol data packet is classified as a binary encoded protocol data packet or a text encoded protocol data packet by combining the two types of results of the field identification result and the content distribution analysis result. For example, when processing the asset data protocol packet from the A engine, it is determined that the starting identification characteristics is the 1-4th byte sequence, the predefined A engine binary protocol identifier is "0x12345678", if the value of the position field matches, it is preliminarily judged as a binary type; then calculate the proportion of non-printing characters in the byte sequence, if the proportion is more than 80% and the readable characters are irregularly distributed, combine the field identification result to finally classify it as a binary encoded protocol data packet; if the value of the fixed position field matches the A engine text protocol identifier "TEXT-A", and the proportion of non-printing characters is less than 20% and the readable characters are regularly distributed in the form of "key:value", then it is classified as a text encoded protocol data packet.

[0075] Secondly, by step S1012, the two types of classified data packets are parsed respectively: the fixed length field of the data packet header and the variable length structure of the data body are parsed from the binary encoded protocol data packet, wherein the first 8 bytes of the header are fixed length fields, which are used to record the length of the data body, and the variable length structure of the data body is extracted according to the length recorded by the fixed length field of the header; the key-value pair separator and the nesting level marker are parsed from the text encoded protocol data packet, for example, the key-value pair separator of JSON format is “:” and “,”, and the nesting level marker is “{” and “}”; then both of the two types of parsed protocol data packets are decoded into structured data elements containing type identification and original data value. For example, for the A engine binary encoded protocol data packet classified above, the fixed length field of the first 8 bytes of the header is parsed to obtain the data body length of 1024 bytes, and then the variable length structure of the data body is extracted according to the length, and after decoding, the structured data element with type identification “model data” and original data value of model vertex coordinate array is obtained; for the A engine text encoded protocol data packet in JSON format, the key-value pair separator “:” and the nesting level marker “{” and “}” are parsed, and after decoding, the structured data element with type identification “texture data” and original data value of texture resolution “1024x1024” is obtained.

[0076] Then, by step S1013, a unified intermediate representation format is established according to the types of structured data elements such as “model data”, “texture data” and contents, and then structured data elements of different types are allocated to the numerical storage fields of the data containers corresponding to the intermediate representation format according to their types. The unified intermediate representation format adopts JSONSchema definition, and its core data structure includes the following fields: asset_type represents asset type (MODEL, TEXTURE or AUDIO), asset_data stores asset original data, spec_params includes max_polygons and other specification parameters, and compatibility is an array of engine compatibility identifiers. For example, the intermediate representation format is provided with “model data container” and “texture data container”, and the structured data element with type identification “model data” is allocated to the “vertex coordinate storage field” of the “model data container”, and the structured data element with type identification “texture data” is allocated to the “resolution storage field” of the “texture data container”.

[0077] Then, the text information of the game design document is read through step S1014, and then the asset specification parameters are extracted by scanning the text information content and matching keywords and numerical expression associated with asset size attributes and asset type attributes. For example, by scanning the A game design document, the keywords "height" and "model" are matched to "character model height 2.0 meters", and the numerical expression "2.0 meters" is matched to "UI map is PNG type". The asset specification parameters extracted from the above include character model height 2.0 meters and UI map type PNG.

[0078] Finally, the text content and graphical symbols of the art director's book are queried through step S1015, and then the engine compatibility identifiers are extracted by locating identifiers related to engine version adaptation conditions. For example, by querying the A game art director's book, the expressions related to engine version adaptation conditions such as "model asset adaptation A engine 3.0 and above version" and "audio asset adaptation B engine 5.0 version" are located, and the engine compatibility identifiers extracted from the above are "model-A3.0+" and "audio-B5.0".

[0079] In practical application, a game development team is processing multi-source asset data for an open-world game, which comes from A engine and B engine and includes three types of core assets: character model, scene map and background sound effect. The team first receives asset data protocol packets transmitted by each engine, identifies that the character model protocol packet sent by A engine is of binary encoding type and the scene map configuration protocol packet sent by B engine is of text encoding type JSON format by analyzing the transmission format characteristics of the protocol signal. For the binary character model protocol packet, the team parses its header fixed length field, determines the data body length, extracts model vertex, texture coordinate and other data, and decodes it into structured elements containing "model data" type identifier and specific coordinate numerical values. For the JSON format scene map protocol packet, the team parses the "resolution", "format" and other key-value pair separators and level markers, and decodes it into structured elements containing "map data" type identifier and parameter information. Subsequently, the team establishes a unified intermediate representation format, stores the model related structured elements into "model data container", and stores the map related elements into "map data container". At the same time, the team reads the game design document and extracts asset specification parameters such as "character model height 2.2 meters" and "scene map resolution 2048x2048" from it; queries the art director's book and determines the engine compatibility identifiers such as "character model adaptation A engine 4.0 and above version" and "scene map adaptation B engine 5.2 version". After the whole process is completed, the team obtains standardized multi-source asset data, which prepares for the subsequent dynamic loading and engine adaptation of the assets.

[0080] In the overall scheme of step S101, the standardization conversion of different format game engine protocol signals is realized, laying a foundation for subsequent unified processing of multi-source heterogeneous data; at the same time, asset specification parameters and engine compatibility identifiers are effectively extracted, providing key data support for asset adaptation to different game engines; through step-by-step analysis and classification processing, the accuracy and orderliness of data processing are ensured, reducing data incompatibility problems in the subsequent asset processing process, and improving the overall efficiency of multi-source asset processing in game development.

[0081] S102, dynamically injecting the asset specification parameters and the engine compatibility identifier into the intermediate representation format data structure to form enhanced asset data with engine-specific markers;

[0082] In this step, the asset specification parameters are data describing the inherent characteristics of the asset, including the size, type, precision and other key attributes of the asset, which directly affect the presentation effect and function implementation of the asset in the game. The engine compatibility identifier is information used to identify the adaptation relationship between the asset and different game engine versions, which can clearly identify the engine environment in which the asset can normally run. The intermediate representation format data structure is a standardized data organization form, which contains multiple fields and containers for storing different types of information, used to uniformly carry multi-source heterogeneous data. Dynamic injection refers to automatically adding asset specification parameters and engine compatibility identifiers to the corresponding positions of the intermediate representation format data structure according to specific rules, rather than manually entering the process. Enhanced asset data refers to the intermediate representation format data after injecting asset specification parameters and engine compatibility identifiers, which not only retains the core information of the original asset, but also increases the key markers required for engine adaptation.

[0083] In the embodiments of the present application, first, the target fields in the intermediate representation format data structure for storing asset specification parameters and engine compatibility identifiers are determined, which are pre-designed and correspond to the size, type and other attribute bits of the asset and the engine version adaptation mark bits. For example, the intermediate representation format for model data sets a "specification parameter area" and a "compatibility identifier area", wherein the "specification parameter area" contains "height", "polygon number" and other subfields, and the "compatibility identifier area" contains "minimum supported engine version", "incompatible engine list" and other subfields. Second, the extracted asset specification parameters are matched to the corresponding subfields through a dynamic injection algorithm, for example, "character model height 2.2 meters" is injected into the "height" subfield of the "specification parameter area", and "polygon number 15000" is injected into the "polygon number" subfield in the same area. At the same time, the engine compatibility identifiers are filled into the "compatibility identifier area" according to the rules, for example, "model-A3.0+" corresponds to the injection of "minimum supported engine version" as "A3.0" and "incompatible engine list" as empty; "audio-B5.0" corresponds to the injection of "minimum supported engine version" and "maximum supported engine version" as "B5.0". The dynamic injection process is implemented through Java reflection API, specifically including: obtaining the Class object of the intermediate representation format data structure, iterating through its declared fields, using Field.setAccessible(true) to remove access restrictions, and finally using the Field.set() method to inject the parameter value into the specified field. Finally, the injected data structure is subjected to integrity check to ensure that all necessary parameters and identifiers have been correctly filled in, and no field omission or format error occurs, and finally the enhanced asset data is formed.

[0084] In practical applications, a game development team processes a batch of character model assets transmitted from A engine and B engine. The team has obtained model data in intermediate representation format through previous processing, including core information such as vertex coordinates and texture mapping, and extracted asset specification parameters of the model as "height 2.5 meters, material type PBR, and face number 20000", and engine compatibility identification as "supporting A engine 3.5 and above versions and not supporting B engine 4.0 and below versions". The team fills "height 2.5 meters" into the "height" sub-item under the "physical property" field in the intermediate representation format, "material type PBR" into the "material" sub-item under the "rendering property" field, and "face number 20000" into the "polygon number" sub-item under the "performance property" field through a dynamic injection tool. After decomposing the engine compatibility identification, "A3.5+" is filled into the "minimum A version" sub-item under the "engine adaptation" field, and "B<4.0 not supported" is filled into the "B version limit" sub-item under the "engine adaptation" field. After the injection is completed, the system automatically verifies that the "collision volume" sub-item under the "physical property" field is not filled, but the model does not need the collision volume parameter, so the verification is passed, and finally the enhanced asset data with complete specification parameters and compatibility identification is generated.

[0085] In the overall scheme of the above step S102, the dynamic injection of asset specification parameters and engine compatibility identification upgrades the intermediate representation format data originally containing only basic information to enhanced asset data, enriching the dimensions and practicality of the data; the organic integration of asset core attributes and engine adaptation information is realized, providing a complete data basis for subsequent asset processing, loading and optimization; the dynamic injection method reduces manual intervention, improves the efficiency and accuracy of data integration, and at the same time ensures that the adaptation of asset data to different game engines has a clear basis, providing key support for the collaborative processing of multi-source assets in game development.

[0086] The specific implementation flowchart of the multi-source heterogeneous data unified processing method based on the dynamic script engine provided by the embodiments of the present application is shown as Figure 2 The specific implementation flowchart of the multi-source heterogeneous data unified processing method based on the dynamic script engine provided by the embodiments of the present application is shown as

[0087] S103, based on the processing requirements of the enhanced asset data, performing syntax analysis and semantic verification on the corresponding dynamic script code, converting the dynamic script code into executable bytecode and loading it into the memory, and establishing a dynamic script hot update mechanism in the memory to support runtime code updating;

[0088] Optionally, step S103 can specifically include the following steps:

[0089] S1031, determine the code block identifier and the input parameter list of the required dynamic script code based on the processing requirement mark embedded in the enhanced asset data, locate the start position and end position of the character sequence according to the code block identifier, and read the character sequence of the dynamic script code;

[0090] S1032, perform lexical analysis on the character sequence to generate a token stream, perform syntax analysis on the token stream, construct an abstract syntax tree, verify whether the node types and connection relationships of the abstract syntax tree conform to the predefined syntax rule set, mark and record the error types at the node positions that do not conform to the rules;

[0091] S1033, map the input parameter list to the variable node in the abstract syntax tree, analyze the data dependency relationship and execution flow consistency in the code logic based on the structure of the abstract syntax tree and the context information of the enhanced asset data, identify variable reference conflicts and resource access conflicts, record the identified conflicts and terminate the current processing flow;

[0092] S1034, convert the verified abstract syntax tree into an executable bytecode instruction sequence, and perform optimization processing on the bytecode instruction sequence to improve execution efficiency and reduce memory occupation;

[0093] S1035, allocate a continuous memory space, load the optimized bytecode instruction sequence into the memory space, set the read-write execution permission attributes of the memory page to realize runtime code replacement, and establish a dynamic script hot update mechanism.

[0094] Wherein, step S1035 can specifically include the following process: calculate the total length and runtime memory requirement of the optimized bytecode instruction sequence, apply a continuous virtual address space to the operating system according to the calculation result, and divide the virtual address space into memory blocks of fixed size; select an idle block that meets the storage requirements of the bytecode instruction sequence from the memory blocks using a memory allocation algorithm, and write the optimized bytecode instruction sequence to the start address of the idle block; modify the access control attributes of the memory block, set the memory page storing the bytecode instruction sequence to a readable and writable and executable state, record the loading address and permission attributes of the bytecode instruction sequence to the memory mapping table, and associate the memory mapping table to the dynamic script hot update manager; track the memory state of the memory mapping table through the dynamic script hot update manager, and when receiving a bytecode instruction sequence update instruction, locate the target memory block according to the memory mapping table and perform code replacement operation.

[0095] In the above steps, the processing requirement mark is identification information embedded in the enhanced asset data indicating the specific processing method of the asset, used to explicitly indicate the calling requirement of the dynamic script code; the code block mark is a unique mark used to locate a specific function module in the dynamic script code, helping to quickly find the corresponding processing logic; the input parameter list is a set of parameters required for the execution of the dynamic script code, containing key information required when processing assets; the lexical mark stream is an ordered sequence composed of basic lexical units such as keywords, variable names, and operators generated after lexical analysis, and is the basis for syntax analysis; the abstract syntax tree is a tree-shaped data structure formed after syntax analysis, which directly presents the syntax structure and logic level of the code, and in the present application, it specifically refers to the memory data structure generated after parsing the Lua script by ANTLR, each node represents a syntax element (such as an expression, a statement) in the script, and is used for subsequent semantic analysis and code conversion. Its specific implementation is the ParseTree object of ANTLR, which contains syntax rule information and source code location information; the predefined syntax rule set is a standard set for judging whether the syntax of the dynamic script code is correct, including statement structure, symbol usage, etc.; the data dependency relationship is the association relationship between variables and resources in the code, which affects the execution order and result correctness; the execution flow consistency refers to the characteristic that the execution order of the code logic meets the expected design and has no logical contradiction; the variable reference conflict refers to the case that the same variable is repeatedly defined or assigned with contradictory values at different positions; the resource access conflict refers to the conflict caused by simultaneous operation of the same resource such as a file or a memory address by multiple code segments; the bytecode instruction sequence is an ordered instruction set formed after the conversion of the abstract syntax tree, which can be directly executed by the virtual machine; the read-write execution permission attribute of the memory page is the access control permission set by the operating system for the memory region, which determines whether the region can be read, modified, or code executed; the memory mapping table is a table recording the location, size, permission, and corresponding code association information of the memory block, used to manage the code in the memory; the dynamic script hot update manager is a module responsible for monitoring the state of the code in the memory, receiving update instructions, and performing code replacement, and is the core of the hot update mechanism.

[0096] In the embodiments of the present application, first, the code block identifier and the input parameter list of the required dynamic script code are determined based on the processing requirement mark embedded in the enhanced asset data through step S1031, and then the start position and the end position of the character sequence are located according to the code block identifier, and the character sequence of the dynamic script code is read. For example, the enhanced asset data is a role model asset of an A engine, the processing requirement mark is "role model lightweight processing", the corresponding code block identifier is "RoleModelLighten", and the input parameter list is "face number threshold, texture resolution upper limit, LOD level number". According to "RoleModelLighten", the character sequence starting from the 25th line and ending at the 80th line in the script file is located and read completely. The dynamic script processing adopts Lua language, and the following is an example code:

[0097] function processAsset(assetData, specParams)

[0098] if assetData.polygonCount > specParams.maxPolygons then

[0099] reducePolygons(assetData, specParams.maxPolygons)

[0100] end

[0101] return assetData

[0102] end

[0103] Secondly, by step S1032, the read character sequence is subjected to lexical analysis to generate a vocabulary token stream, and the vocabulary token stream is subjected to syntax analysis to construct an abstract syntax tree, and it is verified whether the node types and connection relationships of the abstract syntax tree conform to the predefined syntax rule set, and the node positions that do not conform to the rules are marked with errors and the error types are recorded. For example, the character sequence of the "RoleModelLighten" code block is subjected to lexical analysis, and the keywords "function", "if", "for" and the variable names "faceCount", "texRes" in the code are converted into a vocabulary token stream containing "function keyword", "conditional statement token", and "variable identifier"; after the abstract syntax tree is constructed based on the token stream, it is found that a "for" loop node is missing a loop termination condition, which does not conform to the predefined rule that "a loop statement must contain an initial value, a termination condition, and a step", and an error is immediately marked at line 42 of the code line corresponding to the node, and the error type is recorded as "incomplete loop syntax". Syntax analysis and semantic verification are implemented using the ANTLR tool, and the syntax rule set includes variable declaration rules, type matching rules, function call rules, and semantic checking rules such as variable scope checking, type compatibility checking, and resource access permission checking.

[0104] Next, by step S1033, the input parameter list is mapped to the variable nodes in the abstract syntax tree, and based on the structure of the abstract syntax tree and the context information of the enhanced asset data, the data dependency relationship and execution flow consistency in the code logic are analyzed, variable reference conflicts and resource access conflicts are identified, and the identified conflicts are recorded with errors and the current processing flow is terminated. For example, the "face number threshold, texture resolution upper limit, LOD level number" three input parameters are mapped to the "faceThreshold", "texResLimit", and "lodLevel" three variable nodes in the abstract syntax tree respectively; when analyzing the data dependency relationship, it is found that the "lodLevel" is used to calculate the model subdivision degree first, and then the "lodLevel" is assigned, which has a reference conflict of "variable not defined before use", and the error is immediately recorded, the code line 55 is associated, and the current script processing flow is terminated.

[0105] Then, the abstract syntax tree that passes the verification is converted into an executable bytecode instruction sequence through step S1034, and the bytecode instruction sequence is optimized to improve execution efficiency and reduce memory occupancy. For example, the "RoleModelLighten" abstract syntax tree that passes the syntax and semantic verification is converted into a bytecode instruction sequence containing operations such as "read model surface number data", "determine whether the surface number threshold is exceeded", "reduce texture resolution", "generate LOD level", etc. During optimization, repeated "data reading" instructions are combined, "multiple conditional determinations" are simplified into "branch jump tables", the total number of instructions is reduced, redundant constant data in the instructions is compressed, and memory occupancy is reduced.

[0106] Finally, through step S1035, a continuous memory space is allocated, the optimized bytecode instruction sequence is loaded into the memory space, the read-write execution permission attribute of the memory page is set to realize the runtime code replacement, and the dynamic script hot updating mechanism is established. This process specifically includes calculating the total length of the optimized bytecode instruction sequence and the runtime memory requirement, applying a continuous virtual address space to the operating system according to the calculation result, and dividing the virtual address space into memory blocks of a fixed size. The virtual address space in the present application refers to a process address space applied through the mmap system call of the Linux system. By setting the PROT_READ|PROT_WRITE|PROT_EXEC permission flag, the memory area can store bytecode data and be directly executed. Specifically, the mmap(NULL, size, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) is called through the native method. The memory allocation algorithm is used to select the idle block that meets the storage requirement of the bytecode instruction sequence from the memory block, and the optimized bytecode instruction sequence is written to the start address of the idle block. The access control attribute of the memory block is modified, the memory page storing the bytecode instruction sequence is set to a readable, writable and executable state, the loading address and permission attribute of the bytecode instruction sequence are recorded to the memory mapping table, and the memory mapping table is associated with the dynamic script hot updating manager. The memory state of the memory mapping table is tracked through the dynamic script hot updating manager, and when the bytecode instruction sequence update instruction is received, the target memory block is located according to the memory mapping table and the code replacement operation is performed. For example, the total length of the optimized "RoleModelLighten" bytecode instruction sequence is 2048 bytes, and 512 bytes of temporary cache space is required at runtime. According to this, a continuous virtual address space of 3072 bytes is applied to the operating system, and is divided into three memory blocks of 1024 bytes / block. The buddy system algorithm is used to select the first two continuous idle blocks of 2048 bytes to store the bytecode, and the third block of 1024 bytes is reserved as temporary cache. The permission of the block storing the bytecode is set to "readable + writable + executable", and its start address is recorded as "0x10000000" and the permission attribute is recorded as "RWX" in the memory mapping table. Then, the mapping table is associated with the hot updating manager. When the developer updates the "LOD level generation algorithm", the hot updating manager receives the update instruction, locates the block starting at "0x10000000" according to the memory mapping table, and directly writes the new bytecode instruction sequence to complete the code hot updating.

[0107] In practical applications, a game development team is responsible for adapting a batch of enhanced asset data including character models and scene props to B engine, wherein the character models need to perform "lightweight processing". The team first reads the processing requirement mark from the character model enhanced asset data, determines to call the "RoleModelLighten" script block, obtains the input parameter list, and then reads the corresponding script character sequence. After lexical analysis, a stream containing marks such as "function call" and "variable assignment" is generated, and no syntax error is found after building an abstract syntax tree. During semantic analysis, it is confirmed that the parameter mapping is correct, and there is no variable or resource conflict. Then the abstract syntax tree is converted into a bytecode instruction sequence, and after optimization, it is loaded into a memory space of 2560 bytes, the memory permission is set, and the hot update manager is associated. In subsequent development, the team found that the lightweight model was stuck in the B engine, and the "face threshold" calculation logic needed to be adjusted. The bytecode instruction sequence in the memory was directly replaced through the hot update manager, and the new logic took effect immediately without restarting the asset processing service. It only took 5 minutes to complete the processing logic update of all character models, greatly shortening the adaptation cycle.

[0108] In the overall scheme of the above step S103, through syntax analysis and semantic verification, syntax errors and logical conflicts in the dynamic script code are checked in advance to ensure the correctness of code execution and avoid asset processing failure due to code problems; the code is converted into optimized bytecode and loaded into memory to reduce the parsing overhead during code execution, improve asset processing efficiency, and reduce memory resource consumption; the established dynamic script hot update mechanism supports direct code replacement at runtime without interrupting the overall processing flow, greatly improving the iteration speed of asset processing logic, enabling the processing of multi-source assets in game development to quickly respond to changes in engine adaptation requirements, and enhancing the flexibility and stability of the entire data processing system.

[0109] S104, according to the execution state of the dynamic script hot update mechanism, performing large-scale concurrent loading processing on the enhanced asset data to generate a set of asset data processed by multiple threads, and when detecting asset loading failure, automatically recording error information and triggering an exception capture mechanism, and switching to a preset standby resource path to re-execute the loading operation;

[0110] Optionally, step S104 can specifically include the following steps:

[0111] S1041, detecting the running state indicators of the dynamic script hot update mechanism to obtain code execution progress and system resource occupation data, wherein the system resource occupation data includes CPU core utilization and memory bandwidth usage, and the code execution progress indicates the execution stage and remaining task amount of the current hot update script;

[0112] S1042、According to the code execution progress and the system resource occupation data, dynamically calculate the optimal thread pool size and memory buffer allocation scheme, initialize the multi-thread execution environment according to the optimal thread pool size, and allocate the memory buffer area according to the memory buffer allocation scheme;

[0113] S1043, the enhanced asset data is divided into multiple independent processing blocks and stored in the memory buffer area, the independent processing blocks are loaded in the initialized multi-thread execution environment, the data content of each independent processing block is processed by applying dynamic script logic, and the multi-thread processing results are integrated into a unified asset data set;

[0114] S1044, when detecting a failure event in the asset loading process, record error details to the system log file, and trigger an exception capture processing program to abort the current loading process, switch to a preset backup resource path, and re-initiate the loading operation.

[0115] In the above steps, the execution state of the dynamic script hot update mechanism refers to the real-time situation of the mechanism in the running process, including code execution progress and system resource occupation data. The code execution progress is used to indicate the execution phase and the remaining task amount of the current hot update script, helping to determine whether it is suitable to start asset loading. The system resource occupation data includes CPU core utilization and memory bandwidth usage, reflecting the use of current system hardware resources, providing a basis for thread pool and memory allocation. The optimal thread pool size is the number of threads that can maximize loading efficiency and avoid resource waste, calculated based on system resources and task amount. The thread pool in this application refers to a concurrent processing mechanism based on Java ThreadPoolExecutor implementation, which realizes parallel loading and processing of asset data through core thread number, maximum thread number, work queue and other parameter configurations. Its special feature is to support dynamic adjustment of thread number at runtime, automatically expanding or shrinking according to asset processing progress. The memory buffer allocation scheme is the allocation method of planning the memory buffer area, which clearly defines the size, number and purpose of the buffer area, used to temporarily store the enhanced asset data to be loaded. The multi-thread execution environment is the running environment formed after initializing a specified number of threads, supporting concurrent processing tasks. The independent processing block is a data segment formed by dividing the enhanced asset data, which can be independently loaded and processed by a single thread. The asset data set is a unified data collection formed by integrating all independent processing block results after multi-thread loading and processing. The failure event is an abnormal situation that occurs during asset loading, such as file corruption, path error, etc. The error details are a specific description of the failure event, including failure time, failure asset identifier and failure reason, which are used for subsequent problem troubleshooting. The system log file is a file that stores various event records during system operation, and the error details are written into it for traceability. The exception capture processing program is a program module for monitoring and responding to loading failure events, which can abort the current error loading process and trigger the subsequent backup scheme. The preset backup resource path is a resource storage path configured in advance in parallel with the main resource path, which can be switched to for reloading when the main path fails.

[0116] In the embodiments of the present application, first, the running state indicators of the dynamic script hot update mechanism are detected through step S1041, and the code execution progress and system resource occupation data are obtained. The code execution progress will clearly indicate whether the current hot update script is in the initialization phase, execution phase or end phase, and how much code is left to execute; the system resource occupation data collects CPU core utilization and memory bandwidth usage in real time. For example, the current hot update script is in the end phase, with 10% task amount left, CPU core utilization of 30%, and memory bandwidth usage of 25%, which will be collected and recorded in real time.

[0117] Secondly, according to the acquired code execution progress and system resource occupation data, the optimal thread pool size and memory buffer allocation scheme are dynamically calculated through step S1042, and then the multi-thread execution environment is initialized according to the optimal thread pool size, and the memory buffer area is allocated according to the memory buffer allocation scheme. When calculating the optimal thread pool size, the CPU core number, CPU utilization and task parallelism are combined. If the current system has 8 CPU cores and the CPU utilization is 30%, the optimal thread pool size is calculated to be 4; the memory buffer allocation scheme will plan 4 memory buffer areas of 2 GB each according to the total amount of enhanced asset data and the size of a single data block, which are used to temporarily store independent processing blocks. Then, the multi-thread execution environment of 4 threads is initialized, and the corresponding 4 memory buffer areas are allocated.

[0118] Then, through step S1043, the enhanced asset data is divided into multiple independent processing blocks and stored in the memory buffer area, and the independent processing blocks are loaded concurrently in the initialized multi-thread execution environment, the dynamic script logic is applied to process the data content of each independent processing block, and finally the multi-thread processing result is integrated into a unified asset data set. For example, the total size of the enhanced asset data is 8 GB, which is divided into 4 independent processing blocks of 2 GB each and stored in 4 memory buffer areas; the 4 threads in the multi-thread execution environment load the independent processing blocks from the corresponding buffer areas at the same time, and the script logic after hot update is applied to format check and preliminarily process the data during the loading process. After all threads are processed, the results of the 4 independent processing blocks are integrated to form a complete asset data set. The concurrent loading adopts a dynamic thread pool size calculation strategy, and the calculation formula is: number of threads = min(CPU core number x 0.8, number of asset blocks to be processed), where 0.8 is the resource utilization factor.

[0119] Finally, through step S1044, when a failure event in the asset loading process is detected, the error details are recorded in the system log file, and the abnormal capture processing program is triggered to stop the current loading process and switch to the preset backup resource path to re-execute the loading operation. For example, a thread fails to load the second independent processing block due to file damage in the main resource path, and the system immediately records the error details, including the failure time of 14:30, the failure asset identifier of "scene model-002", and the failure reason of "file damage", and writes these information into the system log file; at the same time, the abnormal capture processing program is started, which stops the current loading process of the thread, and then switches to the preset backup resource path to re-read the independent processing block corresponding to "scene model-002" and execute the loading operation.

[0120] In practical applications, a game development team needs to load a batch of enhanced asset data with a total amount of 16 GB, including scene models and character animations. The team first detects the execution status of the dynamic script hot update mechanism and finds that the script is in the tail phase, with 5% of the remaining task amount, 28% of the CPU core utilization rate, and 22% of the memory bandwidth usage rate. According to these data, the optimal thread pool size is calculated to be 6, and the memory buffer allocation scheme is 6 memory buffer areas of 3 GB each. Then, a multi-thread execution environment with 6 threads is initialized and the memory buffer areas are allocated. The team divides the 16 GB of enhanced asset data into 6 independent processing blocks, with the first 5 being 3 GB each and the last one being 1 GB, and stores them in the corresponding memory buffer areas. The 6 threads are loaded concurrently. During the process, when one thread loads the "character animation-005" independent processing block, a failure event is triggered due to network fluctuations in the main resource path. The system records error information to a log file, and the exception handling program aborts the loading process and switches to the backup resource path to successfully reload. After all threads are processed, a unified asset dataset is formed for subsequent game engine use.

[0121] In the overall scheme of the above step S104, by first detecting the execution status of the dynamic script hot update mechanism, the asset loading is ensured to start at a time when the system resources are sufficient and the script has minimal impact, avoiding efficiency decline due to resource competition; the optimal thread pool size and memory buffer allocation scheme are dynamically calculated to achieve reasonable allocation of resources and maximize the efficiency of multi-thread concurrent loading; the asset data is segmented and loaded concurrently, significantly reducing the loading time of large-scale assets; when loading fails, errors are automatically recorded, exception handling is triggered, and the backup path is switched, ensuring the stability and reliability of the loading process and reducing the interruption of the development process caused by loading failure, providing a stable data foundation for subsequent asset processing.

[0122] S105, convert the format of the asset dataset to the native format required by the target game engine, update the execution parameters of the asset optimization algorithm through the dynamic script hot update mechanism, and perform batch quality optimization processing on the asset data in the native format to ensure that the processed assets meet the performance requirements and quality standards of the target engine.

[0123] Optionally, step S105 can specifically include the following steps:

[0124] S1051, identify the native format specification of the target game engine, define data field mapping rules and type conversion rules based on the data structure definition and storage requirements in the native format specification;

[0125] S1052, adjust the file organization structure and data encoding method of the asset dataset according to the data field mapping rules and type conversion rules, and generate native format data that meets the reading requirements of the target game engine.

[0126] S1053, query parameter update instruction through the dynamic script hot update mechanism, obtain the latest execution parameter set of the asset optimization algorithm, and update the configuration items and threshold settings of the processing algorithm by using the latest execution parameter set;

[0127] S1054, perform batch quality optimization operation on the original format data by using the updated processing algorithm, and adjust the texture resolution value, polygon quantity value and material attribute parameter value of the original format data;

[0128] S1055, verify whether the performance indicators of the optimized data meet the rendering efficiency standard and the memory occupation standard of the target game engine, and repeatedly perform optimization processing on the asset data that does not meet the quality requirements until the quality requirements are met.

[0129] In the above steps, the native format specification of the target game engine is the standard requirement of the target engine for asset data, including data structure definition and storage requirements, which specify how asset data should be organized and encoded to be normally read by the target engine. The data structure definition explicitly defines the field composition, field type and inter-field relationship of the asset data; the storage requirement explicitly defines the file format, compression method and storage path rule of the data. The data field mapping rule is the rule that defines the correspondence between the fields of the asset data set and the fields of the target engine native format, ensuring that the source data fields can be accurately matched to the target fields. The type conversion rule is the rule that specifies the conversion method of the data type of the asset data set and the data type of the target engine native format, solving the incompatibility problem of different data types. The file organization structure is the arrangement method of asset data in the file, including directory level, file naming format and data block division; the data coding method is the method of converting data into binary or text form that can be recognized by the target engine. The native format data is the asset data that meets the reading requirements of the target engine after adjusting the file organization structure and data coding. The parameter update instruction is an instruction received by the dynamic script hot update mechanism for triggering asset optimization algorithm parameter update, which contains the acquisition path of the latest execution parameter set. The latest execution parameter set of the asset optimization algorithm is a parameter group used to adjust the configuration items and threshold values of the optimization algorithm, which determines the direction and degree of optimization operation. The configuration item is a function switch or mode selection parameter in the optimization algorithm, and the threshold value is a critical numerical value in the optimization algorithm that determines whether to perform a certain operation. Batch quality optimization operation is a quality improvement process performed on a large amount of native format data at the same time, which is achieved by adjusting the texture resolution value, polygon number value and material attribute parameter value. The texture resolution value is a value that describes the pixel density of a texture image, which affects the clarity of texture display; the polygon number value is a value that describes the number of polygons on the surface of a model, which affects the rendering efficiency of the model; the material attribute parameter value is a parameter that describes the optical properties of the material, such as reflectivity, transparency, etc., which affects the display effect of the material. The performance indicator is an indicator that measures the running performance of asset data in the target engine, including rendering efficiency standard and memory occupancy standard. The rendering efficiency standard is the qualified requirement of the rendering speed of asset data in the target engine, and the memory occupancy standard is the qualified requirement of the memory size occupied by asset data in the target engine.

[0130] In the embodiments of the present application, first, the native format specification of the target game engine is identified through step S1051, and based on the data structure definition and storage requirements in the specification, data field mapping rules and type conversion rules are defined. For example, the target engine is A engine, and its native format specification requires model data to contain "vertex coordinates", "texture coordinates", and "material ID" fields, and the storage format is binary and uses LZ4 compression. Based on this, the data field mapping rules are defined, mapping "model vertices" in the asset dataset to "vertex coordinates" of the A engine, "texture coordinates" to "texture coordinates", and "material number" to "material ID". At the same time, the type conversion rules are defined, converting "floating-point vertex coordinates" in the asset dataset to "32-bit floating-point type" required by the A engine.

[0131] Secondly, through step S1052, the file organization structure and data encoding method of the asset dataset are adjusted according to the defined data field mapping rules and type conversion rules, and native format data conforming to the reading requirements of the target game engine is generated. For example, according to the requirements of the A engine, the adjusted model data is organized in the file structure in the order of "vertex data block - texture data block - material data block", the file is named "Model_A_XXX.bin", and the file is encoded using the LZ4 compression algorithm, and finally the native format model data that can be directly read by the A engine is generated.

[0132] Then, through step S1053, the latest execution parameter set of the asset optimization algorithm is obtained by querying the parameter update instruction through the dynamic script hot update mechanism, and the configuration items and threshold settings of the processing algorithm are updated using the set. For example, the dynamic script hot update mechanism queries the parameter update instruction, and the latest execution parameter set obtained includes "texture resolution optimization mode = automatic adaptation", "polygon number threshold = 10000", and "material reflectivity adjustment coefficient = 0.8". Based on this, the "mode configuration item" of the optimization algorithm is set to "automatic adaptation", the "polygon number threshold" is set to 10000, and the "reflectivity coefficient configuration item" is set to 0.8.

[0133] Then, by step S1054, the updated processing algorithm is used to perform batch quality optimization on the native format data, adjusting the texture resolution value, polygon number value and material attribute parameter value of the native format data. The quality optimization uses a mesh simplification algorithm based on quadric error metrics, with parameter settings including an error threshold of 0.1, a maximum number of iterations of 100, and a minimum face ratio of 0.3. For example, performing optimization on a batch of A-engine native format model data, adjusting the texture resolution value from the original 4096x4096 to 2048x2048 to adapt to the target device, simplifying models with a polygon number value exceeding 10,000 to within 10,000, and adjusting the material reflectance parameter value by a factor of 0.8 to ensure that the material display effect meets expectations.

[0134] Finally, by step S1055, the performance indicators of the optimized data are verified to see if they meet the rendering efficiency standards and memory usage standards of the target game engine, and the optimization process is repeated on asset data that does not meet the quality requirements until the quality requirements are met. For example, testing the rendering frame rate and memory usage of the optimized model data in the A-engine, if the rendering frame rate of a certain model is lower than the A-engine rendering efficiency standard or the memory usage exceeds the memory usage standard, then the optimization operation is re-executed to further reduce the polygon number or compress the texture until the performance indicators of the model meet the standards.

[0135] In practical applications, a game development team needs to convert multi-source assets containing 200 character models, 500 scene prop models, and 300 scene maps into the native format of B engine and optimize them. The team first consults the B engine development documents to determine the specifications: the models must contain four fields, namely "vertex array", "normal vector", "UV coordinate", and "skeleton weight", and be stored in ".bmodel" format and compressed with ZSTD. The maps are stored in ".btx" format and support BC7 compression. Based on this, the team defines field mapping rules, such as mapping "model normal" to "normal vector" and type conversion rules, converting 64-bit floating-point coordinates to 32-bit, and adjusts the file structure in batches through Python scripts, divides the files into directories according to "character / prop / map", names them as "type_number.bmodel / .btx", and encodes them to generate native data. Then, the team obtains parameters through a dynamic script hot update mechanism, simplifies character models in batches using MeshLab tools, reduces the number of faces of models with more than 15000 faces to 12000-15000 using edge folding algorithm, and adjusts maps in batches using Photoshop according to "mobile terminal 1024x1024, PC terminal 2048x2048". The team builds a simulated game level in B engine and finds that 45 props such as trees exceed the "single prop ≤5MB" standard and 20 long-range maps have a frame rate lower than "mobile terminal ≥30FPS". The team optimizes the models further by reducing the number of faces to 6000 and compressing vertex data, and changes the map compression format to BC5. Finally, all assets meet the standards and can be directly imported into B engine for level development.

[0136] In the overall scheme of step S105, the target engine native format specification is accurately matched to ensure that asset data can be normally read by the target engine, solving the multi-engine format adaptation problem. The dynamic script hot update mechanism is used to update optimization parameters, enabling asset optimization to quickly respond to demand changes and improving optimization flexibility. Batch optimization significantly improves asset processing efficiency, avoiding the tediousness of processing one by one. The performance verification and repeated optimization mechanism ensures that the processed assets meet the performance and quality requirements of the target engine, providing a reliable asset foundation for the stable operation of the game in the target engine.

[0137] The following is a complete embodiment for steps S101-S105:

[0138] As Figure 3As shown, a game development team undertook a cross-platform game project that needed to integrate 150 character models of A engine, 300 scene prop models of B engine, 200 scene maps of C engine, and other multi-source heterogeneous assets, and finally adapt to the target C engine. The team first started the data conversion link, and through the self-developed format analysis tool, the binary protocol signals of A engine, JSON text protocol signals of B engine, and XML protocol signals of C engine were uniformly converted into a custom intermediate representation format. At the same time, with the help of document parsing scripts, game design documents were scanned to extract asset specification parameters such as "character model face number ≤20000, map resolution ≤2048x2048", and engine compatibility identifiers such as "character model supports C engine 4.0 and above, scene props need to be compatible with C engine 3.5+" were located from the art direction book.

[0139] Subsequently, the team wrote these parameters and identifiers into the data structure fields of the intermediate representation format through the dynamic injection module, generating enhanced asset data with C engine adaptation markers. Then, for the "format conversion + quality optimization" processing needs of enhanced assets, the syntax analysis and semantic verification of the supporting dynamic script code were carried out, and after confirming that there was no error, the script was converted into executable bytecode and loaded into memory, and a dynamic script hot update manager was built to support real-time adjustment of subsequent code.

[0140] In the loading stage, the system monitored that the hot update mechanism was in an idle state, automatically initialized an 8-thread execution environment, and loaded the enhanced asset data in 650 independent processing blocks according to "character / prop / map" classification. In the process, 23 B engine scene maps failed to load due to damage to the main resource path file, and the system immediately recorded the error time, asset ID, and failure reason to the log, triggered the exception capture program to abort the current loading, automatically switched to the preset cloud backup resource path for reloading, and finally successfully generated a complete asset dataset. Finally, the team converted the dataset into the ".cmod" native model format and ".ctex" native map format required by C engine through the format conversion tool, and then obtained the latest optimization parameters through the hot update mechanism. "Character models with more than 20000 faces are simplified to 15000-20000 faces, and maps with more than 2048x2048 are compressed to 1024x1024", and batch optimization was performed on the native format assets. After the first optimization, it was found that 35 A engine character models exceeded the face number, and the team adjusted the script parameters through hot update. After the second optimization, all assets met the rendering efficiency and memory occupancy standards of C engine, and were successfully imported into the engine for level development.

[0141] The multi-source heterogeneous data unified processing method based on a dynamic script engine provided in the application completely solves the heterogeneous problem of multi-engine protocol signals through a unified intermediate representation format, and realizes the standardized integration of assets of different sources. Dynamic injection of asset specifications and compatibility identifiers provides accurate adaptation basis for subsequent processing and avoids adaptation deviation. The script verification mechanism guarantees the correctness of code execution, and the hot update function supports real-time iteration of processing logic without interrupting the overall process. Large-scale concurrent loading significantly improves processing efficiency, and the automatic recovery mechanism reduces manual intervention and ensures data loading stability. The format conversion and batch optimization steps accurately match the target engine requirements, and dynamic parameter updating realizes the balance between asset quality and performance, significantly reducing the time cost and labor cost of multi-source asset processing, and effectively improving the process smoothness and asset adaptation flexibility of cross-platform game development.

[0142] Figure 4 A specific implementation structure diagram of a multi-source heterogeneous data unified processing system based on a dynamic script engine provided for an embodiment of the application is shown in Figure 4 The system can include:

[0143] An extraction module 41 is configured to convert game engine protocol signals of multiple different formats and structures into a unified intermediate representation format, and extract asset specification parameters and engine compatibility identifiers from game design documents and art direction books;

[0144] An injection module 42 is configured to dynamically inject the asset specification parameters and engine compatibility identifiers into the data structure of the intermediate representation format to form enhanced asset data with engine-specific markers;

[0145] A conversion module 43 is configured to perform syntax analysis and semantic verification on corresponding dynamic script code based on the processing requirements of the enhanced asset data, convert the dynamic script code into executable bytecode and load it into memory, and establish a dynamic script hot update mechanism in memory to support runtime code updating;

[0146] A generation module 44 is configured to perform large-scale concurrent loading processing on the enhanced asset data according to the execution state of the dynamic script hot update mechanism, generate a multi-threaded processed asset data set, automatically record error information and trigger an exception capture mechanism when asset loading failure is detected, and switch to a preset backup resource path to re-execute the loading operation;

[0147] An update module 45 is configured to convert the format of the asset data set into a native format required by a target game engine, update the execution parameters of the asset optimization algorithm through the dynamic script hot update mechanism, and perform batch quality optimization processing on the asset data in the native format to ensure that the processed assets meet the performance requirements and quality standards of the target engine.

[0148] The multi-source heterogeneous data unified processing system based on the dynamic script engine of the embodiments of the present application is used to implement the multi-source heterogeneous data unified processing method based on the dynamic script engine as described above, and therefore the specific embodiments of the multi-source heterogeneous data unified processing system based on the dynamic script engine can be seen from the embodiment part of the multi-source heterogeneous data unified processing method based on the dynamic script engine as described above. The specific embodiments can be referred to the description of the corresponding embodiment part, and will not be described here again.

[0149] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the multi-source heterogeneous data unified processing method based on the dynamic script engine as described above.

[0150] The present application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the multi-source heterogeneous data unified processing method based on the dynamic script engine as described above.

[0151] In an exemplary embodiment, the computer readable storage medium as described above can include, but is not limited to, a U disk, a read-only memory, a random access memory, a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0152] The embodiments of the present application also provide a computer program product, wherein the computer program product comprises a computer program, and the computer program is executed by a processor to implement the steps in the multi-source heterogeneous data unified processing method based on the dynamic script engine as described above.

[0153] The skilled person can further realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in general terms in the above description. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0154] The above describes in detail the method and system for unified processing of multi-source heterogeneous data based on a dynamic script engine provided by the present application. The principles and implementation modes of the present application are described by using specific examples, and the above description of the examples is only used to help understand the method of the present application and its core idea. It should be pointed out that, for those skilled in the art, some improvements and modifications can be made to the present application without departing from the principles of the present application, and these improvements and modifications also fall within the protection scope of the present application.

Claims

1. A method for unified processing of multi-source heterogeneous data based on a dynamic script engine, characterized in that, The application relates to a method for converting game engine protocol signals of various formats and structures into a unified intermediate representation format, extracting asset specification parameters and engine compatibility identifiers from game design documents and art direction books, dynamically injecting the asset specification parameters and engine compatibility identifiers into a data structure in the intermediate representation format to form enhanced asset data with engine-specific markers, performing syntax analysis and semantic verification on corresponding dynamic script codes based on processing requirements of the enhanced asset data, converting the dynamic script codes into executable bytecodes and loading the bytecodes into memory, establishing a dynamic script hot updating mechanism in the memory to support runtime code updating, performing large-scale concurrent loading processing on the enhanced asset data according to the execution state of the dynamic script hot updating mechanism, generating asset data sets processed by multiple threads, automatically recording error information and triggering an exception capturing mechanism when asset loading fails, and switching to a preset backup resource path to re-execute the loading operation, converting the format of the asset data sets into a native format required by a target game engine, updating execution parameters of asset optimization algorithms through the dynamic script hot updating mechanism, performing batch quality optimization processing on the asset data in the native format, and ensuring that the processed assets meet the performance requirements and quality standards of the target engine. The method comprises the following steps: based on processing requirements embedded in the enhanced asset data, determining code block identifiers and input parameter lists of required dynamic script codes, positioning starting positions and ending positions of character sequences of the dynamic script codes according to the code block identifiers, and reading the character sequences of the dynamic script codes; performing lexical analysis on the character sequences to generate a word token stream, performing syntax analysis on the word token stream to construct an abstract syntax tree, verifying whether node types and connection relationships of the abstract syntax tree conform to a pre-defined syntax rule set, marking error positions of nodes that do not conform to the rule set and recording error types; mapping the input parameter lists to variable nodes in the abstract syntax tree, analyzing data dependency relationships and execution flow consistency in code logic based on the structure of the abstract syntax tree and context information of the enhanced asset data, identifying variable reference conflicts and resource access conflicts, recording the identified conflicts and terminating the current processing flow; converting the verified abstract syntax tree into an executable bytecode instruction sequence, and performing optimization processing on the bytecode instruction sequence to improve execution efficiency and reduce memory occupation; allocating continuous memory space, loading the optimized bytecode instruction sequence into the memory space, setting read-write execution permission attribute of the memory page to realize runtime code replacement, and establishing a dynamic script hot updating mechanism. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ 2. The method of claim 1, wherein, Allocating continuous memory space, loading the optimized bytecode instruction sequence into the memory space, implementing runtime code replacement by setting read-write execution permission attribute of memory page, establishing dynamic script hot update mechanism, comprising: Calculating the total length and runtime memory requirement of the optimized bytecode instruction sequence, and applying a continuous virtual address space to the operating system according to the calculation result, dividing the virtual address space into memory blocks of fixed size; Selecting an idle block that meets the bytecode instruction sequence storage requirement from the memory block by using a memory allocation algorithm, and writing the optimized bytecode instruction sequence into the start address of the idle block; Modify the access control attribute of the memory block, set the memory page storing the bytecode instruction sequence to read-write and executable state, record the loading address and permission attribute of the bytecode instruction sequence to the memory mapping table, and associate the memory mapping table to the dynamic script hot update manager; Tracking the memory state of the memory mapping table through the dynamic script hot update manager, and when receiving a bytecode instruction sequence update instruction, locating the target memory block according to the memory mapping table and performing code replacement operation.

3. The method of claim 1, wherein, Convert game engine protocol signals of various formats and structures into a unified intermediate representation format, and extract asset specification parameters and engine compatibility identifiers from game design documents and art direction books, including: According to the difference of transmission format characteristics in the game engine protocol signal, the received protocol data packet is divided into two types: binary encoded protocol data packet and text encoded protocol data packet; Parse the fixed length field of the packet header and the variable length structure of the data body from the binary encoded protocol data packet, and parse the key-value pair separator and nested level marker from the text encoded protocol data packet, and decode the parsed protocol data packet into structured data elements containing type identifier and original data value; According to the type and content of the structured data element, a unified intermediate representation format is established, and the structured data element is allocated to the numerical storage field of the corresponding data container of the intermediate representation format according to its type; Read the text information of the game design document, and extract asset specification parameters by scanning the content of the text information and matching keywords and numerical expressions associated with asset size attributes and asset type attributes; Query the text content and graphical symbols of the art direction book, and extract engine compatibility identifiers by locating identifiers related to engine version adaptation conditions.

4. The method of claim 3, wherein, According to the difference of transmission format characteristics in the game engine protocol signal, the received protocol data packet is divided into two types: binary encoded protocol data packet and text encoded protocol data packet, including: Analyze the transmission format characteristics of the game engine protocol signal, including the start identification characteristics and content encoding characteristics of the data packet; Obtain the byte sequence of the protocol data packet, identify whether the numerical value of the fixed position field information in the byte sequence matches the predefined protocol identifier based on the start identification characteristics, and obtain the field identification result; Based on the content coding feature, content analysis is performed on the byte sequence, the structural characteristics of the data content are determined by calculating the proportion of non-printable characters and counting the distribution pattern of readable characters, and a content distribution analysis result is generated; According to the combination judgment of the field recognition result and the content distribution analysis result, the protocol data packet is classified as a binary encoding protocol data packet or a text encoding protocol data packet.

5. The method of claim 1, wherein, According to the execution state of the dynamic script hot update mechanism, the enhanced asset data is processed for large-scale concurrent loading, and an asset data set processed by multiple threads is generated. When asset loading failure is detected, error information is automatically recorded and an exception capture mechanism is triggered, and a preset backup resource path is switched to for re-executing the loading operation, including: Detecting the running state indicators of the dynamic script hot update mechanism, obtaining code execution progress and system resource occupation data, the system resource occupation data including CPU core utilization and memory bandwidth usage, and the code execution progress indicating the execution stage and remaining task amount of the current hot update script; According to the code execution progress and the system resource occupation data, dynamically calculating the optimal thread pool size and memory buffer allocation scheme, initializing a multi-thread execution environment according to the optimal thread pool size, and allocating a memory buffer area according to the memory buffer allocation scheme; The enhanced asset data is divided into multiple independent processing blocks and stored in the memory buffer area, and the independent processing blocks are loaded concurrently in the initialized multi-thread execution environment. The data content of each independent processing block is processed by applying dynamic script logic, and the multi-thread processing result is integrated into a unified asset data set. When a failure event in the asset loading process is detected, error details are recorded in a system log file, and an exception capture processing program is triggered to stop the current loading process, switch to a preset backup resource path, and re-initiate the loading operation.

6. The method of claim 1, wherein, The format of the asset data set is converted to the native format required by the target game engine, the execution parameters of the asset optimization algorithm are updated through the dynamic script hot update mechanism, and batch quality optimization processing is performed on the asset data in the native format to ensure that the processed assets meet the performance requirements and quality standards of the target engine, including: Identify the native format specification of the target game engine, define data field mapping rules and type conversion rules based on the data structure definition and storage requirements in the native format specification; According to the data field mapping rules and type conversion rules, adjust the file organization structure and data encoding method of the asset data set to generate native format data that meets the reading requirements of the target game engine; Query parameter update instructions through the dynamic script hot update mechanism to obtain the latest execution parameter set of the asset optimization algorithm, and update the configuration items and threshold settings of the processing algorithm using the latest execution parameter set; Perform batch quality optimization operations on the native format data using the updated processing algorithm, adjust the texture resolution value, polygon quantity value, and material attribute parameter value of the native format data; Verify whether the performance indicators of the optimized data meet the rendering efficiency standards and memory occupation standards of the target game engine. If not, repeat the optimization process until the quality requirements are met.

7. A dynamic script engine-based multi-source heterogeneous data unified processing system for performing the dynamic script engine-based multi-source heterogeneous data unified processing method according to any one of claims 1-6. The method comprises the following steps: An extraction module is used to convert game engine protocol signals of multiple different formats and structures into a unified intermediate representation format, and extract asset specification parameters and engine compatibility identifiers from game design documents and art direction books; An injection module is used to dynamically inject the asset specification parameters and engine compatibility identifiers into the data structure in the intermediate representation format, forming enhanced asset data with engine-specific markers; A conversion module is used to perform syntax analysis and semantic verification on the corresponding dynamic script code based on the processing requirements of the enhanced asset data, convert the dynamic script code into executable bytecode and load it into memory, and establish a dynamic script hot update mechanism in memory to support runtime code updates; A generation module is used to perform large-scale concurrent loading processing on the enhanced asset data according to the execution state of the dynamic script hot update mechanism, generate multi-threaded processed asset data sets, automatically record error information and trigger an exception capture mechanism when asset loading fails, and switch to a preset backup resource path to re-execute the loading operation; An update module is used to convert the format of the asset data set into the native format required by the target game engine, update the execution parameters of the asset optimization algorithm through the dynamic script hot update mechanism, and perform batch quality optimization processing on the asset data in the native format to ensure that the processed assets meet the performance requirements and quality standards of the target engine.

8. An electronic device, comprising: The method comprises the following steps: A memory is used to store a computer program; A processor is used to execute the computer program to implement the steps of the dynamic script engine-based multi-source heterogeneous data unified processing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the dynamic script engine-based multi-source heterogeneous data unified processing method according to any one of claims 1 to 6.

Images