A personalized trial ad generation method and system

Abstract

The application is suitable for the technical field of trial play advertisement, and provides a personalized trial play advertisement generation method, which comprises the following steps: selecting at least one target module from a pre-set standardized game play module library, and obtaining first module configuration data; obtaining user portrait information of a target user, and adjusting the first module configuration data based on the user portrait information to generate second module configuration data; and generating personalized trial play advertisement based on the second module configuration data. The application realizes personalized content adaptation and dynamic optimization from "one face for thousands of people" to "thousands of faces for thousands of people" without manual intervention.

Description

Technical Field

[0001] This application belongs to the field of trial play advertising technology, and in particular relates to a method and system for generating personalized trial play ads. Background Technology

[0002] Playable ads are an interactive ad format that allows users to experience the core gameplay directly before downloading an app. With the development of mobile internet, they can effectively improve app download conversion rates.

[0003] Current playable ad creation technologies typically utilize HTML5, heavily relying on manual coding and art asset production. From gameplay logic and UI design to particle effects, each step demands significant time investment from professional developers and designers, resulting in high development costs and an inability to adapt to the rapidly evolving market demands. Furthermore, most existing playable ads are fixed versions, offering all users identical game scenes, difficulty levels, and visual effects. This ignores the vast differences among users in terms of device performance, gaming preferences, and user behavior, leading to monotonous content and hindering improvements in click-through and conversion rates.

[0004] In summary, how to fundamentally solve the problems of low production efficiency and high cost, and achieve personalized content adaptation and dynamic optimization for different users, is a bottleneck that urgently needs to be overcome in the field of playable advertising technology. Summary of the Invention

[0005] This application provides a method and system for generating personalized trial ads, which can solve one of the problems in the prior art mentioned above.

[0006] In a first aspect, embodiments of this application provide a method for generating personalized trial advertisements, including: Select at least one target module from the pre-built standardized gameplay module library and obtain the configuration data for the first module; Obtain user profile information of the target user, and adjust the configuration data of the first module based on the user profile information to generate configuration data of the second module; Based on the configuration data from the second module, personalized trial ads are generated.

[0007] Furthermore, the standardized gameplay module library abstracts and encapsulates gameplay into independent functional modules with standardized interfaces. Each functional module includes a logic code body, an art resource package, a module description list, and a standardized interface adaptation layer. The module description list includes module identity information, configurable parameter definitions, dependency declarations, and event interface declarations. The module identity information includes module ID, semantic version number, model type label, and relation type label; The model type tags are divided into gameplay logic modules and functional support modules according to whether an independent gameplay rule loop is defined. The gameplay logic module defines a set of gameplay rule loops, while the functional support module is a module that does not have gameplay logic itself and is used to provide supporting functions or environment adaptation capabilities for the gameplay logic module. The relationship type label is used to describe the types of relationships that this module can establish with other modules, specifically including host type, parasitic type, independent type, and service type.

[0008] Furthermore, the step of selecting at least one target module from a pre-set standardized gameplay module library and obtaining the first module configuration data includes: The modules in the standardized gameplay module library are displayed in the module library panel in the form of a classification tree or card flow; The target module can be dragged or selected from the module library panel and placed into the canvas editing area, and then dependency verification, interface compatibility check, instantiation and configuration placeholder, and preview update can be performed. Through the instantiation and configuration placeholders, an instance node is created for each target module placed into the module library panel, and serialized into a module selection list. The module selection list includes a unique instance identifier for each module instance, a module description list for each module instance, and the topological relationship between the module instance and other module instances in the canvas. For each module instance in the module selection list, a parameter editing interface is dynamically constructed based on the configurable parameter definitions in its module description list. Parameter values ​​are selected from the parameter editing interface and mapped to the first module configuration data.

[0009] Furthermore, the step of obtaining user profile information of the target user and adjusting the configuration data of the first module based on the user profile information to generate configuration data of the second module includes: When a request to display a playable ad is received, user profile data is collected and constructed from ad request fields, ad platform data interfaces, and context environment parameters. Device performance metrics and user behavior preference tags are extracted from the user profile data, and combined with user metadata to generate user profile objects; Based on the user profile object, a dual-mode collaborative approach of rule engine and machine learning model is adopted to adapt the configuration data of the first module and generate the configuration data of the second module.

[0010] Furthermore, the rule engine has a set of judgment rules built in, and each rule is encapsulated into a rule object to form a rule library. Each rule object includes at least a rule ID, rule priority, rule description, condition expression tree, and action instruction array. The condition expression tree is the condition expression of the deterministic indicator features in the user profile object in the rule. The action instruction array is specifically a modification operation on the configuration data of the first module, including parameter overwriting, parameter range mapping, module switch control, and resource precision switching. Within the rule engine, all enabled rules are loaded from the rule base and sorted from high to low according to the rule priority to form a rule list. Based on the user profile object, the rule list is traversed to form a set of hit rules. The actions of the set of hit rules are obtained sequentially according to the rule priority, and conflict arbitration is performed to form a rule increment object. The rule increment object records its parameter change information and activation status change information using the unique instance identifier of the module instance as the key.

[0011] Furthermore, the machine learning model includes at least the following steps: The system performs two types of prediction tasks: gameplay preference and module recommendation, and parameter dynamic optimization prediction. It outputs a prediction increment object, which includes module insertion instructions and parameter adjustment instructions. The predicted incremental object and the rule incremental object are converted into standard instructions, each of which includes instruction type, instruction purpose, instruction priority, and instruction increment adjustment; The aforementioned standard instructions are arbitrated for conflicts and then encapsulated into an executable instruction set. The executable instruction set is applied to the configuration data of the first module to generate the configuration data of the second module, and a consistency check is performed simultaneously.

[0012] Furthermore, the task of predicting gameplay preferences and module recommendations includes at least the following steps: Based on the user profile object, construct the user tower feature vector and the advertising tower feature vector; Based on the user tower feature vector and the advertising tower feature vector, calculate the overall preference adaptation score and the marginal preference score for each gameplay type, where the gameplay type corresponds to the gameplay logic module; If the overall preference fit score is greater than or equal to the first preset threshold, then the module recommendation will not be triggered, and the overall preference fit score and the marginal preference score of each gameplay type will be output. If the overall preference fit score is less than the first preset threshold, then module recommendation is triggered. Based on the marginal preference scores of each gameplay type and combined with the configuration data of the first module, candidate modules are selected and an insertion module instruction is generated.

[0013] Furthermore, the parameter dynamic optimization prediction task includes at least the following steps: Iterate through all parameters of each module instance in the first module configuration data and filter the parameters whose adaptability type is adaptable. Based on the user profile object, and the parameter name, current parameter value, and module type label of the adaptable parameter, a parameter prediction feature vector is generated for each adaptable parameter, wherein the parameter name corresponds to the business semantic category; Based on the business semantic category, determine the parameter adjustment coefficient for each adaptable parameter; Based on the parameter adjustment coefficients and the current parameter values, a final predicted value is generated, and a parameter adjustment instruction is output.

[0014] Furthermore, the step of generating personalized trial ads based on the configuration data of the second module includes: Construct a code template library, in which a template file is set for each version of each module of the standardized gameplay module library. The template file includes a structure template, a style template, a logic template, and a resource list template. Using the tuple constructed from the module ID and semantic version number of each module as the key, a template index table is generated by associating all template files of the corresponding module in the code template library. The configuration data of the second module is parsed, the array of module instances is extracted, and the corresponding template file set is searched in the template index table according to the module ID and semantic version number of each module instance. Construct a global context object, and create an instance context object for each enabled module instance in the second module configuration data; Based on the global context object and the instance context object, and combined with the main HTML skeleton template, a trial ad program is generated.

[0015] Secondly, embodiments of this application provide a personalized trial ad generation system, including: First processing module: used to select at least one target module from a pre-set standardized gameplay module library and obtain the configuration data of the first module; The second processing module is used to obtain the user profile information of the target user, and adjust the configuration data of the first module based on the user profile information to generate the configuration data of the second module. The third processing module is used to generate personalized trial ads based on the configuration data of the second module.

