Information processing method and electronic device

Abstract

This disclosure provides an information processing method and an electronic device. The method displays a first type of game resources and a second type of game resources in a second game screen using a first display mode and a second display mode, respectively. It also configures differentiated virtual resource consumption logic for the two types of game resources, enabling the fusion and display of different resource information within the same game stage. Players can flexibly choose between the two types of resources based on their own strategic needs, enriching the interaction dimension and the strategic dimension of the game, improving the flexibility of resource allocation, and enhancing the interactive experience and system processing 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, resource selection phases are typically inserted at different stages of the game to balance the game situation. The system centrally generates shared rewards, which are then selected by the participating players according to certain rules to achieve resource compensation. During this process, the terminal device renders and displays these selectable resources and allocates them in response to player selections.

[0003] However, the resource selection mechanism of related technologies is relatively simple and the interaction path is fixed, resulting in low strategic depth and player participation experience during the resource selection phase. Players may generate invalid interaction requests due to the inability to match suitable resources, increasing the data processing pressure and signaling overhead of the terminal during phase switching, and making it difficult to match diverse resource allocation needs. 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, comprising: displaying a first game screen corresponding to a first game account in a first game stage through a graphical user interface; when a game match meets preset stage conditions, controlling a jump from the first game stage to a second game stage, and displaying a second game screen corresponding to the first game account in the second game stage through the graphical user interface, wherein the first game stage is different from the second game stage, and the second game stage is configured to determine a target game resource from game resources provided in the second game stage in response to selection instructions from multiple game accounts participating in the game match; displaying a first type of game resource in the second game screen through a first display method, and displaying a second type of game resource through a second display method; the first display method is configured to display first type of resource information of the first type of game resource; the second display method is configured to display second type of resource information of the second type of game resource; when a selection instruction for the first type of game resource is detected, controlling the allocation of the target game resource corresponding to the selection instruction to the first game account without consuming the virtual resources of the first game account; when a selection instruction for the second type of game resource is detected, controlling the allocation of the target game resource corresponding to the selection instruction to the first game account and consuming the virtual resources of the first game account.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, comprising: a first display module for displaying a first game screen corresponding to a first game account in a first game stage via a graphical user interface; a first control module for controlling a jump from the first game stage to a second game stage when a game meets preset stage conditions, and displaying a second game screen corresponding to the first game account in the second game stage via a graphical user interface, wherein the first game stage is different from the second game stage, and the second game stage is configured to determine a target game resource from game resources provided in the second game stage in response to selection instructions from multiple game accounts participating in the game; and a second display module for displaying a second game screen. The interface displays a first type of game resource through a first display method and a second type of game resource through a second display method. The first display method is configured to display the first type of resource information of the first type of game resource. The second display method is configured to display the second type of resource information of the second type of game resource. A second control module is used to, when a selection instruction for the first type of game resource is detected, control the allocation of the target game resource corresponding to the selection instruction to the first game account without consuming the virtual resources of the first game account. The second control module is also used to, when a selection instruction for the second type of game resource is detected, control the allocation of the target game resource corresponding to the selection instruction to the first game account and consume the virtual resources of the first game account.

[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, comprising: displaying a first game screen corresponding to a first game account in a first game stage through a graphical user interface; when a game meets preset stage conditions, controlling a jump from the first game stage to a second game stage, and displaying a second game screen corresponding to the first game account in the second game stage through the graphical user interface, wherein the first game stage is different from the second game stage, and the second game stage is configured to determine a target game resource from the game resources provided in the second game stage in response to selection instructions from multiple game accounts participating in the game; displaying a first type of game resource in the second game screen through a first display method, and displaying a second type of game resource through a second display method; the first display method is configured to display first type of resource information of the first type of game resource; the second display method is configured to display second type of resource information of the second type of game resource; when a selection instruction for the first type of game resource is detected, controlling the allocation of the target game resource corresponding to the selection instruction to the first game account without consuming the virtual resources of the first game account; when a selection instruction for the second type of game resource is detected, controlling the allocation of the target game resource corresponding to the selection instruction to the first game account and consuming the virtual resources of the first game account. In this way, by providing resource options with different information visibility and resource consumption mechanisms on the same interface, players can flexibly choose between two types of resources based on their own strategic needs, enriching the interaction and strategic dimensions of the game and improving the flexibility of resource allocation. At the same time, the differentiated display and consumption mechanisms help guide players to make effective decisions, reduce invalid interaction requests processed by the terminal during the resource selection phase, and reduce data processing pressure. Attached Figure Description

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

[0011] Figure 1 A flowchart illustrating an information processing method provided in one exemplary embodiment of this disclosure is shown. Figure 2 This diagram illustrates an application scenario of an information processing method provided by one exemplary embodiment of the present disclosure. Figure 3 This diagram illustrates the structure of an information processing apparatus provided in one exemplary embodiment of the present disclosure. Figure 4 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0012] 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, 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, chat, visit their homes, and delete them. Other games include quest-related controls, such as displaying a list of current quests, including main 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, such as Figure 1 As shown, the method may include: Step S110: Display the first game screen corresponding to the first game account in the first game stage through the graphical user interface; Step S120: When the game meets the preset stage conditions, control jump from the first game stage to the second game stage, and display the second game screen corresponding to the first game account in the second game stage through the graphical user interface. The first game stage is different from the second game stage. The second game stage is configured to determine the target game resource from the game resources provided by the second game stage in response to the selection instructions of multiple game accounts participating in the game. Step S130: In the second game screen, display the first type of game resources using a first display method and display the second type of game resources using a second display method; the first display method is configured to display the first type of resource information of the first type of game resources; the second display method is configured to display the second type of resource information of the second type of game resources. Step S140: When a selection instruction for the first type of game resource is detected, the target game resource corresponding to the selection instruction is assigned to the first game account without consuming the virtual resources of the first game account. In step S150, when a selection instruction for the second type of game resource is detected, the control assigns the target game resource corresponding to the selection instruction to the first game account and consumes the virtual resources of the first game account.

[0021] According to one embodiment of this disclosure, by providing resource options with different information visibility and resource consumption mechanisms on the same interface, the interaction dimensions are enriched and the flexibility of resource allocation is improved. Simultaneously, the differentiated display and consumption mechanisms help guide players to make effective decisions, reduce invalid interaction requests processed by the terminal during the resource selection phase, and lower data processing pressure.

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

[0023] In step S110, the first game screen corresponding to the first game account in the first game stage is displayed through the graphical user interface. This provides players with intuitive visual feedback on the current game stage, ensuring that players can clearly grasp the current stage of the game and providing a smooth visual transition basis for subsequent stage switching.

[0024] For example, when a player participates in a multiplayer auto chess game as the first game account, the terminal device renders and displays the game screen of that account in real time through a graphical user interface such as the screen. For instance, if the current stage is the preparation phase of the first major round, the interface displays the chessboard, the waiting area, and the shop area. Players can place pieces or purchase characters on this screen, and the screen displayed at this time is the first game screen corresponding to the first game phase.

[0025] Optionally, the first game phase may include multiple different sub-phases to provide an interactive environment for resource accumulation and lineup adjustments before the second game phase is triggered. Optionally, the first game phase can be a regular battle preparation phase or an automatic battle phase in an auto chess game, or other phased processes requiring lineup adjustments, resource acquisition, or battle settlement. Considering the rhythmic and phased characteristics of auto chess gameplay, this phase is typically configured to allow players to perform actions such as purchasing virtual pieces, adjusting piece positions, upgrading account levels, or refreshing the shop. At the graphical user interface level, the first game screen corresponding to the first game phase usually displays interactive controls such as a virtual chessboard, a preparation area, and a resource information bar, allowing players to intuitively view their current virtual resources and lineup status. It should be noted that the above description of the specific execution content of the first game phase is only one example and is not intended to exhaustively limit its composition. In actual implementation, different sub-phases can be dynamically divided according to the progress of the total number of rounds in the game, as long as they can provide a basis for accumulating state parameters for the subsequent second game phase.

