Declarative game configuration cross-file consistency verification methods, devices, and program products

Abstract

This invention provides a declarative game configuration cross-file consistency verification method, device, and program product. The declarative game configuration cross-file consistency verification method includes: acquiring all types of configuration files at the game loading entry point, including world files, blueprint files, graph files, interface files, and data files; constructing a read-only verification context based on the acquired configuration files; registering multiple rules in the form of a static array, each rule being an independent function, the rule functions being used to check error patterns, and the rule functions accessing the verification context in read-only mode; and executing all registered rules through a command-line interface at the game loading entry point, allowing the game to enter runtime only when all rules report no errors. This application achieves the goal of improving the success rate and reliability of AI-generated games.

Description

Technical Field

[0001] This invention belongs to the field of metaverse technology, and in particular relates to a declarative game configuration cross-file consistency verification method, device and program product. Background Technology

[0002] In software engineering, checking the consistency of the entire program before runtime falls under static analysis. Compiled languages ​​have type checkers (TypeScript, Rust borrow checker); lint tools (ESLint, clang-tidy) perform higher-order naming / structure checks; formal methods (SMT, Coq) provide completeness and correctness proofs. In the fields of physics engines and twin simulations, game engine configuration files are neither under the control of type systems nor complex enough to require an SMT solver, making rule-driven linting a suitable, medium-cost approach. Existing technologies for game engines include: (1): TypeScript + JSON Schema, to impose type constraints on JSON configuration. This technique has the following drawbacks: JSON Schema can only describe the structure of a single file and cannot express that field X references a tag declared in another file; cross-file relationships can only be validated in the runtime code, and errors are still postponed; it cannot express semantic conditions such as event:collision:X requiring the peer entity X to have a collision component.

[0003] (2): Online validation of Unity animators / behavior trees. The Unity editor performs UI-level validation on animation state machines and behavior tree nodes (red crosses indicate connection errors). This technology has the following drawbacks: it can only be done in the editor environment, and the AI-generated scenes cannot be reused at runtime; each asset type has its own validator, and there is no unified validation context; it does not apply to assets generated by players at runtime.

[0004] (3): Unreal Blueprint compilation. Unreal performs a compiler traversal (type checking, dead nodes, deprecation warnings) before compiling the Blueprint. This technique has the following drawbacks: it only occurs in the editor stage; the rules are hard-coded within the compiler context, and extensions require recompiling the engine; it is not available at runtime.

[0005] (4): Self-check at game startup: A small number of games (such as some MMOs) will perform a self-check at startup to see if all monster templates are valid. This technology has the following disadvantages: the self-check logic is scattered in the business code; the rules are interdependent and the order is sensitive, and adding new rules is costly; there is no unified verification context for index sharing.

[0006] In summary, the existing technology has the following problems: 1. Cross-file references are nowhere to be found; 2. Editor-level validation is not applicable to runtime AI generation; 3. Hard-coded rules have high expansion costs; 4. SMT solver is too heavy and has poor error information; 5. Lack of a dedicated rule set for common LLM illusions. Summary of the Invention

[0007] To address the aforementioned problems in existing technologies, this invention provides a declarative game configuration cross-file consistency verification method, device, and program product.

[0008] In a first aspect, embodiments of this disclosure provide a method for declarative game configuration cross-file consistency verification, including: All types of configuration files are retrieved at once at the game loading portal. These configuration files include world files, blueprint files, graph files, interface files, and data files. Based on the obtained configuration file, construct a read-only verification context; Multiple rules are registered as a static array, each rule is an independent function, the rule function is used to check error patterns, and the rule function accesses the verification context in read-only mode; At the game loading entry point, all registered rules are executed through the command-line interface. The game is allowed to enter the runtime only if no errors are reported by any of the rules.

