Information processing method

Abstract

An embodiment of the present disclosure provides an information processing method, comprising: displaying a virtual scene, the virtual scene comprising a first virtual object set; in a manual control mode in a virtual task, determining and displaying a recommended operation sequence set according to a current scene parameter and a habit model, the recommended operation sequence set comprising at least one recommended operation sequence; in response to a selection operation on a first recommended operation sequence in the recommended operation sequence set, displaying effect prediction information of the first virtual object set based on the first recommended operation sequence.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to information processing methods. Background Technology

[0002] In task scenarios involving controllable virtual objects, two control modes are typically provided: manual control and automatic control. In the former, the user selects the operation behavior and target of the virtual object one by one; in the latter, the system executes the operation behavior sequentially according to preset fixed logic. To assist user decision-making, some applications also provide a general default operation sequence in the interface to simplify the interaction process.

[0003] However, in manual control mode, users often need to try multiple times to determine the optimal combination of behaviors, resulting in frequent sending and receiving of interactive commands and increasing the pressure on terminal data processing; the preset rules of automatic control mode are not adaptable to changing scene parameters, which can easily lead to frequent switching between modes and cause additional consumption of computing resources. Summary of the Invention

[0004] This disclosure provides an information processing method, apparatus, electronic device, and computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this disclosure, an information processing method is provided, the method comprising: displaying a virtual scene, the virtual scene including a first set of virtual objects; in a manual control mode in a virtual task, determining and displaying a set of recommended operation sequences based on current scene parameters and a habit model, the set of recommended operation sequences including at least one recommended operation sequence; and in response to a selection operation on a first recommended operation sequence in the set of recommended operation sequences, displaying effect prediction information of the first set of virtual objects based on the first recommended operation sequence.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, comprising: an interface display module for displaying a virtual scene, the virtual scene including a first set of virtual objects; an operation sequence display module for determining and displaying a set of recommended operation sequences based on current scene parameters and a habit model in a manual control mode of a virtual task, the set of recommended operation sequences including at least one recommended operation sequence; and an information display module for displaying effect prediction information of the first set of virtual objects based on the first recommended operation sequence in response to a selection operation of the first recommended operation sequence in the set of recommended operation sequences.

[0007] According to one aspect of this disclosure, an electronic device is provided, comprising: a processor, a memory, and computer program instructions stored in the memory and executable on the processor; the processor executes the computer program instructions to implement any of the above information processing methods.

[0008] According to one aspect of this disclosure, a computer-readable storage medium is provided, which stores computer program instructions that, when executed by a processor, are used to implement any of the above information processing methods.

[0009] One embodiment of this disclosure provides an information processing method, comprising: displaying a virtual scene, the virtual scene including a first set of virtual objects; in a manual control mode of a virtual task, determining and displaying a set of recommended operation sequences based on current scene parameters and a habit model, the set of recommended operation sequences including at least one recommended operation sequence; and responding to a selection operation on a first recommended operation sequence in the set of recommended operation sequences, displaying effect prediction information of the first set of virtual objects based on the first recommended operation sequence. Thus, recommending operation sequences and predicting effects based on a habit model in manual control mode helps reduce the number of times users manually intervene and switch control modes, reduces the data processing load on the terminal caused by frequently receiving control mode switching commands and recalculating execution logic, reduces redundant interaction commands, and improves interaction efficiency. Attached Figure Description

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

[0011] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this disclosure; Figure 2 A flowchart illustrating a method in one exemplary embodiment of this disclosure is shown; Figure 3 A schematic diagram of a game interface is shown in one exemplary embodiment of this disclosure; Figure 4 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0012] Exemplary embodiments of this disclosure will be described more fully below with reference to the accompanying drawings.

[0013] To enable those skilled in the art to better understand the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present disclosure.

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0016] Figure 1A system architecture diagram of the operating environment of this exemplary embodiment is shown. This system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, game console, etc., and has a display function capable of displaying a game interface, which may include the operating system interface or the application interface. An application, such as a game program, is installed on the terminal device 110. The server 120 generally refers to the backend system providing the game service in this exemplary embodiment; it may be a single server or a cluster of multiple servers. Exemplarily, a game server program is deployed on the server 120 to perform server-side game data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this disclosure can be executed by any one or more of the terminal device 110 and the server 120.

[0017] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be the system architecture described above. Various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming can be a game mode based on cloud computing. In the cloud gaming operation mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of the game's control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 120). The cloud gaming client (such as the aforementioned terminal device 110) is responsible for receiving and sending data and presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing the game, the user operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the cloud gaming client via the network, and finally, the cloud gaming client decodes and outputs the game screen.

[0018] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to implement the game function and execute the method described above.

[0019] According to one embodiment of the information processing method of this disclosure, such as Figure 2 As shown, the method may include: Step S210: Display a virtual scene, which includes a first set of virtual objects; Step S230: In the manual control mode of the virtual task, determine and display a set of recommended operation sequences based on the current scene parameters and habit model. The set of recommended operation sequences includes at least one recommended operation sequence. Step S250: In response to the selection operation for the first recommended operation sequence in the recommended operation sequence set, display the effect prediction information of the first virtual object set based on the first recommended operation sequence.

[0020] According to one embodiment of this disclosure, recommending operation sequences and predicting effects based on habit models in manual control mode helps reduce the number of times users manually intervene and switch control modes, reduces the data processing load on the terminal caused by frequently receiving control mode switching instructions and recalculating execution logic, and reduces redundant interaction instructions, thereby improving interaction efficiency.

[0021] The embodiments of this disclosure will now be further described.

[0022] In step S210, a virtual scene is displayed, which includes a first set of virtual objects.

[0023] By combining habit models and scene parameters to recommend operation sequences and preview the effects, it can not only effectively reduce the operational burden of repeated decision-making for players, but also help players evaluate tactical benefits in advance, thereby significantly improving the strategic depth and operational smoothness of manual combat.

[0024] Optionally, the first virtual object set aims to provide a group of combat units that players can directly control, serving as the main body for subsequent manual decision-making and automatic execution. Optionally, the first virtual object set can consist of one or more first virtual objects, each with independent character attributes and skill configurations. It should be noted that the first virtual objects can be offensive roles, or they can include roles with different functions such as support, control, or healing. For example, in a turn-based combat environment, the first virtual object set can include damage dealers, energy suppliers, and status buff characters, who sequentially gain operation permissions through action bars. Correspondingly, the skill slots possessed by different virtual objects and the combat resources consumed by their skills also differ, which directly determines the diversity of combo combinations. The above descriptions regarding the number and functional division of virtual objects are merely illustrative examples, and this disclosure is not intended to limit the internal composition of the first virtual object set. In actual deployment, it can be flexibly adjusted according to the game genre and level difficulty.

[0025] Optionally, the arrangement and visual presentation of the first virtual object set in the interface can be varied. As one possible implementation, the first virtual object set can be arranged in a horizontal array, with the portraits and health bars of each virtual object arranged side-by-side below the virtual scene. Alternatively, it can be presented in a circular arrangement, placing the core output unit at the geometric center and surrounding it with auxiliary units, allowing players to quickly identify the primary and secondary relationships. At the game interface level, each member of the first virtual object set can also be bound to different status indicators, such as actionable highlight boxes and control effect countdown icons. These visual elements can dynamically refresh with changes in turn phases and scene parameters.

[0026] In one implementation, such as Figure 3 As shown, Figure 3 The diagram illustrates a game interface in one exemplary embodiment of this disclosure. In response to a player initiating a virtual task, the game interface 300 of the terminal device loads and displays a virtual scene 310. The virtual scene 310 is a digital representation of a turn-based battle environment. The virtual scene 310 includes a first set of virtual objects and a second set of virtual objects. The first set of virtual objects contains at least one first virtual object waiting to act in one's own faction, such as first virtual object 3101. The second set of virtual objects contains at least one second virtual object waiting to act in the opposing faction, such as second virtual object 3102. The virtual objects are arranged in the virtual scene 310 in the form of portraits. As shown in the figure, the first set of virtual objects is located in the lower half of the virtual scene, and the second set of virtual objects is located in the upper half of the virtual scene.

[0027] In step S230, in the manual control mode of the virtual task, a set of recommended operation sequences is determined and displayed based on the current scene parameters and habit model. The set of recommended operation sequences includes at least one recommended operation sequence.

[0028] By integrating and matching real-time scene parameters with player historical habit models, the combo recommendations in manual combat are more in line with the player's style and the current battle situation, effectively reducing the decision-making burden and improving combat efficiency.

[0029] Optionally, as shown in Figure 3, the game interface 300 provides a mode switching control 302. Users can switch between manual and automatic control modes by triggering the mode switching control 301. The manual control mode is designed to receive individual manual commands from the player to control virtual objects to perform skill releases or resource allocation round by round. Optionally, the manual control mode refers to an operation mode where players need to click on their own characters one by one and select specific skill targets during each battle round. In this mode, players can completely autonomously determine the action order of each character, skill selection, and the way combat resources are consumed.

[0030] Considering that some players desire a high degree of control over the combat process, while others wish to receive intelligent system assistance on top of manual operation to reduce decision-making costs, as a possible implementation, in manual control mode, the system will provide a decision-making function switch in a designated area of ​​the game interface (e.g., the lower left corner). Players can trigger this switch to invoke their habit model and bring up a set of recommended operation sequences, thereby achieving personalized combo recommendations through human-machine collaborative decision-making while retaining the initiative of manual operation. Figure 3 As shown, the current mode is manual control by the player. The game interface 300 includes a decision function switch 303. By triggering the decision function switch 303, the player triggers the system to collect the current scene parameters in real time and inputs the current scene parameters into the constructed habit model. The habit model searches for combat records with similar scene parameters in the player's historical manual games, and then determines a set of recommended operation sequences containing at least one recommended operation sequence, and displays the set of recommended operation sequences 301 on the game interface 300.

[0031] Optionally, the manual control mode is not limited to the global settings before the start of battle; it can also be switched by the player during automatic battle. To avoid a sudden interruption of the battle rhythm and a disruptive player experience, the above mode switching can take effect at the end of the current turn or immediately before the player's designated character takes action.

[0032] Optionally, the current scene parameters may include, but are not limited to, the quantity of combat resources, virtual object attributes, or the round phase, which are dynamically determined based on the real-time battle situation.

[0033] Optionally, the current scene parameters refer to the multi-dimensional data set collected in real time by the system to depict the state of the battle at the moment the recommended operation sequence calculation is triggered. Among these, the quantity of combat resources can be represented as consumable resources required for a character to unleash skills, such as energy points or rage points; virtual object attributes can include the percentage of health, attack power, and defense status of the first virtual object, as well as the remaining health and buff / debuff status of the second virtual object; and the turn phase can distinguish between specific mechanics of the early, mid, late, or boss battle stages. Considering the rapidly changing nature of the battle, as a possible implementation, the system can perform an update scan of the current scene parameters before each character's action to ensure that the recommended operation sequence set is highly matched with the latest battle situation, thereby avoiding a disconnect between recommended combos and actual needs due to information lag.