[0026] In step S120, when the game meets the preset stage conditions, the system controls the transition from the first game stage to the second game stage. A second game screen corresponding to the first game account in the second game stage is displayed via a graphical user interface. The first game stage differs from the second game stage; the second game stage is configured to determine target game resources from the game resources provided in response to selection commands from multiple game accounts participating in the game. This automatic transition to the second game stage and display of the corresponding screen when the preset stage conditions are met achieves a smooth transition between game stages. Simultaneously, the second game stage's response to multiple selection commands to determine target game resources allows resource allocation to combine rhythm control and interactive gameplay, enhancing strategic depth and interactive coherence.

[0027] In one implementation, taking an 8-player auto chess game as an example, when the game progresses to a specified number of rounds (e.g., after every 3 rounds), the preset stage conditions are met, and the system automatically controls the transition from the battle stage (i.e., the first game stage) to the draft stage (i.e., the second game stage), simultaneously displaying the draft scene (i.e., the second game screen) on the graphical user interface of all players. In this draft scene, the 8 players, according to their respective health parameters from low to high, sequentially gain the right to choose. Each player can select one of the 10 game resources provided by the system as their target game resource. Game resources selected by the preceding player are removed from the candidate list, and subsequent players cannot select them again, thus ensuring that each resource is uniquely assigned.

[0028] Optionally, preset stage conditions are used to trigger automatic switching of game stages, which can be determined based on the number of rounds, time points, or the occurrence of specific events.

[0029] Optionally, the preset stage condition can be related to the round progress of the game. For example, in auto chess gameplay, the preset stage condition can be set to trigger after a specified number of rounds, such as after every 3 rounds. It can also be set to trigger at fixed round nodes (such as round 3, round 6, round 9, etc.). It should be noted that the above description of the number of rounds is only one example and is not intended to limit the specific parameters of the trigger condition. In actual implementation, the preset stage condition can also be set to be associated with specific game events according to the design needs of the game rhythm, such as triggering a stage jump when a player's faction reaches a specified size or when the resources in the public resource pool are consumed below a specified threshold, thereby flexibly adapting to the rhythm control needs of different gameplay modes.

[0030] Optionally, preset stage conditions can also be determined based on time or a combination of dimensions. As one possible implementation, preset stage conditions can be set to be met after a specified time (e.g., 120 seconds) following a jump from the previous stage. This approach is suitable for real-time or semi-real-time games without fixed round divisions. As another implementation, preset stage conditions can be determined by combining the number of rounds and player status. For example, a jump can be triggered only when the number of rounds reaches a specified value and at least one player's health parameter value is below a preset threshold. Considering that player progress may vary in different game matches, multi-dimensional combined judgments can prevent premature jumps before players have completed the core operations of the current stage, thereby improving the rationality of stage transitions and the continuity of the player experience.

[0031] Optionally, the second game phase can be configured to determine the target game resources in response to selection commands from multiple game accounts, which is different from the combat gameplay of the first game phase.

[0032] Optionally, the second game phase can be the draft phase in auto chess gameplay, where the system centrally distributes public rewards (i.e., game resources) for multiple participating game accounts to choose from in a predetermined order. In this phase, the system provides a batch of game resources to all participating game accounts, and each account selects one resource as its target resource according to a predetermined selection order. It should be noted that the specific form of the second game phase is not limited to the draft phase; it can also be other phases requiring multiple parties to choose resources sequentially or simultaneously, such as equipment allocation, talent selection, or lineup adjustment. The second game phase differs fundamentally from the first game phase in its gameplay mechanics. The first game phase focuses on automatic combat or strategic formation, while the second game phase focuses on resource selection and allocation; the two alternate to form a complete game cycle.

[0033] Optionally, the duration or number of rounds of the second game phase can be dynamically adjusted according to the progress of the game. As one possible implementation, the second game phase can be configured as a single-round selection, where each game account performs only one selection operation before ending the phase and returning to the first game phase. Alternatively, the second game phase can be configured as a multi-round selection, providing different batches of game resources for selection in each round, and returning to the first game phase after multiple rounds. In the second game phase, the second game screen displayed by the graphical user interface can include a selection interface or a virtual scene. The selection interface displays all available game resources in a list or grid format, while the virtual scene presents game resources in designated locations within a three-dimensional or two-dimensional scene for game accounts to select through interactive operations.

[0034] Optionally, the game resources include a first type of game resources displayed in a first display mode and a second type of game resources displayed in a second display mode.

[0035] Optionally, game resources can include two main categories: deterministic free rewards and paid unknown rewards. Deterministic free rewards correspond to the first category of game resources. Their resource information is fully visible to all game accounts, including specific details such as the pieces' rarity and equipment types. Selecting this type of resource does not consume any virtual resources. Paid unknown rewards correspond to the second category of game resources. They only display a resource type identifier (such as "piece" or "equipment") while hiding the specific resource content. Game accounts need to consume a specified amount of virtual resources to obtain them, and their specific content is displayed after acquisition. It should be noted that the specific types and quantities of game resources can be flexibly configured according to the gameplay design. For example, one implementation may provide 8 deterministic free rewards and 2 paid unknown rewards, totaling 10 resources; another implementation may provide 6 deterministic free rewards and 4 paid unknown rewards, also totaling 10 resources. This disclosure is not intended to limit the specific quantity or ratio of resources.

[0036] Optionally, the first and second categories of game resources can employ different configuration strategies in terms of rarity distribution. As one possible implementation, the overall expected rarity of the second category of game resources (i.e., paid unknown rewards) can be higher than that of the first category (i.e., deterministic free rewards), reflecting the game design philosophy that higher risk equates to greater potential reward. For example, the probability of high-rarity pieces appearing in paid unknown rewards can be set higher than the probability of high-rarity pieces appearing in deterministic free rewards. As another implementation, the rarity distribution of the two categories of game resources can remain consistent, but the second category of game resources can include a certain probability of special resources (such as rare equipment or synergy items), adding an extra element of surprise to the paid selection. By differentiating the rarity distribution, diverse strategic choices can be provided to game accounts while maintaining fairness in resource acquisition.

[0037] Optionally, the generation and allocation of game resources can be centrally executed by the server and synchronized to all game accounts participating in the game. At the start of the second game phase, the server generates a batch of game resources according to preset resource pool configuration rules and distributes the resource list to the clients of each game account for display. When a game account executes a selection command, the server updates the resource status (marking the selected resource as already owned) and synchronizes the updated resource list to the other game accounts to ensure that all game accounts see consistent available resources.

[0038] Optionally, the selection instruction is used to instruct the game account to select the target game resource from the game resources, and is generated by receiving the trigger operation through the graphical user interface.

[0039] Optionally, selection commands can be generated by the user performing a trigger operation on the graphical user interface. As one possible implementation, the user can generate a selection command by clicking or long-pressing the card area corresponding to the game resource. After detecting this trigger operation, the system determines whether the game resource is selectable (i.e., not selected by other game accounts and the current game account has selection permission). If the conditions are met, the game resource is identified as the target game resource and assigned to that game account. As another implementation, selection commands can be generated through drag-and-drop operations, whereby the user drags the target game resource to a designated area (such as a confirmation button or the account inventory area) to complete the selection. It should be noted that the triggering method for selection commands is not limited to the above examples and can also include alternative methods such as voice commands, shortcut key triggers, or automatic selection. The specific configuration can be flexibly tailored according to the input capabilities of the terminal device and the game interaction design, and this disclosure does not impose any limitations on this.

