Declarative game execution methods and electronic devices without runtime code generation

Abstract

This invention provides a declarative game execution method and electronic device without runtime code generation. The declarative game execution method without runtime code generation includes: during the game loading phase, loading and parsing a set of configuration files describing game logic, the set of configuration files including structured data files but not containing executable instruction streams; mapping the declarations in the configuration file set to corresponding primitive execution function pointers based on a pre-compiled primitive registry, the pre-compiled primitive registry including multiple primitive execution functions statically linked during application construction; during the game execution phase, based on the mapping relationship between declarations and corresponding primitive execution function pointers, an interpreter calls the corresponding primitive execution function pointers to execute the game logic described in the configuration file set. This achieves the goal of running user-generated content and AI-generated content even without runtime instruction streams.

Description

[0001] Cross-reference to related applications This patent application claims priority to Chinese Patent Application No. 2026106271777, filed on May 8, 2026, entitled "Declarative Game Running Method and Electronic Device Without Runtime Code Generation", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This invention belongs to the field of game technology, and in particular relates to a declarative game running method and electronic device that does not generate runtime code. Background Technology

[0003] Virtual games require dynamic modeling, and existing game engines face the following issues in scenarios where "new games are generated at runtime by users or artificial intelligence": The runtime execution of user-generated game logic conflicts with the review rules of mainstream app stores.