[0034] Optionally, to improve the accuracy and response speed of the matching calculation between scene parameters and the habit model, the aforementioned current scene parameters can be assigned different weight coefficients. For example, in a low-health emergency rescue scenario, the percentage of health of friendly characters can be given the highest weight; in a fast-paced charge scenario, the order of action bars and the amount of combat resources receive higher priority. It should be noted that the above weight allocation method can be a fixed rule preset by the system, or an adaptive rule dynamically learned based on players' historical behavior data. Similarly, the sampling frequency of the current scene parameters can also be dynamically adjusted according to the combat rhythm, increasing the sampling frequency in high-intensity combat rounds and decreasing the sampling frequency in stalemate phases to save computing resources. In this way, the performance overhead of terminal devices can be effectively controlled while ensuring recommendation accuracy.

[0035] Optionally, the various sub-items in the current scene parameters often have close coupling relationships. When matching recommended operation sequences, the system needs to comprehensively consider the linkage effect of multiple parameters. For example, when sufficient energy is detected and there are multiple low-health enemy targets, the system may recommend group damage combos even if the round is in the middle stage; conversely, if energy is scarce but the round has entered the endgame, the system will prioritize recommending low-cost functional skill combinations. Based on this, the above matching process can specifically include: determining a basic matching score based on various scene parameters, determining an adjustment coefficient based on the synergistic or mutually exclusive relationships between parameters, calculating the comprehensive recommendation degree of each candidate operation sequence based on the basic score and adjustment coefficient, and generating a set of recommended operation sequences in descending order of comprehensive recommendation degree.

[0036] Optionally, the habit model is used to record and analyze players' historical decision-making tendencies to generate personalized recommendation logic adapted to the player's combat style. Optionally, the habit model is a data model generated by collecting, labeling, and statistically analyzing players' historical operation sequences in manual control mode. These historical operation sequences include not only the order in which character skills are released but also the allocation of combat resources, such as prioritizing energy for damage dealers or healers. After completing a combo, players can use tabs to tag this action with a strategy tendency, such as aggressive rush, conservative survival, or balanced. Upon receiving the tag information and corresponding scenario parameters, the system associates and stores these three elements in the historical behavior database. Considering that players' operating habits may change with game progress and faction composition, as a possible implementation, the habit model can be configured with a time decay mechanism, giving higher weight to recent operation records and gradually decreasing the weight of older records. This ensures that the model can dynamically track the player's latest decision-making tendencies and avoids recommendations remaining based on the player's early operating style.

[0037] Optionally, the strategy preference information recorded in the habit model can be automatically generated through semantic analysis of player action sequences in the system backend, in addition to being based on the player's actively selected tab labels. For example, if the system recognizes that a player repeatedly selects healing skills in a low-health situation, it will automatically assign the player a survival-first preference weight; if a player repeatedly uses high-cost burst skills to try to clear the field in one round, it will automatically increase their aggressive attack preference value. To avoid model misjudgment due to short-term emotional fluctuations or trial-and-error operations, the above automatic analysis can set a statistical threshold, updating the preference weight only after a certain number of similar actions occur in a specific scenario. One objective of this embodiment is to construct a habit model through a combination of active and passive methods, which on the one hand respects the player's explicit intentions, and on the other hand captures the implicit preferences that the player is not consciously aware of, thereby providing a more refined and comprehensive personalized recommendation service.

[0038] Optionally, the habit model should also possess a certain degree of fault tolerance and correction capabilities during automatic generation. If the system detects that a player frequently changes their tag selection in a certain scenario, or repeatedly likes and then cancels their selection, it can reduce the confidence level of short-term operations in that scenario and instead extend the observation window to obtain a more stable statistical sample. If a battle failure occurs and the failure is attributed to an automatic battle strategy executed according to the habit model, the weight of the corresponding tendency information of that strategy can be reduced, and the recommendation priority of alternative strategies can be temporarily increased. It should be understood that during the weight adjustment process of the habit model, a single failure does not necessarily lead to the complete overturning of the habit. Instead, strategy optimization is gradually achieved through gradient descent fine-tuning. This preserves the mainstream battle style that players have developed over a long period of time while reserving flexible adjustment space for version iterations or lineup changes.

[0039] Optionally, the recommended action sequence set is a comprehensive presentation of multiple combo schemes with biased classifications, output by the system after considering current scene parameters and habit models. In one implementation, the recommended action sequence set can be grouped and displayed according to three strategy categories: aggressive fast attack, conservative survival, and balanced. Each category contains a preset number of recommended action sequences, for example, displaying two candidate recommended action sequences per category. This set can be displayed in the game interface in the form of a floating window, side panel, or bottom expand bar. Its display position should avoid the main character and skill touch areas to reduce interference with normal operation. Figure 3As shown, the recommended operation sequence set 301 includes multiple strategy category labels, such as strategy category label 3001. Under strategy category label 3001, two candidate recommended operation sequences are displayed, such as recommended operation sequence 3011 and recommended operation sequence 3012. Considering the visual preferences of different players, as a possible implementation, the display of the recommended operation sequence set can support customized settings such as transparency adjustment, size scaling, or list collapse. Players can keep it permanently displayed as needed, or only pop it up after triggering the decision button.

[0040] Optionally, the first virtual object in the first set of virtual objects needs to consume combat resources (such as energy points) to release a skill, such as... Figure 3 As shown, the total combat resource information 305 is provided. The number "8 / 8" indicated by the total combat resource information 305 indicates that the maximum energy point limit of the first virtual object set is 8, and the currently available energy points of the first virtual object set are 8. The first virtual object 3101 is configured with 3 skills, which are triggered by skill controls 3040, 3041, and 3042 respectively. The skill corresponding to skill control 3040 does not consume energy points, the skill corresponding to skill control 3041 consumes 2 energy points, and the skill corresponding to skill control 3042 consumes 3 energy points. If the first virtual object 3101 releases the skill corresponding to skill control 3041, the number indicated by the combat resource information 305 is updated to "6 / 8".

[0041] The recommended action sequence includes the skill release order of the first virtual object and the information on the allocation of combat resources, which constitutes a complete action plan within a turn. For example, a recommended action sequence may include: friendly character A first consumes 2 energy points to cast skill A to add a debuff to all enemy characters; then friendly character B consumes 3 energy points to cast skill B to "revive" a defeated friendly character; next, character C consumes 1 energy point to cast skill C to attack the enemy character with the highest health; finally, character D consumes 2 energy points to deal damage to all enemy characters. In this sequence, each step not only defines the character, skill, and target of the skill, but also implicitly includes the allocation logic of combat resources (such as energy), ensuring that key characters have sufficient resources to release the target skill when they act. It should be noted that the action order of each character in the recommended action sequence can be strictly bound to the absolute order of the action bar, or conditional branches can be set according to the real-time changes in the enemy's status. For example, if the enemy's main monster has died, the subsequent single-target burst skill will be automatically transferred to the target with the second highest health, thereby enhancing the practical adaptability of the sequence.

[0042] In an optional implementation, the method further includes: responding to a sequence labeling operation on a set of recommended operation sequences to determine a target recommended operation sequence; and, in an automatic control mode within a virtual task, controlling a first set of virtual objects to automatically execute the target recommended operation sequence based on the target recommended operation sequence and a habit model.

[0043] By recording players' preferred operation sequences through sequence markers and reusing them in automatic control mode, automatic combat can not only match players' manual operation habits to reduce the sense of disjointedness, but also effectively reduce the frequency of manual intervention in repetitive combat.

[0044] Optionally, the sequence marking operation aims to receive the player's preference expression for a specific combo in the recommended operation sequence set, so as to establish that specific combo as the target recommended operation sequence to be called first in subsequent automatic control mode. Optionally, the sequence marking operation can be triggered by a single click icon, or by a secondary confirmation menu that pops up after a long press, or by a gesture operation that is completed by dragging the recommended operation sequence to a designated collection area.

[0045] Considering the high cost of shifting players' gaze during fast-paced combat, one possible implementation is to place a sequence marker control on the right or bottom edge of each recommended action sequence. Its visual presentation can include, but is not limited to, heart-shaped icons, star-shaped icons, thumbs-up indicators, or label buttons with glowing borders. When players browse the recommended action sequence set during manual combat, if they are particularly satisfied with one particular sequence (e.g., an aggressive, fast-paced sequence where the first virtual object, acting as an initiator, applies a mark skill, followed by an offensive first virtual object applying a vulnerability effect, and finally a group-attack first virtual object dealing area damage), they can trigger the marker control corresponding to that sequence, establishing that combo as the target recommended action sequence and writing it into their habit model. Subsequently, when players switch to automatic control mode in the same type of level, and the current action bar and energy level meet the trigger conditions for the target sequence, the system directly calls the marked target recommended action sequence, controlling the first set of virtual objects to automatically release skills in the order of mark → vulnerability → area damage, thus replacing the default automatic combat logic. As shown in Figure 3, a marker control is provided for each recommended operation sequence. For example, a marker control 3002 is set for recommended operation sequence 3012. The system responds to the trigger operation (such as a click operation) of the marker control 3002, and determines the recommended operation sequence 3012 associated with the marker control 3002 as the target recommended operation sequence. In automatic control mode, the first virtual object set is controlled to automatically release skills according to the recommended operation sequence 3012.

[0046] Before the player triggers the sequence marking operation, the control can be in an inactive grayscale display state; upon receiving a valid marking command, its display state immediately switches to an active state with a highlighted display, accompanied by a slight shaking or particle scattering animation effect to provide clear operation feedback. It should be noted that the above-described interaction method for the sequence marking operation is only one example, and this disclosure is not intended to limit the triggering form of this operation.

[0047] Optionally, the automatic control mode, once activated by the player, directly invokes the recommended action sequence already marked in the habit model, replacing the default logic control of the first set of virtual objects for automatic combat. Optionally, the trigger path for the automatic control mode can take various forms. For example, it can be triggered via a persistent toggle button on the game interface (such as...). Figure 3 The mode switching control 302 is activated, or it can be automatically entered by the system after the player's decision phase in the current battle round ends, or it can be switched by the system by default when the player has not manually clicked for several consecutive rounds.

[0048] Optionally, in automatic control mode, the system does not simply loop skill animations in a fixed sequence when executing the target recommended operation sequence. Instead, it can adjust the process based on the dynamic changes in real-time combat resources. Considering that abnormal states such as character being controlled, dying, or temporarily lacking energy may occur during automatic combat, as a possible implementation, the above control process can specifically include: detecting the current scene parameters before the predetermined release node; if the actual conditions do not meet the release prerequisite of a skill in the target recommended operation sequence, then according to the alternative logic recorded in the habit model or the default rollback rule, the skill is replaced with the same character's basic attack or postponed to the next skill that meets the conditions. In this way, on the one hand, the continuity of automatic combat can be guaranteed, avoiding process blockage; on the other hand, it can also maintain the player's preset strategic tendencies to a certain extent, thereby improving the stability and strategy fidelity of automatic combat.

[0049] Optionally, the target recommended action sequence is a specific skill combination scheme that is determined from the set of recommended action sequences by the player's sequence marking operation and is intended to be automatically executed in automatic control mode.

