Information processing method and electronic device

Abstract

The present disclosure provides an information processing method and an electronic device, which determines at least one operation information through a target lineup and state data of a first game account in a current game round; determines target operation information from the at least one operation information, and displays identification information corresponding to the target operation information in a graphical user interface. In this way, based on the target lineup and the state data of the current game round, the intermediate round operation suggestion from the current state to the target lineup is dynamically determined and displayed, which helps to reduce the blind operation and redundant instructions of the player in the intermediate stage due to the lack of guidance, reduces the data processing pressure brought by the terminal processing of invalid operation requests, and improves the human-computer interaction efficiency.

Description

Technical Field

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

[0002] In strategy games (such as auto chess games), lineup recommendation features are often provided to assist players in making strategic decisions. The recommendation mechanisms in these technologies are typically based on version strength analysis or fixed configurations, displaying players static final-state information such as the final virtual object combination and synergy pairings of the target lineup.

[0003] However, the above solution only displays the final state information and lacks effective guidance, making it difficult for players to make reasonable decisions. This can easily lead to frequent invalid operations and redundant instructions, which not only reduces the interaction efficiency of the terminal but also increases the data processing overhead of the system. 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, which provides a graphical user interface through a terminal device. The graphical user interface displays a virtual scene of a target game match in which a first game account participates. The target game match includes multiple game rounds. The method includes: acquiring target lineup and status data of the first game account in the current game round; determining at least one operation information based on the target lineup and status data, wherein the at least one operation information is used to indicate an operation suggestion from the current state to at least one intermediate round of the target lineup; determining target operation information from the at least one operation information, and displaying the identification information corresponding to the target operation information in the graphical user interface.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, which provides a graphical user interface through a terminal device. The graphical user interface displays a virtual scene of a target game match in which a first game account participates. The target game match includes multiple game rounds. The apparatus includes: an acquisition module configured to acquire target lineup and status data of the first game account in the current game round; a determination module configured to determine at least one operation information based on the target lineup and status data, wherein the at least one operation information is used to indicate an operation suggestion from the current state to at least one intermediate round of the target lineup; and a display module configured to determine target operation information from the at least one operation information and display the identification information corresponding to the target operation information in the graphical user interface.

[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, when executing the computer program instructions, implements any of the above-described 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 information processing methods described above.

[0009] One embodiment of this disclosure provides an information processing method, including: acquiring the status data of a target lineup and a first game account in the current game round; determining at least one operation information based on the target lineup and status data, wherein the at least one operation information is used to indicate operation suggestions for at least one intermediate round from the current state to the target lineup; determining target operation information from the at least one operation information, and displaying the identification information corresponding to the target operation information in a graphical user interface. In this way, by dynamically determining and displaying operation suggestions for intermediate rounds from the current state to the target lineup based on the status data of the target lineup and the current game round, it helps reduce blind operations and redundant commands by players in intermediate stages due to a lack of guidance, reduces the data processing pressure caused by the terminal processing invalid operation requests, and improves the accuracy of operation guidance and the efficiency of human-computer interaction. 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 This diagram illustrates a flowchart of an information processing method provided in one exemplary embodiment of the present disclosure. Figure 2 This diagram illustrates the structure of an information processing apparatus provided in one exemplary embodiment of the present disclosure. Figure 3 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0012] The technical solutions of this disclosure will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0013] This embodiment provides a method that provides a graphical user interface (GUI) through a terminal device. The GUI displays a game interface, which includes a game scene and a user interface (UI). The game interface refers to the interface of an application provided or displayed through the GUI. The user interface is used for information interaction with the user and may include game design elements that directly or indirectly interact with the user, such as buttons, animations, text, sounds, and windows. In optional embodiments, the interface elements in the user interface may include the following controls: (1) controls related to the character, such as skill controls, movement controls, and function controls; (2) controls for indicating information, also known as indicator information markers, such as direction indicators, character indicators, character stamina indicators, item pickup points, or treasure chest locations; (3) information display controls, also known as information display areas, such as displaying basic character information (character name, profession, health points, mana points, etc.), character status information (such as whether the character is unconscious or poisoned), or match information (such as the number of kills, match time, etc.); (4) game setting controls, such as system settings, shop, and gold coins. Furthermore, the controls displayed in the user interface may differ between games. Some games include a friend list control, allowing users to view information about added friends and perform actions such as chatting, visiting each other's homes, and deleting friends. Other games include quest-related controls, such as displaying a list of current quests, including main quests and side quests. These controls help users better manage and play the game.

[0014] In an optional implementation, the game scene screen is the screen corresponding to the virtual scene displayed on the terminal device. The game scene screen may include virtual objects such as game characters (such as controlled virtual characters, also known as player virtual characters), NPC characters (NonPlayer Characters), and AI (Artificial Intelligence) characters that execute game logic in the virtual scene. The game scene screen usually changes as the controlled virtual character moves.

[0015] The aforementioned virtual scene is the content displayed (or provided) by the game application when it runs on a terminal or server. Optionally, the virtual scene is a simulation environment of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. The virtual scene can be any of a two-dimensional virtual scene, a 2.5-dimensional virtual scene, or a three-dimensional virtual scene. The virtual environment can be sky, land, ocean, etc., where the land includes environmental elements such as deserts and cities. Among them, a virtual scene is a scene containing the complete game logic of virtual objects controlled by the user. For example, in a sandbox-style 3D shooting game, a virtual scene is a 3D game world used by players to control virtual objects in battle. Instances of virtual scenes can include at least one element among mountains, plains, rivers, lakes, oceans, deserts, skies, plants, buildings, and vehicles. For example, in a 2D or 2.5D card game, a virtual scene is a scene used to display and release cards or display the virtual objects corresponding to cards. Instances of virtual scenes can include arenas, battlegrounds, or other "field" elements or other elements that can display the card battle status. For 2D or 2.5D multiplayer online tactical competitive games, a virtual scene is a 2D or 2.5D terrain scene used by virtual objects in battle. Instances of virtual scenes can include elements such as canyon-style mountains, lines, rivers, classrooms, desks and chairs, and podiums.

[0016] The aforementioned virtual object refers to a controllable dynamic object within a virtual scene. Optionally, this dynamic object can be a virtual character, virtual animal, anime character, etc. This virtual object is a character controlled by the player through an input device, or an AI character trained and set up for battle in a virtual environment, or an NPC set up for battle in a virtual scene. Optionally, this virtual object is a virtual character competing in a virtual scene. Optionally, the number of virtual objects in the virtual scene battle is preset or dynamically determined based on the number of clients joining the battle; this disclosure does not limit this. In one possible implementation, the user can control the virtual object to move within the virtual scene, for example, controlling the virtual object to run, jump, crawl, etc., and can also control the virtual object to use skills, virtual items, etc., provided by the application to fight against other virtual objects.

[0017] The method in one embodiment of this disclosure can be run on a terminal device or a server. The terminal device can be a local terminal device, such as a touch device or a non-touch device. When the method of the embodiment is run on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and client devices.

[0018] In an optional implementation, cloud gaming can run under a cloud interactive system. Cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operation mode, the game program and the game screen presentation are separate. The storage and operation of the method in this embodiment are completed on the cloud gaming server. The client device is used for receiving and sending data and presenting the game screen. For example, the client device can be a display device with data transmission capabilities close to the user, such as a mobile terminal, television, computer, or PDA; however, the terminal device for information processing is the cloud gaming server in the cloud. When playing the game, the player operates the client device 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 interface and other data, returns it to the client device through the network, and finally, the client device decodes and outputs the game interface.

[0019] In an optional implementation, the terminal device can be a local terminal device that stores the game program and is used to present the game interface. The local terminal device is used to interact with the player through the game interface; that is, it typically downloads, installs, and runs the game program via an electronic device. The local terminal device can provide the game interface to the player in various ways, such as rendering it on a terminal's display screen or providing it to the player via holographic projection. For example, the local terminal device can include a display screen and a processor. The display screen is used to present the game interface, which includes game scene visuals, and the processor is used to run the game, generate the game interface, and control the display of the game interface on the display screen.

[0020] According to one embodiment of the information processing method of this disclosure, a graphical user interface is provided through a terminal device. The graphical user interface displays a virtual scene of a target game match in which a first game account participates. The target game match includes multiple game rounds, such as... Figure 1 As shown, the method may include: Step S110: Obtain the target lineup and the status data of the first game account in the current game round; Step S120: Based on the target lineup and status data, determine at least one operational information, wherein the at least one operational information is used to indicate operational suggestions for at least one intermediate round from the current status to the target lineup; Step S130: Determine the target operation information from at least one operation information and display the identification information corresponding to the target operation information in the graphical user interface.