[0004] 1. Both Apple and Google App Stores explicitly prohibit apps from downloading and executing executable code or scripts at runtime (only interpreted executable code that serves the core purpose of the app is allowed, and this code must not significantly change the app's basic functionality). Existing game engines (Unity, Unreal, Godot) rely on scripting languages ​​(C#, Lua, GDScript, Blueprint bytecode) or hot-update packages for their runtime extension mechanisms. Essentially, they all involve "obtaining and executing new instruction streams at runtime." Therefore, app stores cannot legally support UGC features such as "players or AI generating a completely new game scene and rules within the app."

[0005] 2. When generating a complete game using artificial intelligence, the output of word units is consumed in a high amount of time and at a high cost.

[0006] Currently, generating complete, runnable games using large language models requires the model to output script code for each lexical unit. Taking Godot GDScript as an example, a minimal, complete bowling game (including player control, camera, physics, ten pins, launcher, scoring, and lifecycle) requires approximately 2500 lexical units. Each additional functional module introduces a large amount of boilerplate code (class definitions, node type declarations, property assignments, signal bindings, etc.), causing the total time and cost of AI-generated games to increase approximately linearly with the game's size.

[0007] 3. The game logic generated at runtime cannot be detected before the error occurs, causing players to experience crashes or the game to become unresponsive.

[0008] Script-driven engines only trigger errors when the code path is executed. In runtime UGC scenarios, players often enter the game and see a blank scene, characters cannot move, and events are not triggered, which are intermediate states that disrupt the experience. The engine cannot perform an overall consistency check on the "new game generated by the player or AI" during the loading phase. Summary of the Invention

[0009] In view of the problems existing in the prior art, the present invention provides a declarative game running method and electronic device without runtime code generation, which at least partially solves the problem that game running requires the execution of instruction streams in the prior art.

[0010] In a first aspect, embodiments of this disclosure provide a declarative game execution method without runtime code generation, including: During the game loading phase, a set of configuration files describing the game logic is loaded and parsed. The set of configuration files includes structured data files but does not contain executable instruction streams. The pre-compiled primitive registry maps the declarations in the configuration file set to corresponding primitive execution function pointers. The pre-compiled primitive registry includes multiple primitive execution functions that are statically linked during application build. During the game's execution phase, based on the mapping relationship between declarations and corresponding primitive execution function pointers, the interpreter calls the corresponding primitive execution function pointers to execute the game logic described in the configuration file set.

[0011] Optionally, before the step of loading and parsing the set of configuration files describing the game logic, the method further includes: performing a semantic consistency check on the set of configuration files.

[0012] Optionally, the semantic consistency check includes checking the context pre-index, independent rule functions, and parameter reduction-driven recursive parameter checks; the semantic consistency check is used to detect at least one type of error before the configuration file set is run, including cross-file reference errors, type compatibility errors, event handling mismatch errors, and control flow nested type errors.

[0013] Optionally, the various primitives in the pre-compiled primitive registry are registered through a corresponding static registration mechanism. The types of primitive registry entries include: The action primitive table contains multiple action execution functions used to describe behavioral logic; The condition primitives list contains multiple condition evaluation functions used to describe the decision logic; The component initialization primitive list is used to initialize entity components; Visual constructor table, used to generate scene graph nodes; The semantic validation rule table contains multiple rule functions used to check configuration consistency during the validation phase.

[0014] Optionally, the pre-compiled primitive registry is a data structure that, during application construction, solidifies the primitive name, parameter specification, and corresponding primitive execution function pointer into the application binary file through a static registration mechanism.

[0015] Optionally, the set of configuration files includes: The world manifest file is used to declare the game entry point, input mappings, and global configurations. Blueprint files are used to declare entity templates and their attributes, physical bodies, geometry, behavioral rules, and child nodes; Behavior graph files are used to define named action sequences by referencing action primitives; UI panel files are used to define the user interface layout and data binding. A data table file used to define key-value pair data.

[0016] Optionally, it also includes: receiving a new set of configuration files, parsing and verifying them during the game loading stage, and then entering the game running stage to achieve dynamic generation and updating of game content.

[0017] Optionally, the syntax design of the configuration file set includes an optimization design to reduce the number of output lexical units required for generation, the optimization design including at least one of the following: Automatic allocation and propagation mechanism of collision filtering bits based on semantic tags; The compound entity reference microsyntax supports expressing space queries with filtered conditions in a single declaration string; Zero-configuration default inheritance mechanism automatically applies preset default values ​​to undeclared parameter fields; The syntax for merging property-binding-interpolation declarations.

[0018] Optionally, the optimization method further includes inline control flow, aggregated conditional primitives, and / or event symbolic routing.

[0019] 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 that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform any of the declarative game execution methods without runtime code generation as described in the first aspect.

[0020] This invention provides a declarative game execution method without runtime code generation. It declaratively describes the logic, behavior, and rules of the entire game through a structured set of configuration files. These files are in pure data format and do not contain any executable code. Before the application runs, the game engine, during the loading phase, parses and maps all declarations in the configuration files to corresponding, pre-defined primitive execution function pointers based on the primitive registry that has been statically compiled and linked during application construction. At runtime, the game engine's interpreter drives the game by calling these pre-compiled function pointers and passing in configuration parameters, entirely based on this mapping. This fundamentally eliminates the path of "acquiring, parsing, or generating any new executable instruction stream." Therefore, even if entirely new game content is dynamically generated by the user or AI at runtime, only structured configuration data is added. The engine only uses this data to schedule its inherent, pre-defined functional primitives. This achieves the goal that the "new game" added at runtime does not exist in the form of any executable instruction stream, but only in the form of structured configuration data. It enables the execution of user-generated and AI-generated content even without an executable instruction stream at runtime. Attached Figure Description

[0021] 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.

[0022] Figure 1 A flowchart of a declarative game execution method without runtime code generation provided in this embodiment of the disclosure; Figure 2 A flowchart of the declarative game execution method without runtime code generation provided in this embodiment of the disclosure during the game loading phase; Figure 3 Flowchart of the execution phase of the declarative game running method without runtime code generation provided in this embodiment of the disclosure; Figure 4 A schematic block diagram of an electronic device is provided for embodiments of this disclosure. Detailed Implementation

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

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] One of the technical objectives of this embodiment is to enable AI-native games to achieve game diversity in mobile commercial scenarios without executing any newly generated instruction streams.

[0029] No runtime code generation means that during application runtime, no new executable instructions or code that were not determined at the time of application build (compile and package) are dynamically created, compiled, loaded, or interpreted.

[0030] The technical problems solved by this embodiment include: 1. Compliance conflict: The "add game logic at runtime" path of all mainstream game engines is essentially "download or generate script → execute script", which directly conflicts with the application rules of Apple and Google.

[0031] 2. Lexical Redundancy: Boiler code such as type declarations, node instantiation, signal or callback templates in scripting languages ​​consumes a large number of lexical units, which is extremely uneconomical for AI-generated scenarios. Game scripts with similar functionality consume 50% to 70% more lexical units than compact configurations.

[0032] 3. Error Post-Processing: Script errors can only be exposed when the execution path is triggered, while players in AI or player-generated content scenarios have already seen the broken game.