[0040] In an optional implementation, the method further includes: obtaining attribute parameter values ​​for each of the multiple game accounts corresponding to a game match, wherein the attribute parameter values ​​represent the current state parameters of the corresponding game account in the game match; and sorting the multiple game accounts according to the attribute parameter values ​​to determine the selection order. In this way, by obtaining attribute parameter values ​​and sorting them to determine the selection order, the current state of each account in the game can be objectively reflected, thereby providing a reasonable basis for subsequent resource allocation and ensuring the fairness and strategic nature of the game compensation mechanism.

[0041] In one implementation, when a game in Auto Chess reaches a certain round and meets preset stage conditions, the system triggers a draft phase. Before the draft phase begins, the server obtains the current health value of each of the eight players participating in the game as attribute parameter values. The system then arranges these eight players' health values ​​in ascending order, generating a corresponding selection order list. For example, if player A has 20 health and player B has 80 health, player A will be ranked before player B and will have priority in selecting game resources. This ranking method based on attribute parameter values ​​ensures that players in a disadvantageous position can obtain resource selection opportunities earlier.

[0042] Optionally, attribute parameter values ​​are used to quantify the overall performance or survival status of a game account in a match, serving as benchmark data for ranking.

[0043] Optionally, attribute parameter values ​​can be health values ​​that directly reflect the game account's survival status, economic values ​​that reflect the game account's economic development, or win / loss streaks that reflect the game account's recent combat performance. It should be noted that the above description of specific attribute parameter value types is merely one example and is not intended to limit the scope. Considering the complexity of player situations in auto chess gameplay, to avoid a single parameter failing to comprehensively measure a player's true disadvantage, as a possible implementation, the aforementioned attribute parameter values ​​can also be a comprehensive score obtained by weighting multiple different current status parameters according to preset weights. For example, the system can simultaneously acquire the player's health and gold parameters, assigning a higher weight to the health parameter to calculate a comprehensive situation score. Through this multi-dimensional parameter acquisition and calculation method, game accounts that truly need resource compensation can be more accurately identified, making the selection order more scientific and reasonable, and avoiding unfairness that may result from relying on a single indicator.

[0044] Optionally, the timing of acquiring attribute parameter values ​​can be dynamically set according to the game phase transition nodes. Before the game transitions from the first game phase to the second game phase, the system can automatically read the latest attribute parameter values ​​of each game account from the game engine's underlying database. One objective of this embodiment is to ensure that the attribute parameter values ​​used for sorting accurately reflect the player's latest state after the previous round of combat by synchronizing data at the critical point of phase transition. If an anomaly occurs where certain special skills or items cause attribute parameter values ​​to change at the moment of transition, the system can further verify this through a secondary verification mechanism. In other words, the system can not only acquire the values ​​once before the phase transition but also monitor and update them in real time during the loading of the second game screen to ensure that the selection order list displayed to the player is generated based on the most accurate data, thereby improving the reliability of the interaction and the player's trust.

[0045] Optionally, the current status parameters include, but are not limited to, survival parameters, economic parameters, or combat performance parameters, which are used to dynamically reflect the real-time situation of the account.

[0046] Optionally, current status parameters can specifically include survival parameters (such as health points and shield points), economic parameters (such as the amount of virtual resources currently held and the expected interest resources), and combat performance parameters (such as winning streaks, losing streaks, or total damage dealt). In the auto chess battle environment, different types of current status parameters depict the player's situation from different dimensions. Considering that a player's disadvantage in the game may manifest in multiple ways—for example, some players may have low health but abundant resources, while others may have decent health but be on a losing streak—to avoid the limitations of relying solely on health for compensation, the above method can employ different sorting rules based on the specific type of current status parameters when determining the selection order. For example, survival parameters can be compared first, and combat performance parameters can be compared only when survival parameters are similar. It should be understood that the types and combinations of current status parameters can be flexibly configured according to the actual game mechanics, thereby providing rich data support for determining the selection order and making the compensation mechanism more closely aligned with the actual game experience.

[0047] Optionally, the current status parameters are not limited to objective data automatically collected by the system, but may also include dynamic status markers related to player behavior. For example, current status parameters may include information such as whether the player used specific strategy items or triggered special synergy effects in the previous game phase. This information can be used as additional current status parameters to assist in sorting when the main attribute parameter values ​​are the same. It should be noted that the above extended description of current status parameters aims to broaden the applicability of the solution, and this disclosure is not limited to this. In actual implementation, it can be determined based on experience or specific application conditions. In the extreme case where multiple game accounts have completely identical core current status parameters, the system can further introduce a random number generation mechanism or fine-tune the sorting based on secondary parameters such as the game account's creation timestamp to ensure that each game account receives a unique and clear selection order, thereby ensuring the smooth progress of the entire selection process and avoiding logical stuttering or player disputes caused by sorting conflicts.

[0048] In an optional implementation, the method involves obtaining the attribute parameter values ​​corresponding to multiple game accounts in a game match, including: obtaining the health parameter values ​​of the multiple game accounts as attribute parameter values; and sorting the multiple game accounts according to the attribute parameter values ​​to determine the selection order, including: sorting the multiple game accounts in ascending order of health parameter values ​​to determine the selection order, wherein game accounts with lower health parameter values ​​are selected earlier. In this way, by using health parameter values ​​as the specific sorting criterion for determining the selection order, players with lower health are given priority in selection, thus achieving precise situational compensation during the draft phase. Simultaneously, this works in conjunction with the increasing payment price curve to effectively suppress the snowball effect of advantageous players.

[0049] In one implementation, taking the draft phase of an 8-player auto chess game as an example: After the previous round's settlement, the system obtains the current health parameters of each of the 8 players, for example, player A has 32 health, player B has 78 health, player C has 15 health, etc. The system sorts the health parameters from lowest to highest, resulting in the following selection order: player C (15) → player A (32) → player B (78) → ... Player C, with the lowest health, gets the first pick and can choose from 10 rewards first or unlock a paid unknown reward at the lowest price. It should be noted that when two or more players have the same health parameter value, the system can further determine the relative order between these players according to auxiliary rules such as random allocation or the order of the previous round's end time, to ensure that each player has a unique and clear selection order.

[0050] Optionally, the health parameter value represents the remaining health of a game account in a match, and is used as a sorting basis to determine the selection order of each game account. The lower the health, the higher the selection order.

[0051] Optionally, the health parameter value can be the remaining health value of a game account after multiple rounds of automatic battle settlement in an auto chess game. This value is deducted or maintained at the end of each battle round based on the win or loss result. In one specific implementation, when the 8 players enter the draft phase, the system simultaneously reads the current health parameter value of each player. For example, player A has 28 remaining health, player B has 65 remaining health, and player C has 12 remaining health. The system uses these values ​​as specific values ​​for the attribute parameter and generates a selection queue in ascending order from smallest to largest. Players with lower health parameter values ​​mean they have accumulated more penalties for losing in the game and are in a more passive position. Placing them in a higher selection order allows them to prioritize choosing certain free rewards or unlocking paid unknown rewards at a lower cost in gold, thus achieving targeted compensation for the disadvantaged side. It should be noted that the initial value and deduction rules of the health parameter value can be flexibly configured according to the game mode. For example, the initial health value is 100 and 5 to 15 points are deducted for each round of loss. The above values ​​are just one example and are not intended to limit the specific value range.

[0052] Optionally, besides using health points as the sole sorting criterion, in cases where multiple game accounts have identical health points, the system can introduce auxiliary sorting parameters to further differentiate the selection order of these players. As one possible implementation, when at least two game accounts are detected to have equal health points, the system can obtain the win or loss streaks of these game accounts in the current match as auxiliary attribute parameters. Players with higher loss streaks receive a higher selection order because losing players are also at a disadvantage and require additional compensation. As another implementation, the system can also sort players based on the settlement timestamp of their previous match, with players whose settlement times were earlier receiving a higher priority. It should be understood that, in cases where health points are identical, regardless of whether loss streaks or timestamps are used as auxiliary criteria, the purpose is to ensure the uniqueness and certainty of the selection order, avoiding resource conflicts caused by multiple players triggering selection commands simultaneously. This embodiment does not limit the specific type of auxiliary sorting parameters.