[0016] The beneficial effects of the embodiments in this application compared with the prior art are: This application discloses a method for generating personalized playable ads. By constructing a standardized game gameplay module library, common gameplay is abstracted into reusable, independent functional modules. This allows developers to build the gameplay framework and configure parameters through a visual creation interface via drag-and-drop or point-and-click operations, without writing any code, resulting in high production efficiency and low cost. Furthermore, through the fusion analysis of multi-source user profile data, combined with a dual-mode collaborative architecture of rule engine and machine learning model, it is possible to automatically adjust module combinations and / or module parameter configurations based on user preferences and device performance while ensuring basic usability. This achieves personalized content adaptation and dynamic optimization from a "one-size-fits-all" approach to a "personalized experience" without manual intervention. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a personalized playable ad generation method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a personalized playable ad generation system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] Please see Figure 1 As shown, this invention is a method for generating personalized playable ads, including the following steps: S100: Select at least one target module from the pre-set standardized gameplay module library and obtain the configuration data of the first module; In some embodiments, the standardized gameplay module library abstracts and encapsulates gameplay into independent functional modules with standardized interfaces. Each functional module includes a logic code body, an art resource package, a module description list, and a standardized interface adaptation layer. The module description list includes module identity information, configurable parameter definitions, dependency declarations, and event interface declarations. The module identity information includes module ID, semantic version number, model type label, and relation type label; The model type tags are divided into gameplay logic modules and functional support modules according to whether an independent gameplay rule loop is defined. The gameplay logic module defines a set of gameplay rule loops, while the functional support module is a module that does not have gameplay logic itself and is used to provide supporting functions or environment adaptation capabilities for the gameplay logic module. The relationship type label is used to describe the types of relationships that this module can establish with other modules, specifically including host type, parasitic type, independent type, and service type.

[0026] In this embodiment, a standardized gameplay module library is deployed. This library abstracts and encapsulates gameplay into independent functional modules with standardized interfaces, such as character control modules, level logic modules, UI interaction modules, shooting modules, elimination modules, and racing modules. Each module is encapsulated into an independent software package and includes logic code, art resource packages, module description lists, and standardized interface adaptation layers, ensuring that each module has self-containment, interoperability, and adaptability.

[0027] Specifically, the logic code body is a collection of script code that implements the module. It is written in a scripting language that supports dynamic loading, such as JavaScript or TypeScript, and includes lifecycle hook functions, logic implementation and state management, as well as a sandbox isolation mechanism.

[0028] More specifically, the lifecycle hook functions set a unified lifecycle interface for each module, including at least: an initialization interface, a start interface, a pause interface, a resume interface, a destruction interface, and a configuration update interface. The initialization interface is called when the module is instantiated, receiving a runtime context object to initialize internal states and register event listeners. The start interface is called when the module is first activated, starting animation loops, timers, etc. The pause and resume interfaces are used to respond to focus switching in the trial ad window, pausing and resuming module operation. The destruction interface is called when the module is unloaded, clearing timers, removing event listeners, and releasing memory resources to prevent memory leaks. The configuration update interface receives parameter overwrite instructions from subsequent dynamic tests, enabling the module to hot-update its behavior parameters at runtime without reloading the entire ad.

[0029] More specifically, in logic implementation and state management, the gameplay logic is organized into several independent pure functions or methods within the logic code body. Each function follows the "input-calculation-output" pattern. Specifically, the function receives the current module state snapshot and external input events as parameters, and returns a new state fragment or an instruction object describing the intention of state change after calculation, without directly modifying any external variables or state storage. This makes the logic unit highly testable and composable. The execution result of any function is determined only by its input and is not affected by the global context. Furthermore, the module state machine is completely decoupled from the specific logic functions mentioned above in terms of architecture. Specifically, the module instance maintains a finite state machine model internally. Its state enumeration and state transition rules are pre-declared in the extended fields of the module description list. At runtime, the state machine engine is automatically built based on the declaration. This state machine engine is responsible for receiving transition intentions returned by external events or internal logic functions, determining whether the transition is allowed in the current state, and calling the corresponding entry and exit callbacks when the transition occurs. The logic functions themselves are unaware of the existence of the state machine; they only need to return a result carrying the state transition instruction identifier to execute the actual transition and state update, thereby achieving the separation of business logic and state lifecycle. In addition, all observable state data generated during module operation, such as current score, remaining health, location coordinates, and whether interaction is possible, are uniformly constrained in a single state object of the module instance. This state object is designed as an immutable data structure. Each state update operation generates a brand new state object reference, while the original object remains unchanged. Changes to this object will trigger predefined "state change events" so that other modules can perceive and respond through the event bus. For example, the UI interaction module subscribes to events that change the player's health, and updates the health bar display immediately when it receives a notification that the health has decreased; the level logic module subscribes to events that change the current score, and triggers the level upgrade process when the score exceeds a certain threshold.

[0030] More specifically, the sandbox isolation mechanism means that the logic code of each module runs in an independent execution context. Through closures or namespaces, it prevents variable pollution between modules, and modules only communicate with the outside world through a standardized interface adaptation layer, and must not directly access global objects or the internal state of other modules.

[0031] Specifically, the art asset package is a collection of visual and audio materials matching the module, which is stored in association with the logical code body in the form of an asset package file, and features material asset combination, graded precision storage, an asset manifest file, etc. The material asset combination contains various materials such as sprite maps, animation sequence frames, particle textures, shader scripts, audio effect files, and font files, and adopts Web common compression formats such as PNG, WebP, MP3, AAC, etc., to minimize the file size of each material on the premise of ensuring quality. The graded precision storage is used to support different device performances, which pre-generates multi-level precision versions for each degradable material asset item and performs graded identification by definition or complexity, usually including a high-definition version, a medium-precision version and a low-precision version. The asset manifest file is an asset manifest attached to each art asset package, which records the file name, asset identifier, asset type, physical size, estimated memory occupation of each material asset in the art asset package and the file path mapping under different precision levels in JSON format, for subsequent code generation.

[0032] Specifically, the module description manifest is a meta-information index of the module, which is written in a machine-readable structured format such as JSON Schema, so as to unambiguously understand the capabilities and requirements of the module. The module description manifest at least includes: module identity information, configurable parameter definitions, dependency declarations, and event interface declarations.

[0033] More specifically, the module identity information usually includes a globally unique module ID, a semantic version number, a module type tag, and a relationship type tag. The semantic version number is set as a three-segment version consisting of a major version number, a minor version number and a revision number. A change in the major version number indicates an incompatible interface change, a change in the minor version number indicates a backward-compatible new function, and a change in the revision number indicates a backward-compatible problem fix. Through the setting of the semantic version number, the subsequent generation of trial-play advertisements can lock compatible versions. The module type tag specifically refers to the type of the module, which includes two major types: a gameplay logic module and a function support module. The gameplay logic module is an independently encapsulable and reusable atomic-level "gameplay interaction mode" extracted by disassembling and analyzing the core gameplay of the game, which can be divided into a primary classification and a secondary subdivision by adopting a multi-level classification method. The primary classification covers various gameplay types, such as character control, level logic, shooting, elimination, racing, etc., while the secondary subdivision is used to subdivide the gameplay types of the primary classification, for example, the shooting category is divided into first-person shooting, bullet shooting, tower defense shooting, etc. In addition, the function support module is a module that has no gameplay logic itself, and this type of module provides support functions or environment adaptation capabilities for the gameplay logic module, such as a visual effect module, a transition animation module, a data burying point module, a UI interaction module, a device adaptation module, etc. The relationship type tag is used to describe the types of relationships that the module can establish with other modules, usually including a host type, a parasitic type, an independent type, and a service type.

[0034] More specifically, configurable parameter definitions declare the adjustable parameters exposed by the gameplay module in array form. Each parameter object contains: a unique parameter identifier, parameter name, parameter data type, parameter constraint information, parameter default value, parameter control type, adaptability type, and optional conditional display expression. The parameter constraint information specifies the constraints for that parameter, with different constraint forms depending on the parameter data type. For example, for numeric parameters, the constraint information is usually the range of numeric values, while for character parameters, the constraint information usually includes regular expression validation mode and maximum length, etc. The parameter control type allows for detailed selection of the control type in the parameter editing interface, such as slider, switch, drop-down menu, color picker, curve editor, etc. The adaptability type indicates whether the parameter can be adjusted for adaptability later, either adaptable or not. The conditional display expression indicates that the visibility or editability of this parameter is dynamically controlled based on the values ​​of other parameters. For example, a parameter may only be displayed when another switch parameter is true.

[0035] It is worth noting that for modules that need to dynamically load external resource files, the array of configurable parameters defines a resource reference parameter, which stores a file path mapping pointing to a specific material in the art asset package. The parameter data type is assetRef, which represents an asset reference. When the parameter editing interface is generated later, the resource selector pop-up is called to view the file path mappings of the art asset package so that the developer can select the corresponding art resource.