[0021] According to one embodiment of this disclosure, based on the target lineup and the state data of the current game round, the operation suggestions for intermediate rounds from the current state to the target lineup are dynamically determined and displayed. This helps to reduce blind operations and redundant commands caused by the lack of guidance in the intermediate stage, reduces the data processing pressure caused by the terminal handling invalid operation requests, and improves the accuracy of operation guidance and the efficiency of human-computer interaction.

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

[0023] In an optional implementation, a graphical user interface (GUI) is provided via a terminal device. This GUI displays a virtual scene of the target game match in which the first game account participates, and the target game match includes multiple rounds. This provides a basic interactive and data-driven environment for subsequent dynamic lineup transition recommendations based on round states, ensuring that the recommended information accurately matches the game's pace and is presented intuitively on the interface.

[0024] In one implementation, players launch an auto chess game application via their smartphones, where a virtual chessboard scene involving eight players is rendered on the screen. This virtual scene displays each player's preparation area, combat area, and shop area. As the game progresses, the match is divided into multiple consecutive phases, each containing several fixed action and combat rounds. During these rounds, the system continuously tracks and records various player status indicators, providing real-time data input for subsequent lineup recommendation algorithms. Optionally, a target game match is used to represent the complete single-game competitive process currently being participated in by the first game account.

[0025] Optionally, the target game match can be a single game in Auto Chess mode or a single match in a tournament mode with multiple elimination rounds. Considering the coexistence of economic management and random game elements in Auto Chess gameplay, the target game match mentioned above not only covers the complete timeline from the initial draft to the final outcome but also includes all intermediate state snapshots generated during the match. It should be noted that the above description of the match type is only one example and is not intended to limit the specific form of the match. In actual implementation, it can be determined according to the specific game mechanics or application scenario, as long as the match process can be divided into multiple discrete stages with state data collection capabilities. By clearly defining the boundaries and properties of the match, a clear data sampling range can be provided for subsequent model inference, avoiding data contamination across matches.

[0026] Optionally, a game round is used to represent a discrete time node or operation phase divided within a target game. Optionally, a game round can be a management phase where players perform actions such as purchasing, deploying units, and refreshing the shop, or it can be a settlement phase where pieces automatically engage in combat. To avoid confusion in the timing of state data collection due to unclear phase divisions, the above method can divide game rounds based on fixed time intervals or system-defined event triggering conditions. One objective of this embodiment is to standardize the frequency of state data collection by clearly defining the boundaries of game rounds. This reduces the amount of data processed in real-time by the system and ensures that the state data input to the prediction model has consistent temporal characteristics. Different round rules can be loaded at different game phases, and the round duration can be dynamically adjusted according to the game's progress. It should be understood that the number and duration of game rounds can vary depending on the specific game design, and this embodiment does not limit this.

[0027] In step S110, the target lineup and the status data of the first game account in the current game round are obtained. This provides accurate basic data support for the subsequent dynamic generation of personalized transition paths, allowing the recommended scheme to fit the player's actual game situation and effectively avoiding the risk of a power vacuum period caused by static final-state recommendations.

[0028] In one implementation, taking an auto chess game as an example, at the start of each round, the client collects the player's current health, shop level, gold, current equipment, and held pieces, and packages this data along with the player's desired final lineup, sending it to the server. Upon receiving this data, the server uses it as input for subsequent reasoning and generating round-by-round transition suggestions. Optionally, the target lineup indicates the desired final combination, which is dynamically determined based on player selection or system recommendations.

[0029] Optionally, the target lineup can be a final piece combination that the player manually selects through the lineup selection interface, or it can be one of several candidate lineups automatically generated by the system based on the player's current piece holdings or resource preferences. Considering that special resources have a decisive impact on the lineup's trajectory in auto chess games, the determination of the target lineup can also be combined with the first resource that strengthens a specific synergy or the second resource that provides additional benefits to a specific virtual object for filtering. For example, if a player selects a synergy enhancement item in a specific round, the system will filter candidate lineups centered around that synergy from the preset lineup pool based on that synergy enhancement item. It should be noted that the above method for determining the target lineup is only one example. In actual implementation, it can be combined and determined according to the specific application situation. This disclosure is not intended to limit the source of the target lineup.

[0030] Optionally, in addition to the above-mentioned method of filtering based on special resources, the target lineup can also directly receive custom lineup configurations input by the player, or provide reverse counter-recommendations based on the current game environment. To avoid information overload for players when selecting lineups, the system can prioritize candidate lineups by combining current game round count, economic status, and other status data, and display the top-ranked lineups first.

[0031] Optionally, state data is used to characterize the real-time game situation of the current round, including basic attributes such as round number, virtual resources, and object level. Optionally, state data can be a structured data set containing the overall picture of the player's current game, sent by the client to the server at the start of each round of the auto chess game. Specifically, in addition to original fields such as current round number, number of virtual resources, object level, currently held virtual objects, currently held virtual equipment, and current health, state data can also include derived features that cannot be directly read from the original fields. Considering that recommending transition paths requires accurate assessment of the player's operational rhythm, derived features can include available deployment slots, gold interest tiers, synergy status, winning streak, or losing streak. By using these original data and derived features together as state data, a unified and clean input interface can be provided for downstream inference models, shielding the details of the original data format and enabling the model to more accurately understand the urgency and resource sufficiency of the current game.

[0032] Optionally, the collection of status data is not limited to fixed round nodes, but can be continuously monitored throughout the game. To avoid the performance overhead of high-frequency data collection, status data updates can be set to be performed when key events are triggered, such as incremental updates when players buy or sell virtual objects, allocate virtual equipment, or when rounds are settled. Furthermore, status data can also include external environmental factors such as changes in opponent strength and shop refresh probabilities. It should be noted that if certain fields in the status data are missing or abnormal, the system can use default values ​​to fill them in or estimate based on historical averages to ensure the stability of subsequent reasoning processes. The specific composition of status data described above is merely an example; those skilled in the art can extend it according to actual game mechanics, and this disclosure is not limited thereto.

[0033] In optional implementations, the status data includes at least one of the following: current round number, number of virtual resources, object level, currently held virtual objects, currently held virtual equipment, current health, synergy status, win streak, loss streak, available slots, and interest tier. This multi-dimensional status data comprehensively depicts the current game situation, providing a detailed data foundation for generating accurate and personalized transition paths, and preventing recommended solutions from being detached from the actual game situation.

[0034] In one implementation, taking an auto chess game as an example, the system collects player status data at the start of each round. For example, in the current round 2-1, the player has 50 gold (virtual resource quantity), a shop level (i.e., object level) of 5, and current health of 80. The player already holds 3 1-cost pieces and 2 2-cost pieces (held virtual objects), and has one attack item (held virtual item). Two synergies are active on the field (synergy status), the player is currently on a 2-win streak (win streak status), there are 2 empty slots remaining (empty slots), and the gold is at the 5-interest tier (interest tier). This data is combined, packaged, and sent to the server as input for the predictive model to infer the current transition suggestion.

[0035] Optionally, status data may include the current round number, number of virtual resources, object level, held virtual objects, held virtual equipment, current health, synergy status, winning streak, losing streak, number of available units, interest tier, etc., to comprehensively depict the current state of the game.

[0036] Optionally, the basic and economic parameters in the aforementioned status data can be directly read from the game server or obtained through simple calculations. The current round number, object level, current health, and virtual resource quantity can be directly obtained from the game's memory fields. The virtual resource quantity specifically refers to the total amount of gold the player currently holds, used to measure the player's purchasing power. Considering the complexity of economic management in auto chess gameplay, interest tiers and available slots are derived features and need to be calculated according to preset rules. For example, the interest tier can be determined based on the preset range into which the virtual resource quantity falls, such as 5 interest per 10 gold, with a maximum of 5 interest, thus determining which interest tier the player is currently in. This parameter helps the system determine whether the player should save or spend money. Available slots are obtained by subtracting the number of currently deployed virtual objects from the maximum deployment limit corresponding to the object level. This parameter directly determines whether the player can deploy new pieces. It should be noted that the above method of obtaining parameters is only one example and can be adjusted according to specific game mechanics. This disclosure is not intended to limit the composition of the parameters.

[0037] Optionally, the lineup composition parameters (e.g., held virtual objects, held virtual equipment, synergy status) and battle result parameters (e.g., winning streak, losing streak) in the above status data are used to reflect the player's current real-time combat power and operational rhythm. Held virtual objects and held virtual equipment record the specific types, star levels, and equipment distribution of the pieces on the player's current board and bench, which is an important basis for generating transition lineup suggestions. Synergy status is calculated based on the currently activated synergy effects of the deployed virtual object combinations, used to assess the synergy strength of the current lineup. Winning streak and losing streak status record the sequence of battle results in the player's recent rounds, such as consecutive wins or consecutive losses. Considering that winning streaks or losing streaks bring additional economic benefits, these two statuses not only reflect the player's current combat power level but also suggest the operational strategies the player may adopt, such as intentionally losing streaks to obtain economic compensation. By comprehensively considering these battle result parameters, the system can more accurately determine whether the player is in an advantageous operational phase or a disadvantageous pressure-resistant phase, thereby outputting transition operation suggestions that are more in line with the actual rhythm.