[0053] In step S130, the first type of game resources is displayed in the second game screen using a first display method, and the second type of game resources is displayed using a second display method. The first display method is configured to display the first type of resource information of the first type of game resources; the second display method is configured to display the second type of resource information of the second type of game resources. In this way, by presenting two types of game resources side-by-side in the same game screen using differentiated display methods, players can simultaneously perceive deterministic rewards and unknown rewards within the same selection sequence, injecting a risk-reward trade-off dimension into resource selection, effectively enhancing the depth of strategic gameplay and the richness of the interactive experience.

[0054] In one implementation, the draft phase of an auto chess game is used as an example: When the game reaches a designated round, the system controls all participating players to jump from the battle phase to the draft phase, and displays a draft interface containing multiple resource items (e.g., ten resource items) in each player's graphical user interface. Eight resource items are presented in a first display mode—the card face up, fully displaying the piece's image, rarity indicator, and equipment type, allowing players to select directly without consuming any virtual resources. The other two resource items are presented in a second display mode—the card face down, only displaying the resource type indicator (e.g., "piece" or "equipment") and the current gold cost for that player; the specific details are hidden. When it's their turn to choose, players can freely select any one of these ten items, and the selected resource is immediately removed from the draft area. For example, the player with the lowest health is in the first position. When faced with ten resource items, they can either directly choose a high-rarity piece that is revealed, or spend less gold to open an unknown reward and gamble. Players in subsequent positions need to choose between the remaining revealed rewards and the more expensive unknown rewards.

[0055] Optionally, the first display method is used to present all resource information of the first type of game resources in a fully visible visual form, allowing players to fully understand the specific content and attributes of the rewards before making a choice. Optionally, the first display method can be a presentation format where the resource card is displayed face up, a presentation format where a complete text label is rendered directly around the resource icon, or a presentation format where a resource preview animation and an attribute value panel are superimposed simultaneously. It should be noted that the core feature of the first display method is to present the resource content of the first type of game resources completely transparently to the player, enabling the player to make a definitive decision based on complete information. In specific implementation, the first display method may include rendering a 3D model preview of the chess piece on the front area of ​​the resource card, rarity border color coding (e.g., gray for common, blue for rare, and purple for epic), and the type icon and attribute bonus value of the equipment. Furthermore, the first display method can also overlay a lineup compatibility indicator on a designated position on the resource card. For example, when the resource can form a synergy combination with the player's currently owned pieces, a highlighted indicator box will be displayed on the edge of the card, thereby helping the player quickly determine the degree of match between the certain reward and their own lineup, reducing decision-making costs.

[0056] Optionally, the first type of game resource can take the form of game character pieces, virtual equipment items, or buff tokens. In the auto chess draft phase, the first type of game resource can specifically manifest as piece cards with a specified rarity level, such as different pieces costing one to five gold, each piece carrying specific racial and class synergy attributes; it can also manifest as equipment items of different grades, such as basic attack equipment, defensive equipment, or special effect equipment. It should be noted that the quantity of the first type of game resource can be dynamically configured according to the stage of the game. For example, in the early draft rounds, eight first-type game resources and two second-type game resources can be configured, while in the later draft rounds, this can be adjusted to six first-type game resources and four second-type game resources to adapt to the increasing demand for high-risk games in the later stages of the game. The core feature of the first type of game resource is the complete transparency of its content information and the zero cost of acquisition, allowing players to make risk-free, deterministic matching choices.

[0057] Optionally, the generation of the first type of game resources can be determined by the server after comprehensive calculation based on the overall progress of the current game, the average lineup strength of all players, and the remaining distribution of the public resource pool. As one possible implementation, the server can draw a specified number of pieces from the public piece pool according to a preset probability distribution before the draft round begins, where the probability of high-rarity pieces appearing can be positively correlated with the current round number to ensure improved reward quality in later draft rounds. Alternatively, some items in the first type of game resources can be fixed as equipment resources, while others are piece resources, to ensure diversity in reward types, allowing players with different lineup development paths to find suitable deterministic rewards. One objective of this embodiment is to provide players with deterministic choices with actual strategic value while ensuring free access to the first type of game resources through reasonable configuration of the content composition and generation logic, avoiding situations where low-quality rewards lead to decreased player willingness to choose.

[0058] Optionally, the second display method is used to display the second type of game resources in a visual form where some information is visible and the core content is hidden, so that players cannot preview the specific content of the virtual resources before paying for them.

[0059] Optionally, the second display method can be a presentation where the card's back is facing up, a presentation where the resource icon is covered by a semi-transparent overlay, or a presentation where only the resource type text label is displayed while omitting specific attribute values. The core feature of the second display method is the selective or complete hiding of the resource content of the second type of game resources, while retaining the visibility of the resource consumption indicator. In specific implementation, the second display method can render a uniform question mark pattern or mystery treasure chest icon on the back area of ​​the resource card, along with the current gold coin value required for that player. Furthermore, a type text label such as "chess piece" or "equipment" can be overlaid below or to the side of the card. The second display method can also add dynamic light effects or particle effects to the edge of the card's back to visually attract players' attention to these unknown rewards, while differentiating them from the first type of game resources through the color of the light effects, allowing players to easily identify the differences between the two types of resources. It should be noted that the content hidden in the second display method includes, but is not limited to, the specific name, rarity level, and synergy attributes of the chess piece, as well as the specific type and attribute bonus values ​​of the equipment.

[0060] Optionally, considering that information asymmetry is the core design intent of the second display method, the issue of other players' observation permissions for the same second-type game resource also needs to be addressed at the specific interaction level. As one possible implementation, when a player selects a second-type game resource by paying for virtual resources, the resource's content is immediately unhidden and fully displayed to the purchaser, while simultaneously displaying the final content to all other players, ensuring that all players are aware of the actual result of the unknown reward. Before being selected by any player, the second-type game resource remains hidden from all players in the second display method, and no player can preview its content through any operation. One objective of this embodiment is to ensure that the unknown nature of the second-type game resource is not compromised before purchase through a strict information isolation mechanism, thereby maintaining the fairness and suspense of the risk-reward game. It should be understood that the specific position, size, and style of the resource type and resource consumption indicators displayed in the second display method can be flexibly adjusted according to the interface layout.

[0061] Optionally, the second type of game resource can take the form of hidden content chess piece cards, equipment items with hidden attributes, or mystery chests containing random quality rewards. In the auto chess draft scenario, the second type of game resource can specifically manifest as chess piece rewards with unknown content, which may yield chess pieces of various rarities ranging from low to high cost; or as equipment rewards with unknown content, which may yield equipment items of different tiers and types. It should be noted that the actual content of the second type of game resource can be predetermined and stored by the server at the start of the draft round (i.e., the second game phase), or it can be randomly generated in real time when the player triggers the selection command. Both methods can achieve the purpose of this solution. The number of second type game resources is usually less than that of first type game resources. For example, two second type game resources can be configured in ten total resource projects to control the scarcity and game value of unknown rewards. The core characteristics of the second type of game resource are its opacity and the fact that it is paid to obtain, making the selection of this type of resource a risky but potentially high-reward strategic behavior.