[0036] More specifically, the dependency declaration lists the external dependencies necessary for the normal operation of the gameplay module in the form of an array. Each dependency is a description object, and each dependency description object includes the dependency type, the identifier of the dependent object, the version constraint expression, the necessity level, and compatibility behavior. The dependency type includes module dependencies on other gameplay modules, system dependencies on underlying system capabilities, and resource dependencies on external resources. The identifier of the dependent object is determined according to the dependency type; for example, for module dependencies, the module ID of the dependent module is entered; for system dependencies, predefined capability identifiers are used, such as 3D graphics rendering capabilities, advanced audio processing capabilities, local persistent storage capabilities, etc.; for resource dependencies, it is usually the file path or resource identifier of the resource. The version constraint expression is used to detect whether there are version conflicts. The necessity level includes necessary dependencies, recommended dependencies, and optional dependencies. A necessary dependency means that the gameplay module cannot initialize if the dependency is missing; dependency verification will forcibly prevent it or prompt for automatic addition. A recommended dependency means that if the module is missing, it can run at a degraded level but its functionality will be limited; a mild warning will be given during verification, and a quick one-click addition operation will be provided. An optional dependency represents an enhancement dependency; its absence will not affect the core functionality. Compatibility behavior refers to the default behavior of gameplay modules when dependencies are missing or versions are incompatible. This typically includes aborting loading and reporting an error, downgrading the operation and disabling related functions, or issuing only a warning and continuing to run.

[0037] More specifically, the event interface declaration lists the custom events triggered by this gameplay module and the external events that can be listened to. Each event declaration object includes an event name, a description of the trigger timing, the data carried during the trigger, an event category label, and an event processing priority. The trigger timing description is a semantic description of when the event is triggered, used to understand the meaning of the event; the data carried during the trigger is the data fields and their data types carried when the event is triggered; the event category label includes, for example, lifecycle events, user interaction events, gameplay logic events, and system notification events.

[0038] Specifically, the standardized interface adaptation layer is used to connect different gameplay modules. All modules communicate with the external environment and other modules through this layer. This is achieved by maintaining a global message bus, with modules communicating asynchronously via a publish / subscribe pattern. The message bus defines a unified communication protocol, and the message body is encoded in JSON format. Each message body structure includes fields such as a unique message identifier, event type, sending module instance identifier, target module instance identifier (or broadcast), data payload, and message timestamp. Specifically, during initialization, each module receives an adapter connector object from its initialization interface. This adapter connector object encapsulates the interaction interface with the global message bus, providing a send method for sending events and a subscribe method for subscribing to events. During message routing, only the adapter connector's API needs to be called, without needing to concern oneself with the underlying message routing implementation details. Furthermore, for system capabilities that modules depend on, the standardized interface adaptation layer provides standardized capability call interfaces. This allows modules to list system dependencies in their dependency declarations and automatically inject the corresponding capability provider proxies during initialization. Modules can then call these capabilities through a unified interface without directly coupling with the underlying API.

[0039] Understandably, the gameplay logic module and functional support module in the standardized gameplay module library are divided according to the boundary of "whether an independent gameplay rule loop is defined". Specifically, the gameplay logic module defines an independent "operation-feedback-win determination" rule loop that users need to understand and actively participate in, while the functional support module is a "presentation layer" that serves the gameplay performance, a "support layer" that provides data for the gameplay, or an "adaptation layer" that connects to external systems, without defining any game rules themselves.

[0040] Specifically, in the gameplay logic module, the character control module maps the user's dragging or swiping spatial input to the continuous movement of the virtual character, encapsulating gameplay logic such as movement speed, acceleration curves, and boundary detection, suitable for gameplay prototypes such as parkour, dodging, and platforming. The shooting logic module maps the user's click / swipe directional input to the generation, flight, hit determination, and damage calculation of projectiles, encapsulating logic such as trajectory calculation and projectile lifecycle management, suitable for gameplay variations such as flight shooting, tower defense shooting, and bullet hell shooting. The elimination logic module maps the user's input of swapping or selecting elements to changes in the board state, encapsulating logic such as match detection, element elimination, falling fill, and a four-stage state machine for combo scoring, suitable for gameplay variations such as match-3, point elimination, and line elimination. The racing logic module maps the user's control input of vehicles to speed and position competition along the track, encapsulating logic such as vehicle kinematics models, AI opponent behavior trees, and ranking statistics, suitable for gameplay such as racing. The level logic module provides an operational orchestration framework for other gameplay modules, managing level state machines (ready, in progress, paused, victory, defeat), wave control, progress triggering, and difficulty increment logic. The physics simulation module provides dynamic solutions for physical phenomena such as collisions between objects, gravity, and constraints. It can independently form physics-based puzzle gameplay or serve as the underlying physics support for modules such as character control and shooting.

[0041] Specifically, within the functional support modules, the UI interaction module maps user actions on virtual controls, such as buttons, joysticks, and sliders, to associated logical actions or interface state updates. It encapsulates interaction logic such as control state machines, gesture conflict resolution, and multi-resolution adaptive layout, serving as a bridge connecting user intentions and game logic. The audio management module maps audio playback events to the loading, decoding, playback, mixing, and output of audio resources. It encapsulates logic such as resource pool management, multi-channel mixing, priority scheduling, mute / volume control, and audio context switching, providing an immersive auditory experience for the entire playable ad. The visual effects module is responsible for the playback and recycling of visual decorative effects such as particle explosions, screen vibrations, halos, and trails triggered by effects playback events. It encapsulates logic such as particle systems, texture animations, and rendering pipeline calls, and does not participate in any victory or defeat determination or gameplay rules, only enhancing expressiveness. The transition animation module maps scene switching or UI state change events to the driving force of easing animations or sequence frame animations, encapsulating time curve calculations and attribute interpolation engines, directly affecting the user's perceived smoothness. The data tracking module captures predefined user behavior events during game execution, such as clicks, playtime, level progress, and conversion actions, and formats and reports them for data analysis. The device adaptation module is responsible for detecting device parameters of the current operating environment, such as screen resolution, device pixel ratio, GPU model, and operating system version, and provides a unified interface for querying adaptation parameters.

[0042] Furthermore, the "dependency declarations" and "event interface declarations" in the module description list jointly define the relationship types between different modules, and implement specific interactions at runtime through a standardized interface adaptation layer and a unified message bus. Specifically, the relationship types include host-parasitic relationships, service consumption relationships, peer-to-peer collaboration relationships, and aggregation-composition relationships.

[0043] Specifically, the host-parasitic relationship is used to measure the structural relationship between gameplay logic modules. A host module provides the runtime environment and orchestration framework, such as a level logic module, while a parasitic module is instantiated and runs within the context of a host module, such as character control, shooting, elimination, or racing modules. Understandably, the host module broadcasts the level state to the parasitic module via an event bus, while the parasitic module feeds back key data, such as score, health, and progress, to the host module through state change events. The host module then advances the level state machine and determines the winner. This relationship type is represented in the module dependency declaration as the necessary dependency level declared by the parasitic module on the host module. It's worth noting that the relationship type label for level logic modules is usually marked as "host," indicating that they provide the runtime environment and orchestration framework for other gameplay logic modules, while the relationship type label for other gameplay logic modules is usually marked as "parasitic," indicating that they can be instantiated and run within a host module. In addition, gameplay logic modules that can run independently without relying on host modules can be labeled as independent, such as character control modules, which can independently control the continuous movement of virtual characters without the cooperation of other gameplay logic modules.

[0044] Specifically, the service consumption relationship is a unidirectional service relationship between the functional support module and all other modules. The support module acts as the service provider, exposing standardized event interfaces and / or API call interfaces. Its relationship type is labeled as service-oriented. Any other module that needs it can act as a service consumer, invoking its capabilities through the message bus or adapter connector. For example, the sound effects management module subscribes to the global "audio playback request" event and responds to playback; the data tracking module listens for global business events and automatically collects and reports them. This data tracking module is depended on by all modules. This relationship type is typically listed as recommended or optional dependency in dependency declarations. It's worth noting that the support module itself does not depend on any gameplay logic modules.

[0045] Specifically, when two or more modules do not have a host-parasitic relationship but need to perceive each other's state to coordinate their behavior, a peer-to-peer collaborative relationship is formed. This typically occurs between two or more gameplay logic modules, or between a gameplay logic module and a UI interaction module. For example, between the character control module and the UI interaction module: the character control module emits a "state change event" indicating a change in health points, at which point the UI interaction module subscribes to this event to update the health bar display in real time; the UI interaction module emits a "control trigger event" indicating a click on a skill button, and the character control module subscribes to this event to execute the corresponding skill. Both parties communicate asynchronously through an event bus, do not hold references to each other, maintain loose coupling, and the matching rules for this relationship type are predefined by the event interface declarations in the module description lists of both parties.