[0033] 4. Closed set verification is missing: The scripting language has unlimited primitives (arbitrary function calls, arbitrary object field writes), making it impossible to perform closed set verification on "whether an AI-generated game is self-consistent as a whole".

[0034] 5. Extended dependency editor: New content from Unity and Unreal Engine depends on the desktop editor toolchain pre-built, and does not support player-generated content.

[0035] Based on the above issues, such as Figures 1 to 3 As shown, this embodiment discloses a declarative game running method without runtime code generation, including: During the game loading phase, a set of configuration files describing the game logic is loaded and parsed. The set of configuration files includes structured data files but does not contain executable instruction streams. The pre-compiled primitive registry maps the declarations in the configuration file set to corresponding primitive execution function pointers. The pre-compiled primitive registry includes multiple primitive execution functions that are statically linked during application build. During the game's execution phase, based on the mapping relationship between declarations and corresponding primitive execution function pointers, the interpreter calls the corresponding primitive execution function pointers to execute the game logic described in the configuration file set.

[0036] In this embodiment, all primitives (actions, conditions, components, visual constructors, and validation rules) are compiled into binary code during application build, resulting in zero new additions, zero dynamic string-to-function parsing, and zero code generation at runtime. The configuration file is merely a parameterized "call graph," with the compiled primitives scheduled by the interpreter in a table-driven manner.

[0037] The configuration file completes the string-to-function pointer parsing during the loading phase, and there is zero string parsing, zero dynamic linking, and zero code generation during the runtime phase.

[0038] Before the step of loading and parsing the set of configuration files describing the game logic, the method further includes: performing a semantic consistency check on the set of configuration files.

[0039] The semantic consistency check includes checking the context pre-index, independent rule functions, and parameter reduction-driven recursive parameter checks; the semantic consistency check is used to detect at least one type of error before the configuration file set is run, including cross-file reference errors, type compatibility errors, event handling mismatch errors, and control flow nested type errors.

[0040] The load-time verification pipeline consists of verifications including context pre-indexing, independent rule functions, and parameter reduction-driven recursive parameter verification, which can detect at least N types of errors (N not less than 30) before runtime, such as cross-file reference errors, undeclared attributes, event mismatches, and control flow nesting type errors.

[0041] The pre-compiled primitive registry entries are registered through corresponding static registration mechanisms. Table 1 shows the types of primitive registry entries, including: The action primitive table contains multiple action execution functions used to describe behavioral logic; The condition primitives list contains multiple condition evaluation functions used to describe the decision logic; The component initialization primitive list is used to initialize entity components; Visual constructor table, used to generate scene graph nodes; The semantic validation rule table contains multiple rule functions used to check configuration consistency during the validation phase.

[0042] The engine in this embodiment has the following five types of primitives built-in, all of which are statically linked during application packaging and are not added at runtime: Table 1. Primitive Registry This embodiment protects over 100 pre-compiled primitives and validation rules. Each primitive consists of three elements: Primitive name: string key, mapped to a function pointer at load time; Parameter specifications: Declare parameter names, types (string, floating point, entity attribute reference, condition, statement array, etc.), and optional custom validation functions; Execution function pointer: points to a static function in the C++ compilation unit.

[0043] Static registration mechanism refers to the method of registering the definitions, type information, and execution function addresses of all the basic operation units ("primitives") required by the game engine into the engine core system in one go during application compilation / building.

[0044] The static registration mechanism is as follows: Primitive definition: Each action (such as "generate", "move"), condition (such as "attribute comparison", "distance comparison"), etc., is implemented by a separate C++ (or Rust, etc.) function.

[0045] Compile-time registration: In the source code, by using registration macros provided by the engine (such as action registration macros, condition type enumerations with evaluation function pointers), the string name of each primitive, parameter specification (parameter type, validation rules) and the corresponding C++ function pointer are bound together and placed into a global, statically initialized data structure (registry).

[0046] Static linking: During the program compilation and linking phase, these functions and their corresponding registration information are fixed in the final executable file (binary). At runtime, this registry is read-only and cannot be modified.

[0047] The pre-compiled primitive registry is a data structure that, during application construction, solidifies the primitive name, parameter specification, and corresponding primitive execution function pointer into the application binary file through a static registration mechanism.