[0062] Optionally, the potential content quality distribution of the second type of game resources can be differentiated from that of the first type of game resources to reflect the principle of "risk and reward matching." As one possible implementation, the average rarity of pieces in the second type of game resources can be higher than that of pieces in the first type of game resources; that is, the expected value of unknown rewards is slightly better than that of deterministic rewards, thereby incentivizing players to take the risk of information asymmetry and make paid choices. Alternatively, the content pool of the second type of game resources can include special rare pieces or unique equipment not found in the first type of game resources, giving unknown rewards exclusive content that deterministic rewards cannot provide, further enhancing their attractiveness. One objective of this embodiment is to ensure that, by rationally designing the content distribution and expected quality of the second type of game resources, paid unknown rewards have strategic value that competes with free deterministic rewards, avoiding situations where the quality of unknown rewards is too low, causing players to completely ignore the option. It should be understood that the above description of content quality distribution is merely illustrative, and specific parameters can be configured according to game balance requirements.

[0063] Optionally, the first type of resource information is used to characterize the complete content attributes of the first type of game resource, which may include at least one of the following: resource name, rarity level, type identifier, and attribute parameters. Optionally, the first type of resource information may be a combination of the name of a chess piece character and its rarity color code, or a complete description of the name, type icon, and attribute bonus value of an equipment item. It may also simultaneously include multi-dimensional attribute data such as the chess piece's race synergy tag, class synergy tag, and skill name. It should be noted that the core feature of the first type of resource information lies in its completeness and visibility; that is, this information is completely transparent to the player in the first display mode, without any hiding or obfuscation. In specific implementation, the first type of resource information can be displayed in different areas of the resource card according to a preset information hierarchy. For example, the resource name is displayed at the top of the card, a visual preview model is displayed in the middle, and attribute values ​​and synergy tags are displayed at the bottom, allowing players to quickly scan and obtain the key information needed for decision-making. One objective of this embodiment is that, through the structured display of the first type of resource information, players can obtain all decision-related data of the first type of game resource without additional operation, reducing the cognitive load of information acquisition and improving selection efficiency. It should be understood that the specific information items included in the first category of resource information can be flexibly added or removed according to the game type and resource type.

[0064] Optionally, the second type of resource information is used to characterize some content attributes of the second type of game resource. This may include a resource type identifier and a resource consumption identifier, while hiding the specific content of the resource. Optionally, the second type of resource information can be a combination of a type text label for "chess piece" or "equipment" and a gold coin consumption value, or a visual combination of a resource type icon and a price label. It can also be overlaid with status prompts such as "unknown" or "mysterious." It should be noted that the essential difference between the second type of resource information and the first type lies in the difference in information completeness—the second type of resource information only displays the resource's category and acquisition cost, while hiding core decision-making information such as the resource's specific name, rarity, and attribute values. In specific implementation, the resource consumption identifier in the second type of resource information displays different values ​​for players with different selection priorities. For example, for the same second game resource, it displays "1 gold coin" for the first-priority player and "3 gold coins" for the third-priority player, ensuring that each player sees a personalized price at their selection moment. One objective of this embodiment is to enable players to conduct preliminary risk assessments and strategy judgments based on resource type and current price even in the absence of complete information, through the partial display of the second type of resource information and a dynamic pricing mechanism, thus providing a basic reference for subsequent payment decisions. It should be understood that the specific information items displayed and hidden in the second type of resource information can be adjusted and configured according to design requirements.

[0065] In an optional implementation, a first type of game resource is displayed in the second game screen using a first display method, and a second type of game resource is displayed using a second display method. This includes: displaying a selection interface in the second game screen, displaying the first type of game resource in the selection interface using the first display method, and displaying the second type of game resource in the selection interface using the second display method. By independently displaying the selection interface in the second game screen, both types of game resources are integrated into the same interactive view, allowing players to intuitively compare the attributes and acquisition costs of different resources, thereby improving decision-making efficiency and operational convenience during the resource selection phase.

[0066] In one implementation, when the game reaches the draft phase, the terminal device displays a selection interface that is either fully covered or partially popped up on the graphical user interface. This selection interface can be presented as a draft panel containing ten parallel card zones (each zone corresponding to a game resource). Eight zones display guaranteed free rewards in an open-ended manner, while the other two zones display unknown paid rewards hidden on the card backs, with the current price tag displayed below the card backs. Players can browse and select target cards within this selection interface by clicking or swiping.

[0067] Optionally, the selection interface is used to centrally display the first and second types of game resources. Its presentation can be a panel, a pop-up window, or an embedded area within the scene. Optionally, the selection interface can be a full-screen overlay independent of the virtual scene, a semi-transparent pop-up floating above the virtual scene, or an embedded panel integrated into a specific area of ​​the virtual scene (such as a sidebar at the scene edge). This selection interface is triggered when preset stage conditions are met in the game (e.g., the current round reaches a specified threshold or a specific battle stage ends). Regarding the layout of the selection interface, it can be arranged in a grid to display multiple resource cards side-by-side, or in a list format for players to scroll through. It should be noted that the above description of the selection interface's position and form is only one example. In actual implementation, it can be flexibly adjusted according to the screen size of the terminal device or the interface design requirements. This disclosure is not intended to limit it.

[0068] Optionally, considering that players need to quickly obtain key information and make decisions during the resource selection phase, the display logic of the selection interface can include various implementation methods. As one possible implementation, the selection interface can highlight currently selectable resource items, for example, by using a highlighted border or dynamic lighting effects, while graying out or removing resource items already selected by other game accounts. As another implementation, to avoid accidental touches due to overly dense interface elements, the selection interface can also display resource content in pages, or dynamically adjust the interface scaling based on the selection order of the current first game account. If network latency causes abnormal interface loading, the system can display a placeholder and refresh the specific content after data synchronization, thereby ensuring the closed loop and stability of the interaction process.

[0069] like Figure 2 As shown in an exemplary application of this embodiment, after a player enters the selection stage, a selection interface 200 pops up in the graphical user interface. The selection interface 200 displays eight first-type game resources 201 and two second-type game resources 202 in card format. The cards for second-type game resources 202 display a question mark icon and do not show the specific resource content. The cards for first-type game resources 201 do not display a question mark icon and do show the specific game resource content. If a player clicks to select a first-type game resource 201, the system directly assigns the resource to the first game account without deducting virtual resources. If a player clicks to select a second-type game resource 202, the system determines whether the player's current virtual resources are sufficient to cover the cost of the selected second-type game resource 202. If sufficient, the selected second-type game resource 202 is assigned to the first game account and the corresponding virtual resources are deducted. If insufficient, a message indicating insufficient virtual resources pops up.

[0070] In an optional implementation, the second game screen displays at least a portion of the virtual scene; the second game screen displays a first type of game resource through a first display method and a second type of game resource through a second display method, including: displaying the first type of game resource in the virtual scene through the first display method and displaying the second type of game resource through the second display method. This directly integrates the two types of game resources into the virtual scene, enhancing the immersion and spatial depth during resource selection, and allowing the differentiated display of different types of resources to be presented in a more natural game environment, thus improving the continuity of the interactive experience.

[0071] In one implementation, the virtual scene displayed in the second game screen can be a wraparound talent hall scene. Specifically, when the game enters the second game stage, namely the talent stage, the graphical user interface switches from the battle screen to a top-down view of the talent hall scene. In the central area of ​​this virtual scene, eight deterministic free rewards are arranged in the form of resource models floating on the ground, and players can clearly see the resource images and rarity indicators. Two paid unknown rewards are arranged in the form of treasure chest models floating on the ground, with gold coin price tags displayed on the top of the treasure chests. All treasure chest models and resource models are embedded in the three-dimensional space of the scene, and the player's view can be panned within the scene by dragging their finger to view these resources from different angles.

[0072] Optionally, the virtual scene is a three-dimensional or two-dimensional spatial environment that is at least partially presented in the second game screen, used to carry the spatialized display of the first type of game resources and the second type of game resources.