[0009] Optionally, the validation context includes the original JSON view, pre-indexing, and output callback; The pre-index includes at least the following mappings: blueprint file tags to blueprint file names, blueprint file names to blueprint file tags, mappings of whether a blueprint file declares a collider, a set of collision whitelist tags, a set of collision layer tags, a set of peer tags listened to by the in-collision event handler, a set of peer tags listened to by the out-collision event handler, a mapping of whether a blueprint file declares displacement capabilities, a displacement pattern string mapping, a set of parsed attribute keys, a set of attributes bound to input actions, a set of referenced attributes, a set of attributes referenced as events, a set of processed event names, a set of emitted event names, a set of input actions declared in the world list, and tags actually used by the world master entity after parsing.

[0010] Optionally, the output callbacks include error callbacks, warning callbacks, or prompt callbacks; The error callback is used to record problems that cause loading to fail, the warning callback is used to record problems that can be loaded but require a reminder, and the prompt callback is used to record style improvement suggestions.

[0011] Optionally, the raw JSON view is shared with the runtime engine to avoid repeated data parsing. The raw JSON view includes a collection of blueprints, a collection of graphs, and a world list.

[0012] Optionally, the rule function is registered through a compile-time static array. Adding a new rule only requires adding a function and adding a row of two tuples to the static array. The two tuples include a rule name identifier and a rule function pointer.

[0013] Optionally, the error mode includes at least one of the following categories: The system includes checks for the existence of referenced targets, alignment of both sides, physical and regional semantics, consistency of attribute declarations and usage, and closed-loop checks for event emission and processing.

[0014] Optionally, the rule function includes: The collision mask target existence rule is used to traverse the collision whitelist tag set corresponding to each blueprint in the verification context. If any tag does not appear in the mapping from tag to blueprint file name, an error callback is used to report that the blueprint references an unknown tag. The duplicate destruction rule in collision events is used to traverse the clauses of each blueprint file, count the number of times the entity destroys itself in the collision event action list, and if the number is greater than once, a warning callback will be sent to report that the same entity has been destroyed repeatedly in the same collision event. The isolated graph rule is used to traverse each graph name in the graph collection, check in the validation context whether the graph name is referenced, and if it is not referenced, report that the graph has been defined but is not referenced through a warning callback.

[0015] Optionally, the method is applied to game scenes generated by runtime artificial intelligence, and is used for verification before the game is loaded.

[0016] Secondly, embodiments of this disclosure also provide an electronic device, the electronic device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which enable the at least one processor to perform the declarative game configuration cross-file consistency verification method described in any of the first aspects.

[0017] Thirdly, embodiments of this disclosure also provide a computer program product, including a computer program / instruction that, when executed by a processor, implements the declarative game configuration cross-file consistency verification method described in any of the first aspects.

[0018] The declarative game configuration cross-file consistency verification method provided by this invention obtains all types of configuration files at once and constructs a verification context. The rule function accesses the verification context in read-only mode, traverses and executes all registered rules, and allows the game to proceed only when no errors are reported by any of the rules. This achieves the goal of improving the success rate and reliability of AI-generated games. Attached Figure Description

[0019] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0020] Figure 1 A flowchart illustrating a declarative game configuration cross-file consistency verification method provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating the execution of a declarative game configuration cross-file consistency verification method provided in this embodiment of the present disclosure in a specific game scenario; Figure 3 A schematic block diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0021] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0022] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0023] It should be noted that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice method. Furthermore, this device and / or practice method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0024] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0025] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0026] This embodiment addresses the problem of how to determine the overall consistency of AI / player-generated declarative game configurations (multiple files including .world, .bp, .graph, .ui, and .data) before runtime. It proposes a pre-indexed, independent rule table, and zero-framework-modification-based integrity verification method. This embodiment aims to solve the following four technical problems: Question 1: Script engine's default error settings: The correctness of code in traditional script-driven engines (Unity C#, Unreal Blueprint, Godot GDScript) is only revealed when the execution path is triggered. In AI-generated game scenes, players often enter the game and see the broken behavior (characters not moving, events not triggering, strange physical behavior) before they can locate the error. This is especially fatal for app store compliance scenarios where entirely new games can be generated at runtime, as the store has already approved the app when the error occurs.