[0038] In an optional implementation, obtaining the target lineup includes: obtaining information on virtual objects and / or special resources currently held by the first game account; generating at least one candidate lineup based on the currently held virtual object data and / or special resource information; and determining the target lineup in response to a selection operation for the at least one candidate lineup. This approach, by combining currently held virtual objects and / or special resource information to generate candidate lineups, avoids the problem of players blindly choosing lineups that cannot be formed later, making lineup recommendations more closely aligned with the player's current resource situation, thereby improving the rationality of lineup determination and the player's gaming experience.

[0039] In one implementation, a player acquires a synergy enhancement item early in the game (e.g., the first round of the second phase) that strengthens a specific synergy. At this point, the system retrieves this synergy enhancement item as special resource information and, combined with the player's currently held virtual objects, filters multiple candidate team compositions centered around that specific synergy from a pre-set team composition library. These candidate team compositions are displayed in a list in the team composition recommendation area of ​​the graphical user interface. Players can select a candidate team composition by clicking on its card. In response to this selection, the system designates the selected candidate team composition as the target team composition for subsequent transition path recommendations.

[0040] Optionally, special resource information is used to characterize non-basic resources that produce specific beneficial effects on bonds or virtual objects in the game, and it is dynamically acquired according to the game progress.

[0041] Optionally, special resource information can be a primary resource that strengthens a specific synergy, or a secondary resource that provides additional benefits to a specific virtual object. Considering that players in auto-chess games receive system-provided buff items in specific rounds (such as round 2-1), as a possible implementation, the aforementioned primary resource could specifically be a synergy-strengthening item. When a player selects this item, the system will collect it as special resource information. It should be noted that the above description of special resource information types is only one example and is not intended to limit its composition. In actual implementation, special resource information can also include other information, such as lucky items that can change the shop refresh probability. These items can further influence the generation logic of subsequent candidate lineups, making the recommended results more diverse.

[0042] Optionally, besides using items automatically distributed by the system in fixed rounds as special resource information, resources acquired by players through other means can also be received as special resource information; this disclosure is not limited to this. To avoid limiting the scope of recommended candidate lineups due to a single resource type, the above method categorizes and matches special resource information based on its attribute tags when it detects it. In one specific way, the second resource can be manifested as special equipment such as a legendary dagger. Ordinary virtual objects using this equipment only enjoy basic attribute bonuses, while designated virtual objects using this equipment will trigger additional exclusive buffs. Based on this, after acquiring this second resource, the system will prioritize selecting candidate lineups centered around the designated virtual object, thereby ensuring maximum resource utilization and improving the overall strength of the formed lineup.

[0043] Optionally, the candidate lineup is a combination of alternative final lineups selected by the player based on currently held virtual objects and / or special resource information, which can be chosen as the target lineup.

[0044] Optionally, the candidate lineup can be a lineup combination based on specific synergy pairings or a lineup combination built based on specific core virtual objects. Considering the randomness of resources acquired by players in the early stages of the game, as a possible implementation method, the above-mentioned candidate lineup generation process may include: matching several lineup templates with the highest correlation to the type of special resource information from a preset lineup library, sorting them based on the overlap of virtual objects already held by the player, and selecting the top-ranked lineups as candidate lineups. It should be noted that the number of candidate lineups can be dynamically adjusted according to the interface layout and device performance, and this embodiment does not limit this. If multiple special resource information coexists, the weight of each resource can be comprehensively evaluated to generate a composite candidate lineup that takes into account multiple beneficial effects.

[0045] Optionally, the selection operation is used to determine one of the at least one candidate lineups as the target lineup, which is received through interactive controls in the graphical user interface. Optionally, the selection operation can be a touch click on a candidate lineup display card or a press on a specific shortcut key. The interactive control corresponding to this selection operation can be directly displayed in the lineup recommendation panel of the graphical user interface, or it can be displayed after detecting a player's instruction to call up the recommendation panel. In one implementation, when multiple candidate lineup thumbnails are displayed in the graphical user interface, the player can perform a selection operation by clicking on the target thumbnail. In response to this operation, the system determines the candidate lineup corresponding to the thumbnail as the target lineup and highlights the final form of the target lineup in the interface. It should be understood that if the player does not perform any selection operation within a preset time, the system can default to determining the candidate lineup with the highest score as the target lineup to ensure the continuity of the recommendation process and avoid game lag due to waiting for player input.

[0046] In an optional implementation, the special resource information includes a first resource that strengthens a specified synergy or a second resource that provides additional benefits to a specified virtual object. Based on the currently held virtual objects and / or special resource information, at least one candidate target lineup is generated, including: selecting candidate target lineups centered around the specified synergy or specified virtual object from a preset lineup library based on the first or second resource. This approach, by identifying the type of special resources held by the player and selecting matching candidate target lineups from the preset lineup library accordingly, avoids players blindly choosing from numerous lineups, making lineup recommendations more accurate and personalized, and effectively reducing the player's decision-making cost.

[0047] In one implementation, the synergy enhancement system in an auto chess game is used as an example. In an early round (e.g., round 2, stage 1), a player selects a synergy enhancement item (i.e., the first resource) that strengthens the "Mage" synergy. After detecting this special resource, the system filters multiple candidate target lineups centered around the "Mage" synergy from the preset lineup pool (e.g., a "6 Mage 3 Warrior" lineup, a "4 Mage 4 Assassin" lineup, etc.) and displays them for the player to choose from. Similarly, if a player obtains a legendary dagger (i.e., the second resource) from the shop, which provides an additional critical strike bonus to a specific piece, the system will filter candidate target lineups centered around that specific piece for damage output from the preset lineup pool. It should be noted that the selected candidate target lineups can be sorted according to their compatibility with the current special resource, prioritizing the lineups with the highest compatibility. The reasons for the matching can also be displayed on the interface to help players understand the recommendation criteria.

[0048] Optionally, the first resource is used to strengthen a specific synergy. This resource can be a synergy-enhancing item, synergy-boosting rune, or other virtual resource that can improve the effect of a specific synergy. Considering that the synergy system is one of the core mechanisms of lineup building in auto chess games, the first resource a player acquires early in the game often determines the subsequent development direction of their lineup. As a possible implementation method, when the system detects that a player holds a first resource, it will analyze the specific synergy type strengthened by that first resource (such as "Mage," "Warrior," "Assassin," etc.) and use this as an index to perform a matching search in the preset lineup library. It should be noted that the first resource can be obtained through the selection interface at a specific round stage, or it can be obtained by defeating specific virtual objects as a drop; this disclosure is not limited to these. If a player holds multiple first resources simultaneously, the system can comprehensively analyze the synergy between the synergy types strengthened by each first resource and prioritize recommending candidate target lineups that can utilize multiple synergy bonuses simultaneously, thereby improving resource utilization efficiency.

[0049] Optionally, besides strengthening synergies through synergy enhancement items, the primary resource can also take the form of synergy class-changing items or synergy trigger condition-reducing items. Synergy class-changing items allow virtual objects that are not of the specified synergy type to temporarily gain that synergy attribute, thus expanding the flexibility of team composition. Synergy trigger condition-reducing items lower the maximum number of virtual objects required to achieve a certain synergy, allowing players to complete the synergy effect with fewer pieces. Under these different forms of primary resources, the system's logic for selecting candidate target team compositions is adjusted accordingly: for synergy class-changing items, the system will select team composition templates that include cross-synergy combinations; for synergy trigger condition-reducing items, the system will select team composition templates that rely on high-threshold synergies. It should be understood that the above descriptions of the specific forms of primary resources are merely examples. In actual implementation, more types of primary resources can be introduced based on game version updates or gameplay expansions; the system only needs to expand the matching dimensions of the preset team composition library accordingly to adapt.

[0050] Optionally, the second resource is used to provide additional buffs to a specified virtual object. This can be special equipment, exclusive items, or other virtual items that enhance the combat attributes of a specific virtual object. Considering the significant differences in the buff magnitude of different equipment to different virtual objects in auto chess games, and the fact that some equipment can exert far greater combat effects in the hands of specific virtual objects, as a possible implementation, when the system detects that a player possesses a second resource, it will identify the specified virtual object corresponding to that second resource (i.e., the piece that can obtain additional buffs) and filter candidate target lineups from the preset lineup library that use that specified virtual object as the core output. For example, when a player obtains a legendary dagger that provides additional critical strike buffs to assassin-type virtual objects, the system will filter lineup templates that use assassin virtual objects as the main output. It should be noted that the correspondence between the second resource and the specified virtual object can be pre-configured in the game data table or dynamically determined through semantic parsing of the equipment description text; this disclosure does not limit this.