[0073] Optionally, the aforementioned virtual scene can be a spatial environment of various forms, such as a talent show hall, the central area of ​​a circular arena, or an extended area of ​​a chessboard. This virtual scene is loaded and displayed on the graphical user interface at the start of the second game phase, at least partially replacing or overlaying the battle screen of the first game phase. It should be noted that the spatial arrangement of the first and second types of game resources in the virtual scene can be flexibly configured according to design requirements. For example, the first type of game resources can be concentrated in the central area of ​​the scene for quick player browsing, while the second type of game resources can be placed at the edge of the scene or on a separate elevated platform to create visual separation, thereby strengthening the information difference between the two types of resources at the spatial level. One objective of this embodiment is that by migrating resource selection from a separate pop-up interface to an immersive virtual scene, on the one hand, the visual continuity of the game screen can be maintained, avoiding the disjointed feeling caused by interface switching; on the other hand, the spatial depth of the scene can be used to provide richer layers for resource display, allowing players to obtain a more immersive interactive experience during the selection process.

[0074] Optionally, besides the centralized arrangement mentioned above, resources in the virtual scene can also be distributed according to the path corresponding to the selection order. As one possible implementation, a circular or spiral guide path can be set up in the virtual scene, with eight first-category game resources arranged sequentially along this path, and two second-category game resources placed at the branch nodes of the path. The player's view moves along the path as the selection order progresses, with currently selectable resources highlighted and unselected resources dimmed. As another implementation, the virtual scene can also adopt a layered structure, with first-category game resources displayed on the ground layer of the scene, and second-category game resources suspended in the air layer, further distinguishing free and paid resources through height differences. It should be understood that the specific spatial layout of the virtual scene is not limited to the above examples. In actual implementation, it can be dynamically adjusted according to the scene's art style, the number of resources, and the player's viewing habits, as long as both types of resources are presented side-by-side in the same scene space and each maintains its corresponding display method.

[0075] In an optional implementation, the second type of game resources is displayed in the second game screen using a second display method. This includes displaying a resource type identifier and a resource consumption identifier for the second type of game resources in the second game screen, while hiding the resource content of the second type of game resources. The resource consumption identifier is used to identify the virtual resources required for the first game account to acquire the second type of game resources. By displaying the resource type identifier and resource consumption identifier while hiding the resource content, information asymmetry is created while ensuring players are aware of the reward categories and acquisition costs. This introduces a risk-based game dimension into the selection stage, enhancing the strategic depth.

[0076] In one implementation, when a player enters the draft phase, multiple reward items (i.e., multiple game resources) are displayed side-by-side on the interface. Two of these reward items are presented as blind boxes with their cards facing down. The upper area of ​​the card displays a resource type indicator labeled "Chess Piece," while the lower area displays a resource consumption indicator that costs 3 gold coins. At this point, the player cannot see which chess piece or its rarity is inside the blind box; they can only decide whether to risk selecting it based on their team composition needs, current gold reserves, and the cost indicated by the consumption indicator.

[0077] Optionally, the resource type identifier indicates the major category to which the second type of game resource belongs. Its presentation can be text, an icon, or a combination thereof, to assist players in making initial lineup matching decisions. Optionally, the resource type identifier can be a visual element used to distinguish the basic attributes of game resources, such as a "chess piece" icon or an "equipment" icon. Considering that players need to quickly assess the fit between rewards and their own lineup during the draft phase, as a possible implementation, the resource type identifier can be directly displayed at the top or edge of the card face of the second type of game resource. It should be noted that the resource type identifier is not limited to major category distinctions; it can also include more detailed sub-type hints, such as further indicating "attack equipment" or "defense equipment" with different background colors under the "equipment" type. This design provides players with a certain degree of decision-making basis without revealing the specific resource content, avoiding the frustration of completely blind selection, while maintaining the tension of information asymmetry in the game. In actual implementation, the display parameters of this identifier can be dynamically adjusted according to the resource rarity range; for example, the edge of the type identifier for blind boxes in the high rarity range can have a subtle glow effect.

[0078] Optionally, the resource consumption indicator is used to clearly indicate to players the amount of virtual resources required to acquire the second type of game resources. It can be dynamically presented in the form of numbers, progress bars, or color labels.

[0079] Optionally, the resource consumption indicator can be a dynamic numerical label bound to the player's current selection order. Considering the differences in resource reserves and situation between players with a disadvantage in going first and those with an advantage in going second, as a possible implementation, the value displayed by the resource consumption indicator can increase in a stepwise manner as the selection order progresses. For example, the indicator might display "1 gold coin" in the first position and "4 gold coins" in the fourth position. It should be noted that this increasing mechanism is not a simple linear addition; it can also use exponential or piecewise increases based on the overall economic curve of the game. One objective of this embodiment is to intuitively convey the acquisition cost through the resource consumption indicator, putting greater economic pressure on players going second when grabbing blind boxes, thereby compensating players with a disadvantage in going first at a numerical level. In the actual interface layout, this indicator is usually superimposed in a high-contrast color below the card face of the second type of game resource, ensuring that players can clearly capture the price information in a short time.

[0080] Optionally, in addition to reflecting the basic selection priority price, the resource consumption indicator can also be displayed differently based on the player's real-time economic status. To prevent players from failing to select or experiencing lag due to misjudging their own economy, the resource consumption indicator can be further linked to the current total amount of virtual resources in the first game account. Specifically, when the virtual resources currently held by the player are less than the amount indicated by the resource consumption indicator, the indicator can be grayed out and unselectable, or accompanied by a "Resources Insufficient" message; when the amount held is sufficient, it will be highlighted and interactive. Furthermore, in one implementation, if selecting this second type of game resource will cause the player's virtual resources to fall below the operational safety line for subsequent stages, a warning icon can be generated next to the resource consumption indicator to remind the player to make a careful decision. This combination of a mistake-proof mechanism and dynamic price indicators not only ensures the smoothness of the interaction process but also forces players to make deeper strategic trade-offs between "saving gold" and "opening blind boxes for high returns."

[0081] Optionally, the resource content represents the specific attribute details of the second type of game resource, which includes at least the specific character identity, rarity level or equipment name, and is hidden before it is acquired.

[0082] Optionally, the resource content can be the underlying data and visual representation of the second type of game resource in the game mechanism, such as a chess piece with a specific name and star rating, or a piece of equipment with specific attribute bonuses. Considering that information asymmetry is an important design element of risky game theory in this solution, as a possible implementation, the above-mentioned resource content remains invisible until the second type of game resource is selected by the first game account and the virtual resource is deducted. In terms of interface presentation, the second type of game resource can be displayed as a uniform card back pattern or question mark icon, completely concealing the resource content. One purpose of this embodiment is to make the value of the second type of game resource fluctuate before acquisition by hiding the resource content, potentially yielding either a top-tier reward or a regular reward. When a valid selection command for the resource is detected and the virtual resource is exhausted, the system controls the graphical user interface to play a card-flipping animation or an opening animation, displaying the real resource content to the player and other players globally, thereby creating the surprise of opening a blind box and the tension of the game's revelation.

[0083] In step S140, when a selection instruction for the first type of game resource is detected, the target game resource corresponding to the selection instruction is assigned to the first game account without consuming the virtual resources of the first game account. Thus, by directly assigning the target game resource to the player without consuming virtual resources when a selection instruction for the first type of game resource is detected, a zero-cost way to obtain deterministic rewards is provided to the player, ensuring the supply of basic resources. This also enriches strategic choices in contrast to paid, unknown rewards. In one implementation, when a player faces multiple reward items displayed side-by-side during the draft phase, and the player clicks on one of the publicly displayed deterministic free rewards, the terminal detects the selection instruction, determines that the instruction corresponds to a free acquisition type, and then skips the virtual resource deduction process, directly assigning the corresponding piece or equipment to the player's preparation area or equipment inventory, completing the resource allocation.