[0046] Specifically, the aggregation and composition relationship indicates that within the same host module context, multiple parasitic gameplay logic modules can be aggregated and combined to form a composite gameplay experience. For example, within the host framework of the level logic module, the character control module and the shooting logic module can coexist: the user moves the character through the character control module and fires bullets through the shooting logic module. Both share the same game loop and collision space and work together through an event bus. The feasibility of such combinations is ensured by the dependency declarations and event interface declarations in the module description list, allowing any module conforming to the interface contract to be "assembled" as needed without the need for manual code writing.

[0047] In some embodiments, step S100 above includes: The step of selecting at least one target module from a pre-set standardized gameplay module library and obtaining the first module configuration data includes: The modules in the standardized gameplay module library are displayed in the module library panel in the form of a classification tree or card flow; The target module can be dragged or selected from the module library panel and placed into the canvas editing area, and then dependency verification, interface compatibility check, instantiation and configuration placeholder, and preview update can be performed. By instantiating and configuring placeholders, a module instance is created for each target module placed into the module library panel, and serialized into a module selection list. The module selection list includes a unique instance identifier for each module instance, a module description list for each module instance, and the topological relationship between the module instance and other module instances in the canvas. For each module instance in the module selection list, a parameter editing interface is dynamically constructed based on the configurable parameter definitions in its module description list. Parameter values ​​are selected from the parameter editing interface and mapped to the first module configuration data.

[0048] In some embodiments, a visual creation interface is provided, hosted in a browser, requiring no local development tools and lowering the barrier to entry. The front-end interface is built using a component-based architecture, with the core rendering engine based on Canvas or WebGL to achieve real-time drawing of preview frames, and the interface interaction layer using a responsive framework to achieve data binding and state synchronization. This visual creation interface includes a module library panel, a canvas editing area, and a preview window.

[0049] Specifically, the module library panel displays graphical thumbnails and names of all available modules in the form of a category tree or card flow. Each module entry is associated with its module description list, and its compatibility status is displayed in real time. Specifically, the category tree view organizes modules into a tree control according to a hierarchical structure of "first-level category → second-level sub-category → module item." Each branch node of the tree can be expanded and collapsed, and the leaf nodes correspond to specific module entries. This view allows developers to gradually locate the required modules according to the classification system in the standardized gameplay module library. The card flow view displays modules in a tiled grid format. Each card contains a graphical thumbnail of the module, the module name, a brief functional description, a module type label, and a relationship type label. The top of the card flow has a search box and filters, supporting keyword searches by module name, multi-select filtering by type label, and sorting by most recent usage time. This view is suitable for quick browsing and inspirational exploration, reducing the cognitive load for novice developers. Furthermore, the two views can be switched with a single click, and they share the same selection state and filtering conditions, ensuring operational continuity.

[0050] Specifically, the canvas editing area receives the developer's placement operations for each module. It is the main workspace for developers to combine, arrange, and define relationships between modules. Specifically, developers drag and drop target modules from the module library panel into the canvas editing area. At the same time, it iterates through the dependency declarations of the target modules, checking one by one whether there are already dependent modules in the canvas editing area that meet the version constraints. If all necessary dependency levels are met, it is marked as "Can be added," indicating that it can be added for instantiation. If a necessary dependency level is missing, it is marked as "Dependency needs to be added," and a non-blocking notification bar pops up at the edge of the canvas editing area, listing the missing dependent modules and providing a "One-click Auto Add" button. After the developer clicks, the missing dependent modules are automatically instantiated and placed on the canvas, and dependency connections are automatically established. If there is a version conflict, it is marked as "Version Conflict," and the developer is notified with a prominent red warning box and message in the canvas editing area, preventing the formation of circular dependencies. In addition, by comparing the custom events and external events declared in the event interface of the target module with the event interfaces of existing modules in the canvas editing area, event trigger listening pairs that can form an effective communication link are identified. These pairs are then marked as "collaborable". Developers can click to confirm to establish a formal event subscription relationship, or ignore it to keep the modules running independently.

[0051] Specifically, the preview window is used to render the interactive preview effect of the current module combination in real time. When modules are added or deleted in the canvas editing area, the logic code body and low-precision art resources of the selected modules are loaded in real time to render interactive trial advertisement preview frames, helping developers to confirm the effect of the gameplay combination.

[0052] Understandably, when a developer drags or selects a target module from the module library panel into the canvas editing area, dependency validation, interface compatibility checks, instantiation and configuration placeholders, and preview updates are performed. Instantiation and configuration placeholders mean that when a target module is placed in the canvas editing area, a module instance of that module is created, a unique instance identifier is generated, and corresponding configuration parameters are automatically generated based on its configurable parameter definitions. These configuration parameters correspond to default values. After the developer completes the module selection, the instance information of all selected modules is serialized into a module selection list. This module selection list includes the unique instance identifier of each module instance, the module ID to which each module instance belongs, the semantic version number and its module description list, and the topological relationship between the module instance and other module instances in the canvas.

[0053] In this embodiment, the unique instance identifier and associated module description list of each module are extracted from the module selection list. For each module instance, a corresponding parameter editing interface is dynamically constructed based on the array of configurable parameters defined in its module description list, allowing developers to select appropriate parameter values ​​and map them to the first module configuration data. Specifically, for the parameter editing interface, the basic control category is determined based on the parameter data type, and then refined by combining the parameter control type. For example, for both numeric types, if the parameter control type is a slider, it is rendered as a slider control with scales; if it is a numeric input box, it is rendered as a numeric input box with fine-tuning buttons. For both character types, if the parameter control type is a color picker, it is rendered as a color picker; otherwise, it is rendered as a single-line text input box by default. At the same time, the parameters of each control are adjusted according to the parameter constraint information. For example, for a slider control, the slider range is determined by the range of numerical values; for a drop-down menu control, the drop-down menu is rendered based on the menu enumeration value. In addition, the parameter editing interface of each parameter is automatically filled with the default parameter value during initialization. Developers can use this default parameter value as the parameter configuration parameter to generate the first module configuration data. For conditional display expressions, a built-in conditional evaluation engine parses the expressions to enable dynamic visibility and availability linkage between parameter controls. For example, if parameter A is only displayed when another boolean parameter B is true, its conditional display expression is written as "paramB == true". When the value of parameter B is changed, the visibility of parameter A is updated in real time through the conditional evaluation engine.

[0054] S200: Obtain user profile information of the target user, and adjust the configuration data of the first module based on the user profile information to generate configuration data of the second module; In this embodiment, before or during ad delivery, the first module configuration data determined by the module selection list selected by the developer in step S100 is automatically adjusted based on the user profile information of the target user. By adjusting the module parameter configuration and / or module combination method in the first module configuration data, second module configuration data optimized for the user is generated. Without manual intervention, the same ad framework can be transformed into a personalized "one-size-fits-all" approach.

[0055] In some embodiments, step S200 above includes: When a request to display a playable ad is received, user profile data is collected and constructed from ad request fields, ad platform data interfaces, and context environment parameters. Device performance metrics and user behavior preference tags are extracted from the user profile data, and combined with user metadata to generate user profile objects; Based on the user profile object, a dual-mode collaborative approach of rule engine and machine learning model is adopted to adapt the configuration data of the first module and generate the configuration data of the second module.

[0056] Furthermore, user profile information of target users is obtained. When a request to display a trial ad is received, structured user profile data is collected and constructed from ad request fields, ad platform data interfaces, and context environment parameters.

[0057] Specifically, when a user's terminal device sends a request to the advertising platform to display a playable ad, the request data packet carries a large amount of basic information according to the standard advertising request protocol, such as device hardware parameters, operating system parameters, network environment parameters, and advertising context parameters. These include device model, CPU architecture and number of cores, GPU renderer name, total physical memory, screen resolution, device pixel ratio, operating system name and version number, user language settings, time zone offset, network type, estimated bandwidth level, mobile network operator information, ad placement type, ad placement size, media application type, current page URL, or content category, etc.

[0058] Specifically, the user's anonymized behavioral tags are obtained through the user data interface provided by the advertising platform. The interface call performs association matching based on the user's anonymous identifier and obtains data such as historical interaction statistics and attribute tags within the privacy compliance framework.

[0059] Specifically, in addition to user data obtained through user device terminals and advertising platforms, contextual parameters related to the current advertising display scenario are also collected, such as time characteristics, media environment characteristics, and frequency control and fatigue characteristics. Among them, time characteristics include the current server timestamp, user's local time, time period, and whether it is a weekend or holiday; media environment characteristics specifically include the type of media application carrying the advertisement, such as social, tool, game, video, etc., and also include media information such as the age classification of the media application, the position and area ratio of the advertisement on the screen; frequency control and fatigue characteristics specifically include the number of times the user has displayed this advertisement or similar advertisements on the same day, and the time interval since the last display, in order to avoid advertisement fatigue.