[0048] As shown in Table 2, the configuration file set includes: The world manifest file is used to declare the game entry point, input mappings, and global configurations. Blueprint files are used to declare entity templates and their attributes, physical bodies, geometry, behavioral rules, and child nodes; Behavior graph files are used to define named action sequences by referencing action primitives; UI panel files are used to define the user interface layout and data binding. A data table file used to define key-value pair data.

[0049] Table 2, Configuration File Table: All five configuration files are plain JSON data, containing no executable code, no function bodies, no dynamic evaluation, and no dynamic imports.

[0050] In this embodiment, the parameter reduction declaration of each primitive includes a complete parameter definition, and load-time verification can be implemented: Reference closure: The target of all generated actions must be a defined blueprint; all events must either be handled or ignored; all properties must be declared in the property sheet. Type consistency: The type of the action parameter is consistent with the type of the actual parameter; the types of the left and right values ​​of the condition are consistent; Cross-file consistency: Input actions in the world list must be consumed by a blueprint's when rule; a behavior graph must be referenced by at least one blueprint. Physical feasibility: Region bodies cannot apply movement actions, and character bodies must have input bindings; User experience priority: The blueprint that receives an event must have a corresponding action in the world list input or in the blueprint's when field.

[0051] Configurations that fail to load will never be allowed to run, thus eliminating "new runtime errors" through this mechanism.

[0052] The method also includes: receiving a new set of configuration files, parsing and verifying them during the game loading stage, and then entering the game running stage to achieve dynamic generation and updating of game content.

[0053] During game runtime, a new configuration file is generated by the player or AI and sent to the loading and verification process. Since the output of this process is structured data rather than a stream of instructions, it complies with the restrictions on runtime code execution in Apple and Android applications. (See Table 3.) Table 3. Compliance Comparison Table: The syntax design of the configuration file set includes optimizations to reduce the number of output lexical units required for generation, and these optimizations include at least one of the following: The automatic allocation and propagation mechanism of collision filtering bits based on semantic tags, namely automatic bit mapping of semantic tags; Traditional collision filtering engines require manual declaration of 16- or 32-bit masks, with each entity requiring a set of bitwise operations. In this embodiment, each string label (such as "enemy" or "player") is automatically allocated one bit during loading, and the configuration is degenerated into a whitelist field (e.g., "collides_with" followed by an array of labels); the engine internally performs backpropagation to complete the other side.

[0054] The compound entity reference microsyntax supports expressing space queries with filtered conditions in a single declaration string; Traditional scripts require writing more than ten lines of loop sorting and filtering code to "find the nearest entity of a certain type with a certain attribute". This embodiment provides a reference string, in the form of "nearest entity with a certain tag, filtered with a certain attribute", which is parsed into a structured entity reference (including type field, tag field, and filter expression field) once during loading. At runtime, the spatial index is looked up and the results are cached within the frame, allowing for constant-time calls.

[0055] Zero-configuration default inheritance mechanism automatically applies preset default values ​​to undeclared parameter fields; The physics field is written as the string "rigid body", which expands into a complete set of rigid body parameters in the context (type, gravity coefficient multiplied by world gravity, mass, elasticity, friction, etc. all take default values); only fields that deviate from the default values ​​need to be written out.

[0056] The syntax for merging property-binding-interpolation declarations.

[0057] A single attribute field can simultaneously declare three types of information: initial value, target component field, and interpolation coefficient, replacing the three code segments in the script: variable declaration, frame-by-frame synchronization loop, and interpolation function call. For example, a health value attribute can be written as a compound declaration of "value 100, target is material transparency, interpolation 5".

[0058] The optimization method also includes inline control flow, aggregated conditional primitives, and / or event symbolic routing.

[0059] Inline control flow: Branching, traversal, looping, and waiting are directly nested as data array elements, eliminating the need for boilerplate terms such as closures, anonymous functions, and function definitions.

[0060] Aggregate condition primitives: A single aggregate condition (e.g., "all enemy health is less than or equal to zero") can replace a loop for evaluating values ​​in a script.

[0061] Event symbolic routing: The event name is used as a symbolic path, replacing the four-part structure of "subscribing to signals + binding callback functions + judging within the function + unbinding" in the script.