[0084] Optionally, attributing the target game resource to the first game account may include adding the target game resource to the resource storage area or equipment configuration area corresponding to the first game account for use in subsequent game stages. Optionally, the specific implementation of attributing the target game resource to the first game account can be dynamically adapted according to the resource type. Considering that game resources in auto chess mainly include two categories: pieces and equipment, as one possible implementation, when the target game resource is a piece, the above attribution action can be specifically manifested as adding the piece's data object to the preparation queue corresponding to the first game account and updating the preparation queue's capacity occupancy status; as another implementation, when the target game resource is equipment, the attribution action can be manifested as storing the equipment in the first game account's equipment temporary storage area, or directly prompting the player to select to equip it to a specific piece. It should be noted that since the above attribution process targets the first type of game resource, the system directly skips the virtual resource balance verification and deduction steps when executing the attribution logic, thereby achieving zero-cost acquisition. This design not only simplifies the process of distributing free rewards and reduces the computational overhead on the server side, but also ensures that players can still steadily acquire basic combat power when resources are scarce, thus maintaining the balance of the game.

[0085] Optionally, after assigning the target game resource to the first game account, the graphical user interface can also provide corresponding visual feedback and status synchronization. Upon detecting a selection command, the above method can first send a resource lock request to the server. After receiving confirmation of successful assignment from the server, the assignment animation is then executed on the local interface. Specifically, the card corresponding to the target game resource can play an animation of flying towards the player's avatar or preparation area, and then disappear from the public draft area. Furthermore, for other game accounts participating in the game, their clients will also synchronously receive an update that the resource is occupied, thus graying out or hiding the target game resource to prevent subsequent players from making invalid selections. This status-synchronized assignment confirmation mechanism effectively ensures data consistency in a multi-player draft environment and improves the smoothness and accuracy of the interaction.

[0086] In step S150, when a selection instruction for the second type of game resource is detected, the control assigns the target game resource corresponding to the selection instruction to the first game account and consumes the virtual resources of the first game account. This avoids the simplistic strategy resulting from the zero-cost selection process in conventional mechanisms, making resource consumption a game-changer and enhancing the strategic depth of resource allocation and the risk-reward balance experience.

[0087] In one implementation, when a player clicks on a second-category game resource that is displayed as a hidden card back on the draft screen, a confirmation prompt pops up, indicating that 3 gold coins are required. After the player clicks confirm, the system deducts 3 gold coins, the card is flipped to reveal its specific piece content, and added to the player's lineup. Other players can also see the result.

[0088] Optionally, virtual resources can include various types, used in-game to perform consumable operations such as acquiring second-type game resources, thus expanding the strategic dimensions of resource allocation. Optionally, virtual resources can be in-game gold. Considering that players need to use gold to purchase pieces, upgrade population, or refresh the shop in auto chess gameplay, using gold as a consumable medium for acquiring second-type game resources can effectively enhance the strategic depth of resource management. In one specific approach, when a player is in the draft phase and decides to choose a second-type game resource, the system checks whether their current gold amount meets the consumable value corresponding to that draft position. If it does, a deduction is performed, and the corresponding unknown reward is distributed to the player's bench or equipment slot. This design makes gold no longer just used for regular lineup building, but a game chip that can be exchanged for potentially high returns. Players need to weigh the balance between preserving gold for later rounds and immediate consumables for immediate combat power, thus enriching the game's decision-making dimensions.

[0089] Optionally, virtual resources are not limited to gold coins; they can also be diamonds, arena points, honor points, or other types of in-game tokens. This disclosure does not impose any restrictions on these. It should be noted that the amount of virtual resources consumed is not only related to the current selection order but can also be linked to the expected potential rarity of the second type of game resource. To prevent disadvantaged players from being unable to participate due to resource scarcity, the system can set a minimum consumption threshold or a reduction mechanism for players with low health. For example, for a first-move player with extremely low health, the consumption amount could be only 1 unit, while for a second-move player with higher health, the consumption amount may increase linearly or exponentially. This dynamic pricing strategy ensures the operation of the resource consumption mechanism while also balancing the game situation, preventing advantageous players from further expanding their lead through unlimited resource investment, thereby maintaining the overall competitive fairness of the match.

[0090] In an optional implementation, the method further includes: determining the virtual resources required to execute a selection command for the first game account based on the second type of game resources, wherein the quantity of virtual resources consumed is associated with the selection order corresponding to the first game account, and the selection command is triggered based on the selection order. By associating the quantity of the second type of game resources consumed with the selection order, players with an early disadvantage can acquire high-risk, high-reward resources at a lower cost, while players with a later advantage must pay a higher price. This introduces a dynamic game mechanism of risk and reward at the resource allocation level, enhancing the strategic depth.

[0091] For example, in the selection order, the first player needs to consume 1 gold coin to select the second type of game resource, the second player needs to consume 2 gold coins, and so on, up to the eighth player who needs to consume 8 gold coins. This pricing method, which increases with the player's position, provides a cheap opportunity for disadvantaged players to play. Optionally, the "consumption quantity" refers to the specific amount of virtual resources deducted to acquire the second type of game resource, and its value changes dynamically according to the selection order.

[0092] Optionally, the consumption quantity and selection order can exhibit a linear positive correlation. Specifically, when the selection order corresponding to the first game account is the kth order, the system can directly determine the consumption quantity as k units of virtual resources. For example, if the virtual resource is gold coins, the player in the first order only needs to pay 1 gold coin to unlock the unknown reward, while the player in the eighth order needs to pay 8 gold coins. This linearly increasing pricing strategy not only has a simple calculation logic, is easy for players to quickly understand and predict, but also accurately compensates disadvantaged players at the numerical level. It should be noted that the above linear relationship is only one example. In actual implementation, different increment steps can be set according to specific numerical balance needs, such as adding 3 gold coins every two orders. This disclosure does not intend to limit the specific slope of the increment curve.

[0093] Alternatively, besides the linear increasing method mentioned above, the consumption quantity can also adopt a non-linear correlation pattern such as a stepped or exponential increasing pattern. Considering the differences in resource reserves and the urgency of the situation among players in different priority intervals, as a possible implementation method, the system can divide multiple priorities into several stepped intervals. For example, the consumption quantity for priorities 1 to 3 is fixed at 2 gold coins, the consumption quantity for priorities 4 to 6 is fixed at 5 gold coins, and the consumption quantity for priorities 7 to 8 is fixed at 10 gold coins. Through this stepped price curve, the excessive consumption behavior of advantageous players after hoarding gold coins can be effectively controlled in the mid-game, preventing later players from easily monopolizing high-value unknown resources through high-cost spending. Similarly, a multiplier increasing method can also be adopted, such as the consumption quantity of the next priority being 1.5 times that of the previous priority and rounded down, thereby further widening the cost gap between the first and second players.

[0094] Optionally, the logic for determining the consumption quantity can not only rely solely on the selection order, but can also combine multiple dimensions for joint calculation, including the current round number of the game, the preset base value of the second type of game resources, or the current resource holdings of the first game account. Specifically, the system can first determine a base consumption coefficient based on the selection order, then assign a time decay or gain weight based on the current round number, and finally multiply the base consumption coefficient by the weight to obtain the actual consumption quantity. For example, in the later stages of the game, during the draft phase, since players have relatively abundant resources, the system can add an additional global fluctuation coefficient on top of the ranking base, further increasing the cost for later players. One objective of this embodiment is to make the dynamic changes in the consumption quantity more closely match the economic curve of the actual game through multi-dimensional parameter correlation. On the one hand, this can prevent strategy failure caused by numerical inflation, and on the other hand, it can increase the complexity of resource management and the depth of strategy.

[0095] In an optional implementation, the amount of virtual resources consumed increases with the order in which game accounts are selected. This increases the amount of virtual resources consumed with the order of selection, allowing players who go first at a disadvantage to obtain unknown rewards at a lower cost, while players who go later at a higher cost. This effectively compensates disadvantaged players numerically and suppresses the snowballing speed of the advantaged players, thus increasing the strategic depth of resource allocation.