[0027] Question 2: Cross-file references have no natural location for validation: The game configuration inherently involves cross-file configurations: `spawn:"player"` in `.world` points to a tag in a blueprint within `.bp`; `when.do.graph:"attack"` in a blueprint references the name of a `.graph` file; `bind:"world.score"` in `.ui` references an `attr` declared in `.bp`; and `collides_with:["enemy"]` in `.bp` references a tag in another `.bp` file. Renaming any file on either side constitutes a broken reference. This cross-file error cannot be detected by individually verifying each file.

[0028] Question 3: The distribution of errors generated by artificial intelligence is enumerable in a set: Real-world testing data shows that game configuration errors generated by LLM are highly concentrated in the following 10-30 types: misspelled attr names, referencing non-existent blueprints, using move actions on areas, declaring collisions on one side without handling the other, the same entity being destroyed multiple times in collision events, .graphs being defined but not referenced, input actions without corresponding handling, system attrs being overwritten by blueprint redefinitions, etc. Each type of error has fixed structural characteristics, which can be manually identified and written into independent functions. Using the SMT solver for global constraints would be severely inefficient in terms of error message readability, speed, and maintainability.

[0029] Question 4: The number of rules expands with the growth of game engine features, requiring pluggability. This embodiment currently supports 32 rules; as functionality expands (such as animation systems, AI behavior trees, and narrative engines), dozens more rules will be added. If the main framework process is disrupted for each new rule added, the development pace will be severely hampered.

[0030] The unified method provided in this embodiment: (a) Scan all five types of configuration files at the loading entry point to build a pre-index of the validation context (LintContext), providing a validation context that shares the same JSON parsing result with the runtime engine, allowing for multiple queries from a single index; (b) Each rule is declared as a static array. Each rule is an independent C++ function that accesses the validation context in read-only mode. Rules are registered as static arrays in C++, achieving scalability without dynamic loading. A set of orthogonal independent rules is provided, with each rule addressing a specific error mode. (c) The rule function outputs feedback through three levels of callbacks: error, warning, and prompt. It does not write directly to the output stream. The error output of the rule is abstracted through callbacks and can be redirected to CLI, IDELSP, and loading logs. (d) Adding a new rule only requires adding a function and a row to the array, with zero changes to the framework; (e) Load the CLI entry point and iterate through all rules at once. Only after all rules are passed will the runtime begin.

[0031] (f) Covers at least 30 common errors in LLM-generated games; (g) When generating game scenes in UGC / runtime, verify them before running to eliminate new runtime errors from a mechanism perspective.

[0032] like Figure 1 As shown in the figure, this embodiment discloses a declarative game configuration cross-file consistency verification method, including: All types of configuration files are retrieved at once at the game loading portal. These configuration files include world files, blueprint files, graph files, interface files, and data files. A one-time scan refers to a function that the system executes before the game starts running. This function reads all files in the specified folder, such as .world (world files), .bp (blueprint files), .graph (graph files), .ui (interface files), and .data (data files), into memory.

[0033] Based on the obtained configuration file, construct a read-only verification context; The validation context data structure is as follows: The validation context (LintContext) is a read-only aggregate structure that stores three raw JSON views parsed by the loader, a completed metadata index, and three hierarchical error output callbacks. Its fields are divided into the following three groups: Group 1: Raw JSON view (shared with load, not copied): Blueprint Collection: A mapping from names to blueprint JSON; Graph Collection: A mapping from graph names to graph JSON; World List: The entire .world JSON.

[0034] Group 2: Pre-indexing: Mapping from tag to blueprint name (tag_to_name); Mapping from blueprint name to tag (name_to_tag); Mapping for whether the blueprint declares a collider (has_collision); Collision whitelist tag set, indexed by blueprint name (collision_masks); Collision layer tag set, indexed by blueprint name (collision_layers); Set of peer tags listened to by the in-collision event handler (collision_handlers); Set of peer tags listened to by the out-collision event handler (exit_handlers); Mapping for whether the blueprint declares displacement capability (has_movement); Displacement mode string mapping (movement_mode); Solution The resolved attrs set is indexed by blueprint name (resolved_attrs); the attrs bound to input actions (input_bound_attrs); the referenced attrs (referenced_attrs); the attrs referenced in the event.other.X format (event_other_attrs); the handled event names (handled_events); the emitted event names (emitted_events); the input actions declared in the world inventory (world_input_actions); and the tags actually used by the world entity after resolution (world_entity_actual_tag).