[0060] Furthermore, the aforementioned multi-source user profile data is integrated into a standardized user profile object. This user profile object includes device performance indicators and user behavior preference tags. Specifically, the original device parameters, including device hardware parameters, operating system parameters, and network environment parameters, are converted into corresponding device performance scores, ranging from 0 to 100. These device performance scores are calculated by a device performance evaluation model, which maintains a mapping database between each original device parameter and its performance score and updates it periodically. The device performance scores of each original device parameter are aggregated into a comprehensive performance score from 0 to 100 using weighted summation or the analytic hierarchy process. This comprehensive performance score is further mapped to three device performance levels. For example, in one embodiment, a score below 40 indicates a "low-end performance device," 40 to 70 indicates a "mid-range performance device," and a score above 70 indicates a "high-end performance device." The thresholds for each level are not fixed but are dynamically adjusted based on the percentile distribution of the performance scores of all active devices to ensure that the level classification always reflects the current market device landscape.

[0061] Specifically, user behavior preference tags represent users' multidimensional preferences in the form of structured vector features, including gameplay type preference vectors, challenge preference levels, and art style preference tags.

[0062] For the gameplay type preference vector, the user's interaction depth for different gameplay type modules is obtained from historical interaction statistics. The metrics for interaction depth include: trial play duration, whether the core gameplay loop is completed, number of active operations, and whether the final conversion is triggered. Then, each metric is combined with different weights to form a "gameplay preference intensity" value, which is then aggregated by gameplay type and normalized by softmax to obtain the preference weight of each gameplay type. The sum of all weights is 1.

[0063] For the challenge preference level, the user's level completion rate, operation frequency, and operation stability in the trial advertisement are determined from historical interaction statistics. Specifically, for the level completion rate, the number of times the user triggered the "level completion" event and the total number of times are counted in all trial sessions to calculate the completion rate. For the operation frequency, for all trial sessions of the user in the past 30 days, the number of effective operations and trial duration in each session are counted, and the operation frequency of a single session is calculated as operation frequency = number of operations / trial duration. Then, the weighted average of the operation frequencies of each session is calculated, with the session duration as the weight, to obtain the final user operation frequency. For the operation stability, each trial session is divided into multiple segments according to a fixed time window, and the operation frequency in each segment is calculated to obtain a set of frequency sequences. The coefficient of variation of this sequence is calculated as: coefficient of variation = standard deviation / mean. The mean of the coefficients of variation of all effective sessions is taken and converted into a stability index. The stability index is calculated as: stability index = 1 - min(mean coefficient of variation / standardized threshold, 1), where the standardized threshold is set to 0.5 based on experience. The closer the stability index is to 1, the more stable the operation rhythm; the closer it is to 0, the less stable it is. During the assessment process, if a user's operation frequency is higher than the preset average level, it indicates high engagement and active participation; however, if their level completion rate is lower than the preset minimum completion rate, it suggests that despite repeated attempts, they struggle to succeed, fitting the behavioral profile of "low level completion rate but high operation frequency," thus classifying them as a hardcore, high-difficulty user. If a user's level completion rate is higher than the preset maximum completion rate, it indicates sufficient ability to handle the challenge, and their operational rhythm stability index is higher than the preset stability coefficient, classifying them as a light, casual user. Users who do not fall into either the hardcore / high-difficulty or light / casual category are classified as neutral challenge users. It is worth noting that the preset average level, preset minimum completion rate, preset maximum completion rate, and preset stability coefficient are derived from offline historical data analysis.

[0064] For art style preference tags, historical interaction statistics are used to obtain the differences in click-through rates (CTR) for ads of different art styles. When the CTR of an ad of a certain style type is significantly higher than that of other styles and the statistical sample size is sufficient, that style is marked as the user's preferred style. Specifically, art style tags include cartoon rendering, realistic rendering, pixel art, minimalist style, watercolor / hand-painted, dark / hardcore, anime / Japanese style, etc. The meta-information data of each playable ad is labeled by the developer or automatically identified by the system to its respective set of art style tags. For each art style tag, it is determined whether its effective exposure count reaches the minimum sample size threshold. For style tags that reach the minimum sample size threshold, the difference between the historical CTR of that style tag and the global average CTR of all styles is compared. If it is higher than a preset significant difference, the style tag is determined to be the user's preferred style. It is worth noting that this art style preference tag adopts a multi-tag classification method, and users can prefer multiple styles simultaneously.

[0065] Furthermore, the aforementioned device performance indicators and user behavior preference tags are encapsulated into user profile objects. At the same time, the basic information obtained from the ad request field, the time characteristics, media environment characteristics, frequency control and fatigue characteristics in the context environment parameters, etc., obtained from the user profile data are encapsulated into user metadata and stored synchronously in the user profile object. The aforementioned user profile object is generated in real time each time a trial ad request is initiated, in order to generate personalized trial ads.

[0066] In this embodiment, a dual-mode collaborative architecture of "rule engine + machine learning model" is adopted. Combined with the user profile object mentioned above, the configuration data of the first module is adjusted for adaptability. The rule engine handles the adaptation logic with strong determinism and interpretability, while the machine learning model handles the complex, non-linear preference prediction and module recommendation tasks that need to be learned from the data. The two have a clear division of labor and complement each other's advantages.

[0067] In some embodiments, the rule engine has a set of judgment rules built in, and each rule is encapsulated into a rule object to form a rule library. Each rule object includes at least a rule ID, rule priority, rule description, condition expression tree, and action instruction array. The condition expression tree is the condition expression of the deterministic indicator features in the user profile object in the rule. The action instruction array is specifically a modification operation on the configuration data of the first module, including parameter overwriting, parameter range mapping, module switch control, and resource precision switching. Within the rule engine, all enabled rules are loaded from the rule base and sorted from high to low according to the rule priority to form a rule list. Based on the user profile object, the rule list is traversed to form a set of hit rules. The actions of the set of hit rules are obtained sequentially according to the rule priority, and conflict arbitration is performed to form a rule increment object. The rule increment object records its parameter change information and activation status change information using the unique instance identifier of the module instance as the key.

[0068] Specifically, the rules engine contains a set of judgment rules defined by domain experts or extracted from historical data. Each rule follows the "condition → action" principle and is used to adjust the configuration data of the first module.

[0069] More specifically, within the rule engine, each rule is sequentially encapsulated into a rule object, forming a rule library. Each rule object includes at least a rule ID, rule priority, rule description, conditional expression tree, and action instruction array. The rule ID is a globally unique identifier for easy log tracing and conflict resolution. Higher rule priority values ​​resolve conflicts when the same parameter is adjusted by multiple rules. The rule description is used for operational management and auditing. The conditional expression tree supports arbitrarily complex compound conditional logic through a nested structure. The action instruction array indicates that each rule can contain multiple actions, which are executed sequentially according to the array order.

[0070] More specifically, for ease of management, rules of various types are grouped and managed by category within the rule base, including at least rule categories such as device performance degradation, network condition adaptation, screen size adaptation, system capacity limitation, and ad fatigue adjustment. Furthermore, the rule base supports hot updates; operations personnel can add, delete, and modify rules through the management backend, with changes taking effect immediately without requiring a service restart.

[0071] More specifically, for the conditional expression tree, it refers to the conditional expressions of deterministic indicator features in the user profile object within the corresponding rules. Specifically, based on the deterministic indicator features in the user profile object, such as device performance rating, network type, screen resolution, time characteristics, media application type, gameplay type preference vector, challenge preference level, art style preference tag, etc., Boolean judgments or threshold comparisons are performed to construct atomic conditional expressions. They can also be combined through logical operators to form compound conditional expressions.

[0072] More specifically, the action command array involves specific modification operations on the configuration data of the first module, including parameter overriding, parameter range mapping, module on / off control, and resource precision switching. Parameter overriding forcibly sets the value of a configuration parameter of a module instance to a specified value; parameter range mapping maps the original parameter value to a new target value based on the value of a continuous indicator in the user profile object using linear interpolation or a piecewise function; module on / off control enables or disables a module instance or a type of module, such as disabling the visual effects module to improve smoothness on low-end devices; and resource precision switching switches the precision version of the material resource path, such as switching from a high-definition version to a low-precision version.

[0073] For example, there is rule R1: if the network type is 2G / 3G, then the enable background music parameter of the sound effect management module is overwritten to false to reduce data consumption; rule R3: if the screen size is <5 inches, then the button size parameter of the UI interaction module is mapped to 0.8 times the original value to ensure operability on small screens.