[0062] This embodiment presents a declarative game execution method without runtime code generation. For a minimal, complete bowling game (player character control, WASD input, track camera, ground, 3D ten-pin triangular arrangement, one ball launched every 4 seconds, pin knockdown scoring, scoreboard, ball lifespan of 12 seconds, gravity of 20), using cl100k_base encoding (GPT-4 and Claude universal BPE), the steps for reproducing the bowling game are as follows: 1. Prepare the ANGE bowling setup (8 files); 2. Prepare a GDScript implementation (10 files, with strictly equivalent functionality); 3. Encoding tools: Python package tiktoken, encoder cl100k_base; 4. Analyze the two sets of data to calculate the number of terms, characters, and lines of text. The file data is shown in Table 4, and the file breakdown is shown in Table 5. Table 4. Comparison of data for various methods in bowling: Table 5. Detailed breakdown of bowling game methods by document In existing methods, each entity requires a class declaration, initialization of the subtree, and manual writing of each mesh, collision, and material node. The boilerplate code alone accounts for more than 40% of the vocabulary. This embodiment optimizes the design by compressing entity behavior, physical parameters, and visual parameters into a single declaration, thereby reducing the vocabulary.

[0063] This embodiment performs semantic consistency checks on the configuration file set before loading and parsing the set of configuration files describing the game logic. This allows for error prevention, thereby covering the most common types of illusion errors generated by artificial intelligence, as shown in Table 6. Table 6. Comparison of Error Precursor Capabilities The bowling ball experiment demonstrates that the pre-compiled primitive plus verification rules in this embodiment can express functions such as physical rigid bodies, character control, input mapping, orbital cameras, lifecycles, interval timed emission, condition-effect rules, cross-entity events, 3DUI, and data lookup, and are at the same level as existing GDScript.

[0064] This embodiment's declarative game execution method without runtime code generation involves no "string → instruction" or "configuration → code" conversions from loading to application exit. All "name → function pointer" mappings are statically completed during application construction, with only parameterized calls performed at runtime.

[0065] This embodiment can achieve the following effects: (a) The "new game" added at runtime does not exist in the form of any executable instruction stream, but only in the form of structured configuration data, thus being fully compliant with iOS and Android app stores.

[0066] (b) The syntax of this configuration data has been optimized for information density in the scenario of "AI word-by-word meta-output". The number of generated meta-words in games with the same function is reduced by no less than 30% compared with the script solution (actual test shows a reduction of 39.4%).

[0067] (c) Configuration data can be fully consistent with the engine during the loading phase (reference correctness, type compatibility, cross-file consistency), and errors will not be carried over to runtime.

[0068] (d) The engine’s underlying primitive set is finite and exhaustive, which makes the above verification itself complete and decidable.

[0069] (e) Achieve the above objectives while maintaining equivalence between the game's expressive capabilities (physics, input, artificial intelligence, events, UI, data tables, UGC hot reload) and the script-driven solution.

[0070] This embodiment can change the pre-compiled primitives from C++ implementation to Rust, Zig, and C implementation; the static registration method of the function pointer table can be changed to compile-time code generation (such as static constant expressions based on macros). This embodiment is an architecture that does not add new instruction streams at runtime.

[0071] This embodiment allows you to replace the ECS backend with EnTT, bevy_ecs, or a self-developed ECS.

[0072] In this embodiment, the scene graph backend can be changed from Godot to Unity native, Unreal native, or a self-developed renderer. As long as the operation is configuration-driven, it is within the technical solution defined in this embodiment. The scene graph backend is just a presentation layer.

[0073] In this embodiment, JSON can be replaced with YAML, TOML, MsgPack, or a custom binary protocol. This embodiment does not depend on a specific serialization format, as long as it meets the requirements of "pure data, no executable code, and primitive names that can be looked up in a table".

[0074] The 34 action primitives, 12 conditions, 8 components, 14 visual constructors, and 32 validation rules in this embodiment are merely illustrative examples and do not represent the actual number of primitives. The number can be increased or decreased as needed, provided the primitive set is closed and statically registered during application construction.

[0075] In this embodiment, the label-to-bit mapping can be replaced with "label to sparse Bloom filter" (performance trade-off); the spatial index can be a quadtree, grid hash, hierarchical bounding volume, or kd-tree; the component field function pointer pair can be replaced with "compile-time reflection" (such as the static reflection feature of C++) or "index plus dispatch"; the verification rule can be replaced with "combining with SMT solver to perform stronger global constraint solving".

[0076] Weak validation example: Only primitive name closure and parameter type consistency are checked. Strong validation example: 32 semantic rules are added, and SMT is used for solving. Strongest validation example: Model checking is performed on each graph during loading (covering all event sequences).