[0035] Group 3: Output callbacks: Error callback (error): Records issues that cause loading to fail; Warning callback (warn): Records issues that allow loading but alert the author; Lint callback (lint): Records style suggestions.

[0036] The build function (build_lint_context) fills all indexes in a single scan, and its execution time is linearly related to the total number of characters in the configuration file. It is executed only once. The rule function performs only O(1) or O(index key count) queries.

[0037] Multiple rules are registered as a static array, each rule is an independent function, the rule function is used to check error patterns, and the rule function accesses the verification context in read-only mode; The rules are written as 32 independent functions, all registered uniformly through a compile-time static array. Each row of the array is a tuple of a rule name identifier and a rule function pointer. The rule name serves as a stable English identifier, used for location, logging, and filtering; the rule function itself is implemented as a static C++ function, with a signature that accepts a constant reference to the validation context and has no return value.

[0038] The 32 rules are listed below: 1.collision_mask_target; 2.collision_handler_needs_collision; 3.collision_handler_tag_exists; 4.movement_needs_input; 5.movement_needs_attrs; 6.collision_handler_symmetry; 7.collision_tag_exists; 8.unused_attrs; 9.double_destroy_on_collision; 10.undeclared_attrs; 11.attr_shadows_system_attr; 12.vehicle_mode_body_type; 13.reciprocal_collision_handlers; 14.orphan_collider_layer; 15.area_with_m ove_in_graph;16.area_without_handlers;17.visible_to_target;18.body_type_intent;19.on_ground_mode;20.orphan_graphs;21.zone_with_collision_handler;22 .dual_input_handling; 23.suggest_scaffold; 24.move_requires_velocity; 25.zone_requires_area; 26.navigate_requires_navigation; 27.input_graph_event_wiri ng; 28. invalid_binding_target; 29. ​​input_binding_tag_exists; 30. area_cannot_detect_area; 31. physics_body_with_collision_handler; 32. child_area_needs_tag.

[0039] Adding a new rule costs the same as adding a new static function and adding a new row at the end of a static array, without modifying any callers.

[0040] Rule hierarchy: Classified into 5 orthogonal categories based on error patterns, using target existence verification, bilateral alignment verification, physical and regional semantic verification, attribute declaration and usage consistency verification, and event emission and processing closed-loop verification. See Table 1 for details. Table 1. Rule Hierarchy Table Each type of rule is independent of the others and has no calling dependencies, and can be executed in parallel (in this embodiment, they are executed sequentially, taking less than 50 milliseconds per medium-sized game).

[0041] Example of a rule function: Each rule is implemented as an independent static C++ function, accessing the validation context only in read-only mode, and outputting diagnostic information via error / warning / hint callbacks. Below is an example of a natural language description for three rules: Example 1: Collision mask target existence (collision_mask_target): The rules iterate through the collision whitelist tag set corresponding to each blueprint in the validation context. For each tag, if it does not appear in the tag-to-blueprint name mapping, an error callback is sent to report that the collision mask of blueprint X references the unknown tag Y.

[0042] Example 2: Double destruction on collision events (double_destroy_on_collision): The rule iterates through the `when` clause of each blueprint. For each handler of the form `event:collision:X`, it counts the number of times `destroy self` appears in its action list. If it appears more than once, it reports via a warning callback that the same entity has been destroyed repeatedly in the same collision event.

[0043] Example 3: Isolated graphs (orphan_graphs): The rule iterates through each graph name in the graph set, checking within the validation context whether the graph name is referenced by any blueprint's `when.do.graph`, the world inventory entry point, or by jumps from other graphs. If none are referenced, a warning callback is sent reporting that graph X has been defined but is not being referenced. Each rule consists of 30-200 lines, read-only checks the context, does not modify the state, and is a pure function.