[0074] Specifically, when adjusting the configuration data of the first module of the rule engine, all enabled rules are loaded from the rule base and sorted by rule priority from high to low to form a rule list. The user profile object constructed above is then processed by the condition evaluation engine to traverse the rule list, filter out rules that meet the conditions, and form a set of hit rules. Actions for the set of hit rules are obtained sequentially according to rule priority, and an action source record is maintained for each action, specifically the rule ID and rule priority that triggered the action. When multiple actions issue conflicting adjustment instructions for the same parameter of the same module instance, conflict arbitration is triggered. Specifically, the rule priorities of the multiple action source rules are compared, and the action with higher priority is retained. If the priorities are the same, the action type is compared, with parameter overriding taking precedence over parameter range mapping. For conflicts between parameter overriding and parameter range mapping and module on / off control, the rules that the module disables are executed first. The arbitration-adjusted action sequence is used to generate a rule increment object. This rule increment object uses the unique instance identifier of the module instance as the key and records the parameter change information and the enabled / disabled status information of each module instance.

[0075] In some embodiments, the machine learning model includes at least the following steps: The system performs two types of prediction tasks: gameplay preference and module recommendation, and parameter dynamic optimization prediction. It outputs a prediction increment object, which includes module insertion instructions and parameter adjustment instructions. The predicted incremental object and the rule incremental object are converted into standard instructions, each of which includes instruction type, instruction purpose, instruction priority, and instruction increment adjustment; The aforementioned standard instructions are arbitrated for conflicts and then encapsulated into an executable instruction set. The executable instruction set is applied to the configuration data of the first module to generate the configuration data of the second module, and a consistency check is performed simultaneously.

[0076] Specifically, the machine learning model is responsible for complex adaptation scenarios that are difficult for the rule engine to cover. It mainly includes two prediction tasks: gameplay preference and module recommendation, and dynamic parameter optimization prediction. Based on the rule engine, it predicts the optimal module combination and parameter value scheme according to user profile data to achieve data-driven personalized experience optimization.

[0077] More specifically, the machine learning model adopts a "dual-task parallel inference, unified decision fusion" model architecture, specifically including a data input layer, a feature engineering layer, a core model layer, and a decision fusion layer. The data input layer receives and parses user profile objects and the first module configuration data, while the feature engineering layer converts the raw input from the data input layer into feature vectors that the model can consume. The core model layer performs inference calculations for two types of prediction tasks: gameplay preference and module recommendation, and parameter dynamic optimization prediction. The decision fusion layer combines the prediction increment objects from the core model layer with the rule increment objects output by the rule engine, and after conflict arbitration and consistency verification, generates the final adapted instruction set, outputting the final second module configuration data.

[0078] In some embodiments, the machine learning model includes at least the following steps: The system performs two types of prediction tasks: gameplay preference and module recommendation, and parameter dynamic optimization prediction. It outputs a prediction increment object, which includes module insertion instructions and parameter adjustment instructions. The predicted incremental object and the rule incremental object are converted into standard instructions, each of which includes instruction type, instruction purpose, instruction priority, and instruction increment adjustment; The aforementioned standard instructions are arbitrated for conflicts and then encapsulated into an executable instruction set. The executable instruction set is applied to the configuration data of the first module to generate the configuration data of the second module, and a consistency check is performed simultaneously.

[0079] In the gameplay preference and module recommendation task, user tower feature vectors and advertising tower feature vectors are constructed through a shared embedding layer and a multilayer perceptron mapping. Specifically, the user tower feature vector incorporates user behavior preference tags, time features, media environment features, and frequency control and fatigue features. The advertising tower feature vector corresponds to the module type distribution vector in the first module configuration data. Then, based on the user tower feature vectors and advertising tower feature vectors, an overall preference fit score for the current advertising configuration is calculated. This score is obtained by normalizing the inner product of the user tower feature vector u and the advertising tower feature vector v to the [0,1] interval using the Sigmoid function: score = σ(u·v). Simultaneously, a marginal preference score is output independently for each gameplay type. This score is obtained by calculating the inner product of the user tower feature vector u and the prototype vector of each gameplay type in the embedding space. This marginal preference score represents the user's independent preference strength for each gameplay type, unaffected by the current advertising configuration. The gameplay type corresponds to the gameplay logic module in the standardized game gameplay module library. If the overall preference fit score is greater than or equal to the first preset threshold, module recommendation is not triggered, and the current overall preference fit score and the marginal preference score of each gameplay type are output. If the overall preference fit score is less than the first preset threshold, module recommendation is triggered. From the gameplay types with the highest marginal preference scores that are not configured in the first module configuration data, candidate modules that meet the dependency and event compatibility constraints are retrieved. That is, the dependency declarations in the module description list of the candidate modules are compatible with each module instance in the current first module configuration data, and the event interface declarations indicate that their custom events can be generated by at least one module instance in the first module configuration data. External events must be satisfied, or their external events must be subscribed to by at least one module instance in the first module configuration data. For candidate modules that meet the above conditions, a weighted recommendation score is calculated: Recommendation score = α × User marginal score + β × Module event compatibility + γ × Module dependency satisfaction, where α + β + γ = 1, and the default weights are 0.5, 0.3, and 0.2, respectively. Event compatibility is calculated as the ratio of the number of event links that can be matched between the candidate module and the module instances in the current first module configuration data to the total number of event interfaces of the candidate module. Dependency satisfaction is calculated as the proportion of the necessary level dependencies of the candidate module that have been satisfied in the current first module configuration data.

[0080] Furthermore, the candidate module with the highest recommendation score that exceeds the second preset threshold is selected, and an insertion module instruction is generated. The insertion module instruction carries the module ID, recommendation score, and confidence level, where the confidence level is the product of the overall preference fit score and the recommendation score of the candidate module.

[0081] Furthermore, the aforementioned first and second preset thresholds are values ​​set by the developers based on historical experience. Preferably, the first preset threshold is 0.7 and the second preset threshold is 0.6.

[0082] In some embodiments, the parameter dynamic optimization prediction task includes at least the following steps: Iterate through all parameters of each module instance in the first module configuration data and filter the parameters whose adaptability type is adaptable. Based on the user profile object, and the parameter name, current parameter value, and module type label of the adaptable parameter, a parameter prediction feature vector is generated for each adaptable parameter, wherein the parameter name corresponds to the business semantic category; Based on the business semantic category, determine the parameter adjustment coefficient for each adaptable parameter; Based on the parameter adjustment coefficients and the current parameter values, a final predicted value is generated, and a parameter adjustment instruction is output.

[0083] In the parameter dynamic optimization prediction task, all parameters of each module instance in the configuration data of the first module are traversed, and parameters whose adaptability type is adaptable are selected and their adaptability is adjusted. Specifically, the parameter dynamic optimization prediction task consists of a shared underlying network and multiple task-specific output headers. The shared underlying network concatenates user behavior preference labels, frequency control and fatigue features, device performance level, current parameter value, module type label of the module to which the parameter belongs, and parameter name, thereby obtaining parameter prediction feature vector. It is worth noting that the business semantic category of the parameter can be determined by the parameter name, such as difficulty level, particle effects, texture resolution, sound volume, etc. Furthermore, each task-specific output head has an independent output head corresponding to each business semantic category. Each output head can output a normalized parameter adjustment coefficient b mapped to the [0,1] interval by a Sigmoid function. Based on the business semantic type determined by the parameter name, the parameter adjustment coefficient can be obtained from the corresponding output head. The final predicted value = current parameter value × (1 + a × (b - 0.5)), where a is the adjustment magnitude hyperparameter, with a default value of 0.5, to control the maximum adjustment range of the final predicted value relative to the current parameter value. Additionally, the final predicted value must be adjusted to the range defined by the parameter constraints. Thus, the shared underlying network can learn common user preference patterns among different parameter types, such as hardcore users tending to increase game speed, difficulty, and particle count. The task-specific output head learns the adjustment logic specific to each parameter type. Then, a parameter adjustment instruction is output, carrying the unique instance identifier of the module instance, the unique parameter identifier, the current parameter value, the predicted value, the adjustment amount, and the confidence level.