[0050] Optionally, automatic execution aims to drive each virtual object in the first set of virtual objects to release skills in sequence according to the skill release order and resource allocation information contained in the target recommended operation sequence in automatic control mode.

[0051] Optionally, the automatic execution process can be specifically manifested as follows: Following the skill node order contained in the target's recommended operation sequence, when the current virtual object's turn arrives, the system automatically locks onto the target object specified by that node and triggers skill release. Simultaneously, based on the combat resource allocation information recorded in the sequence, it allocates the corresponding amount of energy or buff items to the virtual object when needed. If the target's recommended operation sequence involves multi-turn linkage, automatic execution can also maintain state synchronization across turns. For example, if a support character applies an attack buff mark to a damage dealer in the first turn, when that damage dealer's turn arrives in the next turn, the system prioritizes their high-damage skill over a normal attack to fully replicate the combo logic designed by the player's manual operation. It should be understood that during automatic execution, if the system detects that the player has actively triggered a manual intervention command, it can immediately interrupt the current automatic execution process and switch back to manual control mode to allow the player to deal with unexpected situations. After the intervention ends, the player can choose whether to resume automatic execution.

[0052] In an optional implementation, the method further includes: obtaining a first operation sequence for a first set of virtual objects, and strategic tendency information corresponding to the first operation sequence; obtaining a first scene parameter; associating and storing the first operation sequence, the first scene parameter, and the strategic tendency information in historical behavior data; and generating a habit model based on the historical behavior data. In this way, by associating and storing the operation sequence, scene parameter, and strategic tendency to generate a habit model, not only can a data foundation reflecting the player's real decision-making patterns be established, but also subsequent automatic battles can break the fixed logic restrictions and effectively reduce the sense of disconnect between manual and automatic modes.

[0053] In one implementation, the player enters manual combat and controls multiple characters from a first set of virtual objects to sequentially release skills and allocate combat resources. The system records this process as the first operation sequence. Simultaneously, the player selects an aggressive, fast-paced attack as the strategy preference for the current combo through a tab in the game interface. The system simultaneously collects the player's remaining health and the enemy's current round buff status as the first scenario parameters. Subsequently, the system binds the first operation sequence, the first scenario parameters, and the strategy preference information and writes them into historical behavior data. After the battle ends or predetermined recording conditions are met, the system summarizes and analyzes this historical behavior data to generate a habit model, which is used to provide recommendations tailored to the player's decision-making style in subsequent similar or identical scenarios.

[0054] Optionally, the first operation sequence is used to record continuous manipulation behaviors against the first set of virtual objects in manual control mode, including at least the skill release order and combat resource allocation information.

[0055] Optionally, the continuous control behaviors recorded in the first operation sequence can take various forms. In one possible implementation, the first operation sequence includes the sequential order in which multiple virtual objects in the first set of virtual objects release skills. For example, after character A releases a mark-type skill, character B releases a skill with a vulnerability effect, and then character C releases an area-of-effect skill, thus forming a complete combo chain. Simultaneously, the first operation sequence can also cover information on the allocation of combat resources, such as the specific amount and allocation order of energy resources consumed at multiple skill release nodes, or the targeted resource deployment of single-target buff skills to specific friendly characters. It should be noted that the first operation sequence is not limited to the example containing three virtual objects; it can be dynamically adjusted according to the size of the battle lineup, ranging from a brief combination of two virtual objects to a complex multi-stage combo consisting of five or more virtual objects. By accurately recording the above operation sequences, the system can capture the player's true control intentions in specific scenarios, thereby providing fine-grained behavioral data support for the generation of habit models.

[0056] Optionally, the strategy preference information is used to characterize the combat style classification identifier chosen by the player for the first action sequence, and may include multiple strategy categories so that the action sequences can be grouped and recorded according to player preferences.

[0057] Optionally, strategic preference information can be provided to players via tabs or menus, and can include at least three basic strategy categories: aggressive rush, conservative survival, and balanced. In practice, after a player completes a first sequence of actions, a preference selection overlay appears on the game interface. Players can click the corresponding strategy tag based on the actual intent of the current combo, such as selecting aggressive rush to indicate that the combo aims to maximize damage output in a short time. Simultaneously, the system can automatically correct or supplement this strategic preference information. For example, it can add brief descriptions to each skill based on its actual effect in the first sequence, such as sub-tags like mark, vulnerability, or area-of-effect damage, thus displaying skill information to the player and allowing them to quickly identify the characteristics of the combo. It should be noted that strategic preference information is not limited to the three basic categories mentioned above; more sub-categories can be added based on game version expansions or player customization needs, such as priority control, burst damage, or sustained attrition, as long as they reflect the player's subjective positioning of the current action sequence.

[0058] Optionally, besides allowing players to manually select strategy preference information after each action, the system can also perform semi-automatic or fully automatic preference classification based on the objective characteristics of the first scene parameters and the first action sequence. As a possible implementation, if the system detects that the player's overall health is below a preset threshold in the first scene parameters, and the first action sequence contains multiple healing or defensive skills, the system can automatically classify the strategy preference information of that sequence as conservative survival without requiring manual confirmation from the player, only providing a prompt interaction after classification. Furthermore, players can also batch correct stored strategy preference information on the history page, for example, reclassifying a high-damage combo that was previously misclassified as balanced as aggressive fast attack. One objective of this embodiment is to reduce the operational burden on players during intense battles by providing multiple methods for determining strategy preference information, including manual, semi-automatic, and post-correction methods, while ensuring sufficient accuracy in the player preferences learned by the habit model.

[0059] Optionally, after strategic preference information is associated with and stored in historical behavior data, it will directly affect the subsequent habit model generation and the sorting logic of recommended operation sequences. Specifically, when a player triggers the decision-making function in manual control mode, the system can match historical behavior data according to the current scene parameters and display candidate operation sequences according to strategic preference information. For example, under the "aggressive fast attack" tag, historical combos characterized by single-target burst damage or group attrition are prioritized, while under the "conservative survival" tag, combo combinations containing healing, shields, or resurrection mechanisms are prioritized. Furthermore, the system can also count the frequency of players' likes or tags under different strategic preference information and assign higher recommendation weights to high-frequency preference categories. If it is detected that a player has frequently tagged combos under the "aggressive fast attack" tag recently, the system will correspondingly increase the execution priority of operation sequences of this strategic preference type in automatic combat mode. In other words, strategic preference information is not only a static classification label for historical behavior, but also a dynamic adjustment factor connecting players' subjective preferences and the system's automatic decision-making.

[0060] Optionally, the first scenario parameter is used to describe the state of the game environment when the first operation sequence is executed, including at least one or more of the following: the quantity of combat resources, virtual object attributes, and turn phase.

[0061] Optionally, the first scene parameters can encompass various dynamic indicators closely related to the combat rhythm. In one specific implementation, the first scene parameters include the quantity of combat resources, such as the total energy possessed by the team in the current match and the amount recovered per round; simultaneously, it can also include the first object attributes of each first virtual object in the first virtual object set, such as the percentage of remaining health, the number of stacked buffs or debuffs, and skill cooldown status. Furthermore, since the second virtual object set belongs to a different game faction than the first virtual object set, the first scene parameters can also include the second object attributes of enemy virtual objects, such as whether the enemy is in a strengthening phase where values ​​increase with each round, or whether there is an exploitable vulnerability state. It should be noted that the above description of parameter types is only one example, and the first scene parameters can be expanded according to specific game mechanics, such as including field environment effects, weather buffs, or special dungeon mechanism trigger markers, as long as they can reflect the real-time combat situation during the execution of the operation sequence.

[0062] Optionally, considering that different combinations of scenario parameters often correspond to drastically different optimal decisions, the system can also record the first scenario parameters using multi-dimensional snapshots. That is, the first scenario parameters can include not only the static values ​​at the moment the operation sequence is executed, but also the trend of state changes within a specific time window before and after the sequence's execution, such as the rate of decrease in the enemy's health over the last two rounds, or the fluctuation range of the energy consumption of friendly support characters. When generating a habit model based on historical behavior data, the system can use these multi-dimensional snapshots as a clustering basis to identify the operation patterns repeatedly taken by players in similar scenarios. For example, when the system identifies that the current scenario parameters and a historical snapshot all reach a preset matching threshold in three dimensions—friendly remaining health, enemy enhancement layers, and remaining rounds—the first operation sequence corresponding to that historical scenario parameter can be recommended as a high-priority candidate. One objective of this embodiment is to improve the accuracy of the habit model in recognizing complex battle situations by introducing scenario parameters that include trend changes, avoiding a disconnect between recommended combos and actual battle situations caused by only matching instantaneous values.

[0063] Optionally, historical behavior data is used to store multiple interconnected and integrated first operation sequences, first scene parameters, and strategy preference information, providing a data foundation for the generation of habit models. Optionally, historical behavior data can be stored in various forms at the physical storage level, such as relational databases, unstructured documents, or hybrid storage media. Its data structure includes at least operation sequence fields, scene parameter fields, and preference identifier fields. In one implementation, each time a player completes a combo and confirms their strategy preference in manual control mode, the system generates a record and writes it to the historical behavior data. This record not only saves the skill release order and resource allocation details but also marks the record generation time with a timestamp. Furthermore, to ensure that the habit model reflects the player's latest operating habits, the system can configure a time-sensitivity weight for each record in the historical behavior data. For example, records from the past week have a higher weight, while the weight of earlier records gradually decreases over time, or expired records are automatically cleaned up when there are significant numerical adjustments in the game version. In addition, historical behavior data can also have a capacity limit set. When the storage volume reaches the threshold, an overwrite update is performed based on weight or record frequency. In other words, by dynamically maintaining historical behavioral data, the system can ensure that the habit model is always generated and updated based on the player's most realistic decision preferences.

[0064] In an optional implementation, the first operation sequence includes: the skill release order for the first set of virtual objects, and information on the allocation of combat resources.

[0065] By recording the skill release order and combat resource allocation information, it is possible to fully reproduce the player's operating habits, making the habit model more in line with actual preferences, thereby improving the accuracy and personalization of automatic combat strategies.

[0066] Optionally, the skill release order is used to record the sequence in which each virtual object in the first set of virtual objects performs skill operations in manual control mode, so as to facilitate the habit model to reproduce the player's tactical logic. Optionally, the skill release order can reflect the temporal relationship formed by the player triggering the skills of different first virtual objects in manual control mode. For example, in a combat round, the player first controls the output-type virtual object at the front of the action bar to release a mark-type skill, applying a continuous damage mark to the enemy; then controls the support-type virtual object to release a vulnerability-type skill, reducing the enemy's defense; finally, controls the area-of-effect virtual object to release an area-of-effect damage skill, in order to maximize the use of the aforementioned negative status to create burst damage. It should be noted that the above skill release order is not limited to three virtual objects, and can be expanded or reduced according to the actual number of virtual objects in the first set of virtual objects. In addition, the trigger targets of each skill in the skill release order can also be flexibly changed, either targeting the same enemy virtual object for concentrated fire, or dispersing to different enemy virtual objects for multi-point suppression. By accurately recording this sequence, the system can reconstruct the player's combo strategy in subsequent recommended operation sequences, ensuring that the skill triggering logic during the automatic combat phase is highly consistent with the player's tactical intentions during manual operation.