[0044] At the game loading entry point, all registered rules are executed through the command-line interface. The game is allowed to enter the runtime only if no errors are reported by any of the rules.

[0045] Error classification (error / warning / hint): Error (load denied): Target does not exist, physical constraint violated, syntax condition not met; Warnings (load passed and alerts): Redundant declarations, possible typos, dead branches; Lint suggestions: Suggestions for style improvements and alternative equivalents. The CLI (command-line interface) immediately halts execution upon first encountering an error; warnings and lint are output together but not blocked. Production builds are strictly prohibited from entering via CI gates with warning / lint entries. For details... Figure 2 As shown.

[0046] Rule observability allows for the instrumentation of the following information before and after each rule execution: rule name; number of errors / warnings / notifications triggered; execution time.

[0047] For regression analysis: If the time consumption of a rule increases sharply after a modification to a shader or blueprint resolution, it indicates the introduction of pathological complexity. This reflects the natural advantages of rule independence and the registry architecture.

[0048] The method is applied to game scenes generated by runtime artificial intelligence and is used for verification before the game is loaded.

[0049] The method of this embodiment is compared with the prior art as follows: 1. Comparison of error detection timing, as shown in Table 2: Table 2. Comparison of Error Detection Timing .

[0050] 2. Comparison of rule expansion costs, as shown in Table 3: Table 3. Comparison of Rule Extension Costs .

[0051] 3. Aligning with AI-generated illusions, the error distribution of 100 UGC game configurations generated by AI is compared with the rules in this embodiment. The results are shown in Table 4: Table 4. Alignment Table of Artificial Intelligence Generated Illusions Common AI errors with a cumulative coverage of ≥60% can be directly intercepted and flagged during the loading process.

[0052] 4. The dependency mapping is shown in Table 5: Table 5. Dependency Comparison Table .

[0053] The pre-indexing structure in this embodiment can also adopt the following technical solutions: Unordered mappings and unordered sets in the C++ standard library; sparse arrays and integer IDs; embedded SQLite for SQL queries; RDF / datalog engine (stronger semantics, higher cost).

[0054] The rule discovery mechanism in this embodiment can also adopt the following technical solutions: Static arrays are registered at compile time; global initialization is performed through constructor properties; macros are loaded and registered for dynamic libraries; JSON configuration declares rule enable items (allowing a rule to be disabled at runtime).

[0055] The rule implementation level in this embodiment can also adopt the following technical solutions: Pure C++ functions; declarative matching templates and action templates DSL; query languages ​​like CodeQL and Semgrep; machine learning classifiers (identifying structures that "look like errors," with a high false positive rate).

[0056] The hierarchical strategy in this embodiment can also adopt the following technical solutions: Three levels: error / warning / prompt; two levels: blocking / non-blocking; severity is rated on a scale of 0 to 9.

[0057] The execution timing of this embodiment can also adopt the following technical solutions: CLI validation (ange validate); runtime loader automatic validation; IDE LSP real-time validation; Git pre-commit hook / CI access control.

[0058] This embodiment can be used in combination with other methods: Combining rule validation and SMT solution, with important global constraints intersecting with SMT; rule validation and unit test generation (automatically generating negative examples from rules); rule validation and model detection (enumerating event sequences).

[0059] The terminology for this embodiment is shown in Table 6: Table 6. Terminology Comparison Table .

[0060] In a specific scenario When executing `ange validate` on a game directory, a typical output format is as follows (presented as indented text): $ ange validate demo / hub / games / showcase: [blueprint:bowling_ball], Error: Collision mask references unknown tag 'pin_old'; [graph:obsolete_anim], Warning: The graph has been defined but no one has referenced it; [blueprint:player] Error: attr 'move_speed' is used but not declared in attrs; [hud:score], Tip: You can use the abbreviation "bind:world.score" instead; 2 errors, 1 warning, 1 message. Verification failed.