[0077] In this embodiment, the AI ​​output can be direct configuration data or natural language converted into configuration data by the engine front end; the AI ​​output can be a single file package or a streaming incremental output (accumulated by the front end to the loading validator); the AI ​​can run in the cloud (delivering configuration data to the application) and / or locally (via NPU or CoreML inference), because what is delivered or generated is data rather than a stream of instructions.

[0078] The glossary of terms in this embodiment is shown in Table 7. Table 7. Reputation Statement: 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.

[0079] 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 the computer-readable instructions stored in the memory, causing the electronic device to perform all or part of the steps of the declarative game running method without runtime code generation described in the foregoing embodiments of this disclosure.

[0080] 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.

[0081] like Figure 4 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 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0082] like Figure 4 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.

[0083] 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 4Electronic 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.

[0084] 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 running method without runtime code generation according to embodiments of this disclosure are performed.

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

[0086] 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 execution method without runtime code generation described in the foregoing embodiments of the present disclosure are performed.

[0087] 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).

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

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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 execution method without runtime code generation, characterized in that it includes: During the game loading phase, a set of configuration files describing the game logic is loaded and parsed. The set of configuration files includes structured data files but does not contain executable instruction streams. The pre-compiled primitive registry maps the declarations in the configuration file set to corresponding primitive execution function pointers. The pre-compiled primitive registry includes multiple primitive execution functions that are statically linked during application build. During the game's execution phase, based on the mapping relationship between declarations and corresponding primitive execution function pointers, the interpreter calls the corresponding primitive execution function pointers to execute the game logic described in the configuration file set.

2. The method of claim 1, wherein the step of loading and parsing the set of configuration files describing the game logic is preceded by the further steps of: Perform semantic consistency checks on the set of configuration files.

3. The declarative game execution method without runtime code generation according to claim 2, characterized in that the semantic consistency verification includes verifying the context pre-index, independent rule functions, and parameter reduction-driven recursive parameter verification; the semantic consistency verification is used to detect at least one type of error before the configuration file set is run, including cross-file reference errors, type compatibility errors, event handling mismatch errors, and control flow nested type errors.

4. The declarative game execution method without runtime code generation according to claim 1, characterized in that, the various primitives in the pre-compiled primitive registry are registered through a corresponding static registration mechanism, and the types of the primitive registry include: The action primitive table contains multiple action execution functions used to describe behavioral logic; The condition primitives list contains multiple condition evaluation functions used to describe the decision logic; The component initialization primitive list is used to initialize entity components; Visual constructor table, used to generate scene graph nodes; The semantic validation rule table contains multiple rule functions used to check configuration consistency during the validation phase.

5. The declarative game running method without runtime code generation according to claim 4, characterized in that the pre-compiled primitive registry is a data structure that, during application construction, solidifies the name, parameter specification, and corresponding primitive execution function pointer of the primitive into the application binary file through a static registration mechanism.

6. The declarative game running method without runtime code generation according to claim 1, characterized in that the configuration file set includes: The world manifest file is used to declare the game entry point, input mappings, and global configurations. Blueprint files are used to declare entity templates and their attributes, physical bodies, geometry, behavioral rules, and child nodes; Behavior graph files are used to define named action sequences by referencing action primitives; UI panel files are used to define the user interface layout and data binding. A data table file used to define key-value pair data.

7. The declarative game execution method without runtime code generation according to claim 2, characterized in that it further includes: The system receives a new set of configuration files, which are then parsed and verified during the game loading phase before entering the game running phase, enabling dynamic generation and updating of game content.

8. The declarative game running method without runtime code generation according to claim 1, characterized in that the syntax design of the configuration file set includes an optimization design to reduce the number of output lexical units required for generation, the optimization design including at least one of the following: Automatic allocation and propagation mechanism of collision filtering bits based on semantic tags; The compound entity reference microsyntax supports expressing space queries with filtered conditions in a single declaration string; Zero-configuration default inheritance mechanism automatically applies preset default values ​​to undeclared parameter fields; The syntax for merging property-binding-interpolation declarations.

9. The declarative game execution method without runtime code generation according to claim 1, characterized in that the optimization method further includes inline control flow, aggregate conditional primitives and / or event symbolic routing.

10. 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 running method without runtime code generation as described in any one of claims 1-9.

Images