[0067] Optionally, the combat resource allocation information is used to record the consumption, transfer, or retention of combat resources by each virtual object in the first set of virtual objects under manual control mode, so as to facilitate the habit model learning the player's resource management strategy. Optionally, combat resources can be key quantitative assets that drive skill release in a game, with energy being a prominent example. In a specific scenario, the player currently has six energy points and arranges three virtual objects to act sequentially in manual control mode: the first virtual object releases a group attack skill that consumes three energy points; the second virtual object releases a single-target buff skill that consumes two energy points, providing an attack bonus to the player's core damage dealer; the third virtual object chooses to perform a normal attack that does not consume energy due to insufficient remaining energy. In this case, the combat resource allocation information not only records the actual amount of energy consumed by each virtual object but also records the decision pattern of the third virtual object to use a normal attack instead of skill release when resources are insufficient. It should be noted that combat resources, in addition to energy, can also be represented as rage points, mana points, or other in-game resources with similar functional limitation mechanisms; this disclosure is not limited to these. The collection of the aforementioned allocation information enables the habit model to identify different coping logics of players when resources are scarce or abundant, thereby more realistically simulating the player's human decision-making during the automatic control phase.

[0068] Optionally, to prevent automatic combat from deviating from player expectations due to improper resource allocation, combat resource allocation information can also include targeted allocation records of non-consumable resources. For example, when a player controls a support-type virtual object, the combat resource allocation information can include target selection logic for single-target buff skills, such as prioritizing single-target action bar boosting effects for damage dealers with later action bars, or reserving resurrection skills for fallen units with specific tactical roles. It should be understood that this allocation information is not limited to quantitative records of numerical resources, but can also include the timing and target of key skills with cooldowns. Based on this, when generating habit models, the system can determine whether a player, when low on health, tends to concentrate resources to protect the main damage dealer or disperse resources to maintain the survival of the entire team. This strategic tendency can then be dynamically reused in automatic combat, achieving consistency with the player's manual operation logic.

[0069] In an optional implementation, the first scenario parameter includes at least one of the following: the quantity of combat resources, the first object attribute of virtual objects in the first set of virtual objects, the second object attribute of virtual objects in the second set of virtual objects, and the turn stage; wherein the second set of virtual objects and the first set of virtual objects belong to different game factions. In this way, by decomposing the scenario parameter into multi-dimensional information such as combat resources, object attributes, and turn stage, the habit model can accurately match the actual situation of the current battle, thereby effectively improving the fit between the recommended operation sequence and the real-time combat environment.

[0070] In one implementation, upon entering manual combat mode, the system detects that it is currently in the third round. The first set of virtual objects contains three characters with remaining health values ​​of 80%, 60%, and 45% respectively in their first object attributes. The second set of virtual objects contains two enemy targets with a medium defense level in their second object attributes. The current combat resource quantity is 5 points. Based on this, the habit model matches these scenario parameters with historical behavioral data to determine a set of recommended action sequences that fit the current battle situation.

[0071] Optionally, the amount of combat resources is used to represent the current amount of energy points that can be consumed, and it changes dynamically according to the skill release and resource recovery mechanism.

[0072] Optionally, the amount of combat resources can be the number of energy points that a virtual object can use to unleash skills in the current round, for example, expressed as energy points. In turn-based combat, different skills require different amounts of combat resources; for example, a single-target attack skill might consume 2 resources, while a group healing skill might consume 3 resources. When constructing recommended action sequences, the habit model must use the current amount of combat resources as a prerequisite for verification. Only when the resource reserves meet the total consumption of the entire combo will the action sequence be included in the candidate recommendation set. It should be noted that the amount of combat resources is not only affected by the natural recovery of resources in each turn, but may also generate additional recovery due to the auxiliary skills of specific virtual objects. All of the above situations should be recorded in real time during scene parameter collection.

[0073] Optionally, besides determining the feasibility of combos, the quantity of combat resources can also serve as an important dimension for strategy preference analysis. For example, if a player consistently chooses to allocate resources to offensive virtual objects rather than support virtual objects when they have 4 combat resources in multiple battles, the habit model will associate this resource allocation preference with an aggressive, fast-paced strategy. To prevent combos from being interrupted due to insufficient resources, the system also reserves a certain percentage of resource redundancy for verification during the recommendation phase. If the current resource quantity is exactly equal to the combo requirement without any buffer, the matching priority of the recommended operation sequence will be appropriately lowered, thereby enhancing the stability and fault tolerance of the automatic combat process.

[0074] Optionally, the first object attribute is used to reflect the real-time status and inherent characteristics of friendly virtual objects, serving as the basic input for battlefield situational awareness. Optionally, the first object attribute can be the real-time combat status parameters of each member unit in the first set of virtual objects, including information that dynamically changes with the battle progress, such as the current remaining health percentage and applied buffs or debuffs, as well as relatively fixed basic attribute information, such as basic attack power and basic defense power. In manual combat mode, when a player chooses to release a healing skill when facing a scenario where the health of their core damage dealer is below 30%, this action will be recorded as historical behavioral data associated with a survival-first tendency. Furthermore, in subsequent automatic combat scenarios, if the habit model detects that the health field in the first object attribute of a virtual object is again in the danger zone, it will prioritize matching and executing recommended operation sequences with healing or shield effects.

[0075] Optionally, the first object attribute may also include action speed and skill cooldown status, which together determine the virtual object's attack order in the action bar. It should be noted that the above description of the first object attribute type is merely one example, and this disclosure is not intended to limit the composition of this attribute. In actual implementation, the first object attribute can be configured differently according to different virtual roles. For example, for defensive virtual objects, the focus may be on monitoring their armor value and block rate, while for support virtual objects, the focus may be on their status resistance and energy recovery efficiency. Considering the differences in player operating habits under different team configurations, the habit model, when generating decision logic, will dynamically adjust the order of the recommended operation sequence based on the weight combination of the first object attributes of each virtual object in the current battle lineup.

[0076] Optionally, the second set of virtual objects is used to refer to enemy units as a reference for determining attack targets.

[0077] Optionally, the second set of virtual objects can be a group of enemy characters belonging to a different faction than the first set of virtual objects in a turn-based battle, such as a monster faction in a dungeon or an opponent faction in player-versus-player mode. In the battle scenario, the number of members, their formation positions, and their existence status in the second set of virtual objects directly affect the target-directing logic of skills in the recommended action sequence. When the system determines the recommended action sequence, the habit model, in addition to analyzing the behavioral tendencies of its own virtual objects, also needs to consider the real-time configuration of the second set of virtual objects to determine whether area-of-effect skills or single-target burst skills are more tactically valuable. It should be noted that the composition of the second set of virtual objects is not static. As the battle progresses, some enemy units may be defeated and leave the battlefield, while new reinforcements may join. The system will continuously track changes in the set's members to update the scene parameters.

[0078] Optionally, the second object attribute is used to describe the threat level and hit status of the enemy virtual object, supporting the evaluation of kill priority.

[0079] Optionally, the second object attribute can be various observable combat parameters of the enemy virtual object in the current round, among which the remaining health percentage is the core basis for determining whether to focus fire. For example, under an aggressive, fast-paced strategy, when the second object attribute shows that the main monster's health is at a high threshold but its defense is low, the habitual model will recommend prioritizing applying the Vulnerable Mark to the target and executing a single-target burst combo. To avoid wasting high-multiplier skills due to low enemy health, the system also introduces damage overflow detection logic during the matching process. If the theoretical damage value of the currently recommended operation sequence significantly exceeds the target's remaining health and thus its recommended priority, a more balanced resource allocation scheme will be matched instead.

[0080] Optionally, in addition to basic health and defense information, the second object's attributes can also include advanced parameters such as resistance level and skill charging status. Considering that some enemy units may enter a high-threat charging state at certain round stages, as a possible implementation method, when the dangerous charging marker in the second object's attributes is detected to be activated, the above method will temporarily increase the recommended weight of control or interrupt skills, even if the current overall strategy leans towards conservative survival. It should be understood that the second object attributes of different members in the second virtual object set are generally different, but there are also cases where the attributes are similar. In this case, the system can automatically determine the focus fire order or attack priority based on the player's historical preference for targets with similar attributes.

[0081] Optionally, the turn phase is used to identify the current time position of the battle, serving as a key parameter for recognizing tactical evolution and enemy mechanism windows.

[0082] Optionally, a turn phase can be the current turn number in the battle flow or a sub-phase within a turn, such as the initial burst phase, the mid-game attrition phase, or the endgame cleanup phase. Under different turn phases, the enemy unit's buff mechanisms may change in stages; for example, some dungeons are designed so that enemy characters gradually increase their stats as the number of turns increases. Based on this, when constructing personalized decision-making logic, the habit model will associate turn phases with the timeliness of the action sequence. For example, in the early turns, it may prioritize action sequences that accumulate resources, while in later turns, it may switch to high-output combo sequences. It should be noted that the division of turn phases is not limited to switching between integer turns; it can also be finely divided based on the number of action bar rotations or the triggering nodes of specific story events. This embodiment does not limit this.

[0083] In an optional implementation, the strategy preference information includes multiple strategy categories, and a set of recommended operation sequences is determined and displayed, including: displaying multiple sets of recommended operation sequences categorized by strategy preference information. This partitioning and displaying the recommended operation sequences by strategy category not only helps players quickly locate combo plans that match their own combat style but also effectively reduces information retrieval costs, making decision-making interactions in manual mode more efficient and orderly.

[0084] Optionally, strategy categories are used to differentiate combat tendencies, categorizing recommended action sequences by combat style for easy filtering by players.

[0085] Optionally, the above strategy categories may include, but are not limited to, combat orientations such as aggressive rush, conservative survival, and balanced. The aggressive rush category focuses on maximizing output efficiency within a limited number of rounds, and its recommended action sequences typically include high-damage attack skills and debuff skills that weaken the enemy's defense. The conservative survival category focuses on maintaining the health and combat sustainability of friendly units, and its recommended action sequences often prioritize healing skills, shield skills, or control skills that can remove negative status effects. The balanced category balances offense and defense, and its recommended action sequences typically employ alternating offense and defense or a combination of group buffs and single-target damage in skill combinations. It should be noted that each strategy category can be further subdivided into at least two lower-level implementation methods. For example, the aggressive rush category can be further divided into single-target burst combos and group attrition combos, thus providing players with more refined choices within the same combat orientation.

[0086] Optionally, in addition to the strategy categories based on combat style, strategy categories can also be divided according to the combat scenario. For example, they can be categorized by enemy unit type into focus-fire types targeting single bosses and clear-the-field types targeting multiple units in group battles. They can also be categorized by round stage into early-game burst types and late-game sustain types. In another implementation, strategy categories can be custom-named by players, who can set corresponding filtering rules. For example, players can define a combination with lifesteal and combo characteristics as the "Sustained Harvest" category. It should be understood that the above-mentioned strategy category dimensions can be used individually or in combination. For example, combining the dimensions of "aggressive fast attack" and "single-target burst" can generate a more granular composite strategy category, thereby further narrowing the recommendation range under multi-dimensional cross-classification, making the combo recommendation results more closely match the player's specific combat intentions in the current game.