[0084] Furthermore, the aforementioned insertion module instructions and parameter adjustment instructions are encapsulated into prediction increment objects and input into the decision fusion layer. The decision fusion layer simultaneously receives rule increment objects output by the rule engine and converts both prediction increment objects and rule increment objects into standard instructions. Each instruction includes an instruction type, instruction purpose, instruction priority, and instruction increment adjustment. Specifically, the instruction type is either a rule instruction or a model instruction; the instruction purpose is either parameter adjustment or module activation change; and the priority of rule instructions is higher than that of model instructions. For example, in one embodiment, the rule priority in the rule increment object is mapped... The confidence level of each instruction in the incremental prediction object is mapped to 0-100 as the instruction priority, and the confidence level of each instruction in the incremental prediction object is mapped to 100 as the instruction priority. In the incremental adjustment of instructions, the corresponding parameters are determined according to the purpose of the instruction. For example, the incremental adjustment of the instruction for parameter adjustment includes the unique identifier of the module instance, the unique identifier of the parameter, the current parameter value, the predicted value, and the adjustment amount. The incremental adjustment of the instruction for module activation change includes the enabled module ID, the semantic version number and its module description list, or the unique identifier of the disabled module instance. In addition, for rule instructions, the rule ID that triggered the action is also included for subsequent tracing.

[0085] Furthermore, conflict arbitration is performed on the standardized instructions. For parameter adjustment instructions with the same "unique instance identifier + unique parameter identifier", the instruction with higher priority is retained according to the instruction priority. For module activation change instructions, it is checked whether the module ID is duplicated. If it is duplicated, the instruction priority determines which instruction is retained.

[0086] More specifically, the instructions after conflict arbitration are encapsulated into an executable instruction set and applied to the first module configuration data to generate the second module configuration data. For each module instance in the second module configuration data, an enable field is added with a default value of "true". In the executable instruction set, for module enable instructions, the module ID is added to the second module configuration data, and a new module instance is generated for it, with the enable field set to "true". For disabled module instances, the enable field of the module instance in the rule configuration data is modified to "false". In addition, for module instances of parameter overwriting, parameter range mapping, resource precision switching, or parameter adjustment instructions, their instruction incremental adjustments are applied one by one to the corresponding fields of the first module configuration data to finally form the second module configuration data.

[0087] Furthermore, in the application generation of the configuration data in the second module, all module instances with the enabled field set to "true" are checked synchronously, a verification module sequence is generated, and consistency verification is performed on the verification module sequence, specifically including dependency integrity verification, event chain integrity verification, and resource availability verification.

[0088] For dependency integrity verification, each module instance is checked sequentially within the verification module sequence. Specifically, it verifies whether all necessary dependencies in the dependency declarations of each module instance exist within the verification module sequence. If a dependency break occurs due to a module being disabled, the disabling action is automatically rolled back or an alarm is triggered. For event chain integrity verification, it verifies whether the event trigger listener pairings declared in the event interfaces of each module instance are valid. If isolated event subscriptions exist, a non-blocking warning is issued. For resource availability verification, it checks whether the values ​​of all resource reference parameters for each module instance point to the actual file paths mapped in the art asset package. If resources are missing, it reverts to the default resource path or the original configuration value.

[0089] It is worth noting that the generated second module configuration data has a module selection list with the same structure as the first module configuration data. This module selection list includes the unique instance identifier of each module instance, the module ID to which each module instance belongs, the semantic version number and its module description list, and the topological relationship between the module instance and other module instances in the canvas.

[0090] S300: Based on the configuration data of the second module, generate personalized trial advertisements; In this embodiment, based on the second module configuration data generated in step S200 above, the code generation engine automatically combines the preset code template and art resource package to generate a complete playable ad program containing HTML, CSS and JavaScript. This playable ad program has independent running capability and is a personalized playable ad that can be placed on an advertising platform.

[0091] In some embodiments, step S300 above includes: Construct a code template library, in which a template file is set for each version of each module of the standardized gameplay module library. The template file includes a structure template, a style template, a logic template, and a resource list template. Using the tuple constructed from the module ID and semantic version number of each module as the key, a template index table is generated by associating all template files of the corresponding module in the code template library. The configuration data of the second module is parsed, the array of module instances is extracted, and the corresponding template file set is searched in the template index table according to the module ID and semantic version number of each module instance. Construct a global context object, and create an instance context object for each enabled module instance in the second module configuration data; Based on the global context object and the instance context object, and combined with the main HTML skeleton template, a trial ad program is generated.

[0092] Specifically, the code generation engine has a code template library corresponding to the standardized gameplay module library, which is maintained synchronously with updates to the standardized gameplay module library. Understandably, for each version of each module in the standardized gameplay module library, there is a corresponding template file in the code template library. This template file includes a structure template, style template, logic template, and resource manifest template. The structure template is specifically an HTML fragment, defining the module's mounting node, Canvas element, or DOM container structure in the DOM tree, including the module ID and associated tags with the style and logic templates. The style template is specifically a CSS fragment, defining the module's default visual style, including layout parameters, color variables, animation definitions, etc. Configurable properties in this style template, such as color and size, exist as placeholders and are dynamically replaced by parameter values ​​in the second module's configuration data. The logic template is specifically a JavaScript module skeleton, encapsulating the core gameplay logic code of the module, and marking the reference locations of all configurable parameters, as well as the code framework for reference interfaces to other module instances that the module depends on, and event subscription and publishing statements. The resource manifest template declares the list of static resource files that the module depends on, along with their path placeholders, such as sprite sheets, audio files, and texture packs.

[0093] It's worth noting that, based on standard template syntax such as Nunjucks, Handlebars, or custom syntax, and to adapt to the dynamic generation requirements of different module combinations in the second module configuration data, while supporting variable substitution, conditional judgment, and loop iteration, placeholders in the template file typically include: a unique identifier for the module instance, used to generate variable namespaces in the code to prevent conflicts between multiple instances; parameter value placeholders, which are replaced with the specific value of the parameter in the corresponding module instance in the second module configuration data during generation; unique identifiers for other dependent module instances, used to generate reference variable names when directly calling between modules; code generation markers for event subscription and triggering, which are automatically expanded into specific message bus call code based on the topology of module instances; and resource path placeholders, which are replaced with the actual resource URL based on the current resource precision level and adaptation results.

[0094] Specifically, when generating the configuration data for the second module, the code generation engine is started. The code generation engine loads a template index table. This template index table uses a tuple constructed from the module ID and semantic version number of each module in the standardized gameplay module library as the key to associate all template files of the corresponding module in the code template library. In this way, the content of all template files of the module can be quickly located through this template index table.

[0095] More specifically, after receiving the configuration data for the second module, the code generation engine first parses its structure, extracts the module instance array, records each module instance, and searches for the corresponding template file set in the template index table based on its module ID and semantic version number. If the template file is missing, an exception is thrown and generation is terminated, indicating that the module template file is missing. In addition, it also needs to check whether the parameter value conforms to the parameter constraint information defined in the configurable parameter definition of the parameter in the module description list. If there is an illegal value, it is automatically corrected to the default value or trimmed to the legal range, and a warning log is recorded.

[0096] Furthermore, for all module instances in the second module configuration data where the enable field is true, an instance context object is created. This instance context object includes a unique instance identifier, a template file set, a parameter mapping table, a list of unique instance identifiers of other module instances that the module instance depends on, and the event subscription and publication mapping of the module instance.

[0097] Furthermore, in addition to the instance context objects of each module instance mentioned above, a global context object is also constructed, which contains a list of unique instance identifiers for all module instances and a topological sorting among the module instances, used to determine the script loading order and initialization call order when concatenating code; and a unified message bus instance name, used for event communication across all modules.

[0098] More specifically, the code generation engine loads a main HTML skeleton template. This main HTML skeleton template is a pre-built general HTML5 document structure, which includes an HTML document skeleton, metadata, basic styles, specific ad containers, and a bootstrap script for the core runtime framework. In this embodiment, the core runtime framework specifically includes a message bus, a module lifecycle manager, and a resource loader. The skeleton template also includes placeholders for all merged module instances, such as a global stylesheet generated after merging the style templates of all module instances, logic scripts formed by the logic templates of each module instance loaded according to topology, and lifecycle interfaces in the lifecycle hook functions of each module instance called sequentially according to topology after the page loads.

[0099] More specifically, the process iterates through the topology-sorted list of module instances. For each enabled module instance, it performs style merging, structure generation, logic code generation, and lifecycle hook integration. For style merging, it reads the style template of the corresponding module instance and replaces the variable placeholders with the specific parameter values ​​from the instance context. The processed style fragments are then appended to the global stylesheet. If styles from multiple module instances have the same class selector name, it automatically adds attribute selectors for scope isolation to prevent style conflicts. For structure generation, it reads the structure template of the corresponding module instance and replaces the module instance placeholders with the unique identifiers of the actual module instances for style isolation and script access. For logic code generation, it reads the logic template of the corresponding module and performs placeholder replacement operations for module namespaces, parameter inlining, dependency references, event binding, and resource configuration. Lifecycle hook integration ensures that the generated module instance's logic code body contains complete lifecycle hook functions for initialization, startup, pause, resumption, destruction, and configuration update interfaces, and registers them with the core runtime framework's module lifecycle manager.