[0051] Optionally, the designated virtual object corresponding to the second resource can be one or more. When multiple designated virtual objects exist, the system can filter candidate target lineups centered around each designated virtual object separately, and then merge and display these candidate target lineups for players to choose from. At the graphical user interface level, the system can indicate the benefit relationship between the second resource and the designated virtual object in the preview interface of the candidate target lineups. For example, by highlighting the icon of the designated virtual object and adding a benefit value prompt next to it, the system can help players intuitively understand the reason for recommending the lineup. If a player already possesses the second resource but has not yet obtained any designated virtual object, the system can recommend a transitional lineup that includes a path to obtain the designated virtual object, or lower the priority of such lineups in the candidate target lineup list and add a prompt message, reminding the player to focus on obtaining the corresponding virtual object in subsequent rounds, thereby avoiding recommending lineups that cannot be formed.

[0052] Optionally, the preset lineup library stores various lineup configuration templates, each of which contains at least core synergy information and / or core virtual object information. Optionally, the preset lineup library can be a structured database stored locally or in the cloud, where each lineup configuration template contains at least core synergy information, core virtual object information, recommended equipment configuration, and round stage information required for the lineup to take shape. Considering that the lineup system in auto chess games changes with version updates, the preset lineup library supports a dynamic update mechanism. The development and operation team can add or modify lineup configuration templates in the preset lineup library based on version balance adjustments or the introduction of new virtual objects or synergies. During the selection process, the system can perform multi-dimensional matching in the preset lineup library based on the specified synergy enhanced by the first resource or the specified virtual object benefited by the second resource: it supports both exact matching (i.e., the core synergy or core virtual object of the lineup template completely corresponds to the specific resource) and fuzzy matching (i.e., the lineup template partially contains the synergy or virtual object), and outputs the matching results sorted by matching degree. It should be noted that the lineup configuration templates in the preset lineup library may come from statistical analysis of historical high-ranking match data, manual configuration by the operations team, or a combination of both. This disclosure is not intended to limit the source.

[0053] In step S120, based on the target lineup and status data, at least one operational information is determined, wherein the at least one operational information is used to indicate operational suggestions for at least one intermediate round from the current state to the target lineup. In this way, by determining operational information indicating operational suggestions for intermediate rounds based on the target lineup and status data, the gap in existing recommendation schemes lacking intermediate transition states is filled, providing players with phased dynamic guidance and reducing the risk of being eliminated in the early stages due to blindly pursuing the final lineup.

[0054] In one implementation, in the early rounds of the auto chess game, a player chooses a transitional lineup centered around a low-cost piece. The system obtains the player's current status data (e.g., 10 gold, 100 health) and the player's desired final lineup. Based on this, the system infers and outputs operational suggestions for the next three intermediate rounds, including purchasing a specific 1-cost transitional piece and pairing it with temporary synergies in round 3, and upgrading the shop in round 4 to increase the probability of high-cost pieces appearing, thereby guiding the player to smoothly transition to the target lineup. Optionally, an intermediate round is at least one stage game node between the current game round and the formation of the target lineup.

[0055] Optionally, intermediate rounds can be any one or more consecutive rounds in an auto chess game, from the early setup phase to the stage where the lineup is fully formed. Considering that auto chess games are typically divided into three main phases—early, mid, and late—intermediate rounds can specifically correspond to rounds transitioning from the early to mid-game (e.g., rounds 3 to 10) or from the mid to late-game (e.g., rounds 11 to 20). It should be noted that the specific numerical range for intermediate rounds mentioned above is merely an example and is not intended to be limiting. In actual implementation, the definition of intermediate rounds can be dynamically adjusted based on the difficulty of forming the target lineup, the player's current economic situation, and level milestones. For example, if the target lineup requires a high level to form, the number and span of intermediate rounds may be increased accordingly to ensure that players have sufficient time for economic accumulation and piece transition, thereby avoiding elimination due to a power vacuum before the lineup is fully formed.

[0056] Optionally, the intermediate round refers not only to the number of game rounds in the time dimension, but also to the phased lineup status that the player should hold at that round node. To avoid players lacking combat power in the intermediate round, the above-mentioned operational suggestions for the intermediate round can include transitional piece combinations, equipment allocation suggestions, and synergy transition status. Specifically, in the early stage of the intermediate round, the system can recommend that players use low-cost pieces with similar synergy attributes to the core pieces of the target lineup as a transition; in the mid-stage of the intermediate round, the system can guide players to gradually replace low-cost transitional pieces and begin collecting mid-cost core pieces from the target lineup. Through this phased guidance for the intermediate round, players have a clear direction of action at each time point, effectively reducing the learning threshold and decision-making cost for novice players.

[0057] Optionally, the action suggestion is used to instruct the player on specific game actions to be performed in intermediate rounds, including at least one of purchasing, selling, upgrading, or refreshing. Optionally, the action suggestion can be guidance information for specific game actions such as refreshing the shop, purchasing pieces, selling pieces, deploying pieces, allocating equipment, upgrading the shop, or adjusting positions. Considering the different urgency levels of different actions in the current game state, as a possible implementation, the above action suggestions can have priority indicators, which can be determined by a multi-evaluator parallel dynamic scoring mechanism. For example, when the player's health is low, the action suggestion of refreshing the shop to improve current combat power will be given high priority; when the player has abundant resources and is on a winning streak, the action suggestion of upgrading the shop to obtain high-cost pieces will be given high priority. It should be noted that the specific content of the above action suggestions can be dynamically adjusted based on the inference results output by the prediction model, and this disclosure is not limited to this. By providing priority action suggestions, players can quickly make optimal decisions in complex game environments.

[0058] Optionally, in addition to the specific game behavior guidance mentioned above, the operational suggestions can also include a strategy of saving money without taking any action. To prevent players from blindly spending money when resources are insufficient, leading to economic collapse, the above method can output a suggestion to save money without taking any action when it detects that the player's current gold coins are at a specific interest level. Furthermore, the display form of this operational suggestion in the graphical user interface can be varied. For example, it can use a highlighted thumbs-up icon to indicate the acquisition of pieces needed for the final lineup, or use gray transition labels to indicate the acquisition of pieces needed for the transition. If a high-risk state occurs (such as health falling below a safe threshold), the system will forcibly remove the suggestion to save money without taking any action and replace it with a high-priority suggestion to improve combat power, thereby ensuring the player's survivability in the game and demonstrating the dynamic correction capability of the recommended path.

[0059] In an optional implementation, at least one operational piece of information is determined based on the target lineup and status data, including: inputting the target lineup and status data into a prediction model; and using the prediction model to infer based on the target lineup and status data to output at least one operational piece of information. In this way, by inferring from the target lineup and current status data using a prediction model, personalized operational suggestions can be generated based on proven transition patterns from historical matches, avoiding the limitations of fixed-rule recommendations and effectively improving the accuracy and scenario adaptability of transition path recommendations.

[0060] In one implementation, in round 3 of an auto chess match, a player selects a target lineup centered around the "Assassin synergy." At this point, the system collects the player's status data, including: current round number 3, gold quantity 12, shop level 4, 2 Assassin pieces already owned, and current health 85. The client sends this status data, along with the target lineup information, to a prediction model on the server. Based on high-score match transition patterns learned during training, the prediction model infers and outputs action suggestions for the current round and several subsequent rounds, such as "buy a 1-cost Assassin piece A and deploy it," "keep gold to 20 to earn interest," and "upgrade the shop to level 5 in the next round." This action information constitutes the intermediate transition path from the current state to the target lineup.

[0061] Optionally, the predictive model is used to receive target lineup and state data, perform inference, and output operational information; it can be a machine learning model or a large language model.

[0062] Optionally, the predictive model can be a lineup evolution prediction model trained on historical high-ranking game data, or a strategic profile generation module integrating a large language model. Specifically, the training process of the predictive model includes: collecting a large number of historical game records from high-ranking players or professional players, recording the piece holdings, equipment, economy, level, health, synergy status, and final ranking results at each round node of each game; training an initial model based on this data, enabling it to learn the commonly used and proven effective round-by-round transition patterns in historical high-ranking games under the given target lineup and current game state. In the inference phase, after receiving the target lineup and current state data, the predictive model can output structured strategy parameters, including intermediate parameters such as strategy type, economic target threshold, stage level milestones, core resource list, and operational mode identifiers. These intermediate parameters are then used to generate specific operational suggestions. It should be noted that the output form of the predictive model is not limited to direct operational instructions; it can also be a structured set of intermediate parameters, which are further transformed into specific operational information by the downstream deterministic rule module. This utilizes the model's understanding of lineup semantics while avoiding the uncontrollable problems caused by direct model decision-making.