[0087] Optionally, the specific category of a strategy can be determined jointly by skill semantic tags and scene parameters. The system can pre-configure at least one semantic tag for each skill; for example, skills that cause continuous damage are labeled "wearing down health," and skills that restore health to allies are labeled "restoration." Based on this, the system can automatically determine the strategy category of a recommended action sequence based on the proportion of semantic tags for each skill. Considering that players may temporarily adjust their preferences when low on health, as a possible implementation, the above classification results can also be dynamically corrected based on current scene parameters. For example, when multiple friendly units' health is detected to be below a preset threshold, even if a recommended action sequence is tagged as aggressive and fast-paced, the system can temporarily categorize it into a balanced or conservative survival-oriented recommendation list to avoid pushing combo schemes that do not meet the player's current survival needs, thereby improving the scene adaptability and fault tolerance of the decision recommendations.

[0088] In an optional implementation, after controlling the first set of virtual objects to automatically execute the target recommended operation sequence, the method further includes: if a battle failure is detected, reducing the weight of the strategy tendency information corresponding to the target recommended operation sequence. In this way, by detecting battle failure and reverting the corresponding strategy tendency weight, the repeated use of a single combo strategy in unsuitable scenarios can be avoided, enabling the automatic battle strategy to have dynamic self-correction capabilities, thereby improving the win rate and stability of subsequent matches.

[0089] In one implementation, a player had previously liked a three-stage combo under the "aggressive rush" tag. This combo involved a main damage dealer applying a mark, a support character inflicting vulnerability, and an area-of-effect attack from a damage dealer. When the system invoked this recommended combo sequence in auto-battle mode to challenge a dungeon with a turn-based progression mechanism, the aggressive combo failed to eliminate the enemy units before the critical turn due to their significantly enhanced defense and attack attributes as the number of turns increased. This resulted in the complete annihilation of the player's first set of virtual targets and a battle failure. At this point, the system detected this defeat during post-processing and automatically lowered the weight of the strategy preference information corresponding to the "aggressive rush" tag, for example, from basic priority to secondary priority. In subsequent matching of similar scenarios, the system prioritized displaying recommended combos under conservative survival or balanced preferences and pushed alternative solutions to the player, thereby preventing the player from repeatedly encountering the same difficulty due to fixed preferences.

[0090] Optionally, battle failure can be used as a feedback trigger to initiate a rollback correction of strategic preference priorities, thereby achieving dynamic iteration of the habit model.

[0091] Optionally, the aforementioned battle failure can be triggered in automatic battle mode when the first set of virtual objects is wiped out, the number of rounds is exhausted, or the mission objective is not achieved. The judgment logic is not limited to a single condition. For example, in a dungeon challenge, when all playable characters' health reaches zero, the system determines it as a battle failure. Alternatively, if the enemy's main target unit enters a designated enhancement phase and the player fails to kill it within the time limit, it can also be considered a battle failure and trigger a weight adjustment. It should be noted that the timing of the battle failure judgment can be set before or after the battle results screen is generated; this disclosure is not limited to this. To avoid misjudgments due to occasional network latency or client rendering errors, the system can also perform cross-validation by combining damage statistics and status snapshots from the battle log to ensure the accuracy of the failure judgment. Furthermore, different level types can be configured with differentiated failure judgment rules. For example, surrender settlement in competitive battles and the complete annihilation in dungeon challenges can use the same detection interface but call different threshold parameters, thereby improving the mechanism's compatibility and scalability.

[0092] Optionally, weights are used to quantify the recommendation priority of strategic preference information. Their numerical value directly determines the selection probability of the corresponding preference tag during automatic battle matching. Optionally, the aforementioned weights can be stored in the habit model in various forms such as numerical values, levels, or percentages. Their initial values ​​can be set when a player first marks the recommended action sequence under a certain preference tag. For example, the weight corresponding to the aggressive attack tag can be set to a baseline value of 100, balanced to 80, and conservative survival to 60. When a battle failure is detected, the system lowers the current value of this weight by a fixed step, such as decreasing it by ten points for each failure, until a preset lower threshold is reached. It should be noted that the calculation method of the weight is not only related to the number of defeats, but can also be comprehensively adjusted by combining the enemy attributes, round stage, and remaining combat resources in the current scene parameters. This disclosure does not limit its specific algorithm. In another approach, the weights can also be expressed as a relative order rather than an absolute value. For example, multiple strategic preference information can be arranged into a queue according to priority, and their positions in the queue can be adjusted after a defeat, placing lower-weight preferences later and higher-weight preferences earlier.

[0093] In an optional implementation, in the automatic control mode within a virtual task, based on the target recommended operation sequence and habit model, the first set of virtual objects is controlled to automatically execute the target recommended operation sequence. This includes: when the current scene parameters meet the triggering conditions of the target operation sequence, the first set of virtual objects is controlled to automatically execute the target recommended operation sequence. In this way, by setting triggering conditions to initiate automatic execution, resource misallocation or missed opportunities caused by unconditional automatic combat can be avoided, making the combo release in automatic control mode more closely aligned with real-time battle changes.

[0094] For example, in one implementation, when the system enters automatic control mode, it continuously monitors the current scene parameters. If it detects that the action order and combat resource quantity of each object in the first set of virtual objects have reached the trigger threshold recorded in the target recommended operation sequence, the target recommended operation sequence is automatically triggered, and the corresponding virtual objects are controlled to sequentially release skills and allocate resources, without requiring manual intervention from the player. Optionally, the trigger condition is used to determine the matching relationship between the current scene parameters and the target recommended operation sequence to decide whether to initiate combo execution under automatic control.

[0095] Optionally, the triggering condition can be specifically manifested as one or more of the following: combat resource threshold, virtual object action order matching degree, turn phase window, or object attribute state range. In a turn-based combat scenario, the target recommended operation sequence records a combo scheme in which several virtual objects release specific skills in sequence. The corresponding triggering condition can be set as follows: when the action bar advances to the first virtual object's turn recorded in the sequence and the current combat resource quantity is not less than the total consumption of the combo, the triggering condition is determined to be met. Furthermore, the triggering condition can also be associated with the attribute state of the enemy virtual object. For example, the target recommended operation sequence with a tendency to kill can only be triggered when the enemy's main monster's health is lower than a preset percentage. This multi-dimensional condition design, which binds resource feasibility, action sequence, and enemy state together, not only ensures the actual operability of combo release but also enables the automatic control strategy to dynamically adapt to the real-time battle situation.

[0096] In an optional implementation, controlling the first set of virtual objects to automatically execute the target recommended operation sequence includes: controlling the virtual objects in the first set of virtual objects to perform skill release and / or resource allocation operations based on the skill release order in the target recommended operation sequence and the allocation information of combat resources.

[0097] The system can accurately reproduce combo strategies in automatic combat based on skill release order and resource allocation information, reducing manual player intervention and improving the alignment and intelligence of automatic execution with player decision-making habits. In one implementation, after the player determines the target recommended operation sequence through sequence marking in the preceding steps, the system enters automatic control mode and parses the execution parameters carried in the sequence. For example, the skill release order recorded in the target recommended operation sequence is: the first virtual object releases a mark skill to apply a mark status, the second virtual object releases a vulnerable skill to increase subsequent damage, and the third virtual object releases an area-of-effect skill to trigger a combo burst; simultaneously, the combat resource allocation information carried in the sequence indicates that three energy points should be allocated to the second virtual object first to ensure the smooth release of the vulnerable skill, and the remaining energy should be allocated to the third virtual object. Based on this, the system controls the corresponding virtual objects to execute the above skill release and resource allocation operations in their respective action rounds, thereby automatically reproducing the combo strategy without requiring the player to click one by one.

[0098] Optionally, the skill release order is used to instruct the virtual objects to release skills in the correct order during the automatic control phase.

[0099] Optionally, the skill release order can be a permutation and combination of one or more virtual objects pre-configured in the target's recommended operation sequence releasing skills in sequence. It should be noted that the above description of the skill release order is merely one example, and this disclosure is not intended to limit the composition of this feature. In actual implementation, it can be dynamically adjusted according to the current round phase of the game, the survival status of virtual objects on both sides, or the player's historical selection habits during manual phases. Considering the inherent rules that may exist between the skills of different virtual objects, such as the transfer of benefits or the triggering of synergies, as a possible implementation, the above skill release order may include the first-move virtual object applying a debuff or marking skill, followed by the second-move virtual object releasing a damage skill to trigger additional effects. To avoid invalid operations in special battle situations due to strictly adhering to a fixed order, the above method can also introduce suboptimal switching logic during automatic execution. For example, when the primary target has died or is in an unselectable state, the corresponding skill is automatically redirected to the suboptimal target or the node is skipped and the next skill in sequence is advanced, thereby ensuring the flexibility and robustness of automatic combat.

[0100] Optionally, combat resource allocation information is used to configure the corresponding amount of consumable resources for each virtual object during the automatic control phase.

[0101] Optionally, the allocation information for combat resources can be reflected in the pre-recorded numerical configuration in the target's recommended operation sequence, or it can be adaptively reallocated by the system based on the current remaining total resources during the automatic execution phase. It should be noted that the allocation information for combat resources is not limited to a specific resource type; it can be energy quantity, action points, rage value, or energy bar share, etc., and can be flexibly adjusted according to different game mechanics. Considering that the total amount of combat resources available for allocation under the turn-based combat mechanism is limited, and that most high-level skills require a significant amount of resources to be successfully released, as a possible implementation method, the above allocation information can prioritize ensuring the resource supply for key output-type virtual objects, while allocating basic resources to support or control-type virtual objects to maintain the stability of the battle. Furthermore, to avoid combo interruptions or the inability to release key skills due to insufficient available resources, the system can first check whether the total resource amount meets the preset requirements of the target's recommended operation sequence before performing resource allocation operations. If a resource shortage is detected, the system will compress the resource usage of non-core skills according to preset priorities or automatically switch to low-cost alternatives, thereby improving the fault tolerance rate and game stability of automatic combat.

[0102] In an optional implementation, the method further includes: generating a first operation sequence in response to a first skill operation on a first virtual object in a first set of virtual objects, and a second skill operation on a second virtual object. This not only accurately reproduces the player's manual skill release and target selection logic, providing a high-fidelity data source for the habit model, but also ensures that subsequent automatic combat strategies remain highly consistent with the player's actual decision-making habits.

[0103] In one implementation, during the manual operation phase of turn-based combat, the player first clicks on an offensive character in their own formation to select that virtual object, providing the character's corresponding skill bar. Then, the player selects a high-damage active skill from that character's skill bar, forming the first skill operation targeting that character. Next, the player clicks on the enemy's front-row leader unit, forming the second skill operation targeting a second virtual object. In response to these consecutive input events, the system maps the skill release command and target selection command together as a set of action nodes in the first operation sequence. Furthermore, if the player continues to select a group healing skill for a healing character and targets all allies, the system will also add this continuous process to subsequent nodes in the same first operation sequence.