[0100] Furthermore, while generating the code, all art resources referenced by all module instances are collected. Based on the resource paths determined in the second module configuration data, a resource preload list is generated. This resource preload list is embedded in the main HTML skeleton template, so that key resources can be loaded first when the advertisement starts.

[0101] In some embodiments, the code generation engine also injects a dynamic configuration interface module into the generated trial ad program. This dynamic configuration interface module can report user interaction behavior data during the ad delivery process through asynchronous requests according to predefined event mapping rules. The reported events include, but are not limited to, ad exposure, trial start, core gameplay events, module configuration switching events, and final conversion events, and use this as historical interaction statistics for all gameplay logic modules to call.

[0102] Furthermore, the code generation engine ultimately outputs an HTML file containing a complete playable ad program, which can be directly uploaded to the advertising platform as a personalized playable ad.

[0103] Please see Figure 2 As shown, the present invention also provides a personalized playable ad generation system, the system comprising: First processing module 201: used to select at least one target module from a pre-set standardized gameplay module library and obtain the configuration data of the first module; The second processing module 202 is used to obtain user profile information of the target user, and adjust the configuration data of the first module based on the user profile information to generate configuration data of the second module. The third processing module 203 is used to generate personalized trial advertisements based on the configuration data of the second module.

[0104] It is understandable that, such as Figure 1 The content of the personalized playable ad generation method embodiments shown herein is applicable to the personalized playable ad generation system embodiments. The specific functions implemented by the personalized playable ad generation system embodiments are as follows: Figure 1 The method for generating personalized playable ads shown is the same as the embodiment described above, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the personalized playable ad generation method embodiment shown are also the same.

[0105] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0106] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0107] Please see Figure 3 As shown, this embodiment of the invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the personalized trial advertisement generation method as described in any of the above methods.

[0108] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0109] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0110] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0111] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the personalized play-along ad generation method as described in any of the above methods.

[0112] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / computer device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0113] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for generating personalized playable ads, characterized in that, include: Select at least one target module from the pre-built standardized gameplay module library and obtain the configuration data for the first module; Obtain user profile information of the target user, and adjust the configuration data of the first module based on the user profile information to generate configuration data of the second module; Based on the configuration data from the second module, personalized trial ads are generated.

2. The method as described in claim 1, characterized in that, The standardized gameplay module library abstracts and encapsulates gameplay into independent functional modules with standardized interfaces. Each functional module includes a logic code body, an art resource package, a module description list, and a standardized interface adaptation layer. The module description list includes module identity information, configurable parameter definitions, dependency declarations, and event interface declarations. The module identity information includes module ID, semantic version number, model type label, and relation type label; The model type tags are divided into gameplay logic modules and functional support modules according to whether an independent gameplay rule loop is defined. The gameplay logic module defines a set of gameplay rule loops, while the functional support module is a module that does not have gameplay logic itself and is used to provide supporting functions or environmental adaptation capabilities for the gameplay logic module. The relationship type label is used to describe the types of relationships that this module can establish with other modules, specifically including host type, parasitic type, independent type, and service type.

3. The method as described in claim 1, characterized in that, The step of selecting at least one target module from a pre-set standardized gameplay module library and obtaining the first module configuration data includes: The modules in the standardized gameplay module library are displayed in the module library panel in the form of a classification tree or card flow; The target module can be dragged or selected from the module library panel and placed into the canvas editing area, and then dependency verification, interface compatibility check, instantiation and configuration placeholder, and preview update can be performed. Through the instantiation and configuration placeholders, an instance node is created for each target module placed into the module library panel, and serialized into a module selection list. The module selection list includes a unique instance identifier for each module instance, a module description list for each module instance, and the topological relationship between the module instance and other module instances in the canvas. For each module instance in the module selection list, a parameter editing interface is dynamically constructed based on the configurable parameter definitions in its module description list. Parameter values ​​are selected from the parameter editing interface and mapped to the first module configuration data.

4. The method as described in claim 1, characterized in that, The step of obtaining user profile information of the target user and adjusting the configuration data of the first module based on the user profile information to generate configuration data of the second module includes: When a request to display a playable ad is received, user profile data is collected and constructed from ad request fields, ad platform data interfaces, and context environment parameters. Device performance metrics and user behavior preference tags are extracted from the user profile data, and combined with user metadata to generate user profile objects; Based on the user profile object, a dual-mode collaborative approach of rule engine and machine learning model is adopted to adapt the configuration data of the first module and generate the configuration data of the second module.

5. The method as described in claim 4, characterized in that, The rule engine has a set of judgment rules built in. Each rule is encapsulated into a rule object to form a rule library. Each rule object includes at least a rule ID, rule priority, rule description, condition expression tree, and action instruction array. The condition expression tree is the condition expression of the deterministic indicator features in the user profile object in the rule. The action instruction array is specifically a modification operation on the configuration data of the first module, including parameter overwriting, parameter range mapping, module switch control, and resource precision switching. Within the rule engine, all enabled rules are loaded from the rule base and sorted from high to low according to the rule priority to form a rule list. Based on the user profile object, the rule list is traversed to form a set of hit rules. The actions of the set of hit rules are obtained sequentially according to the rule priority, and conflict arbitration is performed to form a rule increment object. The rule increment object records its parameter change information and activation status change information using the unique instance identifier of the module instance as the key.

6. The method as described in claim 5, characterized in that, The machine learning model includes at least the following steps: The system performs two types of prediction tasks: gameplay preference and module recommendation, and parameter dynamic optimization prediction. It outputs a prediction increment object, which includes module insertion instructions and parameter adjustment instructions. The predicted incremental object and the rule incremental object are converted into standard instructions, each of which includes instruction type, instruction purpose, instruction priority, and instruction increment adjustment; The aforementioned standard instructions are arbitrated for conflicts and then encapsulated into an executable instruction set. The executable instruction set is applied to the configuration data of the first module to generate the configuration data of the second module, and a consistency check is performed simultaneously.

7. The method as described in claim 6, characterized in that, The task of predicting gameplay preferences and module recommendations should include at least the following steps: Based on the user profile object, construct the user tower feature vector and the advertising tower feature vector; Based on the user tower feature vector and the advertising tower feature vector, calculate the overall preference adaptation score and the marginal preference score for each gameplay type, where the gameplay type corresponds to the gameplay logic module; If the overall preference fit score is greater than or equal to the first preset threshold, then the module recommendation will not be triggered, and the overall preference fit score and the marginal preference score of each gameplay type will be output. If the overall preference fit score is less than the first preset threshold, then module recommendation is triggered. Based on the marginal preference scores of each gameplay type and combined with the configuration data of the first module, candidate modules are selected and an insertion module instruction is generated.

8. The method as described in claim 6, characterized in that, The task of dynamic parameter optimization prediction includes at least the following steps: Iterate through all parameters of each module instance in the first module configuration data and filter the parameters whose adaptability type is adaptable. Based on the user profile object, and the parameter name, current parameter value, and module type label of the adaptable parameter, a parameter prediction feature vector is generated for each adaptable parameter, wherein the parameter name corresponds to the business semantic category; Based on the business semantic category, determine the parameter adjustment coefficient for each adaptable parameter; Based on the parameter adjustment coefficients and the current parameter values, a final predicted value is generated, and a parameter adjustment instruction is output.

9. The method as described in claim 1, characterized in that, The step of generating personalized trial ads based on the configuration data of the second module includes: Construct a code template library, in which a template file is set for each version of each module of the standardized gameplay module library. The template file includes a structure template, a style template, a logic template, and a resource list template. Using the tuple constructed from the module ID and semantic version number of each module as the key, a template index table is generated by associating all template files of the corresponding module in the code template library. The configuration data of the second module is parsed, the array of module instances is extracted, and the corresponding template file set is searched in the template index table according to the module ID and semantic version number of each module instance. Construct a global context object, and create an instance context object for each enabled module instance in the second module configuration data; Based on the global context object and the instance context object, and combined with the main HTML skeleton template, a trial ad program is generated.

10. A personalized playable ad generation system, characterized in that, include: First processing module: used to select at least one target module from a pre-set standardized gameplay module library and obtain the configuration data of the first module; The second processing module is used to obtain the user profile information of the target user, and adjust the configuration data of the first module based on the user profile information to generate the configuration data of the second module. The third processing module is used to generate personalized trial ads based on the configuration data of the second module.

Images