[0063] In an optional implementation, the prediction model is trained as follows: A historical match dataset is acquired, comprising records of multiple historical matches. Each match record includes the second game account's status data for each round, whether the target lineup was formed in the match, and the second game account's ranking in the match. An initial model is trained based on the historical match dataset. If the loss function of the initial model converges, the trained initial model is determined as the prediction model. Thus, by training the initial model on a dataset containing records of multiple historical matches, the prediction model learns commonly used and validated round-by-round transition patterns from historical matches, thereby providing players with scientific and reliable lineup transition recommendations.

[0064] In one implementation, the training of a lineup evolution prediction model for an auto chess game is illustrated as an example: The system first collects a large number of historical game records from high-ranking players and professional players from the game server. Each record details the player's piece holdings, equipment, economy, level, health, synergy status, whether a target lineup was formed in the final round, and the final ranking. Next, these historical game records are used to construct a historical game dataset, which is then used to iteratively train the initial neural network model. During training, the model takes the current state data and the target lineup as input, and uses the transition operations actually used in historical high-ranking games as labels, continuously adjusting the model parameters through backpropagation. When the loss function value stabilizes and converges, the trained model is determined to be a predictive model usable for inference.

[0065] Optionally, the historical match dataset is a structured dataset comprised of match records from multiple historical matches. Its data sources may include match records from high-ranking players, professional players, or a combination of both. Each match record must contain at least the second game account's status data for each game round (including but not limited to round number, unit holdings, equipment status, economy, level, health, synergy status, etc.), information indicating whether the match ultimately resulted in the target lineup, and the second game account's final ranking in that match. It should be noted that, in addition to the aforementioned basic fields, the historical match dataset may also include other derived information, such as win / loss streaks, available units, and interest tiers. This derived information can further enrich the model's training features and improve prediction accuracy. In actual implementation, the size and composition of the dataset can be determined based on experience or specific application conditions; this disclosure is not intended to limit this.

[0066] Optionally, the construction of the historical match dataset can employ various strategies. One possible implementation is to extract match records in batches from the game server according to a preset time window (e.g., all high-rank matches from the most recent season), and perform data cleaning and format standardization on each record to ensure field integrity. Another implementation is to use an incremental update strategy, continuously adding newly generated high-rank matches to the historical match dataset after the start of a new season, allowing the prediction model to adapt to changes in lineup strength brought about by version iterations. Considering that unit attributes and synergy effects may differ across versions, a version identifier field can be added to each match record during dataset construction, enabling grouping or weighting by version during training and avoiding cross-version data mixing that could lead to the model learning outdated strategy patterns.

[0067] Optionally, the game record is used to record the entire state and result information of the second game account in a single historical game. Optionally, the game record is the basic data unit in the historical game dataset. Each game record corresponds to a complete historical game and records the state evolution trajectory of the second game account in that game according to the time sequence of game rounds. Specifically, a game record can contain snapshot data of multiple round nodes. Each snapshot data records the second game account's piece holdings, equipment allocation, economic resources, target level, current health, and synergy activation status in the corresponding round. In addition, the game record also contains the global result information of the game, i.e., whether the target lineup was successfully formed and the final ranking of the second game account. It should be understood that the state data recorded in the game record includes not only raw fields that can be directly read from the game server, but also calculated derived features, such as the number of available units and gold interest tiers. These derived features help the model to more comprehensively understand the game context.

[0068] Optionally, the second game account refers to a game account that provides game records from the historical game data set, and its selection criteria are directly related to the quality of the games. As one possible implementation, the second game account can be limited to high-ranking player accounts, i.e., player accounts that have reached a specified rank in the game's ranking system (e.g., the top 5% of the highest rank). These players typically possess rich operational experience and a mature understanding of team compositions, and the transition strategies contained in their game records have high reference value. As another implementation, the second game account can also be limited to professional player accounts, i.e., accounts of professional esports players who have participated in official tournaments, whose game records represent the highest level of operational strategies in the current version. It should be noted that the selection criteria for the second game account can be flexibly adjusted according to data collection needs. For example, records from both high-ranking players and professional players can be included simultaneously, or further filtering can be performed based on dimensions such as win rate and number of matches. This disclosure does not impose any limitations on this.

[0069] Optionally, the ranking is used to represent the final performance of the second game account in the corresponding historical game, serving as label information for model training.

[0070] Optionally, ranking is a key indicator for measuring the performance of a second game account in a single historical match, and it serves as a training label in the training process of the prediction model. In auto chess games, a match typically involves eight players, with final rankings ranging from first to eighth. Considering the direct correlation between ranking and the effectiveness of game strategies—a higher ranking indicates a more successful transition strategy in that match—game records can be filtered or weighted based on ranking when constructing training samples. For example, only the top four ranked matches can be selected as positive samples, allowing the model to focus on learning high-win-rate transition paths; alternatively, different weights can be assigned to different rankings, with higher rankings receiving higher weights, allowing the model to focus more on high-quality strategies during training. If there are cases where players have the same ranking but different strategy paths, auxiliary indicators such as lineup formation time and critical round health can be used for differentiation, but this embodiment does not limit this approach.

[0071] Optionally, the initial model refers to a model instance that has not yet learned historical game data before training begins. Its network structure and parameter initialization method can be determined according to the specific prediction task requirements. As one possible implementation, the initial model can adopt a deep neural network architecture, including an input layer, multiple hidden layers, and an output layer. The input layer receives encoded vectors of the target lineup and current state data, the hidden layers extract nonlinear correlations between features, and the output layer generates a probability distribution of operation information. Alternatively, the initial model can adopt a large language model architecture, inputting a natural language description of the game context into the model for inference. Considering the different advantages and disadvantages of different model architectures in terms of training efficiency and inference performance, the selection of the initial model can be determined comprehensively based on factors such as the computing resources and latency requirements of the deployment environment. Before training begins, the parameters of the initial model can be initialized randomly or based on pre-trained weights; this disclosure does not limit this.

[0072] Optionally, the loss function is used to measure the difference between the initial model's prediction results and the true labels, serving as a basis for determining training termination. Optionally, the loss function is a mathematical metric that evaluates the prediction performance of the initial model during training; it guides the direction and magnitude of model parameter updates by calculating the error between the model output and the true labels. In the lineup transition recommendation scenario, the loss function can employ cross-entropy loss to measure the difference between the probability distribution of the operation information predicted by the model and the operations actually performed in historical games. Considering that different operation types may have different importance—for example, purchasing core pieces has a greater impact on lineup formation than adjusting positions—class weights can also be introduced into the loss function to make the model focus more on the prediction accuracy of key operations during training. When the initial model's loss function converges, i.e., the change in the loss value is less than a preset threshold or the loss value no longer decreases significantly after multiple consecutive training rounds, the initially trained model is determined to be a prediction model. It should be understood that the specific form of the loss function and the convergence criterion can be flexibly selected according to the model architecture and training strategy; this embodiment does not limit this.

[0073] In an optional implementation, the second game account is a high-ranking player or a professional player. This filters and limits the training data source accounts by rank or professional attributes, ensuring the data quality and strategy representativeness of the historical game dataset, thereby making the transition operation suggestions output by the predictive model more scientific and practically effective.

[0074] For example, a high-ranking player can refer to a game account that has reached the Diamond rank or above in the target game's ranked matchmaking system, such as an account whose ranked score is in the top 5% of all active players in the current season; a professional player can refer to a registered player account that is signed with an esports club and whose main professional activity is participating in the target game's events, such as a player participating in an official professional league. The game records of the above two types of accounts contain battle-tested lineup operation decisions and round transition strategies, which can provide highly valuable sample data for training the predictive model.

[0075] Optionally, high-ranking players are used to represent second game accounts that have reached a specified rank threshold in the target game's ranking system, and their historical game records serve as a source of high-quality training samples.

[0076] Optionally, a high-ranking player can refer to a game account whose rank in the target game's ranked matchmaking system has reached a preset higher level. In one implementation, this preset higher level can correspond to the two highest ranks in the ranked system, such as accounts belonging to the Challenger and Master ranks. In another implementation, high-ranking players can also be defined based on their percentile ranking score; for example, accounts whose current season ranking score is in the top 10% of all active players can be identified as high-ranking players. It should be noted that the above-mentioned specific settings for rank thresholds are only one example, and in actual implementation, they can be flexibly adjusted according to the target game's rank system structure, player base size, and data collection needs. By selecting the game records of high-ranking players as training data, it can be ensured that the transition strategies learned by the model come from high-quality decision paths that have been verified in actual combat, thereby improving the reliability and reference value of the prediction model's output results.