[0104] Optionally, the first skill operation is used to receive skill trigger instructions for friendly virtual objects to determine the casting character and skill type for the current round.

[0105] Optionally, the first skill operation can be a skill selection command triggered by the player in manual combat mode for a specific allied character within the first set of virtual objects. Considering that manual combat requires precise reproduction of the player's casting intent, as a possible implementation, during the player's turn, the player clicks on the attacking character's portrait on the top left of the interface to select the virtual object, and then selects the third active skill from the skill bar that pops up at the bottom of the screen. At this point, the system captures a first skill operation, which at least includes the caster's character identifier and the identifier information of the selected skill. For example, the first skill operation is not limited to direct damage skills, but can also include shield skills that provide defensive buffs to teammates, debuff skills that stack marks on subsequent attacks, or special mechanism skills that summon support units. It should be noted that the above description of skill types is only one example. In actual implementation, the same character can be configured with one or more active skills, and players can also achieve multi-stage skill combos by continuously initiating multiple first skill operations on the same character. This disclosure is not intended to limit this.

[0106] Optionally, the second skill operation is used to receive target-specified instructions for enemy virtual objects, in conjunction with the first skill operation to complete combat interaction recording. Optionally, the second skill operation can be a target lock or skill effect targeting of a second virtual object in the enemy camp by the player in manual combat mode. Considering the differences in the activation logic of different skills, as a possible implementation, when the player controls their own offensive character to prepare to release a single-target burst skill, the enemy units on the interface will enter a selectable highlighted state. The player clicks on the leader-level virtual object located in the center of the enemy formation, and the system recognizes this selection as a second skill operation, and packages the unique identifier of the enemy target together with the casting information in the first skill operation into an operation node. That is to say, if the first skill operation is a group attack that does not require target selection, the second skill operation can also be manifested as marking the enemy's overall formation, or the system can automatically record the enemy unit with the highest attack priority as the second virtual object. It should be noted that the second skill operation not only carries the target-specifying function of skill release, but also provides direct underlying data support for analyzing the player's focus fire preference and attack order preference when generating habit models later.

[0107] Optionally, the second virtual object is a member character in the enemy camp, and is recorded in the first operation sequence as the recipient object of the second skill operation.

[0108] Optionally, the second virtual object can be any virtual character from the enemy faction with different roles, such as a high-health boss monster, a support enemy unit with healing abilities, or an agile assassin with high evasion. In practical applications, when a player controls their character to release a single-target skill using the first skill, they must explicitly designate a second virtual object as the recipient of the skill. The system will then write the virtual object's character ID, current health percentage, and its position coordinates within the enemy formation into the operation node. Furthermore, considering the significant differences in enemy lineups across different dungeons or competitive scenarios, the identity of the second virtual object is not fixed. As a possible implementation, the system can also reorder enemy units based on their real-time threat level, and recommend the virtual object with the highest threat level as the priority candidate for the second skill operation, allowing players to quickly confirm their choice. It should be noted that the above description of the second virtual object type is for illustrative purposes only. In actual gameplay, the number, attributes, and distribution of the second virtual objects can be dynamically configured according to the level design. This disclosure is not intended to limit the specific presentation form of the second virtual object. As long as it belongs to the set of virtual objects that are in the opposite camp to the set of first virtual objects, it should fall within the protection scope of this disclosure.

[0109] In an optional implementation, a set of recommended operation sequences is determined and displayed based on current scene parameters and habit models. This includes: determining at least one candidate operation sequence from historical behavior data based on the matching relationship between the current scene parameters and historical scene parameters in historical behavior data, and displaying at least one candidate operation sequence as a set of recommended operation sequences. In this way, by comparing the current game situation with scene parameters in historical records, it is possible to review the player's past decision-making strategies in similar situations, making the recommended combos more aligned with personalized combat habits and effectively improving the accuracy and consistency of manual decision-making recommendations.

[0110] In one implementation, in the current battle round, the player's side has 3 action resources, and the first three characters on the action bar are virtual objects A, B, and C. The enemy leader's health is between 50% and 70% and it carries a shield. The terminal matches the current scenario parameters with historical scenario parameters in historical behavior data. It retrieves past matches in the history records where the player's side had 3 action resources and the enemy carried a shield. It determines the candidate action sequence used by the player in that historical scenario as follows: virtual object A releases a shield-breaking skill, virtual object B releases a buff skill, and virtual object C releases a finishing skill. This candidate action sequence is then displayed as the first record in the recommended action sequence set on the decision panel.

[0111] Optionally, historical scene parameters are used to characterize the state information of the environment in which virtual objects were located in previous matches. This may include, but is not limited to, data such as the quantity of action resources, virtual object attributes, and turn phase. Optionally, historical scene parameters are used to record the environmental state of each segment of the match during the player's initial manual combat. This may include the remaining quantity of action resources, the percentage of health of allied virtual objects and their buffs or debuffs, the health range and special shield layers of enemy virtual objects, and the current turn number or combat phase indicator. Considering that players' decision-making logic often exhibits certain regularities and repetitive tendencies when facing similar resource conditions and enemy / ally lineups, as a possible implementation method, the collection dimensions of historical scene parameters can be dynamically adjusted according to the combat progress. For example, in the early stages of combat, the focus could be on recording the total amount and consumption rhythm of action resources, while in the mid-to-late stages, the focus could be on recording the survival status of key allied virtual objects and the threat level of enemy core targets. It should be noted that the above description of the specific dimensions of historical scene parameters is only one example, and this disclosure is not intended to limit its composition. In actual implementation, it can be adaptively added or subtracted according to the complexity of the turn-based combat strategy.

[0112] Optionally, the matching relationship is used to establish a similarity association between the current game state and previously stored data. Different comparison rules can be set based on differences in parameter types. Optionally, considering that the parameters of the current scene and historical scene may dynamically fluctuate in numerical dimensions, the determination of the matching relationship can be set as a multi-condition weighted comparison mechanism. Specifically, the above processing may include: calculating the absolute value of the error between the current number of action resources and the historical number of action resources, the deviation rate between the current percentage of enemy virtual object health and the corresponding percentage of enemy health in the historical record, and the degree of match between the current action bar order and the historical action bar order; calculating a comprehensive similarity score based on the pre-configured weight coefficients of each dimension, and determining a successful match when the score exceeds a preset threshold. It should be noted that the weight coefficients of each dimension can be dynamically adjusted according to the specific battle mode. For example, in dungeons emphasizing quick kills, the matching weight of action resource holdings and output skill availability can be increased; in dungeons emphasizing survival and endurance, the matching weight of the health status of friendly virtual objects can be increased, thereby achieving differentiated recommendation logic under different strategic tendencies.

[0113] Optionally, candidate operation sequences are past operation records that meet matching conditions and are filtered from historical behavior data. They can be sorted according to recommendation priority and integrated into the recommendation set. Optionally, candidate operation sequences can be complete combo records directly extracted from historical behavior data, which not only include the skill release order of each virtual object, but also the combat resource allocation information in that historical match. For example, in a specific historical scenario, action resources are prioritized for the virtual object at the front of the action bar to release shield-breaking skills, and the remaining resources are allocated to the next virtual object to release buff guidance. It should be noted that there can be one or more candidate operation sequences. When there are multiple sequences, they can be sorted in descending order according to the matching score with the current scenario parameters, or according to the combat benefits obtained by the player after executing the operation sequence in a previous match. The above sorting criteria for candidate operation sequences are only one example. In actual implementation, the weight of strategy preference information can also be dynamically adjusted. For example, if a player has recently frequently favored aggressive fast-attack combos through marking operations, the recommendation priority of such candidate operation sequences can be appropriately increased.

[0114] In step S250, in response to the selection operation for the first recommended operation sequence in the recommended operation sequence set, the effect prediction information of the first virtual object set based on the first recommended operation sequence is displayed.

[0115] This allows players to intuitively understand the expected combat effect before executing combo plans, effectively reducing the resource consumption of decision-making trial and error, and thus significantly improving the strategic depth and operational certainty of manual combat.

[0116] For example, players can select the first combo under the "Aggressive Quick Attack" tag from the recommended action sequence set. In response to this selection, the game interface immediately displays an estimated damage range in a floating window above the target enemy character involved in the combo, such as a value of "8500-9200" calculated based on the current energy and skill multiplier. This range is partially covered by a semi-transparent red phantom to visualize the estimated damage, thus providing players with an intuitive basis for deciding whether to adopt the combo. Figure 3 As shown, for example, the selection operation (such as the click operation) performed on the first recommended operation sequence 3011 displays the effect prediction information of the first virtual object set based on the first recommended operation sequence 3011. The effect prediction information can be a damage prediction value range, which integrates combo bonus, skill multiplier and enemy defense reduction factors, so that the player can intuitively predict the actual combat benefit of the combo without actually consuming combat rounds.

[0117] Optionally, the effect prediction information aims to quantify and estimate the selected recommended operation sequence, and output the combat benefit reference in a visual form on the game interface. Optionally, the effect prediction information can be a numerical estimate of the quantified combat result produced after the first set of virtual objects completes the skill release according to the first recommended operation sequence. Specifically, it can be at least one of the following: damage prediction value, healing prediction value, or skill additional effect trigger determination prediction. Considering that players need to decide whether to adopt a combo within a limited time in manual combat, the above effect prediction information can be presented directly above or beside the target character on the game interface as a floating label. For example, when an attack combo is selected, the estimated damage range is displayed above the enemy virtual object. This range can be calculated in real time by comprehensively considering the current amount of combat resources, skill multiplier, character attack attribute, and the enemy's current defensive status. In terms of presentation, in addition to pure numerical display, auxiliary visual elements such as health bar preview shadows, dynamic text display of damage numbers, or indication of remaining combat resources can be used. On the one hand, this helps players quickly grasp the upper and lower limits of the benefits of combos. On the other hand, it allows players to have a clear expectation of the consequences of their actions before officially consuming combat rounds, thereby effectively reducing the risk of wasting combat resources or making tactical mistakes due to blindly releasing skills.

[0118] Optionally, the selection operation aims to trigger a confirmation command for a recommended operation sequence, thereby retrieving and outputting the corresponding effect prediction information. Optionally, the selection operation can be a click-based interaction command executed by the player in the game interface for a specific combo from the set of recommended operation sequences. It should be noted that the above selection operation is fundamentally different from simple interface browsing; it usually signifies that the player has initially expressed an intention to adopt the recommended operation sequence, thus triggering the system to load the corresponding effect prediction calculation logic in the background. In practical applications, this selection operation is configured such that after a single click, the list item containing the selected recommended operation sequence will display a highlighted border or a changed background color, while the game interface displays a preview of estimated damage or healing values ​​in a floating window above the target enemy character or in the center of the interface. In another possible implementation, when a recommended operation sequence is selected, the remaining unselected combo options can be temporarily weakened or collapsed to focus the player's attention on the selected combo and its effect prediction, reducing interface information interference and facilitating a quick transition from browsing recommendations to previewing effects.