[0061] Alternatively, it can be organized into a summary table, as shown in Table 7: Table 7. Output Summary Table .

[0062] This embodiment has the following effects: 1. By advancing error detection from runtime to before loading, the risk of players experiencing a broken gaming experience is fundamentally eliminated. Traditional script-driven engines inherently delay error detection, only exposing them when specific execution paths are triggered. Players often only passively locate errors after entering the game and witnessing broken behaviors such as immobile characters, untriggered events, and strange physical actions. This implementation performs all cross-file consistency checks at the game loading entry point. Any error will block the loading process, ensuring players don't see broken gameplay caused by configuration errors. This is suitable for app store compliance scenarios involving runtime AI-generated games.

[0063] 2. This solution resolves the inherent problem of unverifiable cross-file references, enabling globally consistent and deterministic checks. Game configurations naturally cross files: generation declarations in the world file point to tags in the blueprint file, graph references in the blueprint file point to the name of the graph file, and data bindings in the interface file point to attributes declared in the blueprint file. Traditional single-file validation methods cannot detect such broken cross-file references. This embodiment scans all configuration files at once and constructs a unified validation context, incorporating all cross-file reference relationships into the same index system, transforming previously undeterminable cross-file errors into detectable deterministic errors.

[0064] 3. A pluggable, zero-framework-modification rule extension mechanism is provided, greatly reducing maintenance costs. As the game engine's functionality expands, the number of validation rules will continue to grow. Traditional solutions require modification of the editor source code, compiler context, or framework main flow for each added rule, easily disrupting the development schedule. This embodiment uses a static array registration mechanism, where each rule is an independent C++ static function. Adding a new rule only requires adding a function and a line to the static array, without modifying any caller code, achieving true zero-framework-modification extension.

[0065] 4. The rule set is highly aligned with the AI-generated illusions, specifically covering the vast majority of common error types. Real-world testing data shows that errors in AI-generated game configurations are highly concentrated in 10 to 30 types, including misspelled blueprint names, misspelled attribute names, one-sided collision declarations, isolated graphs, and inputs without corresponding handling. The 32 rules in this embodiment are specifically designed for these common illusions, capable of directly intercepting and alerting at least 60% of common AI errors during loading, significantly improving the success rate and reliability of AI-generated games.

[0066] 5. Sharing the same JSON parsing result with the runtime engine achieves a zero-redundancy, high-efficiency design. In this embodiment, the validation context directly references the original JSON view already parsed by the loader, eliminating the need to re-parse the configuration file for validation purposes and avoiding the time and memory overhead of double parsing. Furthermore, the validation context only depends on the standard library and the JSON parsing library, with no additional runtime dependencies, making it lightweight, efficient, and easy to integrate.

[0067] 6. Provides a three-tiered feedback system: error, warning, and prompt, balancing strict blocking with flexible guidance. Error-level blocking feedback ensures serious issues are not ignored; warning-level non-blocking feedback helps developers identify potential risks; and prompt-level style suggestions guide developers to write more standardized configurations. The CLI immediately blocks execution upon first detecting an error, and production builds are strictly prohibited from entering via CI gates with warning or prompt entries, achieving end-to-end quality assurance from development to deployment.

[0068] The electronic device disclosed in this embodiment includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.

[0069] The processor may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the electronic device to perform all or part of the steps of the declarative game configuration cross-file consistency verification method of the foregoing embodiments of this disclosure.

[0070] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.

[0071] like Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the electronic device in the embodiment of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0072] like Figure 3 As shown, an electronic device may include a processing unit (such as a central processing unit, graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from a storage device into random access memory (RAM). The RAM also stores various programs and data required for the operation of the electronic device. The processing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0073] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow electronic devices to exchange data wirelessly or via wired communication with other devices, such as edge computing devices. Although Figure 3 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0074] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processing device, all or part of the steps of the declarative game configuration cross-file consistency verification method of embodiments of this disclosure are performed.

[0075] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0076] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When these non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the declarative game configuration cross-file consistency verification method of the foregoing embodiments of the present disclosure are performed.