[0077] Optionally, besides identifying high-ranking players based on rank or score, other data metrics can be combined for comprehensive identification. For example, in one implementation, the average final ranking of a game account over multiple historical seasons can be calculated. If this average final ranking consistently ranks in the top 15%, the account is classified as a high-ranking player. In another implementation, derived metrics such as win rate and top-four entry rate can be introduced as auxiliary criteria. When an account's win rate exceeds a preset threshold and its top-four entry rate exceeds a preset entry rate threshold, it is included in the category of high-ranking players. This multi-dimensional comprehensive judgment mechanism can more accurately screen accounts with stable, high-level operational capabilities, avoiding inconsistent training sample quality due to occasional fluctuations in a single season, thus ensuring the robustness of the prediction model training process.

[0078] Optionally, "professional player" can refer to the game account of a registered player whose primary professional activity is participating in the target game and related esports events. In one implementation, professional players include player accounts signed with esports clubs and registered to participate in official professional leagues. The game records of these accounts are generated in high-intensity training matches or official competitions, and their lineup operation decisions are highly strategic and standardized. In another implementation, professional players can also include player accounts participating in official or semi-official invitational tournaments, cup tournaments, and other similar events. It should be noted that the game data of professional players and the game data of ordinary high-ranking players may differ in terms of strategy and style. For example, professional players tend to be more conservative in their operations and risk control in competitions. Therefore, including the game records of both professional players and high-ranking players in the training dataset can enable the predictive model to learn more diversified transition strategies and improve the model's generalization ability and adaptability in different game scenarios.

[0079] In an optional implementation, the method further includes updating at least one operation information based on the current state of the target game match and the target lineup, provided that preset trigger conditions are met. This dynamic update of operation information by setting preset trigger conditions allows the recommended path to adapt to random factors and changes in the game, preventing the recommended scheme from remaining static and effectively improving the real-time performance and personalized adaptability of the recommendations. In one implementation, a player is pursuing a final lineup (i.e., the target lineup) centered around high-cost pieces. The system has already generated round-by-round operation suggestions to guide the player in upgrading the shop level in the early rounds. When the game progresses to the mid-game, the player encounters several high-intensity opponents, causing a significant drop in health. At this point, the state change dimension condition in the preset trigger conditions is met. Based on this, the system reassesses the current game situation and dynamically corrects the original shop-upgrading operation suggestion to prioritize refreshing the shop to upgrade the current piece star level, thereby helping the player stabilize their health. For example, if a player obtains a key equipment item after the shop refreshes in a certain round, and this change alters the target factor and exceeds a preset threshold, the system also triggers the operation information update process, regenerating transitional operation suggestions that match the current resource state.

[0080] Optionally, preset trigger conditions are used to trigger a dynamic update mechanism for operation information, which may include at least one trigger mechanism among time dimension, interaction dimension, state change dimension and random factor dimension.

[0081] In an optional implementation, the preset triggering condition includes at least one of the following: reaching a preset round interval; detecting a preset triggering operation for the adjustment control; detecting a change in the state data corresponding to at least one operation information before the adjustment in the current state of the target game match relative to the preset condition; detecting a change in a target factor in the target game match and the magnitude of the change exceeds a preset threshold, wherein the target factor includes the shop refresh probability or the opponent's strength. Thus, by setting multiple types of preset triggering conditions, the timing of operation information updates becomes more flexible and diverse, supporting both timed updates and event-driven updates, effectively improving the dynamic adaptability of the transition recommendation path to game randomness and state changes.

[0082] In one implementation, the preset triggering conditions can be met in various ways. For example, when the game reaches the interval node every 3 rounds, the system automatically triggers the operation information update process; or, when the player feels that the current recommended path is not suitable for the actual situation, they can actively click the "Replan" button (i.e., adjust the control) floating on the right side of the interface to trigger an instant update; or, if the system detects that the player's health drops sharply from 60% to 25%, and the change in status exceeds the preset condition, it automatically triggers a correction; or, if the shop refresh probability changes from 30% to 50% due to the increase in the object's level, and the change exceeds the preset threshold, the system automatically re-infers the transition path.

[0083] Optionally, the preset round interval is used to define the time period for automatically triggering operation information updates, which can be configured as a fixed value or a dynamic value according to the game rhythm.

[0084] Optionally, the preset turn interval can be 2 turns, 3 turns, 5 turns, or any other set number of turns. Considering that the time length and operational complexity of each turn in auto chess games are different, the setting of the preset turn interval needs to balance the relationship between update frequency and system load.

[0085] Optionally, the preset round interval can also be configured with a non-uniform interval, setting different interval values ​​for different game stages to create a phased update rhythm. In one specific approach, the entire game can be divided into three stages: early (rounds 1-10), mid (rounds 11-20), and late (round 21 and beyond), with intervals of 2, 3, and 4 rounds respectively. Furthermore, the preset round interval can be linked to key milestone events in the game. For example, when a player reaches levels 5, 7, or 8, an additional update is triggered regardless of whether the preset round interval has been reached. Similarly, when the system detects that a player has experienced a winning or losing streak of 3 or more games, the preset round interval can be broken, triggering a recalculation of operation information ahead of schedule. It should be understood that the specific configuration strategy for the preset round interval can be flexibly adjusted according to game version updates or operational needs.

[0086] Optionally, the adjustment controls can be displayed in various locations within the graphical user interface, such as the right edge of the shop panel, the toolbar area above the chessboard, or as a floating button superimposed in the corner of the lineup recommendation panel. The presentation of the adjustment controls can be diverse; for example, it could be a rectangular button with the text "Redesign," a circular button with a looping arrow icon, or an expandable menu control. In one implementation, the adjustment controls can be presented semi-transparently or with low contrast by default to avoid obscuring the core game screen. It should be noted that the adjustment controls can also be integrated within the lineup recommendation panel as a functional sub-control of the panel, automatically becoming visible when the player opens the lineup recommendation panel. The above descriptions of the location and form of the adjustment controls are merely examples and are not intended to be limiting.

[0087] Optionally, preset conditions are used to define the trigger threshold for changes in state data, such as 30 gold coins, an increase or decrease of more than 3 virtual objects held, etc. Considering the multi-dimensional coupling of state changes in auto chess games, the preset conditions can be judged using either a single-dimensional judgment or a combined-dimensional judgment mode. In the single-dimensional judgment mode, an update is triggered as long as the change in any one dimension reaches the corresponding threshold; in the combined-dimensional judgment mode, an update is triggered only if the change in multiple dimensions simultaneously reaches their respective thresholds, for example, requiring a decrease in health of more than 15% and a reduction in virtual resources of more than 20 gold coins to be met simultaneously.

[0088] Optionally, the target factor is used to characterize external random variables that affect the formation strategy in a game, including but not limited to the probability of shop refresh or the strength of the opponent.

[0089] Optionally, target factors may include external variables affecting the formation path of a team composition, such as shop refresh probability, opponent strength, synergy availability, and equipment drop probability. Shop refresh probability refers to the probability distribution of different cost units appearing in the shop; this probability changes with the target's level, for example, the probability of a 5-cost unit appearing is 1% at level 5 and increases to 10% at level 8. Opponent strength can be quantified using dimensions such as the opponent's average level, the number of completed synergies, win streaks, or historical ranking. Considering the dynamic nature of these target factors during the game, the system needs to continuously monitor their changes. As a possible implementation, when changes in shop refresh probability cause the expected value of acquiring core units in the target team composition to decrease by more than a certain percentage, the system automatically triggers an update to reassess the feasibility of the transition path; when opponent strength suddenly increases (e.g., an opponent achieves first place for three consecutive rounds), the system may switch the recommended strategy from an economic management-oriented approach to a strength-preserving approach. It should be noted that the specific types and judgment logic of target factors can be expanded according to the design of the game mechanics and are not intended to be limited thereto.

[0090] Optionally, a preset threshold is used to quantify the trigger boundary of changes in the target factor. When the change in the target factor exceeds this threshold, an operation information update is initiated. Optionally, the preset threshold can be configured with different numerical ranges or proportions based on the specific type of the target factor. For example, for the shop refresh probability, the preset threshold can be set to a decrease in the probability of the core pieces of the target lineup appearing by more than 5 percentage points; for the opponent's strength, the preset threshold can be set to an increase in the opponent's average combat power index by more than 20% or an opponent's winning streak reaching 3 games. Considering the different sensitivities to changes in the target factor at different game stages, the preset threshold can adopt a phased configuration strategy: in the early game, since the lineup is not yet formed and the margin for error is higher, the preset threshold can be set relatively loosely (e.g., triggering only when the change exceeds 30%); in the late game, since every fluctuation in combat power may lead to elimination, the preset threshold can be set more sensitively (e.g., triggering when the change exceeds 10%).