[0096] In an optional implementation, the method further includes: displaying the resource content of the target game resource when the target game resource is a second type of game resource and the target game resource is controlled to be assigned to the first game account. In this way, by displaying the specific content of the second type of game resource only after it has been assigned to a player, a dynamic transition from hidden to public information is achieved. This maintains the tension of the information asymmetry game during the selection phase while ensuring that all players are aware of the result after the selection, thus enhancing the fairness of the game and the social interaction experience.

[0097] In one implementation, when the player in the third position pays 3 gold coins to select a paid unknown reward, the card back of the reward is immediately flipped over, revealing its actual content in the graphical user interface—for example, a "Fire Mage" chess piece card with an "Epic" rarity. This content is also simultaneously displayed to other players participating in the game, allowing all players to know the specific resource ultimately obtained from the paid unknown reward. Optionally, displaying the resource content of the target game resource may include visually presenting its specific resource information after the second type of game resource is acquired, for the current player and associated players to view.

[0098] Optionally, the display of the target game resource can be represented as a visual transformation process that changes the second type of game resource from a hidden state to a visible state. Specifically, before a player acquires the second type of game resource through a selection command, the specific content of the resource (such as the piece name, rarity level, equipment type, etc.) is hidden, with only the resource type identifier and resource consumption identifier displayed. When it is detected that the resource belongs to the first game account, the system triggers the content display logic, flipping the hidden card back to the front, or popping up a separate display window on the interface to fully present the specific attribute information of the resource. It should be noted that this display is not only for the player corresponding to the first game account that acquired the resource, but can also be broadcast simultaneously to players corresponding to other game accounts participating in the same game, so that all players can know the final result of the paid unknown reward. This design makes information asymmetry a tradable bargaining chip during the selection phase, and transforms it into public information after the selection is completed, avoiding the frustration of a blind box mechanism that relies entirely on luck, and also providing information for strategic adjustments in subsequent rounds.

[0099] Optionally, the display of the target game resource's content can take various forms. As one possible implementation, detailed information about the target game resource can be displayed in a full-screen pop-up window within the graphical user interface, accompanied by animation effects of a preset duration (such as card flipping effects, light particle effects, etc.) to enhance the visual impact upon acquisition. Alternatively, the second type of game resource can be directly switched from a card-back state to a front-facing state at the corresponding location on the selection interface, while keeping the positions of other unselected resources unchanged, allowing players to intuitively compare the selection status of each resource on the same interface. Furthermore, the display process can include resource attribute descriptions, such as skill descriptions of pieces, buff effects of equipment, etc., to help players quickly assess the strategic value of the resource. It should be understood that the above display methods can be used individually or in combination, and this disclosure does not limit this. In addition, the timing of the display can be flexibly configured, for example, triggering the display immediately after resource ownership is determined, or centrally displaying the content of all selected resources at a unified node at the end of the current selection round.

[0100] An information processing apparatus according to one embodiment of the present disclosure, such as Figure 3 As shown, the device may include: The first display module 301 is used to display the first game screen corresponding to the first game account in the first game stage through a graphical user interface; The first control module 302 is used to control the jump from the first game stage to the second game stage when the game meets the preset stage conditions, and to display the second game screen corresponding to the first game account in the second game stage through the graphical user interface. The first game stage is different from the second game stage. The second game stage is configured to determine the target game resource from the game resources provided by the second game stage in response to the selection instructions of multiple game accounts participating in the game. The second display module 303 is used to display a first type of game resource in a second game screen using a first display method and to display a second type of game resource using a second display method; the first display method is configured to display the first type of resource information of the first type of game resource; the second display method is configured to display the second type of resource information of the second type of game resource. The second control module 304 is used to, when a selection instruction for the first type of game resource is detected, control the allocation of the target game resource corresponding to the selection instruction to the first game account without consuming the virtual resources of the first game account. The second control module 304 is also used to, when a selection instruction for the second type of game resource is detected, control the allocation of the target game resource corresponding to the selection instruction to the first game account and consume the virtual resources of the first game account.

[0101] In this way, by providing resource options with different information visibility and resource consumption mechanisms on the same interface, the interaction dimensions are enriched and the flexibility of resource allocation is improved. At the same time, the differentiated display and consumption mechanisms help guide players to make effective decisions, reduce invalid interaction requests processed by the terminal during the resource selection phase, and reduce data processing pressure.

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

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

[0104] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure.

[0105] The following is a detailed reference. Figure 4 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.

[0106] 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 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

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

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

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

[0110] 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: The first game screen corresponding to the first game account in the first game stage is displayed through a graphical user interface; When the game meets the preset stage conditions, the control jumps from the first game stage to the second game stage, and the graphical user interface displays the second game screen corresponding to the first game account in the second game stage. The first game stage is different from the second game stage. The second game stage is configured to determine the target game resource from the game resources provided by the second game stage in response to the selection command of multiple game accounts participating in the game. In the second game screen, a first type of game resource is displayed using a first display method, and a second type of game resource is displayed using a second display method; the first display method is configured to display the first type of resource information of the first type of game resource; the second display method is configured to display the second type of resource information of the second type of game resource. When a selection instruction for the first type of game resource is detected, the system controls the allocation of the target game resource corresponding to the selection instruction to the first game account without consuming the virtual resources of the first game account. When a selection instruction for the second type of game resource is detected, the control assigns the target game resource corresponding to the selection instruction to the first game account and consumes the virtual resources of the first game account.

2. The method according to claim 1, characterized in that, The step of displaying the first type of game resources in the second game screen using a first display method and displaying the second type of game resources using a second display method includes: A selection interface is displayed in the second game screen. In the selection interface, a first type of game resources are displayed using a first display method, and a second type of game resources are displayed using a second display method.

3. The method according to claim 1, characterized in that, The second game screen displays at least a portion of the virtual scene; the step of displaying the first type of game resources in the second game screen using a first display method and displaying the second type of game resources using a second display method includes: In the virtual scene, a first type of game resources are displayed using a first display method, and a second type of game resources are displayed using a second display method.

4. The method according to claim 1, characterized in that, The method further includes: The virtual resources required for the selection instruction of the first game account to be consumed by the second type of game resources are determined, wherein the amount of virtual resources consumed is related to the selection order corresponding to the first game account, and the selection instruction is triggered based on the selection order.

5. The method according to claim 4, characterized in that, The amount of virtual resources consumed increases as the game account selection order increases.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the attribute parameter values ​​corresponding to each of the multiple game accounts corresponding to the game match, wherein the attribute parameter values ​​represent the current state parameters of the corresponding game account in the game match; The multiple game accounts are sorted according to the attribute parameter values ​​to determine the selection order.

7. The method according to claim 6, characterized in that, The step of obtaining the attribute parameter values ​​corresponding to each of the multiple game accounts associated with the game match includes: Obtain the health parameter values ​​of multiple game accounts corresponding to the game match as the attribute parameter values; The step of sorting the multiple game accounts according to the attribute parameter values ​​to determine the selection order includes: The multiple game accounts are sorted in ascending order of their health parameter values ​​to determine the selection order, wherein game accounts with lower health parameter values ​​are selected earlier in the selection order.

8. The method according to claim 1, characterized in that, The step of displaying the second type of game resources in the second game screen using a second display method includes: The resource type identifier and resource consumption identifier of the second type of game resource are displayed in the second game screen, while the resource content of the second type of game resource is hidden. The resource consumption identifier is used to identify the virtual resources that the first game account needs to consume to obtain the second type of game resource.

9. The method according to claim 1, characterized in that, The method further includes: If the target game resource is the second type of game resource and the control assigns the target game resource to the first game account, the resource content of the target game resource is displayed.

10. 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 9.

Images