[0119] In an optional implementation, the method further includes: controlling a first set of virtual objects to simulate the execution of a first recommended operation sequence in a manual control mode within a virtual task; wherein the simulated execution does not occupy actual combat rounds. This allows players to preview combo effects without loss of quality before making a move, preserving the integrity of actual combat rounds while significantly reducing the cost of decision-making trial and error, and improving the efficiency of in-game strategy verification.

[0120] In one implementation, the player is in manual control mode and has selected the first recommended operation sequence. At this time, the pre-play control in the game interface is triggered, and the system controls the first set of virtual objects to simulate the execution of the skill release order and combat resource allocation logic in the sequence in the local sandbox. The entire simulation process runs based on the snapshot data of the current combat state. The enemy target only displays the predicted value and the actual attributes do not change. The entire simulation process does not count the action count consumption of the current round. After the simulation is completed, the interface automatically restores to the decision state before the trigger for the player to reselect or confirm the execution.

[0121] Optionally, the simulation can be used to preview the combat effects of recommended action sequences in manual control mode to assist players in making combat decisions.

[0122] Optionally, the above simulation can be initiated after the player triggers the pre-play function in the interface, such as... Figure 3The recommended operation sequence set 301 can be configured with a pre-play control 3003, which can be clicked by the player to trigger the pre-play function. Specifically, the system reads a snapshot of the current battle scene. This snapshot includes at least the character attributes, combat resource quantity, and current round count of the first and second virtual object sets. The snapshot may also include temporary state information such as scene buffs / debuffs and field effects; this disclosure does not intend to limit its composition. Based on this snapshot, the system, in the local computing environment, drives the corresponding virtual objects to execute skill animations and calculates predicted effects, such as predicting damage range or healing amount, according to the skill release order and combat resource allocation information recorded in the first recommended operation sequence. It should be noted that this execution process is entirely completed in the local preview layer without writing to the actual battle state, allowing players to repeatedly compare the expected benefits of different recommended operation sequences without consuming actual rounds, thus making decisions more suitable for the current battle situation. Furthermore, if the player is not satisfied with the current preview result, they can directly interrupt the simulation and switch to another recommended operation sequence for previewing again; the entire switching process does not affect the actual battle progress.

[0123] Optionally, the triggering method and presentation format of the simulation execution can be flexibly set according to terminal performance or player preferences. As one possible implementation, the simulation execution can be presented by playing combo animations within a full-screen semi-transparent overlay, with the original combat screen retained below the overlay as a reference. Alternatively, a separate preview window can be opened next to the combat scene, playing the complete combo flow at an accelerated speed. Players can choose one presentation method based on their viewing habits. Considering the long animation duration of some combos, the system can also support segmented simulation, allowing players to intervene at the simulation execution pause point to view the current accumulated effects before deciding whether to continue simulating subsequent skills. This avoids long animations disrupting the player's decision-making rhythm and also gives players the possibility to review complex combos midway. Furthermore, segmentation points can be automatically set after key skills where resource allocation changes, allowing players to focus on verifying whether the consumption and gains of combat resources match expectations.

[0124] Optionally, to ensure that simulation execution does not consume actual combat rounds, the system can maintain a simulation state space in memory, isolated from the actual combat state. Specifically, when a player selects the first recommended action sequence and initiates a simulation, the system copies the current combat state vector to the simulation sandbox. This state vector records not only explicit parameters such as the health and energy of each virtual object, but also the action bar progress and the remaining rounds of buffs and debuffs. During simulation execution, all attribute changes caused by skill releases only apply to this sandbox instance; if the player abandons the recommended action sequence after the preview ends, the sandbox data is directly discarded, and the actual combat progress and round count are unaffected. It should be understood that this isolation mechanism can also be extended to support multi-threaded parallel computing, allowing players to continue adjusting the simulation parameters of other candidate sequences while previewing the first recommended action sequence, such as adjusting skill release targets or changing resource allocation order, thereby further improving decision-making efficiency and shortening the overall decision-making time.

[0125] Optionally, not occupying actual combat rounds aims to isolate simulation execution from the actual combat process to avoid pre-action actions consuming official action counts.

[0126] Optionally, the fact that it does not occupy actual combat rounds means that the round counter and action order table of the current battle remain frozen throughout the entire simulation of the first recommended action sequence. Specifically, regardless of how many virtual object skill release actions are included in the previewed combo, the round phase in actual combat will not be advanced as a result, and the first set of virtual objects will retain its original action order and skill cooldown state after the simulation preview. It should be noted that this technique can also be applied to preview scenarios of cross-round combos. For example, if a recommended action sequence is expected to complete resource allocation and skill combos (skill combination skills refer to the combination of multiple skills in a specific order or strategy to achieve a multiplicative effect) within two consecutive large rounds, the system will only map its predicted values ​​during simulation execution without triggering the actual round switching logic. In this way, players can evaluate the feasibility of long-term tactical plans without loss of control of the rhythm or missing the best opportunity to act due to preview behavior; at the same time, the system can seamlessly continue the actual combat process after the preview ends without needing to correct or compensate for the completed actual combat data.

[0127] In an optional implementation, the recommended operation sequence is simulated, including: the release process of the first recommended operation sequence is played step by step in the game interface.

[0128] By presenting the skill release sequence in a step-by-step demonstration environment without consuming the actual game progress, players can intuitively predict the stage benefits and final performance of combos, thereby effectively reducing decision-making costs and increasing the certainty of combat strategies.

[0129] In one example, a player enters a round in manual control mode, selects the first recommended action sequence under the "Aggressive Attack" preference label, and triggers the corresponding [Preview] control. The system then loads an independent simulation layer on the current screen that does not occupy an actual combat round. Starting from the beginning of the action bar, the system plays the skill release process step by step according to the skill release order recorded in the first recommended action sequence: First, it displays the animation effect of the first virtual object applying a mark debuff to the enemy's main target, and the predicted control success rate value appears above the target's head simultaneously; then it switches to the second virtual object releasing a single-target high-multiplier damage skill, and the estimated damage range value is displayed in the damage display area; finally, it presents the complete animation of the third virtual object launching an area-of-effect damage skill. After each step, the player can click the [Pause] control to freeze the screen to observe the cumulative benefits of the current stage in detail, thereby fully predicting the actual performance of the combo plan.

[0130] Optionally, the above-mentioned step-by-step playback sequentially displays the skill release process, allowing players to observe combo connections and stage benefits without consuming real turns.

[0131] Optionally, considering that players need to quickly understand the execution logic and final benefits of combos within a limited turn decision time, the aforementioned step-by-step playback can be performed in the main battle scene of the game interface. Specifically, the system can trigger the corresponding skill release animations sequentially according to the skill release order recorded in the first recommended operation sequence, based on the arrangement of each virtual object on the action bar. Each step of the playback can generate corresponding skill effects near the model of the currently executing character, and simultaneously display combat effect information such as the predicted damage value, predicted healing value, or predicted control success rate value of that step on the hit target. During the above process, the game interface can generate a time progress indicator at the bottom or side edge of the screen to indicate which step is currently being played and how many steps are included in total, thereby helping players establish a clear expectation of the overall combo duration. It should be noted that the switching between each step of the aforementioned step-by-step playback can be automatically advanced by the system's default fixed interval time, or it can enter a pause state after each step ends and wait for the player to trigger the next control before continuing; this disclosure is not limited to this.

[0132] Optionally, the release process is used to define the complete action chain of skill release, including the timing combination of skill selection, target locking, and effect settlement.

[0133] Optionally, the release process can be a standardized demonstration script generated for a predefined skill combination in the first recommended operation sequence. In one implementation, the release process can be organized strictly according to the skill release order of each virtual object, that is, first determine the virtual object that takes the first action and its first skill to be released, and then determine the triggering time of subsequent virtual objects and their associated skills in sequence; wherein, if a skill contains multiple attacks or continuous effects, the release process can be further divided into an initial trigger segment, a continuous effect segment, and a final settlement segment, and presented in sequence according to the above sub-stages during the step-by-step playback. Considering the logic of bonus stacking or state association between different skills, the above release process can also incorporate the connection waiting time between skills during the arrangement, to ensure that the vulnerable mark or debuff applied by the preceding skill can be judged before the subsequent skill hits, thereby ensuring the accuracy of the calculation of the pre-show benefit information. In addition, if it is detected during the step-by-step playback that a certain step cannot be executed as originally planned due to insufficient combat resources or the target being killed, the release process can adaptively skip the step or replace it with a preset alternative action, and provide a prompt in the game interface to avoid players making misjudgments due to idealized demonstrations.

[0134] Optionally, the game interface is used to visually present the preview content, and can be the entire or partial display area of ​​the user interface.

[0135] Optionally, when the game interface gradually plays the release process of the first recommended operation sequence, the display parameters can be dynamically adjusted according to the layout of the current battle scene. For example, in landscape mode, the main battle view of the game interface usually occupies the central area of ​​the screen, while the preview controls of the recommended operation sequence can float or be nested on the blank edge of the main battle view to avoid obscuring key enemy status information. In another approach, if the current match involves complex factional combat and dense battlefield information, the system can also divide the game interface into multiple logical sub-areas. The first sub-area is used to maintain the real-time state of the original battle screen, while the second sub-area is specifically used to gradually play the release process. The two sub-areas can be visually distinguished by a semi-transparent overlay or a highlighted border. It should be understood that during the release process, the game interface can also respond to the player's touch operations to adjust the playback speed, pause, or rewind specified steps. The receiving area of ​​the above interactive commands can cover the entire screen or be limited to the virtual control panel pre-set in the game interface; this disclosure does not impose any limitations on this.

[0136] In an optional implementation, the effect prediction information includes at least one of the following: damage prediction value, healing prediction value, or control success rate prediction value. Thus, by providing multi-dimensional predictions of damage, healing, and control success rate during the rehearsal phase, players can comprehensively assess the overall benefits and risks of combos, thereby making more accurate operational decisions based on the current battle situation.

[0137] For example, in manual combat mode, if a player selects the first recommended combo under the "Aggressive Quick Attack" tab, the system will immediately display the predicted damage value of that combo near the enemy virtual object. If the combo includes a healing skill, the predicted healing value will be displayed simultaneously next to a friendly virtual object with low health. If it includes a control skill, the predicted control success rate will be displayed on the target virtual object, allowing the player to predict the overall combat effect of the combo before entering the actual combat round. Optionally, the damage prediction value can be used to quantify and display the estimated attack effect of the recommended operation sequence on virtual objects in the game interface.

[0138] Optionally, the damage prediction value can be comprehensively estimated based on the skill multipliers and combo bonus coefficients of the virtual objects involved in the recommended operation sequence, as well as the amount of combat resources in the current scene parameters, and presented in the form of a numerical range on the game interface. For example, when a player selects a combo scheme composed of multiple virtual objects, the system calculates the total damage range that the combo may cause to a specified enemy virtual object based on the base damage parameters and synergy bonuses of each skill in the scheme, and generates a corresponding floating window above or next to the enemy virtual object, dynamically displaying the damage prediction value in red font or as a progress bar.