[0077] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0078] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0079] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0080] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0081] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0082] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0083] Various changes, substitutions, and modifications can be made to the techniques described herein without departing from the teachings defined in this embodiment. Furthermore, the scope of this embodiment is not limited to the specific aspects of the processes, machines, manufacturing processes, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufacturing processes, events, means, methods, or actions that perform substantially the same functions or achieve substantially the same results as the corresponding aspects described herein can be utilized. Therefore, this embodiment includes such processes, machines, manufacturing processes, events, means, methods, or actions within its scope.

[0084] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0085] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A declarative game configuration cross-file consistency verification method, characterized in that, include: All types of configuration files are retrieved at once at the game loading portal. These configuration files include world files, blueprint files, graph files, interface files, and data files. Based on the obtained configuration file, construct a read-only verification context; Multiple rules are registered as a static array, each rule is an independent function, the rule function is used to check error patterns, and the rule function accesses the verification context in read-only mode; At the game loading entry point, all registered rules are executed through the command-line interface. The game is allowed to enter the runtime only if no errors are reported by any of the rules.

2. The declarative game configuration cross-file consistency verification method according to claim 1, characterized in that, The validation context includes the original JSON view, pre-indexing, and output callback; The pre-index includes at least the following mappings: blueprint file tags to blueprint file names, blueprint file names to blueprint file tags, mappings of whether a blueprint file declares a collider, a set of collision whitelist tags, a set of collision layer tags, a set of peer tags listened to by the in-collision event handler, a set of peer tags listened to by the out-collision event handler, a mapping of whether a blueprint file declares displacement capabilities, a displacement pattern string mapping, a set of parsed attribute keys, a set of attributes bound to input actions, a set of referenced attributes, a set of attributes referenced as events, a set of processed event names, a set of emitted event names, a set of input actions declared in the world list, and tags actually used by the world master entity after parsing.

3. The declarative game configuration cross-file consistency verification method according to claim 2, characterized in that, The output callbacks include error callbacks, warning callbacks, or prompt callbacks; The error callback is used to record problems that cause loading to fail, the warning callback is used to record problems that can be loaded but require a reminder, and the prompt callback is used to record style improvement suggestions.

4. The declarative game configuration cross-file consistency verification method according to claim 2, characterized in that, The raw JSON view is shared with the runtime engine to avoid repeated data parsing. The raw JSON view includes a collection of blueprints, a collection of graphs, and a world list.

5. The declarative game configuration cross-file consistency verification method according to claim 1, characterized in that, The rule functions are registered through a compile-time static array. To add a new rule, you only need to add a function and add a row of two tuples to the static array. The two tuples include a rule name identifier and a rule function pointer.

6. The declarative game configuration cross-file consistency verification method according to claim 1, characterized in that, The error modes include at least one of the following categories: The system includes checks for the existence of referenced targets, alignment of both sides, physical and regional semantics, consistency of attribute declarations and usage, and closed-loop checks for event emission and processing.

7. The declarative game configuration cross-file consistency verification method according to claim 1, characterized in that, The rule function includes: The collision mask target existence rule is used to traverse the collision whitelist tag set corresponding to each blueprint in the verification context. If any tag does not appear in the mapping from tag to blueprint file name, an error callback is used to report that the blueprint references an unknown tag. The duplicate destruction rule in collision events is used to traverse the clauses of each blueprint file, count the number of times the entity is destroyed in the collision event action list, and if the number is greater than once, a warning callback will be sent to report that the same entity is destroyed repeatedly in the same collision event. The isolated graph rule is used to traverse each graph name in the graph collection, check in the validation context whether the graph name is referenced, and if it is not referenced, report that the graph has been defined but is not referenced through a warning callback.

8. The declarative game configuration cross-file consistency verification method according to claim 1, characterized in that, The method is applied to game scenes generated by runtime artificial intelligence and is used for verification before the game is loaded.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the declarative game configuration cross-file consistency verification method according to any one of claims 1-8.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the declarative game configuration cross-file consistency verification method as described in any one of claims 1-8.

Images