[0091] In an optional implementation, under preset triggering conditions, at least one action information is updated based on the current state of the target game match and the target lineup. This includes: if the current health value is detected to be less than a health value threshold, modifying the first action information in the at least one action information to a second action information. The first action information is guiding the target level upgrade, and the second action information is guiding a refresh of the shop. This dynamic modification of action suggestions when health is critical avoids the flaw of blindly pursuing level increases while neglecting survival, as is common in conventional mechanisms. This makes the transition path more flexible and consistent with actual combat situations, effectively improving the player's margin for error and survivability in the game.

[0092] In practical applications, assuming a player's target lineup requires a high level to be fully formed, the system's initial first action would guide the player to level up their target lineup from level 7 to level 8. However, if at the start of a round the system detects that the player's current health is only 25 points, below the set health threshold of 30 points, the system determines that continuing to save money to level up will risk elimination. Based on this, the system modifies the first action to a second action, guiding the player to use gold to refresh the shop to quickly acquire pieces to improve their current combat power and stabilize their health. Optionally, the health threshold is used to define the critical point at which the game account is in a dangerous state, and its specific value can be dynamically configured according to the stage of the game or the characteristics of the lineup.

[0093] Optionally, the health threshold can be a pre-configured fixed value, such as 30 health points, or a percentage threshold calculated based on the total maximum health in the target game, such as 20% of the total health. Considering the differences in players' damage tolerance at different game stages, as a possible implementation, the health threshold can also be adjusted in stages as the number of game rounds increases, for example, setting it to 40 points in the early game and 20 points in the late game. It should be noted that the above description of the specific value and adjustment method of the health threshold is only one example and is not intended to limit it. In actual implementation, the system can also fine-tune the threshold based on win / loss streaks or the opponent's remaining health to ensure that the judgment of dangerous states is more in line with the actual game environment and avoid misjudgments or delayed reactions caused by a single threshold.

[0094] Optionally, the first operation information is used to indicate operational suggestions for upgrading an object's level under normal operational rhythm, and its manifestation includes text prompts or control highlighting. Optionally, the first operation information may be an instruction guiding players to consume virtual resources to purchase experience points to upgrade the object's level, or it may be an instruction guiding players to save gold coins at specific round nodes to reach the interest level and thus prepare for subsequent upgrades. Considering that leveling up is the key way to unlock high-cost pieces in auto chess gameplay, as a possible implementation, the above-mentioned first operation information may specifically include the target level value and the expected amount of gold coins required. For example, the first operation information is manifested as a glowing border with an upward arrow around the upgrade control, accompanied by a text prompt to upgrade to level 7. If the player's current gold coins are insufficient to support a one-time upgrade, the first operation information may further include sub-step prompts for saving money strategies. It should be understood that in the mid-stage when the lineup is not yet formed, the first operation information and the second operation information generally point to different operational directions, the former focusing on long-term benefits and the latter focusing on short-term combat power. This disclosure embodiment does not limit the specific presentation form and decomposition logic of the first operation information.

[0095] Optionally, the second action information is used to indicate action suggestions for refreshing the shop to obtain immediate combat power in a critical situation, and its triggering priority is higher than that of the first action information.

[0096] Optionally, the second operation information can be an instruction guiding the player to spend gold to refresh the shop's chess piece pool, or it can be a combination of instructions further guiding the player to purchase specific transitional chess pieces. To avoid running out of gold without obtaining the required chess pieces due to blindly refreshing, the second operation information can calculate the required key transitional chess pieces based on the target lineup and currently held virtual objects when it is generated, and prompt the player to purchase only when the key chess piece is refreshed. In one implementation, the second operation information can be displayed as a highlighted animation with a looping arrow on the refresh control, and a specific visual label can be added to the recommended chess pieces in the shop area. It should be noted that the number of times the second operation information is executed can also be limited, for example, by setting a maximum number of refreshes based on the current remaining gold to prevent the player's economy from collapsing. This embodiment uses the second operation information as an alternative when health is critical, enabling the recommendation system to achieve a dynamic balance between pursuing long-term lineup formation and maintaining short-term survival, thus improving the robustness of the game recommendation.

[0097] In step S130, a target operation information is determined from at least one operation information, and the corresponding identifier information is displayed in the graphical user interface. In this way, by filtering out the target operation information from multiple operation information and displaying the corresponding identifier, the most urgent or optimal operation suggestion can be focused on, reducing the player's decision-making cost among multiple options and intuitively guiding the player to perform the correct transition operation.

[0098] In one implementation, at the start of each round, the system outputs multiple action options using a predictive model, such as "Buy 1-cost piece A," "Upgrade the shop," and "Refresh the shop." The system calculates the priority of these actions based on the current state, identifying the highest priority "Buy 1-cost piece A" as the target action. Subsequently, in the shop area of ​​the graphical user interface, the action corresponding to the 1-cost piece A is highlighted, and a highlighted thumbs-up icon is displayed above it as an identifier, prompting the player to prioritize purchasing this piece. The target action information indicates the highest priority or most strategically sound action suggestion for the current game round.

[0099] Optionally, the target operation information can be one of the following operation types: guiding the purchase of a specified virtual object or equipment, guiding the upgrade of an object's level, guiding the refresh of the shop, or guiding the allocation of virtual equipment. Considering that auto chess games may face multiple feasible operation paths during the transition phase (the stage from the current state to the desired state), to avoid players experiencing difficulty in choosing and thus slowing down the game's pace, the system uses a multi-evaluator parallel dynamic scoring mechanism to score various candidate operations. This is combined with resource budget simulation and a final safety check to ultimately select the operation that maximizes benefits under current resource constraints and does not violate safety guidelines as the target operation information. It should be noted that the determination of the target operation information depends not only on the basic score but also on the adjustment of the mode correction coefficient, allowing the same operation to receive a smoothly changing priority across different game stages. Furthermore, when a high-risk state is detected, the system will forcibly remove inactive candidates and supplement them with high-priority default candidates, ensuring that the target operation information always has substantial transitional guidance significance.

[0100] Optionally, the logic for determining target action information can be dynamically adjusted based on player preferences or operational mode identifiers. For example, in win-loss or loss-loss economic operation modes, the system may assign higher correction coefficients to actions such as "saving money without doing anything" or "refreshing the shop to find key pieces," thus identifying them as target action information. If multiple actions have the same score, the system can further sort them based on resource consumption or lineup synergy, selecting actions with lower resource consumption or higher lineup synergy as the final target action information. This design ensures that the generation process of target action information possesses both the stability of deterministic rules and the flexibility to adapt to complex and ever-changing game environments, effectively improving the accuracy and practicality of the recommendations.

[0101] The identification information is used in the graphical user interface to intuitively indicate the target operation and the suggested operation type. Optionally, the identification information can be presented as a highlighted thumbs-up icon, a gray transition label, a dynamic arrow, or a text prompt. To lower the barrier to entry for novice players and enhance the prominence of visual guidance, the identification information can be directly overlaid on the target operation, such as displaying a glowing border or thumbs-up icon on a chess piece card to be purchased in the shop, or displaying a dynamic arrow on an empty slot in the preparation area. At different game stages, the display parameters of the identification information can be dynamically switched according to the urgency of the operation; for example, high-priority operations use a bright red flashing light, while medium- and low-priority operations use a static, soft lighting effect. It should be noted that the above description of the identification information format is only one example, and this disclosure does not intend to limit the visual representation of the identification information; in actual implementation, it can be adapted to the overall art style of the interface.

[0102] In an optional implementation, determining the target operation information from at least one set of operation information includes: determining the priority of each operation information among the at least one set of operation information based on the current state of the target game; and determining the operation information with the highest priority as the target operation information. In this way, by dynamically evaluating the priority of each operation information in conjunction with the current state and filtering out the highest priority target operation information, it can be ensured that the displayed operation suggestions best match the current game situation, thereby effectively improving the accuracy and real-time performance of the recommendations and avoiding resource waste caused by inappropriate operation guidance.

[0103] In one implementation, after the system generates multiple candidate operation information, including upgrading the shop, refreshing the shop, and purchasing specific pieces, through a predictive model or evaluator, it does not display all of them directly. Instead, it comprehensively evaluates them based on the player's current health, gold, win streak, and loss streak data. For example, when the player's health is healthy and they are on a winning streak, the system may give a higher priority to the operation information "save money to upgrade level"; while when the system detects that the player's health is below a danger threshold, it will dynamically adjust and give a higher priority to the operation information "refresh the shop and purchase pieces to improve immediate combat power," and highlight it as the target operation information on the interface.