[0139] Optionally, the damage prediction value can include not only single-target damage estimates against a single enemy virtual object, but also area-of-effect damage predictions against multiple enemy virtual objects. Considering the differences in enemy formation distribution, the aforementioned area-of-effect damage prediction can be further subdivided into full-damage zones and attenuated damage zones, and displayed differently in the game interface using various visual markers. For example, during the preview phase, when the recommended combo includes an area-of-effect attack skill, the system can mark all enemy targets affected by that skill on the battlefield and display the corresponding predicted damage value for each target.

[0140] Optionally, the healing prediction value is used to display the estimated amount of health that your virtual character will recover after executing the recommended action sequence in the game interface. Optionally, the healing prediction value can be calculated based on the base recovery amount of the healing skills included in the recommended action sequence, the current percentage of lost health of the virtual character being healed, and any potential healing buffs. Considering that players often need to balance damage output and survival in the late game, when the recommended combo includes healing skills, the system can display the corresponding healing prediction value for your endangered virtual character in the preview screen. This value is presented around the virtual character in green font or with a health recovery icon and numbers, helping players intuitively judge whether the combo can effectively prevent the character from dying. Furthermore, if there is a healing effect that lasts for multiple rounds, the healing prediction value can also be displayed in stages to indicate the short-term and long-term survivability of the combo.

[0141] Optionally, the control success rate prediction value is used to display the estimated probability of the recommended operation sequence and the control skill hitting the enemy virtual object in the game interface.

[0142] Optionally, the predicted success rate of control can be comprehensively determined by combining the hit attribute of the virtual object releasing the control skill, the resistance attribute of the target enemy virtual object, and the possible buffs or debuffs in the current round. In one implementation, when the recommended combo includes control skills such as freeze, stun, or silence, the system can display a percentage value floating above the target enemy virtual object during the pre-release process to represent the estimated probability that the control effect can successfully restrict the target's actions. To avoid players misjudging probabilistic results, the percentage value can also be divided into regions based on color intensity or icon shape. For example, values ​​above 70% are displayed as a stable control range, and values ​​below 30% are displayed as a low-probability attempt range, thereby guiding players to consider both the stability of control and tactical benefits when choosing combos.

[0143] By subdividing the effect predictions into damage, healing, and control success rates, players can not only intuitively compare the effectiveness differences of different combos during the pre-play phase, but also effectively reduce decision-making costs and enhance strategy consistency.

[0144] For example, when a player selects a recommended combo from the Aggressive Attack tab in manual combat mode, the game interface can display a damage prediction range as a floating numerical bar above the enemy virtual object's head (e.g., estimating that this combo can deal 12,000 to 15,000 damage). If the player switches to the Conservative Survival tab and selects a combo that includes a healing skill, the system can display the healing prediction value next to the player's low-health unit (e.g., expecting to restore 4,800 health points). When the combo includes control mechanisms such as taunt or stun, the game interface can also mark the control success rate prediction value on the edge of the target object (e.g., displaying that the probability of the control taking effect is 75%), thereby helping the player quickly assess the feasibility of the combo from multiple dimensions.

[0145] Optionally, the damage prediction value is used to quantify and display the combo damage result by combining skill multipliers and enemy defensive status. The damage prediction value can be estimated by combining multiple factors, including the attack power attribute of the currently acting character in the first set of virtual objects, the base damage multiplier of the selected skill, the defensive attribute of the target virtual object, and the buffs or debuffs currently in effect. As one possible implementation, the prediction value can be presented as a fixed value (e.g., a single attack is expected to cause 3,500 points of damage) or as a floating range (e.g., a damage range between 2,800 and 4,200 points), thus balancing the display requirements of certainty and fluctuation range. It should be noted that the above estimation not only considers the panel value but also incorporates dynamic factors such as combo bonuses and attribute advantages, making the prediction result closer to the actual combat performance.

[0146] Optionally, the predicted healing value is used to pre-estimate the amount of recovery by combining the healer's attributes and the recipient's status, and then display it on the interface. The predicted healing value can be calculated based on the caster's base healing amount, skill level coefficient, the recipient's current lost health percentage, and any healing buffs or debuffs present in the scene. In one specific way, the predicted value can be directly displayed as the expected recovery amount for a single heal (e.g., an estimated recovery of 4200 health points), or it can be visualized as a green floating number above the target virtual object's head, along with a pre-increased brightness of the health bar. Furthermore, to prevent players from over-relying on fixed values ​​and making misjudgments, the system can also add a floating range indicator next to the predicted value (e.g., the actual recovery amount fluctuates within a range of plus or minus 15 percent of the predicted value), thereby enhancing the accuracy of the pre-healing information.

[0147] Optionally, the control success rate prediction value is used to show players the expected probability of the control skill taking effect on the target before releasing it, thereby reducing the risk of blind operation. The control success rate prediction value can be dynamically calculated by combining the spellcaster's effect hit rate attribute, the target virtual object's effect resistance attribute, the number of control immunity stacks accumulated in the current round, and the historical effectiveness record of this type of control skill in this battle. For example, the system can attach this probability to the target object in the form of a percentage pie chart in the preview interface (e.g., showing a base success rate of 65%, and a final success rate of 52% after attribute adjustment), and indicate the risk level with a red-yellow gradient. It should be noted that for specific targets with an uncontrollable state, this prediction value can be forcibly reset to zero or replaced with a special symbol (e.g., a gray lock icon) to avoid players executing ineffective control combos.

[0148] According to one embodiment of the present disclosure, the information processing apparatus may include: The interface display module is used to display a virtual scene, which includes a first set of virtual objects; The operation sequence display module is used to determine and display a set of recommended operation sequences in the manual control mode of a virtual task, based on the current scene parameters and habit model. The set of recommended operation sequences includes at least one recommended operation sequence. The information display module is used to respond to the selection operation of the first recommended operation sequence in the set of recommended operation sequences and display the effect prediction information of the first virtual object set based on the first recommended operation sequence.

[0149] In this way, recommending operation sequences and predicting effects based on habit models in manual control mode helps reduce the number of times users manually intervene and switch control modes, reduces the data processing load on the terminal caused by frequently receiving control mode switching commands and recalculating execution logic, and reduces redundant interaction commands, thereby improving interaction efficiency.

[0150] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0151] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0152] The following is for reference. Figure 4The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 4 The electronic device 400 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0153] like Figure 4 As shown, the electronic device 400 may include: a processor 410, a memory 420, a bus 430, an I / O (input / output) interface 440, a network adapter 450, and a display 460.

[0154] Memory 420 may include volatile memory, such as RAM 421 and cache unit 422, and may also include non-volatile memory, such as ROM 423. Memory 420 may also include one or more program modules 424, such program modules 424 including, but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 424 may include the modules in the above-described device.

[0155] Processor 410 may include one or more processing units, such as: AP (Application Processor), modem processor, GPU (Graphics Processing Unit), ISP (Image Signal Processor), controller, encoder, decoder, DSP (Digital Signal Processor), baseband processor and / or NPU (Neural-Network Processing Unit).

[0156] The processor 410 can be used to execute executable instructions stored in the memory 420 to perform the methods described above in this disclosure, such as the following method steps: an information processing method in a game, the method comprising: displaying a functional system interface in the game, the functional system interface at least partially obscuring the game scene; in response to detecting a hit event of a controlled virtual object in the game scene, acquiring game information associated with the hit event; and displaying visual cues corresponding to the game information in the functional system interface.

[0157] Bus 430 is used to connect different components of electronic device 400 and may include a data bus, an address bus and a control bus.

[0158] Electronic device 400 can communicate with one or more external devices 500 (such as keyboard, mouse, external controller, etc.) through I / O interface 440.

[0159] Electronic device 400 can communicate with one or more networks via network adapter 450. For example, network adapter 450 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 450 can communicate with other modules of electronic device 400 via bus 430.

[0160] Electronic device 400 can display a graphical user interface, such as virtual scenes or virtual characters, through display 460.

[0161] although Figure 4 Other hardware and / or software modules may also be configured in the electronic device 400, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0162] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0163] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. An information processing method, characterized in that, The method includes: Display a virtual scene, wherein the virtual scene includes a first set of virtual objects; In the manual control mode of the virtual task, a set of recommended operation sequences is determined and displayed based on the current scene parameters and habit model. The set of recommended operation sequences includes at least one recommended operation sequence. In response to the selection operation of the first recommended operation sequence in the set of recommended operation sequences, the effect prediction information of the first virtual object set based on the first recommended operation sequence is displayed.

2. The method according to claim 1, characterized in that, The method further includes: In response to a sequence labeling operation on the set of recommended operation sequences, a target recommended operation sequence is determined; In the automatic control mode of the virtual task, the first set of virtual objects is controlled to automatically execute the target recommended operation sequence according to the target recommended operation sequence and the habit model.

3. The method according to claim 1, characterized in that, The method further includes: Obtain a first operation sequence for the first set of virtual objects, and policy preference information corresponding to the first operation sequence; Obtain the parameters of the first scene; The first operation sequence, the first scenario parameters, and the strategy preference information are associated and stored in historical behavior data; Based on the historical behavioral data, a habit model is generated.

4. The method according to claim 3, characterized in that, The first operation sequence includes: The skill release order and combat resource allocation information for the first set of virtual objects.

5. The method according to claim 3, characterized in that, The first scene parameters include at least one of the following: The quantity of combat resources, the first object attribute of virtual objects in the first set of virtual objects, the second object attribute of virtual objects in the second set of virtual objects, and the round phase; The second set of virtual objects and the first set of virtual objects belong to different game factions.

6. The method according to claim 3, characterized in that, The strategy preference information includes multiple strategy categories, and the determination and display of the recommended operation sequence set includes: Multiple sets of recommended operation sequences are displayed according to the strategy preference information.

7. The method according to claim 1, characterized in that, The method further includes: In the manual control mode of the virtual mission, the first set of virtual objects is controlled to simulate the execution of the first recommended operation sequence; wherein, the simulated execution does not occupy actual combat rounds.

8. The method according to claim 7, characterized in that, The simulated execution of the recommended operation sequence includes: The release process of the first recommended operation sequence is played step by step in the game interface.

9. The method according to claim 1, characterized in that, The effect prediction information includes at least one of the following: damage prediction value, treatment prediction value, or control success rate prediction value.

10. The method according to claim 2, characterized in that, After controlling the first set of virtual objects to automatically execute the target recommendation operation sequence, the method further includes: If a battle failure is detected, the weight of the strategy preference information corresponding to the target's recommended operation sequence is reduced.

11. The method according to claim 2, characterized in that, The step of controlling the first set of virtual objects to automatically execute the target recommendation operation sequence includes: Based on the skill release order in the target recommended operation sequence and the combat resource allocation information, control the virtual objects in the first set of virtual objects to perform skill release and / or resource allocation operations.

12. The method according to claim 3, characterized in that, The method further includes: The first operation sequence is generated in response to a first skill operation on a first virtual object in the first set of virtual objects and a second skill operation on a second virtual object.

Images