[0104] Optionally, priority is used to characterize the urgency of executing operational information, and can be expressed in various forms such as numerical values, levels, or sorting numbers. Optionally, the process of determining the above priority can involve multi-dimensional feature combinations and parameter calculations to achieve a scientific and smooth evaluation of operational suggestions. Specifically, for each type of candidate operation (e.g., upgrade, purchase, refresh, sell, etc.), its base score in the current state can be calculated first, which reflects the urgency of the operation itself; then, based on the current state conditions (e.g., health range, win / loss streak range) and the operation mode identifier, the corresponding mode correction coefficient is retrieved from the preset mapping relationship; finally, the base score and the mode correction coefficient are multiplied to obtain the final score of the operational information, which can be used as a quantitative representation of priority. Considering that traditional hard-coded rules are prone to sudden priority changes during stage switching, a continuous multiplication correction mechanism is adopted, which enables the same operation to obtain a smoothly changing priority in different game stages, thereby improving the consistency and rationality of the recommendation results.

[0105] Optionally, after calculating the priority of each operation, a resource budget simulation and security final check mechanism can be introduced to ensure that the final highest priority operation is resource-feature-capable and does not violate bottom-line constraints in terms of security. In one specific approach, candidate operations can be sorted in descending order of priority score, and virtual resources (such as gold coins) can be deducted sequentially for budget simulation. If the resources required for a high-priority operation exceed the current budget, it is removed. Simultaneously, for multiple candidates of the same operation object, only the highest priority one is retained for deduplication. Furthermore, if a high-risk state is currently hit (such as extremely low health), the system can forcibly remove low-priority or negative candidates such as "saving money without action," and forcibly fill the empty list with a high-priority default candidate. It should be noted that the above resource budget and security verification logic is only one example. This disclosure does not aim to exhaustively limit the post-processing flow of priority filtering. In actual implementation, other filtering rules can be introduced based on experience or specific application conditions.

[0106] Optionally, the aforementioned priorities not only serve as intermediate parameters for internal decision-making but can also be directly or indirectly mapped to the graphical user interface to assist players in understanding the recommendation logic. Different priority indicators can be loaded and displayed at different running or game stages, and their display parameters can be dynamically switched according to the state. For example, the interface can simultaneously display priority labels (such as star ratings and color gradients) for players to choose from; when the priority of a certain operation is significantly higher than others, it can be directly guided to the player through highlighting, animations, or other prominent display methods. If priorities are tied under normal circumstances, a secondary sort can be performed based on the historical usage frequency or resource consumption of the operation type. It should be understood that the presentation form and triggering timing of priorities are diverse; they can be statically displayed at the beginning of each round or dynamically refreshed when the player opens a specific panel. This disclosure does not limit this aspect.

[0107] In an optional implementation, displaying the identifier information corresponding to the target operation information in the graphical user interface includes highlighting the operation object corresponding to the target operation information in the graphical user interface. This highlights the operation object, intuitively guiding players to focus on the specific operation to be performed, reducing information filtering costs, and improving operation efficiency and interactive experience. In one implementation, when the system recommends that a player purchase a one-cost piece A as a transition in the current round, the icon of piece A can be highlighted in the shop interface, and a gray transition label can be added to its corner, thereby guiding the player to quickly complete the purchase.

[0108] The presentation of highlighted elements can take many forms, but it at least partially includes visual enhancements to differentiate between different types of actions. Considering that players need to quickly locate action targets during intense gameplay, one possible implementation is to change the display color of the action object, increase its brightness, add borders or glowing effects, or overlay specific graphic markers on it. For example, a highlighted thumbs-up icon could be used to indicate the pieces needed for the final lineup (i.e., the target lineup); a gray transition label could be used to indicate the pieces needed for the transition. It should be noted that the above description of specific forms of highlighted elements is merely one example and is not intended to limit the composition of this feature. In actual implementation, it can be flexibly configured according to the overall art style of the interface or the urgency of the operation, and multiple visual techniques can be combined to enhance the guidance effect.

[0109] Optionally, the specific style of the highlighted text can be dynamically switched according to the role of the manipulated object in the target lineup to achieve more refined guidance. One objective of this embodiment is to reduce the cognitive burden on players in distinguishing between core pieces and transitional pieces through differentiated visual presentation, and to avoid resource waste due to misoperation. Specifically, in the graphical user interface, if the manipulated object is a core virtual object that needs to be retained until its final state, a continuously flashing highlight effect can be applied to it; if the manipulated object is a temporary virtual object used only for transitional rounds, a static semi-transparent mask or a specific color filter can be applied to it. Different display parameters can be loaded at different game stages, and its display intensity can be dynamically adjusted according to the urgency of the current round, thereby ensuring visual guidance while avoiding overly complex interface elements that interfere with the player's core gaming experience.

[0110] According to one embodiment of the information processing apparatus of this disclosure, a graphical user interface is provided through a terminal device. The graphical user interface displays a virtual scene of a target game match in which a first game account participates. The target game match includes multiple game rounds, such as... Figure 2 As shown, the device may include: Module 201 is configured to acquire the target lineup and the status data of the first game account in the current game round. The determination module 202 is configured to determine at least one operation information based on the target lineup and status data, wherein the at least one operation information is used to indicate an operation suggestion for at least one intermediate round from the current state to the target lineup; The display module 203 is configured to determine target operation information from at least one operation information and display the identification information corresponding to the target operation information in the graphical user interface.

[0111] In this way, by dynamically determining and displaying operation suggestions for intermediate rounds from the current state to the target lineup based on the target lineup and the current game round status data, it helps to reduce blind operations and redundant commands caused by the lack of guidance in the middle stage, reduces the data processing pressure caused by the terminal to handle invalid operation requests, and improves the accuracy of operation guidance and human-computer interaction efficiency.

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

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

[0114] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.

[0115] The following is a detailed reference. Figure 3 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0116] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0117] In particular, according to one embodiment of this disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this disclosure includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication device 1209, or installed from memory 1208, or installed from ROM 1202. When the computer program is executed by processor 1201, it performs the functions defined in the methods described above in various embodiments of this disclosure.

[0118] Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0119] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0120] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

Claims

1. An information processing method, characterized in that, The method includes providing a graphical user interface (GUI) via a terminal device, the GUI displaying a virtual scene of a target game match in which a first game account participates, the target game match comprising multiple game rounds, and the method comprising: Obtain the target lineup and the status data of the first game account in the current game round; Based on the target lineup and the status data, at least one operational information is determined, wherein the at least one operational information is used to indicate operational suggestions for at least one intermediate round from the current state to the target lineup; The target operation information is determined from the at least one operation information, and the identification information corresponding to the target operation information is displayed in the graphical user interface.

2. The method according to claim 1, characterized in that, The status data includes at least one of the following: Current round number, number of virtual resources, object level, virtual objects already held, virtual equipment already held, current health, synergy status, win streak status, loss streak status, available slots, interest tier.

3. The method according to claim 1, characterized in that, The step of determining at least one piece of operational information based on the target lineup and the status data includes: Input the target lineup and the state data into the prediction model; The prediction model infers from the target lineup and the state data to output at least one operational information.

4. The method according to claim 1, characterized in that, The method further includes: If the preset triggering conditions are met, the at least one operation information is updated according to the current state of the target game match and the target lineup.

5. The method according to claim 4, characterized in that, The preset triggering conditions include at least one of the following: Reach the preset round interval; A preset trigger operation for the adjustment control was detected; The change in the state data corresponding to at least one operation information before the adjustment of the current state of the target game match is detected to meet a preset condition. The system detects that a change in a target factor during a game exceeds a preset threshold. The target factor includes the probability of a shop refresh or the strength of the opponent.

6. The method according to claim 4, characterized in that, The step of updating at least one operation information based on the current state of the target game match and the target lineup when the preset triggering conditions are met includes: If the current health value is detected to be less than the health value threshold, the first operation information in the at least one operation information is corrected to the second operation information, wherein the first operation information is to guide the upgrade object level, and the second operation information is to guide the refresh of the store.

7. The method according to claim 1, characterized in that, Determining the target operation information from the at least one operation information includes: Based on the current state of the target game match, determine the priority of each operation information among the at least one operation information; The operation information with the highest priority is determined as the target operation information.

8. The method according to claim 1, characterized in that, The acquisition of the target lineup includes: Obtain information on virtual objects and / or special resources currently held by the first game account; Based on the currently held virtual object data and / or special resource information, generate at least one candidate lineup; In response to the selection operation for the at least one candidate lineup, the target lineup is determined.

9. The method according to claim 8, characterized in that, The special resource information includes a first resource that strengthens a specified bond or a second resource that provides additional benefits to a specified virtual object; The step of generating at least one candidate target lineup based on the currently held virtual object and / or special resource information includes: Based on the first resource or the second resource, select candidate target lineups from the preset lineup library that are centered around the specified synergy or the specified virtual object.

10. The method according to claim 1, characterized in that, The graphical user interface displays the identification information corresponding to the target operation information, including: The operation object corresponding to the target operation information is highlighted in the graphical user interface.

11. An electronic device, characterized in that, include: Processor, memory, and computer program instructions stored in said memory and executable on the processor; When the processor executes the computer program instructions, it implements the information processing method as described in any one of claims 1 to 10.

Images